> I had thought that it was clearly stated in the API, but now that look
> there, all I can find are statements about InterruptedException that are at
> best open to interpretation.
Right. Among the things NOT specified are
* The synchronicity of Thread.interrupt:
1. If thread t is blocked, is it guaranteed to become unblocked
at/before return from t.interrupt() invoked by some other thread?
2. Is t.isInterrupted() guaranteed true at/before return
from t.interrupt()?
I once posted something here reminding people that the
Thread.interrupt javadoc spec is full of "will be"'s, unlike the
specs for any other Thread control method. (Compare wording with,
for example, Thread.setPriority). I recall that everyone refused to
believe this meant that the method doesn't guarantee synchronous
effects, but I still believe the intent is that promptness is left
as a quality of implementation isssue.
(As I also pointed out before, this wording allows different
implementations to differently internally demarcate the point at
which a thread is considered to be interrrupted, and thus
differently define and deal with notify/interrupt races.)
* Whether an already-interrupted thread calling wait() will detectably
release and re-acquire the lock. Because there are no ordering
guarantees for acquisition, no one can reliably detect whether you
release and immediately re-acquire. Which means that
implementations can pre-check status and return immediately if so
desired.
> Indeed, for this reason, it is not
> sufficient for wait() to perform this test on entry to the method.
> Something of an equivalent nature has to be done somewhere further in.
>
JVMs generally wake up interrupted threads upon interrupt no matter
how/why they are blocked. In the case of Sylvia's semantics for
Object.wait(), the internal response to the wakeup would differ
depending on whether the thread is currently on the monitor wait queue
(throw IE upon ultimate return) versus the lock reacquisition wait
queue (return normally, but set/preserve interrupt status). For JSR166
ReentrantLock, the response is the same in both cases (throw IE).
-Doug
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:54 EDT