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

[Paul E. McKenney]

On Tue, May 01, 2007 at 01:04:04AM +0200, Alexander Terekhov wrote:
> On 4/30/07, Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote:
> [...]
> >> >> 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.
> >>
> >> 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.

> [...]
> >> IOW with an empty "B-cumulativity", whatever you add to the A set
> >> (calling it "A-cumulativity") is not constrained at all with respect
> >> to other processors.
> >
> >By "empty B-cumulativity", do you mean that there is no store following
> >the barrier providing the cumulativity,
> 
> Yes.

OK.  Then saying "is not constrained at all" is going too far.  It is true
that if there are no stores following a memory barrier, B-cumulativity
cannot come into the picture, but there are other constraints.  For example:

	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, but there are still constraints on the relationships between T2's
loads and T2's stores.

> >or do you mean that there is no load referencing that store,
> 
> Same effect. Let's optimize it out, then.

If we can prove that there are no such loads at compile time, and we
know that it is not an MMIO reference, then yes, why not optimize it out?

						Thanx, Paul