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

David Holmes dholmes@dltech.com.au
Tue, 6 Jan 2004 14:56:24 +1000

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.

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

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

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.

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

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.

David Holmes