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

[Doug Lea]

On 07/21/2016 10:57 PM, John Rose wrote:

> Putting aside the history and esthetics of terms, the big question
> here is whether to remove the exception for 64 bit types in
> 17.7 (Non-atomic Treatment of double and long), and mandate
> that all primitive types are atomic, including non-volatile longs
> and doubles.

(This was in the initial issues list for JMM revision, and like
every other issue, refuses to go away all by itself :-)

>
> Is it time to do that yet, or is there some 32-bit JVM out there
> that will fall over if it has to do the volatile dance even on
> non-volatile types?
>
> I'm going to guess that there still *ARE* such JVMs out there,
> but their number is decreasing exponentially over time.
> Eventually we can do this.
>
> Argument to keep things as they are:  64-bit non-atomicity
> (aka struct tearing) is just a precursor to non-atomicity of 128-bit
> and larger value types.  It's a permanent feature on our landscape,
> so don't fight it.

Right. I think that this where we last left this.

>
> VarHandles provide an easy-enough way to select either the
> atomic or the non-atomic accesses for 64-bit things (right?)
> and presumably they will do the same for value types.
>
> I see one possibly urgent argument to move away from
> non-atomicity of longs in the VH API:  VH's support atomic
> operations on arbitrary, unprepared longs.

The recommended usage is that (as has always been the case), concurrently
accessible fields should be declared as volatile. This provides safe defaults.
People can then use VH for other (non-Plain) access methods.
If people follow this usage guidance, all is well. Except that this doesn't
hold for array elements, that cannot be declared as volatile.
Here, usages relying on access atomicity must use only non-Plain access
methods.  This is not always easy to ensure -- people need to avoid
calling other methods that might access elements without VarHandles
unless there is no possibility of concurrent access during call.
But people writing intentionally racy code using arrays need to be careful
about things like this anyway.

-Doug