Subj : Re: Memory visibility and MS Interlocked instructions To : comp.programming.threads From : David Hopwood Date : Sat Sep 03 2005 04:15 pm Alexander Terekhov wrote: > Andy Glew of Intel (sorta) confirmed that x86 is classic PC. > > http://groups.google.de/group/comp.arch/msg/7200ec152c8cca0c Joe Seigh wrote: > The argument being presented in c.p.t. is that processor consistency > implies loads are in order, perhaps instigated by something Andy Glew > said about this here > http://groups.google.com/group/comp.arch/msg/96ec4a9fb75389a2 and in another post: | "loads in order" means #LoadLoad between loads. > AFAICT, this is not true for 3 or more processors. E.g. > > processor 1 stores into X > processor 2 see the store by 1 into X and stores into Y > > So the store into Y occurred after causal reasoning. Processor consistency is weaker than causal consistency, remember. > processor 3 loads from Y > processor 3 loads from X > > If loads were in order you could infer that if processor 3 > sees the new value of Y then it will see the new value of X. No. Start with X == Y == 0. P1: X := 1 P2: t := X; if (t == 1) Y := 1 P3: u := Y #LoadLoad // or acquire v := X {u == 1, v == 0} is possible. This is because P2 and P3 might see the stores to X and Y in a different order, because they are made by different processors. The #LoadLoad does not prevent this. > But the rules for processor consistency *clearly* state that > you will [not] necessarily see stores by different processors in > order. > > While there are still ordering constraints on the loads they > don't have to be strictly in order as Andy incorrectly infers. #LoadLoad between loads does not imply that you will necessarily see stores by different processors in a single global order. That is what you appear to be misunderstanding. In other words, there is nothing inconsistent between what Andy Glew's post said, and Alexander's assertion that load on x86 implies load.acq. -- David Hopwood .