[concurrency-interest] AtomicReference.updateAndGet() mandatory updating

Justin Sampson jsampson at guidewire.com
Sun May 28 01:23:06 EDT 2017


Alex Otenko wrote:

> Justin Sampson wrote:
>
> > Spurious failure is more about the read than the write, I think. With spurious
> > failure, you can't even rely on volatile read semantics if the CAS fails, because
> > failure doesn't give any information at all about the current value. Without
> > spurious failure, at the very least you know that the current value != the
> > expected value if the CAS fails.
>
> No, that’s not spurious enough failure.
>
> Spurious failure can mean CAS failed because the cache line from which the
> value was read got invalidated (available on some weak memory platforms).
> So you can’t tell even whether the value was != expected or not, or whether
> someone modified a different value that happens to share the cache line -
> hence spurious.
>
> In this setting it does not seem possible to detect whether the read was
> volatile or not.

I think that's what I said: If spurious failure is allowed, failure doesn't tell you
anything about the current state of the variable, and doesn't count as a
volatile read. If spurious failure is not allowed, failure does tell you something
about the current state of the variable, and should count as a volatile read.
That's clearly a different concern from whether a failure counts as a volatile
_write_, which is the difference I thought you were asking about.

(And thanks for fleshing out your example to the point where we can see the
whole sequence of actions in both threads.)

Cheers,
Justin



More information about the Concurrency-interest mailing list