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

Paul Sandoz paul.sandoz at oracle.com
Tue Jul 12 12:22:17 UTC 2016

> On 12 Jul 2016, at 13:30, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> On 07/12/2016 01:22 PM, Andrew Haley wrote:
>> On 12/07/16 11:19, Aleksey Shipilev wrote:
>>> On 07/12/2016 01:13 PM, Andrew Haley wrote:
>>>> I wonder if a better solution to this might be to make
>>>> VarHandle.{get,set}Opaque atomic on all primitive types.  This gives
>>>> us a way to get atomic operations on 32-bit machines without the
>>>> overhead of volatile accesses.  Being able to read a 64-bit counter
>>>> atomically is very useful.
>>> VarHandle.{get,set}Opaque is single-copy atomic for all primitive types.
>>> Pretty much like C++ std::atomic(..., mem_ord_relaxed).
>> So what does
>> Unless stated otherwise in the documentation of a factory method, the
>> access modes get and set (if supported) provide atomic access for
>> reference types and all primitives types, with the exception of long
>> and double on 32-bit platforms.
>> refer to?
> That's for VarHandle.{get|set}, not for VarHandle.{get|set}Opaque.
> Access mode "get" is different from access mode "getOpaque".
>> And where foes the spec say that VarHandle.{get,set}Opaque is
>> atomic?
> Nowhere yet. I tried to capture atomicity in Javadoc like this:
> http://mail.openjdk.java.net/pipermail/jmm-dev/2016-June/000282.html
> ...but it's not yet there.

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.


More information about the jmm-dev mailing list