I didn't expect this to be controversial. The spec for regular compareAndSet has similar wording. I don't think it matters whether implementation is via a lock, because the lock itself entails at least a volatile read and write. As to which variable is being read/written to, it should be obvious that it's the location being CAS'ed (or equivalent).
Can we clarify existing spec for atomics? http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/package-summary.html - compareAndSet and all other read-and-update operations such as getAndIncrement have the memory effects of both reading and writing volatile variables. On Sun, Mar 8, 2015 at 5:34 PM, David Holmes <david.hol...@oracle.com> wrote: > On 7/03/2015 6:49 AM, Martin Buchholz wrote: > >> A wee code review fer ya: >> >> https://bugs.openjdk.java.net/browse/JDK-8074578 >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Unsafe-CAS-spec/ >> > > Sorry Martin but this is neither accurate nor meaningful. It isn't > accurate because the actual Atomic::cmpxchg operations have full > bi-directional fences, and in the long case if locking is used you get > locking related barriers not volatile access barriers. It isn't meaningful > because you haven't said what variable the volatile semantics apply to (not > that that would help in the lock-based case). > > David >
