[concurrency-interest] AtomicReferenceweakCompareAndSet "Mayfailspuriously"?
jmanson at cs.purdue.edu
Mon May 29 09:45:53 EDT 2006
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.
More information about the Concurrency-interest