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

[Martin Buchholz]

On Mon, Aug 29, 2016 at 4:12 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> > On 29 Aug 2016, at 15:32, Martin Buchholz <martinrb at google.com> wrote:
> >
> > We had already agreed on making these changes, and the detail looks
> good, so approved!
> >
>
> Thanks.
>
>
> > 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.
> >
>
> .. and deprecate weakCompareAndSetVolatile?
>

No need to deprecate it; we haven't shipped it in a major release yet!
Just kill it!

Are there any users of  weakCompareAndSet in the wild?  If so, how many of
them are correct?  All I can think of is atomically modified variables that
are independent of others, e.g. statistics counters, where
weakCompareAndSet is called in a loop (but true counters can use
getAndAdd).  At least, strengthening the spec to be sequentially consistent
won't break these users.

I keep hoping for an API where you get sequential consistency by default,
and have to ask for relaxed operations explicitly, as in C++.  I keep
thinking we'll regret making e.g. VarHandle.get the non-volatile variant.

I did wonder about that, it seems a little sneaky, so i did not pursue it,
> existing uses will still function but not necessarily to the same degree,
> so it could still be perceived as broken.
>
> There are however very few use-cases of these methods. I used such usage
> analysis to justify depreciation, but I suppose that same analysis could
> also justify a change in behaviour. Thoughts?
>