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.