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

Larry Riedel larryr@saturn.sdsu.edu
12 Jan 2004 07:47:07 -0000

> Would it make sense to have XYZ.atomicX that would return a
> atomic version of X akin to Collections.synchronizedMap?

Something like XYZ.atomicXYZ() which would return a reference
to an object of the same type but with atomic access semantics?

I think it would be great to be able to get nice support for that
kind of approach to atomic access.  I would welcome an approach
which treats atomic access as orthogonal to the type system,
so for example the java.util.concurrent support for atomicity
would be explicitly agnostic to whether developers will properly
utilize compareTo(), equals(), hashCode(), etc, for objects with
some atomic access semantics.

But it looks to me like things are not going that way, for example it
appears AtomicInteger will provide intValue(), but will not provide
the corresponding obvious(*) implementations of compareTo(), equals(),
and hashCode(), because "usages would almost never be correct".  MY
assumption would be that with competent software engineers at the helm,
which I think should be a fundamental assumption behind ALL API design,
usages would be as correct as they are with anything else.

(*) essentially:

        int compareTo(Object that):
            thatValue = (Number)that.intValue();
            thisValue = this.intValue();
            if (thisValue == thatValue)
                return 0;
                return (thisValue < thatValue) ? -1 : 1;

        boolean equals(Object that):
            return (((Number)that).intValue() == this.intValue());

        int hashCode():
            return intValue();

    Given what I would assert to be a widespread understanding that
    classes which implement Comparable and provide their own equals()
    and hashCode() are not necessarily immutable, and consequently the
    above implementations are not deterministic in the general case,
    I think developers would have no problem understanding that will
    continue to be true in the case of classes with some efficiently
    atomic methods, especially since it would presumably be documented
    as such, like the way those methods are documented with ByteBuffer.