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

[Paul E. McKenney]

On Wed, Apr 18, 2007 at 12:32:02AM +0300, Peter Dimov wrote:
> Paul E. McKenney wrote:
> >On Tue, Apr 17, 2007 at 02:38:29PM +0300, Peter Dimov wrote:
> 
> >>In the dependency discussion paper, you write that a single level of
> >>indirection is not enough for the Linux kernel, but I don't see how
> >>you could make a multi-level primitive work on an Alpha.
> >
> >This depends on how the multi-level list was created. [...]
> 
> Yes, you are right. atomic_load_address will probably always work in 
> practice for such dependencies, but I'm not sure that I can specify it so 
> that it will also work in theory.

I would like to help here, but need to understand what is broken in
theory.  The dependency chains seem to me to be pretty well defined,
particularly given that their heads are marked and that any passage of
the chain to a different compilation unit is also marked in both the
function prototype and the function definition.

So, what am I missing here?

> >Why not just use atomic_load_address() on the index?  Then given a
> >static array whose indexes are dynamically filled in:
> >
> >i = atomic_load_address(myindex);
> >r1 = myarray[i];
> 
> This could work in practice, but again, I'm not sure that I can specify it 
> in a formal way since the object whose visibility needs to be ensured is 
> not known until after the second line.
> 
> The explicit per-object fence can handle these scenarios - in principle - 
> since the user specifies the dependent object explicitly.
> 
> i = atomic_load_relaxed( myindex );
> 
> dependency_fence( &myarray[ i ] );
> dependency_fence( &myarray2[ i * 2 ] );

OK, I'll bite -- what are the above dependency_fence() calls doing,
either in theory or in practice?

> r1 = myarray[ i ].foo;
> r2 = myarray[ i ].bar;
> r3 = myarray[ i*2 ].baz;

						Thanx, Paul