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

Dawid Kurzyniec dawidk@mathcs.emory.edu
Tue, 13 Jan 2004 13:26:39 -0500

On Tuesday 13 January 2004 12:53 pm, Riad Mohammed wrote:
> Gregg Wonderly wrote:
> > Dawid Kurzyniec wrote:
> > > It is a very different situation; Numbers are safe as map keys, atomics
> > > are definitely not. (See my response to Larry's e-mail).
> >
> > That is a single pattern which may or may not be the predominate use of
> > these classes.  I think that its shortsighted to keep throwing this
> > single issue up as THE ARGUMENT.
> I have to agree.
> There is no restriction on mutable objects being used as map keys beyond
> general good programming practice. But it does not follow that if a mutable
> object is used a key then it is always a bad programming practice.

It is always a bad programming practice (actually, an error) if it is possible 
for the value to change _while_ it is used as a key. (Again, I gave details 
in my response to Larry's e-mail).

> The use case would be that at some point my internal AtomicX is no longer
> being changed and I want to use it a key. One way is to make an immutable
> object with AtomicX value and the other is to use the AtomicX object as the
> key directly. The former is the safest but since my internal implementation
> has the knowledge that the AtomicX is not being changed then the immutable
> object creation is an unnecessary step.

So let me try to summarize this:
1) the purpose of atomic classes is to allow atomic, unsynchronized concurrent 
2) the only non-erroneous usage scenario of value-based comparison (for 
atomics in particular) is if it is guaranteed that the comparisons yield 
consistent results during the usage, i.e. values do not change during the 
3) there exist valid usage scenarios where it is preferable to use default, 
identity-based comparison of atomics (see previous Doug Lea's e-mail). 

Given that the behavior of 2) can be obtained with "get()" in a safer way 
(which, for instance, does not break if semantics of the program change in 
the future, allowing the atomic value to change), and that 2) in principle 
conflicts with the purpose of atomics defined in 1), and that 3) seems more 
likely than 2), I argue that the default comparison for atomics should be