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

Larry Riedel larryr@saturn.sdsu.edu
13 Jan 2004 07:32:17 -0000

> > Besides the frequent querying of the object state, there are 
> > various things the application does which leverages the fact 
> > that the state of the object seldom (if ever) changes, by 
> > assuming the state will be constant during a sequence of 
> > operations, or maybe it is virtually guaranteed to take place 
> > between state changes because the completion of the sequence 
> > of operations is one of the logical criteria affecting the 
> > decision to change the state of the object.  
> If you know that the value will not change, you could (and should)
> use the momentary value obtained by .get() as a hashtable key

My perspective is that a sine qua non of this thread ("AtomicInteger
and AtomicLong should implement Number") is the idea of assumption of
the type of the guarded/wrapped entity by the class of wrapper object.
I consider a method which returns a snapshot of the state of the
guarded entity to be pretty much orthogonal to that, to some extent
similar to the idea of using clone() instead of intValue().

> I claim that there is not a single legitimate use of value-based
> comparison methods for AtomicX classes, and this claim so far has
> not been proven wrong.

Such an opinion cannot be proved right or wrong.  My opinion is that
in the case of a class whose instances each provide an atomic access
wrapper/guard for an instance of particular type of entity, it is useful
and valuable for that class to assume the type of the entity, so that
the atomicity is adjunctive rather than disjunctive.  I believe my
opinion cannot be proved right or wrong either, although that does not
mean it is not a lame opinion. :)