[concurrency-interest] Should I avoid compareAndSet with value-based classes?

Brian S O'Neill bronee at gmail.com
Thu Jul 6 00:47:34 EDT 2017


I think the wording in the value-based document is too strong. It's 
perfectly fine to compare value based instances using ==, but it can 
lead to confusing results when comparing distinct instances with 
equivalent state. Using compareAndSet with a box isn't necessary for it 
to work "correctly" with a value-based class.

By "correctly", I mean the compareAndSet operation works correctly, 
using == comparison. However, if your intention is for compareAndSet to 
compare Instants based on their state, then this of course won't work 
properly.

If you want to perform a compareAndSet for an Instant's state (time 
since epoch), then you need to use something that can be compared 
atomically. This means the state must be representable in a 64-bit value 
or smaller. The Instant class measures time using a 64-bit long and a 
32-bit int, and so this state cannot be compared atomically. You'd have 
to chop off some precision or use something else.


On 2017-07-05 09:20 PM, Gil Tene wrote:
> Reference equality for value based classes (as referenced below) lacks meaning, as there is no notion of identity in such classes (only a notion of value). And since compareAndSet on reference fields is basically an idenitity-based operation [in the compare part], the two won't mix well logically.
> 
> Specifically, while two references to e.g. java.time.LocalDateTime instances being == to each other *probably* means that the two are actually equal in value, the opposite is not true: Being != to each other does NOT mean that they are logically different. As such, the "compare" part in compareAndSet may falsely fail even when the two instances are logically equal to each other, leaving the rest of your logic potentially exposed.
> 
> Bottom line: given the explicit warning to not use == and != on references to value-based instances, I'd avoid using compareAndSet on those references. If you really need to use a value-based class in your logic, consider boxing it in another object that has [normal] identity.
> 
> — Gil.
> 
>> On Jul 5, 2017, at 8:59 PM, Michael Hixson <michael.hixson at gmail.com> wrote:
>>
>> AtomicReference and VarHandle are specified to use == in compareAndSet
>> (and related) operations [1].  Using == to compare instances of
>> value-based classes may lead to "unpredictable results" [2].  Does
>> this mean I should avoid using compareAndSet with arguments that are
>> instances of value-based classes?
>>
>> It seems like the documentation clearly tells me "yes, avoid doing
>> that" but I'm hoping I misunderstood, or maybe AtomicReference and
>> VarHandle are exempt somehow.  Otherwise, how do I implement
>> non-broken compareAndSet and updateAndGet for a java.time.Instant
>> value for example?  Do I have to box the value in something that's not
>> a value-based class first, like AtomicReference<Box<Instant>>?
>>
>> -Michael
>>
>> [1] http://download.java.net/java/jdk9/docs/api/java/util/concurrent/atomic/AtomicReference.html#compareAndSet-V-V-
>> [2] http://download.java.net/java/jdk9/docs/api/java/lang/doc-files/ValueBased.html

> 


More information about the Concurrency-interest mailing list