On Sunday 06 January 2013, Daniel Lescohier wrote: > I'm not sure we should include memory barriers inside the > apr_atomic_read32 and apr_atomic_set32 functions, because you > don't necessarily need a full memory barrier on each read or set. > Instead, perhaps we should add three functions to APR: > > 1. apr_atomic_rmb(): read memory barrier. > 2. apr_atomic_wmb(): write memory barrier. > 3. apr_atomic_mb(): full memory barrier.
Introducing new functions into APR may not be the perfect solution for this problems because there will be some reluctance to bump the minimum apr version required for httpd, especially for 2.2.x. Also, writing such functions for all supported architectures and compilers is quite some effort. In any case, if we introduce new atomic and/or barrier functions, I would be in favor of something that aligns with a subset of the C11 atomic API. An alternative that would work without changes to apr would be per- thread caches for cached_explode(). This would at least not be less efficient than the current code is with mpm-prefork. Or one could do that only if compiled with an apr that does not have the new barrier functions...
