[concurrency-interest] atomic references

Jeremy Manson jmanson at cs.umd.edu
Wed Aug 23 00:31:08 EDT 2006

Dhanji R. Prasanna wrote:

> However, it is not clear if AtomicReference performs an == or an 
> equals() comparison. As we know v1 == v2 can be entirely different 
> from v1.equals(v2). Can anyone shed some light on which type of 
> comparison is done?

 From the JavaDoc:

> compareAndSet(V expect, V update)
> Atomically set the value to the given updated value if the current
> value == the expected value.

(and similarly for weakCompareAndSet)

So I would say you are getting a == comparison.  :)

> Furthermore, assuming the former (==), is it not incongruous for 
> AtomicReference to do a reference comparison while other atomics do a
> value comparison (on primitives)? Im curious about this one.

I think that the thing that must be understood about these classes is
that they are basically wrappers for hardware level atomic operations.
If there were a widely available hardware level atomic operation that
allowed you to do a CAS on more than 64 bits, then you would probably
get it.

OTOH, equals() doesn't have to test for equality at all.  It can do
something completely different.  Making it look atomic would be an
enormous undertaking.  If you are interested in that sort of thing,
you can look at the literature on software transactions, but none of it
is ready for deployment on a production system, really.


More information about the Concurrency-interest mailing list