[cpp-threads] SC on PPC (was Re: Increment/decrement operators on atomics package)

[Alexander Terekhov]

On 5/1/07, Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote:
[...]
> > >> But isync is not really a bidirectional barrier. It's just a way to
> > >> achieve .acq using fake or real dependencies.
> > >
> > >It can indeed be used to achieve ,acq in some cases, but as near as I
> > >can tell its original intent was to handle the case where the subsequent
> > >instruction stream depended on prior operations, for example, after
> > >mapping in a module but before executing it.
> >
> > I meant its effect on memory ordering.
>
> Fair enough.  But you -did- say "It's just a way to achieve .acq".
>
> > http://www.ussg.iu.edu/hypermail/linux/kernel/0603.1/0379.html
>
> Yep.  But this URL says that isync -can- be used to create a type
> of memory barrier.  It doesn't imply that isync's use is restricted
> to this use case.

It can be used for context synchronization stuff as well but hardware
can be smart enough to maintain a flag telling whether context sync is
actually needed and optimize isync in this respect to make it less
expensive for common usage as one-way "import barrier" in conjunction
with dependencies... i.e. that regarding memory ordering, it's just a
way to achieve .acq using fake or real dependencies.

[...]
>        T1:
>        x = 1;
>        eieio();
>        y = 1;
>
>        T2:
>        r1 = y (=>1)
>        sync();
>        r2 = x (must => 1)
>
> T2's sync does not have a store in its B-set, so B-cumulativity does not
> apply,

With only two players cumulativity doesn't come into play at all, I agree. And

T2: if (y == 1) isync(), assert(x == 1);

is probably much better. ;-)

regards,
alexander.