[concurrency-interest] Re: AtomicInteger and AtomicLong should
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
> 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 == AtomicInteger2
These things really are numeric values. I think it would be best to
complete the contract and make them feel like numeric values.