[concurrency-interest] AtomicReference weakCompareAndSet "Mayfailspuriously"?

[David Holmes]

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?

David