Subj : Re: Memory visibility and MS Interlocked instructions
To   : comp.programming.threads
From : Joe Seigh
Date : Tue Aug 30 2005 04:49 pm

Alexander Terekhov wrote:
> Mayan Moudgill wrote:
> [...]
> 
>>Ask in comp.arch, 
> 
> 
> Joe Seigh did it already.
> 
> http://groups.google.com/group/comp.arch/msg/9e507575af908132
> 
> 
> 
>>                  people like Andy Glew and others might be able to give 
>>a reasonably authoritative answer.
> 
> 
> Andy Glew did it already.
> 
> http://groups.google.com/group/comp.arch/msg/96ec4a9fb75389a2
> 
 
where Andy Glew states
    "The second rule allows a read to pass a write...  howefver...

    In a multiprocessor system, the following rules apply:
    * Individual processors obey the same rules as in a single
       processor system.
    * Writes by a single processor are observed in the same
       order by all other processors.
    * Writes by different processors on the system bus [*gack*]
       are NOT observed by processors in the same order.>>

    If you think it through, you will see that allowing reads to
    be "bound" in any order corresponds to observing
    stores from other processors out of order. Since this is
    not allowed, something else happens."

However, while Andy is correct in stating the reads can't be bound
in any order, it doesn't follow that therefore they must be in order.
They only have to be in order w.r.t. stores by a single processor.
They do not have to observe stores by different processors in the
same order and therefore do not have to be "in order" in that case.

If Andy had simply stated that loads were in order that would be
one thing, though it would only be an authoritative opinion.
The problem is that he screwed up on inferring that processor consistency
gives you TSO for more than 2 processors.  So, either he's wrong about
loads being in order or there is some other reason loads are in order.


-- 
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

.