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

[Paul E. McKenney]

PS to previous: updated dependency discussion at:

	http://wiki.dinkumware.com/twiki/pub/Wg21oxford/EvolutionWorkingGroup/dependencyoptions.2007.04.17a.txt

And updated fence discussion:

	http://wiki.dinkumware.com/twiki/pub/Wg21oxford/EvolutionWorkingGroup/fenceproposal.2007.04.17a.txt

This latter does not include atomic operations, but does include both
memory fences and compiler fences, along with examples.

Both are more along the lines of rationale rather than explicit standards
proposal at this point.

						Thanx, Paul

On Mon, Apr 16, 2007 at 02:24:26PM -0700, Paul E. McKenney wrote:
> On Mon, Apr 16, 2007 at 06:12:14PM +0300, Peter Dimov wrote:
> > Paul E. McKenney wrote:
> > >Hello again!
> > >
> > >I once again thank Hans for his careful description of a number of
> > >interesting optimization situations relating to dependency-based
> > >ordering.  The following text discusses some possible approaches
> > >to resolving these situations.
> > >
> > >Thoughts?
> > 
> > [...]
> > 
> > >8. Allow the optimizer to break dependencies except when explicitly
> > >told not to.  Potential ways of telling the compiler not to break
> > >dependencies include:
> > 
> > [...]
> > 
> > N2195 proposes the following minimalistic approach:
> > 
> > template< class T > inline T * atomic_load_address( T * const * p );
> > template< class T > inline T * atomic_load_address( T * const volatile * 
> > p );
> 
> I do like the template approach!
> 
> > Returns: *p.
> > 
> > Constraint: _Acquire only with respect to **p.
> 
> OK -- but what about p->some_field?  Or does **p indicate any dereference
> of p?  I had been assuming the more restrictive mode.
> 
> > That is, after X * p = atomic_load_address( &q ), *p is guaranteed to be 
> > visible, although traversing any additional pointers in *p using ordinary 
> > or relaxed loads is not well-defined; one needs an additional 
> > atomic_load_address for them.
> 
> One way of making the traversal of additional pointers well defined
> is to tag the dependency chains of interest.  Functions that are to
> be traversed by dependency chains must also be tagged.
> 
> >                               Index-based dependencies are not supported.
> 
> Why not?  Requiring tagging of the important dependency chains
> should make the reduction in optimization tolerable, right?
> 
> > atomic_load_address maps to Relaxed on everything except Alpha, where it 
> > maps to Acquire.
> 
> Makes sense -- and strongly ordered machines need not worry about
> the dependency chains either.
> 
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2195.html
> 
> Thank you for the reminder URL!
> 
> 						Thanx, Paul