[cpp-threads] Visibility question

Boehm, Hans hans.boehm at hp.com
Mon Aug 7 02:59:10 BST 2006


Unfortunately, I don't see consensus here.

I was hoping that if we did call this a race, we could go back to a more
Java-like memory model, where intra-thread sequencing is always part of
the happens-before order.  But I think that's wrong, since we have to
treat the following two cases differently:

Thread 1			Thread 2
r1 = x.load<raw>();	r2 = y.load<raw>();
y.store<raw>(r1);		x.store<raw>(r2);

(Loads cannot both see later stores in other threads; that would cause
out-of-thin-air results.)

Thread 1			Thread 2
r1 = x.load<raw>();	r2 = y.load<raw>();
y.store<raw>(1);		x.store<raw>(1);

(Loads can both see later stores, and write buffers typically make that
possible.)

Thus we need to have a way to order the load and store in the first
case, but not the second.  Or we're back to treating causality issues in
some other way.  There is no way to make this distinction solely on the
basis of inter-thread synchronizes-with relationships.

As far as the difference between <fence> and <ordered> is concerned, I
think this is closely related to the more general question of whether
atomics treated naively with assignments, behave sequentially
consistently, as volatiles do in Java.  I think we haven't answered that
question yet.

Hans

> -----Original Message-----
> As a particular example of what I mean, consider (x,y,z 
> atomic, w ordinary, everything initially zero):
> 
> Thread 1:
> w = 1;	// ordinary store
> y.fetch_add<ordered>(1);		// ordered atomic; orders
> everything within thread
> x.store<raw>(1);
> 
> Thread 2:
> r2 = x.load<raw>();
> z.fetch_add<ordered>(1);		// ordered atomic; orders
> everything within thread; different variable
> if (r2) r1 = w;	// ordinary load
> 
> Is there a data race on w?
> 



More information about the cpp-threads mailing list