Re: persistent synchronization signal?
Tom Forsmo wrote On 11/20/07 16:33,:
Hi
I am working on a server where a request is divided into some paralell
tasks. The tasks have to complete in the correct order, even though its
paralellised. For example, task A and B can start at the same time, but
B can not complete until A is completed, since the last part of B
depends on A's succesfull completion. So I am wondering how can A signal
B abouts its completion. The problem here is twofold 1) that A completes
in only 10-20% of the time of B and 2) that B is the receiver of the
signal sent by A. If I use wait/notify, A will notify long before B has
even gotten to the wait call.
So my question is, does anybody know if there exists a signaling method
that stores a notify signal even though a wait is not yet issued?
I could use some sort of a message queue or even implement a simple
stored_notify_flag()/wait() class myself, but maybe there is another way
of doing it.
You misunderstand wait() and notify() -- don't be ashamed,
because you are not the first to do so and will not be the
last. The only thing notify() does is to awaken a thread
from a wait() on the designated object, *if* a thread happens
to be sleeping in a wait() at that moment. If no thread is
sleeping, notify() is a no-op; it does not create a "notified"
state somewhere.
What B really needs is not a notification, but A's result.
So let's do it this way:
class B {
Result fromA = null;
Object sharedLock = new Object();
void doIt() {
doPreliminaryThings();
synchronized(sharedLock) { // acquire lock
while (fromA == null) {// any result yet?
sharedLock.wait(); // no: unlock, sleep
// ... and re-lock
}
} // yes: unlock
doLaterThings(fromA); // use the result
}
}
class A {
B theB = ...;
void doIt() {
Result result = inventSomething();
synchronized(theB.sharedLock) { // acquire lock
theB.fromA = result; // store result
theB.sharedLock.notify(); // sleeper, awake!
} // unlock
// done!
}
}
Notes:
1) With this pattern it doesn't matter whether A or B
is faster. If A is faster, it stores its result in fromA
and performs a no-op notify(); B will later find fromA non-
null and will not wait at all. If B is faster, it finds
fromA null and waits for the situation to change; A eventually
stores to fromA, and in this case its notify() actually wakes B.
Even a dead heat is fine: since one and only one of A and B
can run its synchronized block while the other stalls, that
one effectively "gets there first" and breaks the tie.
2) A "holder" object like a Collection or an array or
something of your own devising can fill the roles of fromA
and of sharedLock simultaneously. (Can you see why the
reference variable fromA all by itself won't do the whole
job?)
3) Observe that B uses `while' and not `if'. A return
from the wait() method doesn't mean that A *has* called
notify(), only that it *may have* called notify(), so B
must go around and check again -- and possibly go back to
sleep again. Besides, remember the first principle: B is
not interested in the notification, but in the result, so
it's the presence of the result that's the sure-fire test
for whether to proceed.
--
Eric.Sosman@sun.com