[concurrency-interest] Re: AtomicInteger and AtomicLong should
Gregg G. Wonderly
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
email@example.com (Cyte Technologies Inc)