[jmm-dev] weakCompareAndSet memory semantics

[Justin Sampson]

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