<p>I am not sure if I understand your question correctly, but I can try to provide some details about the C++ memory model.</p>

<p>The default memory order of all operations on C++ atomics is <em>sequential consistent</em>. Formally this means that there is a single total order (<em>S</em>) of all sequentially consistent operations (regardless by which thread the are executed). So if a thread <em>A</em> performs a seq-cst-store on some variable <em>X</em>, and thread <em>B</em> performs a seq-cst-load on <em>X</em>, and the store is ordered before the load in <em>S</em>, then it is guaranteed that <em>B</em> sees the value stored by <em>A</em> (or some newer value).</p>

<p>However, once you use more relaxed memory orderings for your operations you lose this guarantee, because these more relaxed atomic operations are generally <em>unordered</em>. However, you can introduce orderings by means of a <em>happens-before relation</em> between certain operations. E.g., an acquire-load that sees the value written by a release-store <em>synchronizes-with</em> that store, thereby establishing a happens-before relation.</p>

<p>The C++ memory model is certainly one of the more complex aspects of the language and can not be thoroughly explained in a simple answer. For more details I recommend further reading like this paper which I have co-authored: <a href="https://arxiv.org/abs/1803.04432" rel="nofollow noreferrer">Memory Models for C/C++ Programmers</a><br>
It not only covers the C++ memory model, but also gives a brief overview over the memory models of x86 and ARM/Power, trying to explain why it is even <em>necessary</em> to have a memory model in the first place.</p>
Are thread shared variables directly accessed?
<p>Reading about the C++ memory model and ordering directives raised me a questions - in the same process when a thread-shared atomic variable (eg. atomic) is set in one thread - and the ordering of the load is after the store - is it possible that the load is not seeing the stored value?</p>

<p>Rephrased - is ordering a guarantee that a set atomic value is loaded as is, or there is a CPU/cache/etc abstraction that could still provide an older value?</p>

<p>The reason of the questions is some literature talks about synchronization (apart from ordering) and the language they use is "as seen by another thread" - which makes me wonder if load is not a direct access to the memory location (which would not need any other synchronization than ordering).</p>