[cpp-threads] Alternatives to SC (dependency-based)

[Hans Boehm]

On Mon, 29 Jan 2007, Paul E. McKenney wrote:

> > 2) I do not believe that any ordering constraints based on dependencies
> > are viable at this level.  I agree that they would be useful.  But all
> > attempts at definition have failed, typically because they end up
> > imposing compilation constraints on compilation units that do not
> > use atomics.  Peter and I have been through long discussions of this
> > that are in the archives.  I will try to post a summary shortly.
> > The nice thing about atomics with acquire and release ordering constraints
> > is that none of this matters.  (This does not mean that dependency-based
> > oredring is useless at the machine level.  It is critical for implementing
> > Java final fields.  But there the compiler knows what it's doing and
> > the dependency doesn't span compilation units.  The JSR133 effort
> > arrived at a similar conclusion for explicit dependency-based ordering.)
>
> I am OK with requiring the programmer to mark dependencies that matter,
> as is done via rcu_dereference() usage in the Linux kernel.  Then any
> unmarked dependency is the compiler's to do with as it will.
>
> Does this work for you?
>
I think that marking the original load doesn't help much, since
it already needs to be marked as atomic in this world.

I haven't thought very much about making something like this work
in environments in which the dependent reference is limited to a
field of the object returned by the first load.  In general, it's
at least nearly impossible to define what constitutes a dependent
load.  Is the second load in

if (*r1) r2 = *r3

(everything starting with r is a local "register" variable) dependent
on the first?  If so, how about

if (*r1) r2 = *r3; else r2 = *r3;

?

Hans