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...