This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]