[concurrency-interest] Re: AtomicInteger and AtomicLong should
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
>>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
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.