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
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:54 EDT