On Wed, Oct 21, 2015 at 09:36:44PM +0200, Peter Zijlstra wrote:

On Wed, Oct 21, 2015 at 12:29:23PM -0700, Paul E. McKenney wrote:

quoted

On Wed, Oct 21, 2015 at 10:24:52AM +0200, Peter Zijlstra wrote:

quoted

On Tue, Oct 20, 2015 at 04:34:51PM -0700, Paul E. McKenney wrote:

quoted

There is also the question of whether the barrier forces ordering
of unrelated stores, everything initially zero and all accesses
READ_ONCE() or WRITE_ONCE():

	P0		P1		P2		P3
	X = 1;		Y = 1;		r1 = X;		r3 = Y;
					some_barrier();	some_barrier();
					r2 = Y;		r4 = X;

P2's and P3's ordering could be globally visible without requiring
P0's and P1's independent stores to be ordered, for example, if you
used smp_rmb() for some_barrier().  In contrast, if we used smp_mb()
for barrier, everyone would agree on the order of P0's and P0's stores.

Oh!?

Behold sequential consistency, worshipped fervently by a surprisingly
large number of people!  Something about legacy proof methods, as near
as I can tell.  ;-)

But how can smp_mb() guarantee anything about P[01]? There is but the
single store, which can race against P[23] arbitrarily. There is nothing
to order.

Indeed, if your barrier is only acting locally, there is no way that
you can order the two stores.  However, some barriers act non-locally,
and this non-local action can order the stores.  This non-locality is
"cumulativity" in the PowerPC docs.

And x86 can also order P0's and P1's stores, courtesy of the "T" in "TSO".

Maybe I'm confused again..

They say that confusion is the most productive frame of mind...

							Thanx, Paul