On 04/05/17 15:06, Toebs Douglass wrote: > 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 :-) That's an implementation detail: all we know is the visible ordering. > 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. Either works. The mappings from C++ atomics to processors are here: https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html > 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. That depends on your machine. On mine (ARMv8) a seq.cst store uses stlr. Andrew.
