[concurrency-interest] AtomicReference weakCompareAndSet "Mayfailspuriously"?

Boehm, Hans hans.boehm at hp.com
Thu May 18 14:19:37 EDT 2006

I think we basically agree, so this is only a detail:

> From: Doug Lea [mailto:dl at cs.oswego.edu] 
> I agree. I think that weakCAS is even less commonly useful 
> for references, but not qualitatively different.
> > This may be less of an issue with CompareAndSet, but I still think 
> > that the fact that the changes to x and y in
> > 
> > if(x.weakCompareAndSet(a, b)) { y = 17; }
> > 
> > can appear out of order is really unintuitive for most people.
> I'm not sure what you have in mind here though. For this 
> ordering to be guaranteed, "y" would need to be volatile, 
> which would cause this to hold regardless of weakCAS 
> ordering. As it stands now, it would basically have the same 
> outcome ordering semantics as, for some variable z,
>    if (z == a) {
>       z = b;
>       y = 17;
>    }
> Where the main ordering constraint relies on whether "y" is 
> volatile, not whether "z" is.
Let me revise the example slightly, though I'm still not sure this is
convincing enough to motivate a change.  Assume x is AtomicSomething
initially not a, y not volatile.

Thread 1:
y = 17; x.set(a);

Thread 2:
if(x.weakCompareAndSet(a, b)) { r1 = y; }

Currently r1 does not have to be 17.  With an ordered weakCompareAndSet,
it would have to be.  I think the current situation is hard to explain,
because there is a data race only in a somewhat technical sense (atomics
are supposed to be used for thread communication after all, and y cannot
actually be accessed concurrently in the sequentially consistent
interpretation), and the program does not behave sequentially
consistently.  It is even less intuitive, since any attempt to explain
this operation runs into the problem that the two memory operations in
thread 2 are dependent, which everyone expects to imply ordering.  (I'd
be the first to agree that it cannot, but still that's the expectation.)
The nice thing about dealing with ordered operations is that they
usually make the dependency issues irrelevant.


More information about the Concurrency-interest mailing list