[concurrency-interest] Re: AtomicInteger and AtomicLong should implement Number

Dawid Kurzyniec dawidk@mathcs.emory.edu
Mon, 12 Jan 2004 16:42:16 -0500


On Monday 12 January 2004 11:48 am, Larry Riedel wrote:
> I would say it would, regardless of anything to do with atomic vs not
> atomic, be an inauspicious decision to use an object as a key in a
> hashtable during a period of time when its value as a key might change
> during the normal/expected course of events in the application.  

I have said it before: It HAS to do with atomic, since they are provided 
SPECIFICALLY to support unsynchronized concurrent modifications. If you don't 
have multiple threads sharing the mutable variable (that's what confinement 
is about, BTW), you didn't need the atomic class in the first place. If you 
have multiple threads sharing the variable, there is NO period of time when 
the value-based hashcode can be relied upon as constant unless you perform 
locking (synchronization) which again defeats the purpose of using atomic 
class.

On the other hand, I can imagine usage scenarios described by Doug where I'd 
put the atomic variable in the hashtable treating the variable as a shared 
*container*, depending on the default, identity-based implementation of 
equals().

BTW, that's yet another reason why I was opposing to the inheritance of 
atomics from Number: I was afraid that it would open this Pandora's box: "how 
come it is a number and it is not comparable?" etc.

Regards,
D