[jmm-dev] bitwise RMW operators, specifically testAndSetBit/BTS

[Paul Sandoz]

> On 18 Jul 2016, at 21:31, Doug Lea <dl at cs.oswego.edu> wrote:
> 
> On 07/18/2016 07:43 AM, Paul Sandoz wrote:
> 
>> In terms of the Unsafe Java implementations have i got the following correct (it’s the acquire variant i am unsure of)?
>> 
> 
> These look OK. For ARM/POWER, it's possible to avoid some fences in loops
> at assembly level, but that's why they are intrinsics.


Here is an initial (and untested) webrev for those that might be interested:

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8161444-vhs-bitwise-atomics/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8161444-vhs-bitwise-atomics/webrev/>

Paul.

> 
>> 
>> Separately, i would like to propose a naming scheme:
>> 
>> - for the read or write method, plain is the default.
>> 
>> - for read-modify-write methods volatile is the default volatile
>>   - rename weakCompareAndSet to weakCompareAndSetPlain
>>   - rename weakCompareAndSetVolatile to weakCompareAndSet
>>   - deprecate (not for removal) Atomic*.weakCompareAndSet, add Atomic*.weakCompareAndSetPlain
>>     which leaves the inconsistency of Atomic*.weakCompareAndSetVolatile.
>> 
> 
> Sure. This does seem slightly better.
> (And I'm content to continue to take the blame for OKing the naming :-)
> 
>> 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.
> 
> -Doug
> 
> 
> 
>