RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics

[David Holmes]

Please ignore :)

I was "catching up" with year old email. :D

Same sentiment applies though.

David

On 4/08/2017 11:57 AM, David Holmes wrote:
> Catching up after very long vacation.
> 
> For the record I still think this is misguided. The only atomic op you 
> can do with float/double is a CAS (and that doesn't operate at the 
> semantic level only raw bits). Everything else has to be emulated by 
> CAS-loop as no hardware support for atomic FP ops exists.
> 
> We made a deliberate choice not to support float/double in j.u.c.atomic 
> back with JSR-166 and _nothing_ has changed since then.
> 
> Regards,
> David
> -----
> 
> Paul Sandoz paul.sandoz at oracle.com
> Tue Jun 14 00:12:14 UTC 2016
>> Hi,
>>
>> Here is an updated webrev.
>>
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/ 
>>
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/ 
>>
>>
>> Changes
>>
>> - the Unsafe.getAndAdd for float/double operate in the bit-domain.
>>
>> - documentation added to the factory methods:
>>
>> 1221          * <p>
>> 1222          * If the field type is {@code float} or {@code double} 
>> then numeric
>> 1223          * and atomic update access modes compare values using 
>> their bitwise
>> 1224          * representation (see {@link Float#floatToRawIntBits} and
>> 1225          * {@link Double#doubleToRawLongBits}, respectively).
>> 1226          * <p>
>> 1227          * @apiNote
>> 1228          * Bitwise comparison of {@code float} values or {@code 
>> double} values,
>> 1229          * as performed by the numeric and atomic update access 
>> modes, differ
>> 1230          * from the primitive {@code ==} operator and the {@link 
>> Float#equals}
>> 1231          * and {@link Double#equals} methods, notably with 
>> respect to
>> 1232          * {@code NaN}.  There are many possible NaN values that 
>> are considered
>> 1233          * to be {@code NaN} in Java, although no IEEE 754 
>> floating-point
>> 1234          * operation provided by Java can distinguish between 
>> them.  As such
>> 1235          * care should be taken when performing a compare and set 
>> or a compare
>> 1236          * and exchange operation with NaN values since the 
>> operation may
>> 1237          * unexpectedly fail.  Failure can occur if the expected 
>> or witness
>> 1238          * value is a NaN value and it is transformed (perhaps in 
>> a platform
>> 1239          * specific manner) into another NaN value, and thus has 
>> a different
>> 1240          * bitwise representation (see {@link 
>> Float#intBitsToFloat} or
>> 1241          * Double#longBitsToDouble for more details).
>>
>> (I also updated the documentation on array/ByteBuffer view methods but 
>> did not bother with the api note)
>>
>> Paul.
>