Roland Schwarz wrote:
Peter Dimov wrote:
#LoadLoad means that loads that precede the barrier cannot be reordered with loads that follow the barrier.
I.e. a instruction sequence
load(A) #LoadLoad load(B)
cannot be executed by the processor as load(B) load(A)
but nothing prevents the processor from executing the sequence load(A) #LoadLoad store(B)
as store(B) load(A)
right?
Right.
Then load(A) load(B) #LoadLoad | #LoadStore store(C)
cannot be reordered as load(B) store(C) load(A)
Yes?
Yes.
But in the acquire/release world load(A) load(B).acquire store(C)
can be reordered as load(B) store(C) load(A)
or I am wrong in this assumption?
Right again.
If I am not wrong, In which respect is your example then an emulation of acquire semantics. If I a wrong, what I am missing?
Nothing; it's an emulation, not an exact mapping. It achieves results that are valid executions under an acquire/release model. The emulation is stricter since it doesn't allow all reorderings that are possible in an acquire/release model. But it's a way to implement acquire/release on hardware that provides bidirectional barriers. When the (physical or conceptual) hardware only offers the more limited #LoadLoad (read barrier), #StoreStore (write barrier) and full barrier subset, the acquire/release emulation is even stricter, since it needs to use the full barriers.