Subj : Re: Memory visibility and MS Interlocked instructions
To   : comp.programming.threads
From : Sean Kelly
Date : Tue Aug 30 2005 02:26 pm

Joe Seigh wrote:
>
> 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.

>From what Alex has been saying, it seems like loads may occur out of
order at a hardware level, but because of the PC model they appear to
occur in order at the program level.  Assuming this is true, all the
talk of behavior at the system bus level is a red herring, as while it
may actualy be taking place, it's not something we need to worry about.
 The resonse from Andy seems to confirm this:

- It was necessary to mention this because validation folk, usually
- fresh out of college, would write a test, see a load on the bus
- occurring before an older store, and think they had discovered a bug.
- Ditto posters to comp.arch.

It's somewhat unfortunate that the spec used for internal validation is
apparently the same one Intel released for public consumption, though I
suppose there's no practical way around it.


Sean

.