[jmm-dev] weakCompareAndSet memory semantics

Andrew Haley aph at redhat.com
Tue Apr 26 07:56:09 UTC 2016


On 26/04/16 02:03, Justin Sampson wrote:
> Sorry, on further thought, perhaps the potential for spurious
> failure in AtomicStampedReference and AtomicMarkableReference isn't
> actually observable in practice. Their compareAndSet methods use the
> same algorithm as their attemptStamp and attemptMark methods, which
> are documented to allow spurious failure. But in all of those cases
> (attemptStamp, attemptMark, _and_ compareAndSet on both classes),
> while it's true that the final casPair call can fail even if the
> current ref and stamp/mark are equal to the expected values at that
> moment, that will only happen if there was an intervening write with
> a _different_ ref or stamp/mark (an A-B-A situation), in which case
> the failure is semantically legitimate.

But that's surely because at the time it was written we didn't have
the necessary underpinnings in Unsafe to implement a weak CAS.

Andrew.



More information about the jmm-dev mailing list