Re: JavaMemoryModel: Thread model algorithm.

From: Doug Lea (
Date: Wed Nov 19 2003 - 09:14:39 EST

> 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

> 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).


JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:54 EDT