[concurrency-interest] Fences

[Boehm, Hans]

> From: Paul E. McKenney [mailto:paulmck at linux.vnet.ibm.com] 
> 
> On Fri, Aug 07, 2009 at 10:40:07PM +0000, Boehm, Hans wrote:
> > Doug -
> > 
> > [Copying Paul McKenney, who should look at the appended message 
> > first.]
> 
> [ . . . ]
> 
> > 3. The volatile emulation seems like it's at best an approximation.
> > If you implement it with the obvious fences, I think you 
> end up with a 
> > PowerPC implementation which is faster than what the PowerPC guys 
> > recommend.  This leads me to suspect it's not correct there.
> > It generally doesn't seem to guarantee the correct outcome for IRIW.
> > I'm not sure about more interesting examples.  It also depends on 
> > parts of the "more formal" definitions I don't yet understand.
> 
> Finally understood what Hans was getting at here...
> 
> PowerPC does indeed require hwsync between volatile loads if 
> you want IRIW to work.  The weaker/faster lwnsync instruction 
> does not guarantee that readers will see a consistent global 
> ordering for stores, due to its weaker cumulativity 
> guarantees.  Or, if you want a more hardware-centric 
> explanation, because lwsync does not flush the store buffer.
> 
> 							Thanx, Paul
> 
I think the right solution here would be to just describe this as an approximate volatile emulation.

On Itanium, it also won't get you a full emulation, I suspect.  For field stores that are implemented with an ordinary store, as opposed to an st.rel, I don't think there is any way to guarantee SC just by inserting fences.

Certainly C++ can't guarantee SC by adding fences between relaxed atomic operations.

Hans