On Mon, Aug 29, 2016 at 4:12 PM, Paul Sandoz <[email protected]> wrote:
> > > On 29 Aug 2016, at 15:32, Martin Buchholz <[email protected]> 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? >
