[concurrency-interest] AtomicReference weakCompareAndSet "Mayfailspuriously"?

Doug Lea dl at cs.oswego.edu
Thu May 18 07:26:45 EDT 2006

Backing up a little first, the intent of weakCAS is to provide the
cheapest possible conditional atomic update available on a machine,
that may entail tradeoffs wrt determinism and ordering.
It is mainly useful for things like collecting statistics
as in Hanson Char's example code, which is a common and useful use case.
It is almost never used inside java.util.concurrent, because atomics
used within synchronizers almost always need to rely on comparison
outcome and/or to ensure happens-before orderings, so the opportunity
to use it rarely arises.

Boehm, Hans wrote:
> I'm not completely convinced that the issue is really different for 
> references.

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.

> I would be more positive on strengthening ordering of weakCompareAndSet for
> both.

But then people like Cliff will be unhappy.

> On the other hand, I'm not at all sure that this is a sufficient argument for
> change at this point.

I'm completely open about adding variants distinguishing
determinism vs ordering, but I don't see a very compelling
argument for it either.


More information about the Concurrency-interest mailing list