Re: Making one or more threads wait for another to produce a value
or fail
On 5/31/2011 7:00 AM, Tom Anderson wrote:
The scenario:
Penelope is a widow, or at least her husband isn't around any more
(she's not sure which; long story). There are 108 suitors who would like
to marry her. She hasn't decided which one she'll marry. So, the 108
suitors are sitting about waiting for her to decide. It's possible that
instead of deciding to marry one of them, she'll deliver some other,
exceptional, verdict (eg "turns out my husband is still alive, and will
now murder you all").
Penelope is a thread, as are her suitors. Penelope has plenty to do
after she delivers her verdict, so the verdict is not a return value -
it's a value she'll pass to a method. In code, this looks something like:
class Penelope implements Runnable {
public void run() {
try {
Verdict v = ... ;
DELIVER(v);
}
catch (Exception e) {
DELIVER_EXCEPTION(e);
}
}
}
class Suitor implements Runnable() {
public void run() {
try {
Verdict v = AWAIT();
}
catch (Exception e) {
// alas
}
}
}
There has got to be something in java.util.concurrent that she can use
to deliver her verdict. What?
In terms of synchronisation, CountdownLatch with a count of 1 does it -
the suitors await, and Penelope counts down. But it has no way to pass a
value.
In any case, I would wrap the verdict delivery issues up in a class so
that neither Penelope nor the suitors need to know about the
synchronization implementation.
Within that class, I would probably use ordinary fields to represent the
verdict, exceptional or otherwise.
One way to do the synchronization would be a semaphore that is initially
zero, but with a large number of permits added when Penelope calls a
setVerdict method. The getVerdict method that the suitors call would
wait to get a permit, record the verdict, and put the permit back so
there is no possibility of running out of permits.
Patricia