Folks,
Amusingly, we just added language to the Object spec permitting
spurious wakeups
(http://developer.java.sun.com/developer/bugParade/bugs/4308396.html).
Of course we could back this out at any time before Tiger ships, but I
just thought you might like to know.
Josh
Doug Lea wrote:
>For those who haven't been following notify/interrupt/etc exchanges
>lately, the main result is that we no longer know of any intrinsic,
>compelling implementation-based reasons for allowing spurious
>wakeups. This holds for the kinds of implementations that actually
>exist and/or that seem plausible, including those adopting the various
>allowed policies surrounding early/late InterruptedException throws.
>in some cases, achieving this leverages other non-determinisms in
>specs, but not in interesting ways. There might still be some
>performance issues in avoiding some spurious interrupts in some
>implementations, but they all seem small enough to ignore.
>
>In which case, it becomes a pure policy issue about whether to:
>
>1. Ban spurious wakeups
>2. Allow spurious wakeups even though {most,all} JVMs never generate them.
>
>The main case for banning them is that the spec becomes simpler --
>unlike original spec, the revised version would explicitly disallow
>them. A secondary reason is that people would be able to write code
>under the reasoning "if I was notified then I must be in state X".
>(Such reasoning almost never works out in practice though.)
>
>The main case for allowing them is that nearly all programs using
>waits that don't recheck conditions are broken, and this would make
>them "officially" broken. Even so, production JVMs would choose to
>use techniques like those we've discussed so as not to generate
>spurious wakeups (except perhaps in a debugging/test mode). There are
>broken programs out there that people rely on, that just so happen
>never to encounter wakeups that they can't deal with, but that would
>stop working if JVMs regularly performed spurious wakeups.
>
>I know members of JMM list and/or JSR133 will disagree about which way
>to go here. Does anyone know how to settle this?
>
>-Doug
>
>-------------------------------
>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:54 EDT