Intended uses of 1.5 atomics package

[Christopher Benson-Manica]

I, in my naivete, have thought that the classes in
java.util.concurrent.atomic were intended for situations like

class foo {
private int bar=0;

synchronized public int getBar() {
return bar;
}

synchronized public void incrementBar() {
bar++;
}
}

, which can be refactored as

class foo {
private AtomicInteger bar=new AtomicInteger();

public int getBar() {
return bar.get();
}

public void incrementBar() {
bar.getAndIncrement();
}
}

Does this example miss the real point of why the
java.util.concurrent.atomic classes exist?

 

[Moiristo]

Christopher Benson-Manica wrote:

Does this example miss the real point of why the
java.util.concurrent.atomic classes exist?

You're coming up with a very simple example here. When you create a
multi-threaded application, it can become very difficult to make
something atomic. In that case, the java.util.concurrent package can be
extremely useful to the programmer.

 

[Thomas Hawtin]

class foo {
private AtomicInteger bar=new AtomicInteger();

^final
(really make sure each thread see the initialiser value)

public int getBar() {
return bar.get();
}

public void incrementBar() {
bar.getAndIncrement();
}
}

Does this example miss the real point of why the
java.util.concurrent.atomic classes exist?

The code isn't much simpler. However it may well be much faster,
particularly on a multiprocessor machine where an instance is used
frequently by multiple threads.

There is a similar example in the 1.6 (mustang) API docs for ThreadLocal
(which now even compiles).

http://download.java.net/jdk6/docs/api/java/lang/ThreadLocal.html

From 1.5, in the source of java.util.Random.next there is an example of
using AtomicLong.compareAndSet to avoid a lock (could have used
weakCompareAndSet in this particular case). In 1.5 the class as a whole
is theoretically thread unsafe as the AtomicLong is not final.

Tom Hawtin

 

[Thomas Hawtin]

So is there any argument against refactoring to use the atomic package
where possible?

Obviously it takes time and causes diffs. You could be doing something
more productive. If you are working alone on the code, then it might be
something you'd consider doing when you've got a odd piece of time.

Also there's compatibility. Probably few people who are committed to 1.5
are going to jump back to 1.4 at this time. However, Java ME isn't like
to get java.util.concurrent any time soon.

Tom Hawtin

 

[Christopher Benson-Manica]

The code isn't much simpler. However it may well be much faster,
particularly on a multiprocessor machine where an instance is used
frequently by multiple threads.

So is there any argument against refactoring to use the atomic package
where possible?