At 9:13 AM -0500 11/23/03, Doug Lea wrote:
>
>
>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
I don't think the "allow spurious wakeups because programs that
depend upon them not happening are likely to be broken anyway" is a
very good one. Perhaps an OK one, but not a good one.
The real question is whether the VM implementors would complain if
forced to change their VMs at this late date.
Of course, we could just argue that all we are doing is not changing
the old spec to allow spurious wakeups.
Can Martin or someone else from IBM check with the IBM JVM people?
Does anyone know if the current IBM JVM allows spurious wakeups?
Bill
-------------------------------
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