Memory model release/acquire mode interactions of relaxed atomic operations

[Toebs Douglass]

On 04/05/17 14:03, Andrew Haley wrote:
> On 04/05/17 12:46, Toebs Douglass wrote:
>> Inherently volatile, kindafing?  lay off the optimisation and caching in
>> registers, etc?
> 
> Much stronger than volatile.
> 
> C++ atomic types are sequentially consistent by default.  Every
> processor sees memory as if the atomic loads and stores of all the
> processors had been executed in some sequential order.  Every
> processor sees that same total ordering.  GCC will throw in as many
> barrier instructions as are necessary to make that work.

This being true if and only if the atomic load/store functions are used,
right?  and I suspect those functions are only issuing memory barriers?
they do not use atomic operations themselves.  If this is so, then all
this is true, but there is within this absolutely no guarantee than any
store on any core will ever *actually be seen* by any other core.  If
they *are* seen, *they will be in the correct order*, but there is no
guarantee they *will* be seen.

I expect you know this, Andrew, but I suspect it's not commonly
understood, so it's useful to state it explicitly for the record and
possibly for the OP.  Also, I may be wrong, and if I am, I'd like to
find out :-)