[cpp-threads] New strawman proposal

[Boehm, Hans]

> -----Original Message-----
> From:  Doug Lea
> Sent: Wednesday, June 08, 2005 4:31 PM
> To: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads] New strawman proposal
> 
> 
> Boehm, Hans wrote:
> 
> > 
> >>2. Leaving the semantics of anything with cycles undefined
> >>might be the best we can do, but means that many programs 
> >>will unknowingly be ill-formed. I suppose it is possible to 
> >>create tools that can detect and inform programmers about 
> >>such constructions.
> > 
> > Do you have an example in mind here?
> > 
> > Actually, my intent was that a cycle generally reflects
> > an infeasible synchronizes-with relation.  I think we're 
> not outlawing
> > 
> > Initially x = y = 0, x and y are unordered synchronization
> > variables:
> > 
> > Thread 1			Thread 2
> > x = y				y = x
> > 
> > Outcome: x = y = 42
> > 
> 
> What if the reads here are atomic.readAcquire
> and writes were atomic.storeRelease (or whatever
> we decide to call these)?
> 
I think then the synchronizes-with relations with cycles
don't correspond to any executions.  Hence I think y = x = 0
is the only acceptable result, since one of the reads must
seen an initializing store, and hence the other read must see
either the initializing store or the later store of zero.

But isn't that exactly what we want?  A loadAcquire cannot
be reordered with a later storeRelease?

I do think we have a different related problem, which
I had overlooked.  By the current definition,

(initially x=y=0, ordinary variables)

Thread1:  if (x) y = 1;

Thread2:  if (y) x = 1;

admits a data race.  That's wrong, and
I have to fix the definition of data race.

Hans