API review of VarHandles

Martin Buchholz martinrb at google.com
Mon Jan 25 21:42:35 UTC 2016


On Fri, Jan 22, 2016 at 5:23 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 01/22/2016 04:51 AM, Andrew Haley wrote:
>>
>> On 22/01/16 00:01, Vitaly Davidovich wrote:
>>>
>>> I think the get/setOpaque methods need a bit more explanation ("opaque"
>>> is
>>> an odd naming choice, IMO).  Specifically, it says the operations are
>>> done
>>> in program order but have no effect on inter-thread ordering/visibility.
>>> Is this spec verbiage for a full compiler-only fence?
>
>
>
> Basically yes. It would be the same as C "volatile" (not C++/C11
> "atomic"), if C volatile had a memory model spec. But in any case
> we can't use "volatile" for this in Java because it already means
> something else.

It would be nice if we could actually say this in the (non-normative
part of the) javadoc.

>>
>> It's like C++ memory_order_relaxed, I guessed.  I understand that but
>> not "opaque".
>>
>
> The new name is required because opaque is only "like" C++
> memory_order_relaxed.
> See the jmm-dev list discussions last year for details, but annoyingly,
> Java normal variables and C++ memory_order_relaxed are not quite the
> same, and neither are the same as C-volatile/opaque.

Could we make atomicity guarantees clear for every method?  When can
we be sure not to get OOTA values?


More information about the valhalla-dev mailing list