[jmm-dev] bitwise RMW operators, specifically testAndSetBit/BTS
paul.sandoz at oracle.com
Tue Jul 19 08:39:14 UTC 2016
> On 19 Jul 2016, at 09:59, Andrew Haley <aph at redhat.com> wrote:
> On 18/07/16 20:31, Doug Lea wrote:
>>> On 07/18/2016 02:27 PM, Andrew Haley wrote:
>>>> On 18/07/16 12:43, Paul Sandoz wrote:
>>>>> - for the read or write method, plain is the default.
>>>>> - for read-modify-write methods volatile is the default volatile
>>>>> - rename weakCompareAndSet to weakCompareAndSetPlain
>>>> Why "plain"? Is this the same as C++ "relaxed"?
>> In this case, yes. But Java-plain is not necessarily always the
>> same as C++ relaxed, so we've been cautious with namings.
> Mmmm, but it's baffling for me, and I've been involved for a long
> time. We have "Opaque" and now "Plain". What is the difference
> between them? I haven't seen these terms anywhere else. Is this new
Plain behaves like non-volatile/non-final field access e.g. like get/putfield byte codes.
Both plain and opaque have “no assurance of memory ordering effects with respect to other threads” but opaque is stronger in the sense that the compiler is restricted in what optimisations it may perform, in a sense the access is “opaque” to the compiler e.g. it cannot elide the access or fold it into a more recent access etc.
A good example is presented in Aleksey’s VarHandles slides #55
I am still holding off updating the specifications to clarify, as Doug may have cooking some foundational tweaks from which we can build upon.
More information about the jmm-dev