On Sat, 23 May 2009, Joshua Cranmer wrote:
Stefan Ram wrote:
So, inspired by ?Swing application architecture question.?, here is
my (lack of )wisdoms about threads:
- To correctly use multi-threading, a special education is needed.
I do not yet have taken the time to undergo this, so I need
to refrain from using threads (that is, more than one thread).
I wouldn't say that special education is needed at Java's level of
abstraction. I've been able to do it to some degree, and I certainly never
had it yet. If you know what synchronized does and when you might want to
use volatile, you'll probably be fine. Java 5 and 6 (and possibly 7)
introduce new concurrency utilities that eases some use, especially if you
have a lot of threads interacting.
Some of them also make life more complicated, because you have more
options!
I do like AtomicBoolean, though. It lets you implement something that's
like an optional synchronized block. Rather than:
private final Object lock = new Object();
synchronized (lock) {
doStuff();
}
You do:
private final AtomicBoolean lock = new AtomicBoolean();
if (lock.compareAndSet(false, true)) {
try {
doStuff();
}
finally {
lock.set(false);
}
}
This still guarantees mutual exclusion, but means that if a second thread
comes along while a first thread is in the critical section, rather than
blocking, it skips over the critical section. I used this construct to
guard some housekeeping work in a multithreaded program; something that
needs to be done quite often, but must only be done by one thread.