On Saturday 05 January 2013, Daniel Lescohier wrote:
> apr_atomic_read32 is not implemented with a memory barrier. The
> implementation of apr_atomic_read32 in the APR code base is just a
> read from a pointer marked volatile. E.g., here is the
> atomic/unix/builtins.c implementation:
>
> APR_DECLARE(apr_uint32_t) apr_atomic_read32(volatile apr_uint32_t
> *mem)
> {
> return *mem;
> }
Sigh. I was too much focused on x86. There the compiler barrier caused
by the function call is enough. But you are right, on other
architectures these functions may also require cpu memory barriers.
The functions are meant to include the barriers, according to the
documentation in apr_atomic.h. So they should be fixed in apr.
