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

Larry Riedel larryr@saturn.sdsu.edu
6 Jan 2004 08:09:48 -0000

> > but it would still make sense to me to try to provide
> > /some/ shared ancestor type which provides a /single/ way to get
> > the value from an Integer /or/ an AtomicInteger.
> The fact that this makes sense concerns me, because there was never an
> intent to associate AtomicInteger with Integer or AtomicLong with
> Long, or to suggest that one might ever want to replace an Integer by
> an AtomicInteger etc. Will changing the names to AtomicIntValue and
> AtomicLongValue break this association?
> Would it also help clarify things if I said that what some people
> really wanted to do was introduce an 'atomic' field modifier and
> introduce a test-and-set operator, but there was no way that was
> going to happen so we had to define the AtomicX classes?

With Integer vs "AtomicIntValue", I am imagining that while there is
some stuff to do with how/when/if the value gets changed, the bottom
line is there is a single primitive "int" value somewhere, and it is
the value of that int which is the critical piece of information, and
from the point of view of something which just wants to know what the
value is, it makes no difference whether the value is under the control
of an Integer or an AtomicIntValue, or whatever.  I think this would be
the basis of any (mis)understanding I have.

I know when it comes to parallel threads accessing some value there
is some stuff about memory barriers and "volatile" and "synchronized"
and I need to do things the right way in my code if I want to make
sure the threads see uptodate values; but the type of the value is
the type of the value, regardless.  If instead of a language thing
"volatile int i", there was a "VolatileIntValue i", I would still think
the fundamental value is an "int" and I want to be able to use it as
an int.  Otherwise it would seem to me like the tail is wagging the dog.

As far as replacing "Integer" with "AtomicInteger", I would expect that
to be equivalent to if there was a keyword "atomic" and I was thinking
about replacing "int i" with "atomic int i".  Sure that seems like
something I would like to do if it means I could get rid of some extra
code I had written to ensure atomic updates to "i" before the "atomic"
feature became part of the language.

(I treat "Integer" and "int" as the same, because my expectation has
been that auto(un)?boxing with JDK 1.5 will make that effectively true)