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

[Paul Sandoz]

> On 30 Aug 2016, at 14:50, Martin Buchholz <martinrb at google.com> wrote:
> 
> 
> 
> On Mon, Aug 29, 2016 at 4:12 PM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
> 
> > On 29 Aug 2016, at 15:32, Martin Buchholz <martinrb at google.com <mailto: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!
> 

Doh, of course.


> Are there any users of  weakCompareAndSet in the wild?

V. few, a search on grepcode shows one primary user is Guava’s AtomicDoubleArray, which wraps, but which itself has few or no usages reported by grepcode IIRC.

I still think it’s kind of sneaky to substitute, especially because of propagation to wrapping classes such as AtomicDoubleArray.

Doug, not sure you care enough to have an opinion :-) but i might as well ask, do you?

Paul.


> 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?