[cpp-threads] Yet another visibility question

Hans Boehm Hans.Boehm at hp.com
Tue Dec 19 17:41:38 GMT 2006



On Tue, 19 Dec 2006, Peter Dimov wrote:

> Boehm, Hans wrote:
>
> > A very simple (perhaps too simple) counter-example is
> >
> > r1 = x.load_raw();
> > if (r1) {
> >   y = 1;  // y not atomic
> > } else {
> >   y = 1;
> > }
> >
> > I think we really have to declare the stores here to be dependent on
> > the load, since each one is.
>
> I'm not sure. We define a store to be dependent if different values of r1
> can cause it to write different values (where not writing at all is
> considered different from writing any value). In this example, changing the
> value of r1 cannot cause different values to be written to y. The static
> code structure (the presence of an if statement) does not and cannot
> determine dependence.
>
> if( f( r1 ) >= 0 )
> {
>     y = 1;
> }
>
> Is this dependent? We can't say without knowing whether f() can return a
> negative value.
>
I completely agree with everything except the applicability to the
original example.  I do think that stores encountered through different
control flow have to be treated as distinct for determining dependence.

Otherwise consider a variant of the above example:

r1 = y_initialized.load_raw();
if (r1) {
   y.foo();
} else {
   y.bar();
}

Assume that y_initialized is set in another thread after initializing y.
I'm now in a situation in which this code is correct unless foo() and bar()
happen to assign the same value to the same field of y.  In that case,
the stores would no longer be dependent, and hence could happen before
initialization.  But clearly it shouldn't be my business to know how
foo() and bar() are implemented.

None of this is making me more comfortable about the case in which the
store is an unordered atomic either.

Hans





More information about the cpp-threads mailing list