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

Gregg G. Wonderly gregg.wonderly@pobox.com
Thu, 15 Jan 2004 09:26:53 -0600


>I often write low-level system code (I admit - not embedded systems),
>but I never do any arithmetic on number wrappers. If you really have
>tight performance/heap memory constraints, you don't write generic
>algorithms which work on generic number wrappers in a type-neutral way,
>but you rather settle with some degree of redundancy by providing
>specialized versions working with primitive types. (java.util.Arrays
>class is a good example).

This is a fact from peoples experience with really lousy embedded environments 
where support for objects is expensive and where native types really are 
faster.  Have you used the aJile aj-100 any?  It's fast, it runs byte codes 
natively.  An object member reference is thus not any more 'expensive' or 
'indeterminate in cost' than a native.  But, if you add another level of 
delegation by wrapping (as opposed to subclassing) then you will have more 
overhead.  Also, if I have to copy all of the existing AtomicX values into new 
Integer values so that I can sort, group or use a value based equals() and/or 
compare to, then I am doubling my use of Objects for that particular case.

I work in industries that do data aquisition in embedded systems.  There are 
often thousands of points of interest visible in user interfaces.  These 
points change based on low level data gathering devices (such as those that 
might be built using the aJ-100.  It is important to me to make the display of 
data changes as fast as possible.  It is important to minimize garbage 
creation because that is what causes hickups in the UI that make people not 
sure of what they are seeing.  There are all kinds of places where code can be 
instrumented with these classes (a profiling compiler can generate uses of 
these classes to watch code execution etc).  All over the place, there are 
numeric algorithms using Objects because that is what is the easiest to store 
in maps, vectors and other dynamically resizing containers.

Is the important thing about the AtomicX classes that they are objects or is 
the important thing in them the numeric value.  I contend that the information 
about these classes that is most important is the numeric value inside.  Thus, 
they really should provide numeric value based equals and implementing 
Comparable would be a great help.

If we can not agree on this, then perhaps considerable thought should be given 
to creating subclasses in this package that do provide value based equals() 
and compareTo() so that there is a standard way for that use case to be 
present in Java programs as well.

>And usually you don't even have to, because
>most of the time you know the types you work with. Some things are ints,
>others are doubles, sometimes there are characters and bytes (but
>usually within arrays), and you tend to have different algorithms for
>all them. Greg claimed he had a valid use case for Numbers in embedded
>systems, but he failed to prove it when challenged (and I attribute his
>emotions to good intentions and strong beliefs, so no offense taken).

It is personal taste in embedded development regarding how lowevel or how 
close to the hardware you are willing to program.  I try to stay as far away 
from the hardware level details as I can.  I create interfaces that describe 
what I need to do, and then write the low level classes that provide the how.  
This makes it much more likely that I can switch out the hardware.  I even 
study the implementation details of multiple pieces of hardware that might 
have to be used at a later date, and engineer the interface with the 
commonalities of all the hardware in mind.

So, if I had a numeric value that was part of details of the hardware and on 
some hardware it was 32bits and on other hardware it was 16bits and on another 
it was 64bits, then you bet that my interface would use Number to pass this 
thing around.  That way it really is independent.

Perhaps I'm crazy and consider more detail than others.  But, I really am 
serious about this issue, and I really think it is a step sideways (almost 
backwards) to add atomic integral value access and not have a value based 
comparison visible in the objects implementation.

>Well, I thought about that, but: 
>
>First of all, people tend not to read javadoc if they believe they
>understand the API. With autocompletion etc., I do it all the time.
>(Although for equals() and hashCode(), I agree that it is a little
>different, because you want to know how is equivalence defined)

These same people are going to see "extends Number" and go woohoo a Number.  
They are then going to skip reading the rest of the JavaDoc and findout after 
some time that equals() is not value based.  They are going to be surprised...

>But, more importantly: I doubt it is possible to document it in javadocs
>in a way it does not sound, well, idiotic:

You are concentrating on a single issue (mutability makes comparison 
impossible under every single possible situation).  As I have stated before 
mutability is an issue with each and every Java Object created or used by Java 
programmers.  It is not a new issue and it is not going to go away.

>While I was writing it, other thing stroke me: the value-based equals()
>returning true does not even guarantee that the values EVER were the
>same, given the inherent race condition between reading values of two
>atomics and their possible concurrent modifications.

You are still supposing that every single time these values are reference by a 
call to equals that they are going to be actively engaged by code that is 
changing the values.  I can not see this being a good argument.  It is a 
situation when the use of value based comparisons is problematic.  But, it is 
not the case that this will be the only time these values could be involved in 
a value based comparison.

Would you be in favor of a value based equals() and no Comparable 
implementation?

-----
gregg@cytetech.com  (Cyte Technologies Inc)