RFR 8164814: Deprecate Atomic*.weakCompareAndSet and defer to Atomic*.weakCompareAndSetPlain
Martin Buchholz
martinrb at google.com
Tue Aug 30 21:50:29 UTC 2016
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?
>
More information about the core-libs-dev
mailing list