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

Gregg Wonderly gregg.wonderly@pobox.com
Tue, 13 Jan 2004 08:24:51 -0600


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

Performance is not the primary issue here.  The primary issue for me is 
that I am going to have to synchronize through memory allocation to 
create all these new objects.  I am also going to expand the JVM's 
memory use to have to representations of the same thing.  There seems 
little advantage to this.

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

But, I would completely understand this issue, and I would get to deal 
with the results.  I don't think that we can protect people from poor 
programming habbits.  I am sure that there have already been people who 
have had the experienec of creating mutal objects that they have used as 
keys in maps and lost the objects.

I do not think that making these classes not have a value based equals 
and compareTo will keep all mutable classes from being misused.  Thus, I 
see little value in this attempt at policing misuse.

> 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
> worse)

The idea behind AtomicX is that it is whatever value it currently holds. 
  Whether I change that value occasionaly, continuously is not defined 
by the class.  Each application will do something different.

In queuing theory, we all know that if you have 100 threads that are all
in the same process loop, all influenced by the same relative latencies, 
that eventually all threads will end up waiting back to back at any 
synchronized section of code if there is any significant difference in 
the relative latency of any particular section.

synchronization puts the breaks on effective load distribution with a 
multithreaded pattern.  Thus, these objects should not implicitly or 
explicitly require the user to inject any synchronization into their 
application.  Memory allocation is one of the predominant 
synchronization latencies in a multi-threaded highly dynamic 
application.  In embedded applications on microcontollers, memory is at 
a premium in general.  Also, the use of the GC is something that is 
generally avoided.  With RT-JAVA, there is opportunity to separate 
threads from the GC.  But, as soon as any thread has to allocate a 
mirror object for one of these objects, on a repeated bases, you've 
impacted the application big time, in this type of environment.

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

That is a single pattern which may or may not be the predominate use of 
these classes.  I think that its shortsighted to keep throwing this 
single issue up as THE ARGUMENT.

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

Its only Pandora's box if there is good lively discussion.  I think that 
is what is happening. API development in a vacuum can typically result 
in APIs that belong "in a vacuum".  If everybody gets a chance to voice 
their opinion, then the API gets to be improved where the arguments hold 
value.  This is a good thing!

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

Okay, no more arguments about "AtomicX as a hashmap key" :-) Let's try 
and find some other issue besides how mutability inpacts these classes 
as keys to see if there is a strong case for not making equals and 
compareTo be value based.

Gregg