[concurrency-interest] AtomicReferenceweakCompareAndSet "Mayfailspuriously"?

Pete Soper Pete.Soper at Sun.COM
Tue May 30 13:44:14 EDT 2006

It doesn't appear that Martin Buchholz has filed a Sun change request 
(CR) for this javadoc improvement. If there's a sense of JSR166 expert 
group (EG) concensus I can get the process started and Martin or I will 
follow through to try to make this happen for Mustang (it seems 
possible, but a lot of stuff is trying to happen all at once). You and 
one other EG member should sign off on the final text change and we'll 
assume this is a draft for the moment.


PS I was studying Lamport clocks when your Java SE 7 ("Dolphin") 
proposal hit my laptop and I almost fell out of my chair.

Bill Pugh wrote:
> 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  
> 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
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list