Re: Memory model release/acquire mode interactions of relaxed atomic operations

[Dietmar Schindler <gnuspam at vodafonemail dot de>]

> Toebs Douglass <toby@winterflaw.net> wrote on 3. Mai 2017 um 08:55:
> 
> On 03/05/17 08:30, Dietmar Schindler wrote:
> > The GCC Wiki says this about the memory model synchronization mode
> > [Acquire/Release][1]:
> > 
> > > To make matters a bit more complex, the interactions of non-atomic
> > > variables are still the same. Any store before an atomic operation
> > > must be seen in other threads that synchronize. For example:
> > > 
> > > |  -Thread 1-
> > > |  y = 20;
> > > |  x.store (10, memory_order_release);
> > > | 
> > > |  -Thread 2-
> > > |  if (x.load(memory_order_acquire) == 10)
> > > |     assert (y == 20);
> > > 
> > > Since 'y' is not an atomic variable, the store to 'y' _happens-before_
> > > the store to 'x', so the assert cannot fail in this case. The
> > > optimizers must still limit the operations performed on shared memory
> > > variables around atomic operations.
> > 
> > Now, what if I make 'y' an atomic variable (without imposing
> > _happens-before_ restrictions)?
> > 
> > |   -Thread 1-
> > |   y.store (20, memory_order_relaxed);
> > |   x.store (10, memory_order_release);
> > | 
> > |   -Thread 2-
> > |   if (x.load(memory_order_acquire) == 10)
> > |      assert (y.load (memory_order_relaxed) == 20);
> > 
> > Can the assert fail? Are there fewer requirements for atomic variables
> > than for non-atomic variables? Or is the Wiki's restriction to
> > non-atomic variables gratuitous and misleading here?
> 
> I may be completely wrong, I'm know very little about GCC, but I think
> the fact a variable is atomic actually makes no difference at all, as
> far as memory barriers are concerned.
> 
> It is and only is the memory barrier which matters, when it comes to
> whether or not changes are propagated.

Thanks for replying! I would think so, too.

> Also, although I may be COMPLETELY wrong, I *think* the "atomic" store
> is actually just a store barrier issued after the write.  If so, this to
> my mind is completely mis-named and by that utterly misleading, for a
> memory barrier imposes only *ordering* constraints.  It imposes
> *nothing* which actually causes stores to *complete*.
> 
> You can store as many times as you like, and write store barriers as
> often as you like; there is no guarantee any other core will ever see
> those stores.

I take that by _the "atomic" store_ you mean the

 x.store (10, memory_order_release)

in the Wiki's example. I also struggled with the meaning of "atomic" in
the context of memory models, and found this description in "Shared Memory
Consistency Models: A Tutorial"
[http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-95-7.pdf], section 4:

> … (2) maintaining a single sequential order among operations from all
> processors. The latter aspect makes it appear as if a memory operation
> executes atomically or instantaneously with respect to other memory
> operations.
> 
> … The atomicity aspect of sequential consistency allows us to assume
> the effect of P1’s write is seen by the entire system at the same time.

Concerning the meaning of "atomic" in the context of C++, I found this in
a presentation "C++ 11 Memory Consistency Model"
[https://www.dcl.hpi.uni-potsdam.de/teaching/numasem/slides/NUMASem_C++11_Memory_consistency.pdf]:

> C++ 11 std::atomic Strictly enforces Sequential Consistency (default) by
> giving three guarantees:
> ■ Operations on std::atomic is atomic
> ■ No instruction reordering past std::atomic operations
> ■ No out-of-order execution of std::atomic operations

According to this, "std::atomic" with the default memory_order_seq_cst
imposes atomicity as well as ordering constraints.

But I may have divagated... back to my original question whether [https://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync#Acquire.2BAC8-Release]
baselessly excludes atomic variables from the cited part on
Acquire/Release. Where is the right place to ask for clarification or
improvement of the GCC Wiki?
-- 
Regards,
Dietmar Schindler