[jmm-dev] weakCompareAndSet memory semantics

[Justin Sampson]

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.

Cheers,
Justin


-----Original Message-----
From: Justin Sampson 
Sent: Monday, April 25, 2016 2:59 PM
To: 'Martin Buchholz'; Aleksey Shipilev
Cc: jmm-dev
Subject: RE: [jmm-dev] weakCompareAndSet memory semantics

Martin Buchholz wrote:

> The old public methods in j.u.c.atomic have documentation, but
> they are weak in two different ways!
> """May fail spuriously and does not provide ordering guarantees"""
> but we (probably) want a variant that "may fail spuriously" but
> still provides sequential consistency, for use in our CAS loops.

At the risk of annoyance-through-repetition, I'll just mention one
last time that there's precedent for exactly that behavior, in the
actual-but-undocumented semantics of compareAndSet on both
AtomicStampedReference and AtomicMarkableReference. (Furthermore,
weakCompareAndSet simply delegates to compareAndSet on both of those
classes.)

The attemptStamp/attemptMark methods are also essentially CAS
operations, and their potential for spurious failure is actually
documented. Their docs don't mention volatile ordering, but they do
provide it (on success). The compareAndSet methods also don't
mention volatile ordering in their own docs, but they're covered by
the package docs.

Cheers,
Justin