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

Dawid Kurzyniec dawidk@mathcs.emory.edu
Mon, 12 Jan 2004 23:43:19 -0500

> -----Original Message-----
> From: concurrency-interest-admin@cs.oswego.edu 
> [mailto:concurrency-interest-admin@cs.oswego.edu] On Behalf 
> Of Gregg Wonderly
> Sent: Monday, January 12, 2004 10:41 PM

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

Yes, a get() call - that's even more than a bit, it is 5*8 = 40 bits ;)

Not to mention that it actually may _improve_ performance to copy values
into int[] arrays and sort them using Arrays.sort() rather than
performing sort directly on object arrays.

> I have been bit by putting more than one instance of 'new 
> Integer(42)' 
> as the key in a hashtable.  

You would be hit much more badly by mutable keys. Se my response to
Larry's e-mail.

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

The idea behind Numbers is that 42 _is_ 42. The 42 number is
(conceptually) the same object as any other 42 number. If you put
objects to the JTree node, you want to put _different_ objects there,
don't you? (I understand though that it can be misleading, but that's
apparently the model of JTree, and alternatives would likely be much

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

It is a very different situation; Numbers are safe as map keys, atomics
are definitely not. (See my response to Larry's e-mail).

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

That's what I meant by a Pandora's box ;)

I personally believe that they're not numeric values, but holders of
numeric values. The relation to Number class, approved by the EG, is
merely a convenience. But again, the decision to be made (or already
made) is based not merely on our taste or beliefs but on careful
evaluation of benefits, drawbacks, possible usage scenarios, and dangers
of possible misuse. Let us keep focused and not reiterate.