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 object. 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? Thanks, Brian
