Subj : Re: Memory Barriers, Compiler Optimizations, etc.
To   : comp.programming.threads
From : Ziv Caspi
Date : Sat Feb 05 2005 01:59 am


"Scott Meyers" <Usenet@aristeia.com> wrote in message 
news:MPG.1c6c9641434522049897bd@news.hevanet.com...
> On Tue, 01 Feb 2005 23:14:30 -0800, Gianni Mariani wrote:
>> All aquire does is to guarentee that any load (memory fetch) operations,
>> possibly many, that have been requested before the barrier instruction
>> are completed before any subsequent memory fetch operations.
>
> I post this with great trepedation, because I've gotten this backwards
> several times before, but my understanding is that an acquire guarantees
> that subsequent memory operations will not take place before any 
> operations
> preceding the acquire, i.e., that memory references "after" the barrier 
> (in
> program order) won't migrate up to "before" the barrier.  However, it's a
> unidirectional barrier, so memory operations preceding the barrier may
> migrate down to after it.  Conceptually, we can move memory operations 
> into
> the critical section, but we can't move opertions inside the critical
> section to above the acquire (i.e., out of the critical section).
>
> Did I get it wrong again, did I misread what you wrote, or is there a
> misstatement above?

No, you got it correctly. See also 
http://www.microsoft.com/whdc/driver/kernel/MP_issues.mspx

* Acquire semantics mean that the results of the operation are visible 
before the results of any operation that appears after it in the code
* Release semantics mean that the results of the operation are visible after 
the results of any operation that appears before it in the code

HTH,
Ziv Caspi

.