[jmm-dev] weakCompareAndSet memory semantics

[Paul Sandoz]

> On 20 Apr 2016, at 13:56, Doug Lea <dl at cs.oswego.edu> wrote:
> 
> On 04/20/2016 06:03 AM, Andrew Haley wrote:
>> On 20/04/16 10:55, Aleksey Shipilev wrote:
>>> I wonder if that was the intended use for weakCAS in C++11, and if so,
>>> shouldn't we re-spec weakCAS in Java to have volatile/seq_cst memory
>>> effects?
>> 
>> Probably.  Or, at least, we want a weakCompareAndSet which is sequentially
>> consistent.  As a general principle: we have an opportunity to make Java's
>> operators consistent with those of C++, and we shouldn't mess that up.
>> 
> 
> Yes. I'm not sure what happened to method weakCompareAndSetVolatile
> that was in early sketches but disappeared (probably my fault) without
> me or anyone else noticing. Aleksey and/or Paul: Can you add this?
> 

Yes.

Aleksey and I propose:

/*
* Possibly atomically sets the value of a variable to the {@code newValue}
* with the memory semantics of {@link #setVolatile} if the variable's
* current value, referred to as the <em>witness value</em>, {@code ==} the
* {@code expectedValue}, as accessed with the memory semantics of
* {@link #getVolatile}.
*
* <p>This operation may fail spuriously (typically, due to memory
* contention) even if the current value does match the expected value.
…
*/
public final native
@MethodHandle.PolymorphicSignature
@HotSpotIntrinsicCandidate
boolean weakCompareAndSetVolatile(Object... args);

We will follow up with notes on C++11 comparison later [1].


We have what might be reasonably considered a naming glitch.

We have:

- compareAndSet, with “volatile" semantics
- compareAndExchangeVolatile
- the proposed weakCompareAndSetVolatile
- and weakCompareAndSet, with “plain” semantics.

I suggest we assume by default CAS/CEA are all have “volatile” semantics:

- compareAndSet
- compareAndExchange [2]
- weakCompareAndSet [3]

Then the existing weakCompareAndSet is renamed to:

  weakCompareAndSetPlain

?

Paul.

[1] https://bugs.openjdk.java.net/browse/JDK-8153875
[2] https://bugs.openjdk.java.net/browse/JDK-8154737
[3] https://bugs.openjdk.java.net/browse/JDK-8154755