Memory model release/acquire mode interactions of relaxed atomic operations

[Jonathan Wakely]

On 4 May 2017 at 14:04, Toebs Douglass wrote:
> On 04/05/17 14:49, Jonathan Wakely wrote:
>> On 4 May 2017 at 13:11, Toebs Douglass wrote:
>>> 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.
>>
>> The C++ standard says:
>>
>>  An implementation should ensure that the last value (in modification
>> order) assigned by an atomic or
>> synchronization operation will become visible to all other threads in
>> a finite period of time.
>>
>> "Should" in ISO-speak is strong encouragement, but not a guarantee.
>> However, it is expected that on all but the most esoteric hardware
>> platforms it will be true.
>>
>> I don't see equivalent wording in the C11 standard though.
>
> 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.