On 04/05/17 13:44, Jonathan Wakely wrote: > On 4 May 2017 at 13:40, Andrew Haley wrote: >> On 04/05/17 13:11, Toebs Douglass wrote: >>> 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? >> >> It works for all accesses: atomicity is part of the type. > > Although there are also relaxed atomic operations (on atomic types) > which are not synchronization operations. Not all atomic operations > provide sequential consistency. I'm sure I said: C++ atomic types are sequentially consistent by default. Everything I said is about SC atomic accesses and does not apply to anything else. Andrew.
