At 05:06 PM 5/11/2003 -0300, Lanchon wrote:
>regarding re-notification, i understand JVMs try to prevent loss of
>notifications by re-notifying the monitor after an interrupted thread
>wakes up. this however is not proposed spec-compliant, because the waiting
>set of the monitor may at wakeup time have new threads that weren't
>present when the original notify was done. in the extreme a thread could
>even end up notifying itself if after the notify it adds itself to the
>wait set.
>
>the only way out of this seems to be that JVMs to do a notifyAll after an
>interrupted thread wakes up, which is ugly. is this how current JVMs
>behave? if not, proposing an executively unimplementable spec to replace
>an older executively unimplementable spec seems to be a bad idea.
>
>i think maybe "notifications cannot be lost due to interrupts" should be
>left out from the spec, maybe explicitly permitting the re-notification
>after interrupt behaviour instead. or maybe the part that defines notify
>that says "if m's wait set is not empty, a thread u that is a member of
>m's current wait set is selected and removed from the wait set" should be
>changed to something that expresses that a notify will schedule the
>selection and removal of a thread from a wait set for later execution (but
>only if the wait set is not empty, otherwise a problem would arise if you
>notify a monitor with an empty wait set: the notify could be postponed
>indefinetly, you could get the notify in a wait that's invoked much latter).
>
>i'm writting all this because i'd like to see spurious wakeups out of the
>spec if possible. i understand the JVM reengineering efforts would be too
>great, so here are my 2c:
Warning: Slight rant content.
This issue has been much debated here. I have pushed hard for behaviour
that is as documented (still) in the API. But the goal posts move.
Initially it was "it's impossible". Now it's "it's too inefficient". In the
end, I've given up. It's a lost cause, because the JVM implementors don't
want to do the work. I don't think this argument can be won, regardless of
what the facts might be.
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:52 EDT