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