Subj : Re: [.NET] Volatile Fields [correction] To : comp.programming.threads From : Joe Seigh Date : Mon Sep 19 2005 10:22 pm Sean Kelly wrote: > Cool Guy wrote: > >>David Hopwood wrote: >> >> >>>The write to Y is not performed as a single atomic event; it has to be modelled >>>as two events: "Y = 1 is performed with respect to processor 2" and "Y = 1 is >>>performed with respect to processor 3". So it can happen that processor 2 sees >>>Y == 1 before writing Z = 1, but processor 3 does not see Y == 1 until after >>>it sees Z == 1. >> >> >> >>So it's impossible to make such code thread-safe, then? > > > Simply by following the (sparsely) documented x86 memory model? Yes. > Though Alexander suggested a method that should work on existing CPUs: > replace load instructions with CMPXCHG. This relies on a comment in > the docs for CMPXCHG that says a write is always performed when this > instruction is executed, even if the value is not changed as a result > of the operation. Hardware folks may argue that this is an > implementation detail however (as Andy Glew did), so future x86 CPUs > may not guarantee the same behavior. > AFAICT, Alexander seems to think the x86 memory model is just PC and *all* of the other stuff in the x86 docs doesn't count. Seems a bit arbitrary and selective to me. If you want to do global memory barriers just using PC and nothing else, you can. Just use a common memory location to "sync" everything with. E.g. processor 1: store fence; // "fence" is common global location store x; // store some value processor 2: load x; // load some value load fence; // If processor 2 sees the store into x by processor 1 it will see the store into fence. Since "fence" is used as the common memory barrier, you get transitivity of memory visibility. No CMPXCHG required. This only works as long as PC is part of x86 memory model. -- Joe Seigh When you get lemons, you make lemonade. When you get hardware, you make software. .