atomic references

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

atomic references

Dhanji R. Prasanna
Hi

Ive a bit of an issue with AtomicReference. Semantically all the
atomic wrappers (AtomicInteger, AtomicLong etc.) perform an equals
comparison on a compareAndSet or weakCompareAndSet.

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?

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.

Thanks

Dhanji.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: atomic references

Jeremy Manson-2
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.

                                        Jeremy
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: atomic references

David Holmes-3
In reply to this post by Dhanji R. Prasanna
Dhanji,

> 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?

If you think about the purpose of atomics it can only be a reference
comparison ==. These are "raw" memory operations. And this is documented in
AtomicReference.compareAndSet/weakCompareAndSet


> 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.

== is always a value comparison - for AtomicReference the value being
compared is a reference.

For non-objects identity and equivalence are the same thing.

David Holmes

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest