[concurrency-interest] AtomicReferenceweakCompareAndSet "Mayfailspuriously"?
pugh at cs.umd.edu
Mon May 29 15:23:45 EDT 2006
On May 29, 2006, at 12:49 AM, Brian Goetz wrote:
>> What Cliff wants is an atomic integer for use with counters that
>> is not
>> volatile, so that the extra memory barriers required for violatile
>> can be elided. This gives rise to a large performance boost in the
>> Cliff wants to use it - performance counters. Cliff can use
>> weakCAS for this
> The behavior Cliff wants is analogous to the meaning of volatile in
> old memory model, where volatile wasn't required to ensure the
> visibility of any value other than the variable being written/read.
> I think what bothers Bill about the proposal (I am confident Bill will
> correct me if I am wrong) is that there is no way to represent the old
> volatile semantics in the new memory model, and therefore there
> would be
> no mathematical basis for the proposed semantics of wCAS.
No, actually, I'm not worried about that.
The way it is described in the current JavaDoc isn't correct,
but the memory model has no problem with synchronization actions that
don't establish happens-before ordering. We can fix the JavaDoc.
My worry is that people using weakCompareAndSet will accidently
a synchronization error into their program.
In particular, I think the use case for a
on a AtomicReference is rather limited.
Thread 1 uses a weakCompareAndSet to store a reference to an
object X into
Thread 2 uses a get on the AtomicReference to get a reference to
there is no happens-before ordering from the CAS in thread 1 to the
get in thread 2.
Thus, if thread 1 constructed X, or performed any updates to X before
the CAS, then there would be a data race if thread 2 tried to read
any of the fields of X,
and the reads wouldn't be guaranteed to see any of the updates to the
fields of X
performed by thread 1.
Doug, and perhaps 3 other people in the world, could figure out
valid and useful
use cases for a weakCompareAndSet on an AtomicReference that didn't
By the way, one of the things that should be added to
java.util.concurrent in Java 7 is a
ConcurrentCounter: somethings you can increment quickly, but for
which reading a value
is more expensive. There are all sorts of games you could play here,
such as using
Suggested JavaDoc for weakCompareAndSet:
Atomically sets the value to the given updated value if the
current value == the expected value.
May fail spuriously. Unlike compareAndSet(), and other operations on
an AtomicX, the weakCompareAndSet()
operation does not create any happens-before orderings. Thus, just
because a thread sees an update to an AtomicX caused
by a weakCompareAndSet doesn't mean it is properly synchronized
with operations that occurred before the weakCompareAndSet(). You
probably don't want to use this method, but instead
should just use compareAndSet;
as there are few cases where weakCompareAndSet is faster than
compareAndSet, and there are a number of cases in which
trying to optimizing your code by using weakCompareAndSet rather than
compareAndSet will introduce subtle and hard to
reproduce synchronization errors into your code.
More information about the Concurrency-interest