On 04/05/17 14:40, Andrew Haley wrote: > On 04/05/17 13:11, Toebs Douglass wrote: >> 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. Why do the load()/store() functions exist? Like this, from the OP; > if (x.load(memory_order_acquire) == 10) > assert (y == 20); Only to specify the memory model? But if you access the variable without the function, how would the compiler know what memory model you wanted to use? Also, you are then saying that seemingly-unadorned accesses, i.e. x = 1; Will cause the compiler to emit not just compiler barriers, but memory barriers? will the compiler in fact convert this into an atomic - in the LL/SC sense - operation? (I don't think this is so?) >> and I suspect those functions are only issuing memory barriers? > > And loads/stores, of course. Yups. >> they do not use atomic operations themselves. > > Umm, what? How can an atomic operation not use an atomic operation? Indeed so :-) This is what I was speaking about in the last email or two. I *think*, if I remember the GCC source code properly, that those load()/store() functions do not use atomic operations to load/store. They issue a load barrier and then a normal load, or issue a store and then a store barrier. They do *not* use (for example on Intel) LOCK, or LL/SC on ARM, etc. But I may be completely wrong. [snip total order] Yes.
