Re: Uses for memory barriers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux