[cpp-threads] Review comments on N2176 WRT dependency ordering

Paul E. McKenney paulmck at linux.vnet.ibm.com
Wed Apr 18 23:04:24 BST 2007


On Wed, Apr 18, 2007 at 02:08:57PM +0300, Peter Dimov wrote:
> Paul E. McKenney wrote:
> >On Wed, Apr 18, 2007 at 02:17:15AM +0300, Peter Dimov wrote:
> 
> >>There's also the option of just providing dependency_fence() which
> >>maps to atomic_compiler_fence( __acquire ) on everything except
> >>Alpha, where it inserts an additional rmb as well.
> >
> >And for strongly ordered machines (e.g., C4 or TSO), this makes sense.
> >The required acquire fence is free (aside from preventing some
> >compiler optimizations).  However, on weakly ordered machines that
> >enforce data dependencies, the acquire fence would be excessively
> >expensive.
> 
> No, the fence is a compiler fence, it will insert no hardware fence 
> instructions, just prevent optimizations that are equivalent to moving a 
> memory access upwards. It then becomes an interesting debate whether a 
> particular dependency-breaking optimization X is equivalent to moving the 
> memory access M upwards. :-) (Which, I believe, it generally is.)

Fair enough!

> I think that if we have compiler fences at all, we'll have this problem of 
> optimization validity in their presence anyway. 

The acquire and release operations that imply actual machine instructions
must also impose constraints on code-motion optimization, so this is
a more general requirement, right?

Attached is an early attempt to write up dependency chains.  Feel free to
correct/criticize/whatever.

							Thanx, Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.decadentplace.org.uk/pipermail/cpp-threads/attachments/20070418/e18f4751/dependencyproposal.2007.04.18a.html


More information about the cpp-threads mailing list