[concurrency-interest] AtomicReferenceweakCompareAndSet "Mayfailspuriously"?

Bill Pugh 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  
>> semantics
>> can be elided. This gives rise to a large performance boost in the  
>> context
>> Cliff wants to use it - performance counters. Cliff can use  
>> weakCAS for this
>> purpose.
>
> The behavior Cliff wants is analogous to the meaning of volatile in  
> the
> 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  
introduce
a synchronization error into their program.

In particular, I think the use case for a  
weakCompareAndSetWithoutHappensBefore
on a AtomicReference is rather limited.

Consider:

   Thread 1 uses a weakCompareAndSet to store a reference to an  
object X into
   an AtomicReference

   Thread 2 uses a get on the AtomicReference to get a reference to  
X. However,
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  
performing
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  
create happens-before
orderings.

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
thread locals.

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.



Bill



More information about the Concurrency-interest mailing list