Subj : Re: Memory visibility and MS Interlocked instructions
To   : comp.programming.threads
From : Alexander Terekhov
Date : Wed Aug 31 2005 07:51 pm


David Hopwood wrote:
> 
> Joe Seigh wrote:
> > If you're thinking that doesn't matter because processor consistency
> > gives you release and acquire semantics between two processors.  But
> > what if you have 3 (or more) processors?   For example, processor A
> > initializes and stores its address in X.   Processors B reads X.  So
> > far, so good.  All the stores by A are read in proper order by B.
> > Now processors B stores the object address in Y and processor C reads Y.
> > Now there's a problem.  There's no guarantee that processor C will see
> > the writes by A in proper order (i.e. relative to the read of Y).  So
> > processor consistency doesn't give you acquire and release as they are
> > commonly understood.
> 
> Right. 

Wrong.

>        In the x86 model:
> 
> Start with object.foo == 0, X == null.
> 
> Processor A:
>    object.foo := 1 
>    X := &object

Before processor A is allowed to perform that "X := &object" store
with respect to any other processor, it must perform preceding 
"object.foo := 1" store with respect to all other processors. 

That's PC.

> Processor B:
>    t := X

Here, when t != null, you can bet that "object.foo := 1" store by 
processor A is already performed with respect to all other processors. 

See above.


>    Y := t

Here, at some point in time, processor B will perform that "Y := t" 
store with respect to processor C.

> 
> Processor C:
>    u := Y

     if (u != null && u->foo != 1) { !! broken PC hardware check
       turn_on_sirens();
       halt();
     }

regards,
alexander.

.