Re: Uses for memory barriers

[Nick Piggin]

Alan Stern wrote:
> On Mon, 18 Sep 2006, Paul E. McKenney wrote:
>
>
> > Restating (and renumbering) the principles, all assuming no other stores
> > than those mentioned, assuming no aliasing among variables, and assuming
> > that each store changes the value of the target variable:
> >
> > (P0):	Each CPU sees its own stores and loads as occurring in program
> > 	order.
> >
> > (P1):	If each CPU performs a series of stores to a single shared variable,
> > 	then the series of values obtained by the a given CPUs stores and
> > 	loads must be consistent with that obtained by each of the other
> > 	CPUs.  It may or may not be possible to deduce a single global
> > 	order from the full set of such series.
>
>
> Suppose three CPUs respectively write the values 1, 2, and 3 to a single 
> variable.  Are you saying that some CPU A might see the values 1,2 (in 
> that order), CPU B might see 2,3 (in that order), and CPU C might see 3,1 
> (in that order)?  Each CPU's view would be consistent with each of the 
> others but there would not be any global order.
>
> Somehow I don't think that's what you intended.  In general the actual
> situation is much messier, with some writes masking others for some CPUs 
> in such a way that whenever two CPUs both see the same two writes, they 
> see them in the same order.  Is that all you meant to say?

I don't think that need be the case if one of the CPUs that has written
the variable forwards the store to a subsequent load before it reaches
the cache coherency (I could be wrong here). So if that is the case, then
your above example would be correct.

But if I'm wrong there, I think Paul's statement holds even if all
stores to a single cacheline are always instantly coherent (and thus do
have some global ordering). Consider a variation on your example where
one CPU loads 1,2 and another loads 1,3. What's the order?

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/