Re: [boost] [thread] Some thoughts about "atomic"

From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-12-01 12:22:10

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.