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

Alexander Terekhov wrote:
> Joe Seigh wrote:
> 
>>Alexander Terekhov wrote:
>>
>>>Joe Seigh wrote:
>>>[...]
>>>
>>>
>>>>If Andy had simply stated that loads were in order ...
>>>
>>>
>>>Once again: please show some pseudo code with *FENCE (or whatever) that
>>>you think is required to ensure visibility of some object initialized
>>>and published by A (OBJECT = ..., ptr1 = &OBJECT) to C (object = *ptr2)
>>>after republishing it by B (r = ptr1, ptr2 = r).
>>>
>>>regards,
>>>alexander.
>>
>>Well, the corrected version of the sample I posted to c.a. ...
> 
> 
> So you have only one store performed by A, and your (corrected) beef is 
> about allowing B to perform a load yielding the value of A's store{.rel}) 
> before A's store is made visible to all other processors. It's the same
> behavior as under release consistency... and your lovely PPC works that 
> way too.
> 

There is no "make visible" in PC, or release consistency for that matter.

Anyway, we're *not* talking about release consistency.  We're talking
about whether PC implies loads (not stores) are in order or not.  I
provided a counter example to the in-order theory.

I'm going to stick with the loads are out-of-order model.  I was willing
to listen to any valid arguments for in-order you could make but the
signal to noise ratio seems to have gone to zero.


-- 
Joe Seigh

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

.