At 10:15 AM 27/05/2003 -0700, Jerry Schwarz wrote:
>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.
However, under the current specification, and in the absence of spurious
wakeups, if the interrupter locks the same monitor, and the program doesn't
itself issue notifies around this time, then it is certain the 'waiting'
thread is really waiting, because the locks are released after the thread
enters the wait state.
Adding spurious wakeups, but preferring to throw IE, means that the program
is still safe, provided that the test for the interrupted state is
performed _after_ the lock is reacquired on the monitor, as seems likely in
real implementations.
Sylvia.
Sylvia.
-------------------------------
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