RFR 8151198: VarHandle factory-specific exceptions

[Vitaly Davidovich]

The issue with "program order" is it may confuse people, particularly ones
that don't know what a compiler fence is, into thinking it implies CPU
fences as well (they may not know those either, perhaps).  You'd need to
define program order anyway for them.  IMHO, I'd rather see compiler fence
used in description rather some more general notion; most people using this
API will understand compiler fence, no need to make it more abstract.

On Saturday, April 9, 2016, Doug Lea <dl at cs.oswego.edu> wrote:

> On 04/09/2016 09:03 AM, Vitaly Davidovich wrote:
>
>> Just to confirm - opaque is also a compiler fence right? C++ relaxed
>> doesn't
>> require compiler fence, but it sounds like opaque does.  Would be good to
>> clarify this, unless "program order" is the way you want to do that.
>>
>>
> "Program order" normally requires a compiler fence.
> Most people don't know what a compiler fence is though, and
> it is not especially easy to define. So I don't think this would
> help.
>
> -Doug
>
>
> On Saturday, April 9, 2016, Doug Lea <dl at cs.oswego.edu
>> <mailto:dl at cs.oswego.edu>> wrote:
>>
>>     On 04/08/2016 02:39 PM, Hans Boehm wrote:
>>
>>         My prior impression was that Opaque was intended to be similar to
>> a C++
>>         memory_order_relaxed access to a variable that is declared as
>> both atomic
>>         and volatile, with the unordered interpretation of C++ "volatile".
>>
>>
>>     Yes. This is awkward to spell out in detail, but surely there is
>>     some way to say it that is more illuminating than confusing.
>>     Especially since the implementation on all known processors
>>     is straightforward -- reading/writing (all bits atomically) in
>> program order.
>>
>>     -Doug
>>
>>
>>
>>
>> --
>> Sent from my phone
>>
>
>

-- 
Sent from my phone