On Fri, Jan 22, 2016 at 5:23 AM, Doug Lea <d...@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?
