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

[Paul E. McKenney]

On Mon, Apr 30, 2007 at 09:09:12PM +0200, Alexander Terekhov wrote:
> On 4/30/07, Raul Silvera <rauls at ca.ibm.com> wrote:
> >
> >Alexander Terekhov wrote on 04/30/2007 08:10:19 AM:
> >
> >> How does cumulativity help in the IRIW case?
> >>
> >> P1: x = 1;
> >> P2: y = 1;
> >> P3: r1 = x; r2 = y;
> >> P4: r3 = y; r4 = x;
> >>
> >
> >The short version of this is that cumulativity on a hwsync between the two
> >loads on P3 would cause a StoreLoad ordering between P1's store to x
> >and P3's load of y.
> 
> This is rather intriguing because unless I'm just missing something,
> cumulativity is defined the same for all barriers including
> lwsync/eieio and it comes into play when *P3* makes a post-barrier
> store which is observed by another processor.

Not for isync or for ordering based on dependencies, however.

B-cumulativity does indeed cover the case where a post-barrier store
is observed by another processor.  In this case, subsequent operations
on this other processor will observe all applicable pre-barrier
operations.  Of course, "subsequent" must be enforced, and in the
case of "lwsync", a pair consisting of a pre-barrier store and a
post-barrier load is not "applicable".

A-cumulativity covers the case where a pre-barrier operation
observes an operation by some other CPU, and forces post-barrier
operations to also observe that other CPU's operation.

As I understand it, of course!!!  In both cases, see Section 1.7.1
for the official wording.

Also, as I understand it, earlier -implementations- of POWER enforced
cumulativity even though the architecture did not require them to do so.
However, this was before my time at IBM, so please take my understanding
with a grain of salt.

> >Do the same for P4, plus some wild hand-waving, and you get to forbid the
> >disallowed IRIW outcome.
> 
> That's a lot of hand-waving, I'm afraid. ;-)

;-)

						Thanx, Paul