At 02:33 PM 27/05/2003 +1000, 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.
Maybe I'm missing the point you're making here, but my line of thinking was
that the expected usage of wait() takes the following form:
synchronized(m)
{
try
{
while(m.flag == false)
{
m.wait();
}
// I woke up for a valid reason.
}
catch (InterruptedException ex)
{
// Someone interrupted me.
}
}
It seems to have been accepted now that the m.wait() call can wakeup
regardless any program action, so the m.flag test is required. If the
thread is interrupted under my proposal, the m.flag test will cause a
further iteration of the loop, whereupon m.wait() will throw
InterruptedException because the interrupt flag is set.
What is the program structure that works correctly under the current
implementations, but would break under my proposal?
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