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

Gregg G. Wonderly gregg.wonderly@pobox.com
Tue, 06 Jan 2004 13:32:42 -0600

>Gregg Wonderly wrote:
>> But they contain values that might be referenced in such a way, and
>> having to have two references to the same value by doing
>> 	AtomicInteger i1 = new AtomicInteger(0);
>> 	... and later...
>> 	externalRef = new Integer( i1.get() );
>> is not going to produce high quality applications.
>If you are currently doing calculations with ints and floats, then
>presumably you must convert to Integer and Float at some point to
>externalize those values (I presume this because Integer et al are
>immutable and not conducive to use directly in calculations). If so,
>then you would replace those int's (there's no atomic float support)
>with AtomicIntegers where appropriate and then convert the
>AtomicInteger to an Integer when needed - there's no extra step just a
>different starting point.

One of the potential uses is to write data to a database and objects must be 
converted to java.sql data types to do this.  Number types are automatically 
converted already.  Another use is reflection.  Where, a value is converted to 
a string to be written to a properties file or some other textual 
representation.  In both of these cases, the lack of 'is a Number' increases 
the complexity of the code involved.

>> I would imagine a lot of people taking these classes and
>> using them in unimaginable ways because everyone will see
>> the word Atomic in the name and think wow this will keep be
>> from spewing 'synchronized' all over my code.
>They would be mistaken in many cases. Any kind of calculation using
>concurrently updating values will likely require atomicity that can't
>be achieved by accessing the individual values atomically.

Imagine parallel operating threads that are measuring some parameter and 
recording that value in a sum.  AtomicX.getAndAdd() provides a way to do this 
summing with synchronization.

>The uses for these classes are fairly simple in the direct sense. The
>algorithms that utilise them can be extremely sophisticated of course.
>> Then, others of the numerically minded type will see 'Integer'
>> and 'Long', and say wow, "Number"s this will let me have lots of
>> calculating threads that can just bang on these values and
>> I won't have to worry about 'synchronized'.
>Given that Integer and Long et al are immutable anyone associating
>AtomicInteger with Integer and AtomicLong with Long should immediately
>become extremely puzzled as they wonder what it is about an immutable
>value that needs to be made atomic ;-)

Yes, a lot of people use the Number subclasses to do math and do have to 
recreate the result Object.  That is one of the issues.  But, my main interest 
is in arriving at a solution to all the referential uses of these values.  In 
the lowest level of my expression evaluation, you will find (as you might 
imagine) code of the form

	new Double(((Number)obj1).doubleValue() * ((Number)obj2).doubleValue())

The cast to Number and the promotion to double are simplifying capabilities. 

>I could buy into your argument if we were talking about existing
>general-purpose arithmetic classes, but we're not, we're talking about
>the immutable wrapper classes. And AtomicInteger and AtomicLong do not
>even pertain to Integer and Long but to int and long.

I don't know what kind of software you have written or used the Number 
descendants with, but I have used these values all over the software that I 
have because I have Hashtable and Vector and List objects that must have 
objects in them.  So, anyplace that I have numeric values, I have to use these 
classes.  So, for me, these are general-purpose arithmetic classes because I
do have to use them in lots of places.  The fact that the Number subclasses 
are immutable is an issue in and of itself.  But, it does provide a 
simplifying capability for security implementation and for some optimizations.

>So while I can envisage a world with a broad range of numerical
>support classes where AtomicX forms part of the spectrum, that is not
>the world we have in Java today and it's not the world AtomicInteger
>and AtomicLong were designed for.
>The only thing that Number gives you is the ability to convert to any
>of the primitive numeric types and that is of extremely limited

It depends on what types of applications you write.  I sounds like you may not 
have encountered applications that utilize JDBC and/or reflection techniques 
to carry data types around.  Anything that provides a generic value transport 
or coversion mechanism as part of its API is saddled with this issue, and it 
is those types of applications that I am trying to bring forward as issues for 
these two classes.

I also believe that it would be wise to provide a 'double' value version of 
these classes and make them even more generic in expected use.

>I am becoming more convinced however that we should change the names
>to AtomicIntValue and AtomicLongValue just to avoid the possibility of
>associating these with Integer and Long.

I think that this doesn't change the use cases that people will find for these 
classes.  I think you are underestimating the needs that people will see these 
classes filling.

gregg@cytetech.com  (Cyte Technologies Inc)