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

[Toebs Douglass <toby at winterflaw dot net>]

On 04/05/17 11:08, Dietmar Schindler wrote:
> Toebs Douglass <toby@winterflaw.net> wrote on 3. Mai 2017 um 08:55:

>> 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)

Yes.

> 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:

Uh oh...

>> … (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.

That's completely wrong for memory barriers.  Memory barriers are not
atomic.  Indeed, atomic operations themselves are not atomic for other
threads unless you also perform additional appropriate and correct
memory barrier magic.

>> … 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

Yes.  I see this a lot.  It's all correct, and totally, utterly and
staggeringly misleading.  Everyone who comes to atomics/memory barriers
having used locks is, *always*, totally and *utterly* misled by this.
There are certain additional *negative* assertations which have to be
made, and they almost never are.  Paul McKenney is the only person I
trust on this stuff.

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

To quote Mr. Claus, "ho ho ho" :-)

The key point no one or almost no one ever mentions (often I suspect
because they don't actually understand how this stuff works - it's very
easy to end up with an internally consistent view of which is wrong) is
that store memory barriers *do not cause stores to complete*.  Once you
take that on board, the whole seemingly-sensible house of cards propped
up by the quotes above starts to fall over.

Atomic in this context, I believe, actually only really means the
absence of word-tearing; you won't write half your int and then get
swapped out and then write the other half later.

I wrote a couple of articles explaining the basics;

http://liblfds.org/mediawiki/index.php?title=Article:Memory_Barriers_%28part_1%29

http://liblfds.org/mediawiki/index.php?title=Article:Memory_Barriers_%28part_2%29

Hopefully what I've written is actually correct.  Any reviews gratefully
received, etc!