[concurrency-interest] AtomicReferenceweakCompareAndSet "Mayfailspuriously"?

[Jeremy Manson]

Brian Goetz wrote:

> 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.

Although I can't speak for him, I am pretty sure that this is _not_ what 
worries Bill.  Any necessary mathematics can be resolved.  It wouldn't 
really matter if it were difficult, anyway; in general, one of the 
things that makes the JMM semantics so complicated is that it has to 
reflect what Java developers and users need, not mathematical simplicity.

More worrisome is the fact that there isn't really any meaningful use 
case for a happens-before-free weakCompareAndSet on an AtomicReference 
(AFAICT).  So do you end up keeping hb for AtomicReference, but losing 
it for AtomicInteger?  Is that a consistent API?

It seems to me that it would be better if you could decide that 
weakCompareAndSet did have hb semantics, and add weakCompareAndSetNoHB 
to the API for everything that is not AtomicReference.  This is not a 
reasonable solution, though, because it seems fairly clear that this 
issue cannot wait until Dolphin to be resolved.

					Jeremy