Doug Lea wrote:
> (Wow, too many issues on too many fronts...)
Tell me about it! ;-)
> Here's the part I am still uncomfortable about. Suppose you have
> underlying blocking/unblocking mechanics in which signals and
> interrupts are never "lost". And you are implementing wait() using
> them. Are you allowed to do
>
> void wait() {
> // ... wait, wake up, etc
> // and then as your final act, if you haven't already
> abnormally exited,
> if (Thread.isInterrupted()) throw new InterruptedException();
> }
>
> I want the answer to be yes, even though it means that you
> cannot, by virtue of getting IE know whether you were woken up
> "because" of a signal or an interrupt. (This may in turn
> reflect the fact that nothing else in the system, even though it is
> correct, knows this either.)
I say no. In this scenario you may (must?) have consumed a
notification (either notify or notifyAll) and if it was from a
notify() then another thread should be woken up in your place. It is
fine for the application code to perform the:
if (Thread.interrupted()) throw new InterruptedException();
but not for the internals of wait().
As I've stated before, if you allow the above then any designs based
on use of notify() (not that there are that many of them), must catch
IE from a wait() and themselves propagate the notification using
notifyAll() (as per previous discussion with Alexander). The need for
this extra scaffolding implies to me that the API design is wrong. As
with POSIX, cancellation should not consume a signal. So your code
needs to be:
void wait() {
// ... wait, wake up, etc
// and then as your final act, if you haven't already abnormally
exited,
if (Thread.isInterrupted()) {
notifyAll();
throw new InterruptedException();
}
}
And that's ugly code.
David Holmes
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:49 EDT