[concurrency-interest] AtomicReference weakCompareAndSet
dcholmes at optusnet.com.au
Sun May 21 18:36:02 EDT 2006
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)?
> 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?
More information about the Concurrency-interest