apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <brian.p...@cnet.com>
Subject apr_atomic_t: can we change it to apr_uint32_t?
Date Tue, 31 Dec 2002 01:32:26 GMT
While trying to replace some mutex-based synchronization
code in the httpd with atomic spinloops, I ran into a
problem in the APR atomic API:

With the API split between apr_uint32_t for the CAS
operation and apr_atomic for most of the get/set
operations, it's impossible to use write portable apps
that need to use both CAS and read/write on the same

I think we could fix this problem by forcing apr_atomic_t
to be defined as apr_uint32_t on all platforms.  This would
work fine for the default (mutex-based) atomic implementation,
as well as most platforms for which we currently have custom
code (Linux/x86, Solaris, etc).  The only two I'm not sure
of are:

  Netware:  apr_atomic_t is defined as unsigned long.
  Does Netware run on any architectures where an
  unsigned long isn't 32 bits?

  OS/390:  apr_atomic_t is defined as cs_t.  Can someone
  familiar with that environment please comment on whether
  it would be safe to use a uint32 as the atomic type?


View raw message