This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Memory model release/acquire mode interactions of relaxed atomic operations
On 04/05/17 15:08, Jonathan Wakely wrote:
> On 4 May 2017 at 14:04, Toebs Douglass wrote:
>> As far as I know (which is *not* very far *at all*) no current processor
>> offers a mechanism such that it can be told it needs to flush its store
>> buffers - the only way in which I think this can be made to occur is by
>> issuing an atomic store, since this forces a store to memory, which in
>> turn will require earlier stores barriers to be honoured, and so earlier
>> stores to complete.
>
> That seems to imply there are non-atomic stores to atomic variables,
> the standards don't allow such a thing.
I do not mean to say that this is so. It is (as far as I know) not so.
I may be wrong, but I think atomic stores bypass store buffers, so when
you issue an LL/SC or LOCK, you really do get a completed store (which
no one else necessarily has seen, of course :-)
However, if writes to atomic variables actually are just normal stores
followed by a store barrier, *then* you have the "reasonable period" of
delay. This gets back to my uncertainty over the internal
implementation of these atomic load/stores, and where I am not certain
they are using LL/SC, LOCK, etc, but just using memory barriers.
I've just had a bit of an online search, as best I could, through the
GCC source code. It looks like expand_atomic_store() does use an atomic
exchange or atomic CAS.