[concurrency-interest] AtomicReference weakCompareAndSet "Mayfailspuriously"?

Bill Pugh pugh at cs.umd.edu
Sat May 27 18:06:20 EDT 2006


On May 21, 2006, at 6:36 PM, David Holmes wrote:

> Bill Pugh writes:
>> I would explain this differently (actually, the JMM requires that
>> it  be explained differently):
>>
>> weakCompareAndSet has volatile semantics, _except_ that it doesn't
>> create any happens-before edges.
>
> But isn't the existence of those edges the only thing that  
> distinguishes
> volatile semantics from non-volatile (barring the 64-bit atomicity  
> issue)?

Nope. Volatile semantics also mean that it it is a synchronization  
action,
that there is a total order over synchronization actions, and that  
each volatile
read sees the value of the write to that variable that occurred most  
recently
in that total order.

Plus, the CAS happens atomically (or, for weak CAS, fails spuriously).

	Bill


>
>> So, here is the question we should discuss:
>>
>> **********
>>
>> Should weakCompareAndSet on an AtomicReference create happens
>> before  edges (just as compareAndSwap does)?
>>
>> **********
>
> For consistency I'd say no. Arguably  
> AtomicReference.weakCompareAndSet was a
> mistake and should be deprecated. But one-in all-in.
>
> We probably need to migrate the details from the package docs into the
> actual method docs.
>
> To address Cliff's problem I think the best solution is to add a
> WeakAtomicInteger class that has no volatile semantics at all. I  
> wonder
> whether the JMX implementation would benefit from using such a class?
>
> David



More information about the Concurrency-interest mailing list