Memory model release/acquire mode interactions of relaxed atomic operations

[Andrew Haley]

On 04/05/17 16:52, Toebs Douglass wrote:
> On 04/05/17 16:21, Andrew Haley wrote:
>> Either works.  The mappings from C++ atomics to processors are here:
>>
>> https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html
> 
> Ah, that is interesting, and makes a lot of sense.
> 
> For SC, it's atomic.  For everything else, not - which means for
> everything else, although ordering is of course guaranteed, visibility
> is not, and we rely on the processor doing something "in a reasonable
> time" (which might for example be long enough that things break).

Umm, what?  All access modes are atomic.

>>> 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.
> 
> I'm surprised.  I would expect that to be able to fail (because of the
> "reasonable time").  I don't know much about ARM though (or about Intel,
> for that matter :-)

Eventually the processor will be pre-empted for some reason or the
cache line which contains the store will be flushed because of another
access, but it could be a long wait.  I've seen delays of thousands
of instructions, but it could be longer.

Andrew.