881
Subj : Re: Memory visibility and MS Interlocked instructions
To   : comp.programming.threads
From : Alexander Terekhov
Date : Fri Aug 26 2005 12:07 am


Scott Meyers wrote:
[...]
> 
> Alexander Terekhov wrote:
>  > No on the first part to the extent that "... thread W (the writer)
>  > writes a value to variable x and thread R (the reader) later reads
>  > the value of x ...  to guarantee that R sees the value written by
>  > W, W must follow the write with a release membar and R must
>  > precede the read with an acquire membar" is not true on shared
>  > memory MP hardware level where acquire and release merely ensure
>  > ordering with respect to other accesses.
> 
> I was actually asking about the truth of this statement:
> 
>     Both writer and reader must participate in a handshake to ensure that
>     writer changes to memory are visible to readers in a relaxed memory
>     architecture.

If all you care about is visibility of one single memory location 
(your "variable x") then it will (eventually) become visible without 
any acquire or release (on hardware level).

> 
> What struck me most about the documentation of the interlocked instructions
> was that it suggested there was no need for a handshake, i.e., if the
> writer called an interlocked routine, there was no need for a reader to do
> anything special when reading.  From the responses I've seen in this thread,
> I get the impression that a handshake *is* required, that both writer and
> reader must do something to ensure that the reader sees what the writer
> last wrote, at least in the general case.

In the general case with more than one single memory location, you 
do need release [sink barrier] -> acquire [hoist barrier] handshake.

> 
> As for your specific statement above, I gather you mean that on some
> architectures, more specific membars may be necessary rather than just
> release by the writer and acquire by the reader.  Is that correct?

On some software DSMs, acquire/release operations cause lazy/eager 
[respectively] propagation of modified data. I've never heard of 
such hardware.

regards,
alexander.

.

0