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.
