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

Dawid Kurzyniec dawidk@mathcs.emory.edu
Tue, 13 Jan 2004 11:54:39 -0500

> -----Original Message-----
> From: concurrency-interest-admin@cs.oswego.edu 
> [mailto:concurrency-interest-admin@cs.oswego.edu] On Behalf 
> Of Gregg Wonderly
> Sent: Tuesday, January 13, 2004 9:25 AM
> Cc: concurrency-interest@altair.cs.oswego.edu
> Subject: Re: [concurrency-interest] Re: AtomicInteger and 
> AtomicLong should implement Number
> 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.

Unless you use some sort of a GUI (and if you did you'd not worry about
memory footprint of number wrappers), you probably don't need to create
wrappers at all, just use primitive values returned by get() -- this
induces no memory allocation whatsoever. You may need to allocate some
primitive arrays if you want to sort, but otherwise you would likely
have to allocate lists of objects for the same purpose. And, because you
have snapshots copied, you can actually release locks much earlier (or
even not lock at all) as you are able to process (sort, display,
analyze) the shapshot values while the program is running.

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

People with intentions to do so will be able to abuse (or find a way to
abuse) any single API. But the key assumption about the JSR166 audience
is that most programmers will want to write correct programs. Thus, API
should not endorse techniques which always (or in vast majority of
cases) lead to incorrect programs.

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

Other mutable classes and existing misuses are irrelevant to this API.
All that matters is that this API by itself does not endorse incorrect
techniques. Your argument is like "there is so much flaky code out
there; why don't we produce some more then?"

> The idea behind AtomicX is that it is whatever value it 
> currently holds. 

Again, this is your feeling, not neccessarily a fact (otherwise we would
not have this discussion).

> That (hashtables, sort - DK) 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.
> (...)
> 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.

>From the Object.hashCode javadoc:
"This method is supported for the benefit of hashtables such as those
provided by <code>java.util.Hashtable</code>"

>From the Comparable javadoc:
"Lists (and arrays) of objects that implement this interface can be
sorted automatically by <tt>Collections.sort</tt> (and
<tt>Arrays.sort</tt>). Objects that implement this interface can be used
as keys in a sorted map or elements in a sorted set, without the need to
specify a comparator.<p>"

Conclusion: sorting (or maintaining a total order) IS a predominant (if
not the only) use of Comparable. Hash maps and sets ARE a predominant
use of hashCode. Hence, these usage patterns are essential to evaluate
appropriateness of value-based comparison for atomics.

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

This is an open forum; opinions have been voiced, quite exhaustively in
fact. But we should respect the authority of the Expert Group, too. The
moment they decide, there is little point in continuing the argument
(unless someone has something really new to say).