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

Gregg Wonderly gregg.wonderly@pobox.com
Mon, 12 Jan 2004 21:40:39 -0600


Dawid Kurzyniec wrote:
> 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.

Here is what I am going to do with Atomics.

I am going to use them to instrument some applications that are very 
thread intensive.  I will have hundreds of these objects active in many 
cases.  Most will be in arrays or vectors for global reachability, but 
will be referenced directly by threads that need them.  Occasionally, I 
will lock things down, do some calculations, sorting and comparing and 
then reconfigure the system to improve performance.

Without compareTo and equals as value based, I will have to write a bit 
more code to dive into the values directly.  The native Number 
implementations follow the value contract that I thinks makes sense.

I have been bit by putting more than one instance of 'new Integer(42)' 
as the key in a hashtable.  It gets even worse when you use the native 
Number values in a swing JTree node.  The nodes values are keys to 
hashtables that find the node components with parallel vectors to 
maintain ordering.  You get the right number of tree 'rows', but only 
one of the rows will have the value drawn correctly because the 
hashtable will always find the last added node with the same key.

There is good reason, both for, and against making these objects 
implement compareTo() and equals() with the value.  Because so many 
people have probably already adopted practices of wrapping Number 
implementations in other objects to create unique values, I think it 
makes sense to roll with the flow and make these classes implement a 
value based compareTo and equals.

If you leave the default in place, there is no ordering defined right? 
So the only thing that is left is a comparison that is identical to == I 
believe.  I.e. will it not be the case that

	AtomicInteger1.equals(AtomicInteger2)
		IFF
	AtomicInteger1 == AtomicInteger2

These things really are numeric values.  I think it would be best to 
complete the contract and make them feel like numeric values.

Gregg