[cpp-threads] Causality on more than two processors, write atomicity

Alexander Terekhov alexander.terekhov at gmail.com
Mon Sep 5 14:39:52 BST 2005


On 9/3/05, Alexander Terekhov <alexander.terekhov at gmail.com> wrote:
> On 9/3/05, Peter Dimov <pdimov at mmltd.net> wrote:
> > There is a discussion in comp.programming.threads, in which the following
> > example:
> >
> > P1: Y = 1;
> > P2: if( Y == 1 ) { Z = 1; }
> > P3: if( Z == 1 ) { assert( Y == 1 ); }
> >
> > is claimed to legitimately assert under "processor consistency" - the memory
> > model that the x86 CPUs are supposed to implement, and under all platforms
> > that don't exhibit write atomicity (even when all loads are ld.acq and all
> > stores are st.rel).

It is my understanding that in order to achieve classic SC on x86, one just 
need to replace all loads by InterlockedCompareExchange(&addr, 42, 42). 

Perhaps someone from Intel here can confirm (or deny) it.

> 
> Itanic defines "remote write atomicity" for st.rel to WB memory only.
> 
> >
> > I'm still struggling with this "discovery". How does it affect us? It seems
> > to me that this makes ld.acq/st.rel impossible to specify in a
> > happens-before framework
> 
> That probably depends on the framework. Y = 1 (and Z = 1) are
> writes in progress, so to speak.
> 
> P1: Y = 1; Y = 2;
> P2: if( Y == 2 ) { Z = 1; }
> P3: if( Z == 1 ) { assert( Y >= 1 ); }
> 
> won't abort legitimately.

And I just wonder how revised Java volatiles (which supposedly meant to 
provide SC semantics) deal with lack of write atomicity on x86 and Power
without cmpxchg and LR-SC respectively.
 
regards,
alexander.




More information about the cpp-threads mailing list