RFR 8164814: Deprecate Atomic*.weakCompareAndSet and defer to Atomic*.weakCompareAndSetPlain

[Martin Buchholz]

We had already agreed on making these changes, and the detail looks good,
so approved!

but ... I wish there was less confusion ... maybe it's unavoidable ... I'm
going to check the docs carefully every time I use one of these APIs!  ...
feel free to ignore rambling:

I am having second thoughts about whether it's too late to fix our API
wart.  Suppose we make weakCompareAndSet the one with volatile semantics
and weakCompareAndSetPlain the one with plain semantics?  The normal rule
is never to change the definition of an API, but here:

- we would only be strengthening the API, so previous users of
weakCompareAndSet will not be broken
- all known historical implementations of weakCompareAndSet pre-jdk9 in
fact delegated to volatile  CAS (is this true?), so future users of
weakCompareAndSet will not be broken in practice when their software is
used on jdk8.

On Thu, Aug 25, 2016 at 1:48 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
>
> Please review:
>
>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8164814--
> atomics-weakCompareAndSet-deprecate/webrev/ <http://cr.openjdk.java.net/~
> psandoz/jdk9/JDK-8164814--atomics-weakCompareAndSet-deprecate/webrev/>
>
> This patch deprecates weakCompareAndSet and adds a new method
> weakCompareAndSetPlain. The intent is to avoid confusion over the memory
> effects of such methods, since other read-modify-write methods, with
> unqualified names, have volatile memory effects.
>
> I just modified atomic classes that have already been updated for Java 9
> [*].
>
> Paul.
>
> [*] atomic classes not updated:
>   AtomicIntegerFieldUpdater
>   AtomicLongFieldUpdater
>   AtomicMarkableReference
>   AtomicReferenceFieldUpdater
>   AtomicStampedReference
>
>