Subj : Re: [.NET] Volatile Fields [correction] To : comp.programming.threads From : David Hopwood Date : Fri Sep 23 2005 04:44 pm David Hopwood wrote: > Chris Thomasson wrote: > >>>Start with F (fence) == Y == Z == 0. >>> >>>P1: F = 1; Y = 1; >>>P2: if (Y == 1) { (void) F; F = 1; Z = 1; } >>>P3: if (Z == 1) { (void) F; assert(Y == 1); } >>> >>>can fail, e.g. in this execution: >> >>Right. The fence is in the wrong place. You store to the fence "after" >>storing to Y or Z. This acts as a release barrier. You would then load from >>the fence to get an acquire barrier: >> >>Processor 1: Y = 1; Fence.rel = 1; >>Processor 2: if (Fence.acq == 1 ) { Z = 1; Fence.rel = 2; } >>Processor 3: if (Fence.acq == 2) { assert( Y == 1 && Z == 1 ); } > > Well, yes, but that's completely changing the logic of the original example. > The point is that you effectively have to design lock-free stuff to work in > a processor consistent model, if you want it to be efficient on x86 etc. or a weaker model, of course. > The lack of "remote write atomicity" can't be hidden just by redefining > fence operations. This applies also if you design for RCpc. -- David Hopwood .