At 09:33 PM 5/26/2003, David Holmes wrote:
>To maintain existing (expected) semantics the wait loop would have to
>be rewritten with an explicit Thread.interrupted() check. It could
>impact real apps that know they only interrupt threads whilst they are
>waiting, and so know that once interrupted that thread won't follow
>the normal code path.
This makes sense, but there seems to be a gap in the methods. If the
intention is to interrupt threads "while they're waiting" it seems likely
that a distinction should be made between the state in which the subject
thread is waiting for a notify (or interruption) and the state in which it
is simply ready and attempting to acquire the lock so that it can return
from the wait. However there doesn't seem to be a mechanism for the
monitoring thread to distinguish these two cases.
Presumably it has determined that the subject thread is in the wait by
synchronizing on the object and examining some state information. But it
can't distinguish the "waiting for notify" from "ready to synchronize" states.
I propose adding an interruptIfWaiting method that would behave the same as
interrupt in the former and be a nop otherwise (which would include cases
where the thread isn't in a wait). It would also return an indication of
what it had done.
An alternative would be some method that could inquire about the state. I
prefer interruptIfWaiting to a method that specifically inquires about the
state as the latter seems to ask about implementation detail than being a
function requirement.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:45 EDT