optimizations and CPU reordering)(2) all memory accesses originally after the [sequentially\_consistent]{} one (in program order) will happen after the fence (after compiler optimizations and CPU reordering)
  ------------------------ ------------------ -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

  : Memory Order and Constraints for Compilers and CPUs[]{data-label="MMcompcpu"}

\
 \

It is important to note, that the semantics of the models above have to be enforced by the compiler (for programs which are DRF). I.e., the compiler “knows” the relaxed memory model of the hardware and inserts memory fences in the machine-code such that the memory model of the high-level programming language is enforced. Compiler optimizations must ensure that reordering of operations is performed in such a way that the semantics of the memory model are not violated. The same applies to CPUs, i.e., reordering of instructions is done with respect to the CPU’s relaxed hardware memory model, constrained by the ordering semantics of fences inserted by the compiler. The constraints enforced by the memory model are summarized in Table \[MMcompcpu\].

[Synchronization primitives]{}\[aspects\]

[[Synchronized]{} Variables\[sec:sync:var\]]{} [Synchronized]{} variables can be used as atomic variables in Ada 2012, the only exception being that they are declared inside the lexical scope (data part) of a [concurrent]{} object. In this case aspects and attributes 