----- Original Message -----
> 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.
" on x86 … is enough" - would it harm x86 to add CPU barriers, or
do we want to have # define distinctions per arch?
> The functions are meant to include the barriers, according to the
> documentation in apr_atomic.h. So they should be fixed in apr.
>
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.ga...@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
