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. > and I suspect those functions are only issuing memory barriers? And loads/stores, of course. > they do not use atomic operations themselves. Umm, what? How can an atomic operation not use an atomic operation? > 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. It's only about ordering. However, you can guarantee that if some processor writes to a (SC) atomic variable, then that processor will have observed all writes before then in the total order. > 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 :-) See above. If you take part in the total order by doing an atomic store, all of everyone else's atomic writes are visible to you before that store. This must be true, by the definition of total order. Andrew.
