Intended uses of 1.5 atomics package

Thread view:

Christopher Benson-Manica - 04 Aug 2006 19:00 GMT

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?

Signature

C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

Reply to this Message

Moiristo - 04 Aug 2006 22:18 GMT

<cut>

> 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.

Reply to this Message

Thomas Hawtin - 08 Aug 2006 10:36 GMT

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

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

> public int getBar() {
> return bar.get();
[quoted text clipped - 7 lines]
> 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

Reply to this Message

Christopher Benson-Manica - 10 Aug 2006 14:33 GMT

> 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?

Signature

C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

Reply to this Message

Thomas Hawtin - 10 Aug 2006 11:10 GMT

>> 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?

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

Reply to this Message

Intended uses of 1.5 atomics package

Free Magazines