[cpp-threads] Web site updated

[Hans Boehm]

On Mon, 12 Feb 2007, Paul E. McKenney wrote:

> On Tue, Feb 13, 2007 at 01:36:07AM -0000, Boehm, Hans wrote:
> > > From:  Paul E. McKenney
> > Thanks for the comments.
> > >
> > > >     * Why do we not guarantee that dependencies enforce
> > > memory ordering?
> > >
> > > In the suggestion at the end of the document, wouldn't it be
> > > reasonable to disallow application of profiling-based
> > > optimizations to quantities that derive from load_raw()?
> > > Should be a matter of tagging, correct?
> > > This might well force a global view during profile-based
> > > optimizations, but such a global view might well enable much
> > > more powerful optimizations.
> > I suspect that's still hard, though we probably want to discuss this.
> > Consider
> > inside f(x,y,z):
> >
> > r2 = *x;
> > r3 = r2 -> a;
> >
> > transformed to
> >
> > r2 = *x;
> > r3 = r1 -> a;
> > if (r1 != r2) r3 = r2 -> a;
> >
> > as before, but without the load_raw.  This is fine unless I call it as
> >
> > tmp = x.load_raw(); f(&tmp, y, z);
>
> But in this case, the value of x would be the address of the temporary,
> -not- of the shared variable x.  Therefore, the comparison should not
> be a problem.
I think it still is.  Assume that r1 is a value that is coincidentally
usually equal to *x (the result of the load_raw) in the function, but
not dependent on it (in the hardware sense).  Then, as far as the
hardware is concerned, in the "optimized" code, r1 -> a is no longer
dependent on the load_raw and hence is no longer ordered with respect
to it.

The comparison is comparing the value returned by the load_raw
(== tmp == *x) to the guess r1.  If r1 and r2 are equal, I don't
see why thre would be any guarantee that the load into r3 and the
load_raw remain ordered, eventhough they appear dependent at the
source level.

Hans