<p>I know that when it comes to memory orderings, people usually try to argue if and how operations can be reorder, but in my opinion this is the wrong approach! The C++ standard does not state how instructions can be reordered, but instead defines the <em>happens-before relation</em>, which itself is based on the sequenced-before, synchronize-with and inter-thread-happens-before relations.</p>

<p>An acquire-load that reads the value from a store-release <em>sychronizes-with</em> that acquire load, therefore establishing a happens-before relation. Due to the transitivity of the happens-before relation, operations that are "sequenced-before" the store-release, also "happen-before" the acquire-load. Any arguments about the correctness of an implementation using atomics should always rely on the happens-before relation. <strong><em>If and how instructions can be reordered is merely a result of applying the rules for the happens-before relation.</em></strong></p>

<p>For a more detailed explanation of the C++ memory model you can take a look at <a href="https://arxiv.org/abs/1803.04432" rel="nofollow noreferrer">Memory Models for C/C++ Programmers</a>.</p>
std::memory_order and instruction order, clarification
<p>This is a follow up question to <a href="https://stackoverflow.com/questions/59626494/understanding-memory-order-acquire-and-memory-order-release-in-c11/59629166#59629166">this one</a>.</p>

<p>I want to figure exactly the meaning of instruction ordering, and how it is affected by the <code>std::memory_order_acquire</code>, <code>std::memory_order_release</code> etc...</p>

<p>In the question I linked there's some detail already provided, but I felt like the provided answer isn't really about the order (which was more what was I looking for) but rather motivating a bit why this is necessary etc.</p>

<p>I'll quote the same example which I'll use as reference</p>

<pre><code>#include &lt;thread&gt;
#include &lt;atomic&gt;
#include &lt;cassert&gt;
#include &lt;string&gt;

std::atomic&lt;std::string*&gt; ptr;
int data;

void producer()
{
    std::string* p  = new std::string("Hello");
    data = 42;
    ptr.store(p, std::memory_order_release);
}

void consumer()
{
    std::string* p2;
    while (!(p2 = ptr.load(std::memory_order_acquire)))
        ;
    assert(*p2 == "Hello"); // never fires
    assert(data == 42); // never fires
}

int main()
{
    std::thread t1(producer);
    std::thread t2(consumer);
    t1.join(); t2.join();
}
</code></pre>

<p>In a nutshell I want to figure what exactly happens with the instruction order at both line</p>

<pre><code>ptr.store(p, std::memory_order_release);
</code></pre>

<p>and</p>

<pre><code>while (!(p2 = ptr.load(std::memory_order_acquire)))
</code></pre>

<p>Focusing on the first according to the documentation</p>

<blockquote>
  <p>... no reads or writes in the current thread can be reordered after this store ...</p>
</blockquote>

<p>I've been watching few talks to understand this ordering issue, I understand why it is important now. The thing I cannot quite figure yet how the compiler translates the order specification, I think also the example given by the documentation isn't particularly useful as well because after the store operation in the thread running <code>producer</code> there's no other instruction, hence nothing would be re-ordered anyway. However is also possible I'm missunderstanding, is it possible they mean that the equivalent assembly of</p>

<pre><code>std::string* p  = new std::string("Hello");
data = 42;
ptr.store(p, std::memory_order_release);
</code></pre>

<p>will be such that the first two lines translated will never be moved after the atomic store?
Likewise in the thread running producer is it possible that none of the asserts (or the equivalent assembly) will ever be moved before the atomic load? Suppose I had a third instruction after the store what would happen to those instruction instead which would be already after the atomic load?</p>

<p>I've also tried to compile such code to save the intermediate assembly code with the <code>-S</code> flag, but it's quite large and I can't really figure.</p>

<p>Again, to clarify, this question is about how the ordering, is not about why these mechanism are useful or necessary.</p>