Subj : Re: Memory Barriers, Compiler Optimizations, etc.
To   : comp.programming.threads
From : Scott Meyers
Date : Thu Feb 03 2005 08:13 pm

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?

> volatile int v1 = BAD;
> volatile bool done = false;
> 
> reader:
> a:	bool is_done = done;
> b:	aquire();
> c:	if ( is_done ) play_with( v1 );

Yes, but consider:

  reader:
       int x = 22;
  a:	bool is_done = done;
  b:	aquire();
  c:	if ( is_done ) play_with( v1 );

The assignment to x can be moved down to between b and c, right?  Also, the
acquire is really meant to be associated with the store to is_done, right?

Scott

.