We had already agreed on making these changes, and the detail looks good, so approved!
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. On Thu, Aug 25, 2016 at 1:48 PM, Paul Sandoz <paul.san...@oracle.com> wrote: > Hi, > > Please review: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8164814-- > atomics-weakCompareAndSet-deprecate/webrev/ <http://cr.openjdk.java.net/~ > psandoz/jdk9/JDK-8164814--atomics-weakCompareAndSet-deprecate/webrev/> > > This patch deprecates weakCompareAndSet and adds a new method > weakCompareAndSetPlain. The intent is to avoid confusion over the memory > effects of such methods, since other read-modify-write methods, with > unqualified names, have volatile memory effects. > > I just modified atomic classes that have already been updated for Java 9 > [*]. > > Paul. > > [*] atomic classes not updated: > AtomicIntegerFieldUpdater > AtomicLongFieldUpdater > AtomicMarkableReference > AtomicReferenceFieldUpdater > AtomicStampedReference > >
