RFR: JDK-8074578 Document memory visibility effects of some Unsafe methods

[Martin Buchholz]

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.holmes at 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
>