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

[Paul E. McKenney]

On Tue, May 01, 2007 at 11:20:20AM +0200, Alexander Terekhov wrote:
> 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.

Sort of.  With respect to subsequent stores, but not with respect to
subsequent loads.  I suspect that the context-synchronization stuff
was the original intent of isync, and that the memory-fence uses were
exploited by "evil software types", but again, this would pre-date my
time with IBM.

> [...]
> >       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. 

Yep.

> And
> 
> T2: if (y == 1) isync(), assert(x == 1);
> 
> is probably much better. ;-)

Or might be, if the subsequent statement was a store rather than a load.

As I understand it, isync() does nothing to prevent fetching from a
possibly-shared store buffer prior to the value being stored being
committed to the coherence region/fabric.  This situation would appear
to software as if the load of x had been reordered to precede the
isync().  So I believe that isync() can serve as a barrier with
respect to subsequent stores, but not with respect to subsequent
loads.

						Thanx, Paul