Subject: Re: [boost] [interprocess] atomic_write32 on GCC/x86/x68_64lacksmemory barrier
From: Peter Dimov (lists_at_[hidden])
Date: 2014-08-08 11:42:54
Ion Gaztañaga wrote:
> El 08/08/2014 14:58, Peter Dimov escribió:
>
> > The problem with the current implementation is not the lack of a
> > hardware memory barrier, but the lack of a compiler memory barrier. On
> > GCC, it's __asm__ __volatile__ ( "" ::: "memory" ). For release
> > semantics, it ought to go before the store.
>
> Thanks. That might be the case in many other platforms provided by users
> (AIX, OSF on Alpha) where the atomic write is implemented without any
> barrier.
On POWER/PPC and Alpha, you need an actual hardware memory barrier there for
acquire/release semantics. You do have __MB() on Alpha. The PPC code has
none, so unless the compiler inserts those automatically on volatile
reads/writes, the code doesn't seem correct. (The x86 code is also missing
compiler barriers on load.)
But you don't document the memory ordering that your read/write primitives
guarantee, so it's hard to say whether they are correct or not. As written,
they are "relaxed".