Re: stale objects in collections
Timo Nentwig wrote On 08/21/06 15:15,:
Eric Sosman wrote:
additional protection if you want to make a sequence of method
calls "atomic:"
// WRONG
if (set.isEmpty()) {
//
// "set" can change here
//
set.add("Elvis");
}
// RIGHT
synchronized(set) {
if (set.isEmpty()) {
set.add("Elvis");
}
}
Why isEmpty()? Why should I start a bunch of threads and only one can
actually write to the collections? We are proably talking at
cross-purposes here...
It was just an illustration of a situation where the
synchronization provided by synchronizedSet() is not enough.
In the WRONG example, isEmpty() is atomic and add() is atomic,
but the combination is not; the set is unlocked in between
the two operations, and the state of the world can change in
that interval. The RIGHT example avoids this by synchronizing
during the entire compound operation, leaving no "window of
opportunity" for interference. The synchronized(set) {...}
is necessary in RIGHT, even though the set's methods are
already synchronized by the synchronizedSet() machinery.
I'll admit the isEmpty()/add() example is perhaps not
too realistic, but that's not the essential point.
What I acutally do is starting multiple threads running the same SQL
statement (with different parameters) against a database and storing
the result in a Set. So, no duplicates, no Set.get(), no nothing.
Simply run query and put result in a Set. So, as I understand your
comment regarding join() below, I wouldn't need to synchronize the Set
(?).
You need to synchronize the different threads' accesses to
the set, or chaos will ensue. After you've joined all those
threads they are no longer running, hence they can no longer
be mucking around with the set. So no: Once the interfering
threads are out of the picture, no synchronization is needed.
Have you considered doing things just a little differently?
Why not let each thread put its results in its own private set,
and then combine them when the threads are all finished? The
threads don't need to synchronize their accesses to the sets
(because each thread manipulates only its own set, and doesn't
interfere with any other thread's set). And after the worker
threads have been joined, the main thread can access their sets
without synchronization because (as before) the threads are no
longer around to create interference. Rough sketch:
class MyThread extends Thread {
private Set mySet = new HashSet();
public void run() {
// fill mySet with results
}
public Set getSet() {
return mySet;
}
}
class Driver {
public static void main(String[] unused) {
MyThread[] t = new MyThread[10];
for (int i = 0; i < t.length; ++i) {
t[i] = new MyThread();
t[i].start();
}
Set bigSet = new HashSet();
for (int i = 0; i < t.length; ++i) {
t[i].join();
bigSet.addAll(t[i].getSet());
t[i] = null; // optional
}
// bigSet now holds combined results
}
}
--
Eric.Sosman@sun.com