[jmm-dev] Make load/store of 64-bit long and double atomic

[Paul Sandoz]

> On 12 Jul 2016, at 14:31, Andrew Haley <aph at redhat.com> wrote:
> 
> On 12/07/16 13:22, Paul Sandoz wrote:
>> It does state it here:
>> 
>> * Read/write access modes (if supported), with the exception of
>> * {@code get} and {@code set}, provide atomic access for
>> * reference types and all primitive types.
>> 
>> Before the “unless stated otherwise…” quoted above.
>> 
>> As part of the sweep through the specification we should make that clearer.
> 
> It's very hard to understand what is going on.  compareAndExchange()
> has stronger ordering semantics than compareAndExchangeRelease() but
> set() has weaker ordering semantics than setRelease().  We're making a
> real mess that nobody is going to thank us for.
> 

It’s an awkward situation. Doug previously mentioned in an email on core-libs:

>> No matter which conventions you choose here, some people will be
>> unhappy or confused. The current scheme seems to make the current users
>> of both Unsafe and AtomicX least unhappy or confused.

  http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042249.html.


You mentioned in a previous email the possibility of using doing something similar to C++ atomics and pass in the the memory order characteristics as a constant.

We did mull that over a little early on, one concern was the performance aspects. It might possible to pull that off with an enum and implementing the if/else in Java so it constant folds enabling reuse of existing intrinsics and simplifying the addition of new ones. That would be a significant deviation from the API/implementation/tests at this stage in the 9 release schedule. I suppose it’s something we could support later on as a complementary feature (e.g. using the “explicit” suffix in the method names).

Paul.