[concurrency-interest] AtomicReference weakCompareAndSet "Mayfailspuriously"?
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
> volatile semantics from non-volatile (barring the 64-bit atomicity
Nope. Volatile semantics also mean that it it is a synchronization
that there is a total order over synchronization actions, and that
read sees the value of the write to that variable that occurred most
in that total order.
Plus, the CAS happens atomically (or, for weak CAS, fails spuriously).
>> 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
> whether the JMX implementation would benefit from using such a class?
More information about the Concurrency-interest