Re: Interrupted exception chaining
On 9/25/2012 1:47 PM, Jan Burse wrote:
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 */
While I agree this works in some cases, I don't think it works for the
OP. He's trying to simulate a spin lock, by extending the Lock
interface. "done" is signaled by calling unlock() on that interface.
I don't see how that can be done reliably.
public class SpinLock implements Lock {
private volatile boolean done;
private final Object lock = new Object();
public void lock() {
// ignore the "spin lock" for now
try {
synchronized( lock ) {
while( !done ) lock.wait();
}
} catch( InterruptedException ex ) {
Thread.currentThread().interrupt();
}
// how does "done" get reset?
}
public void unlock() {
synchronized( lock ) {
done = true;
lock.notify();
}
}
}
I don't see how "done" can be reliably reset. There's going to be a
race condition somewhere. Might as well use ReetrantLock, it solves
this problem.
(You can solve it too, but you're basically cutting and pasting code
from ReetrantLock at that point. Easier to just reuse code.)