At 02:08 PM 5/27/2003, Sylvia Else wrote:
>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.
Yes, but this whole discussion got started under the premise that the
program did issue notifies "around this time". The notify could have been
done before the interrupter locks the monitor.
>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
-------------------------------
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