> At the risk of repeating myself yet again, I remain unconvinced that strict
> compliance with the original specification is unachievable at a reasonable
> cost. This is a view I will continue to push during the public review period.
How many orders of magnitude of performance penalty do you consider
"reasonable cost"? :-)
Much of the Java code that relies heavily on wait/notify/interrupt
runs on multiprocessors. Yet the only constructive design for obeying
original spec that anyone (Sylvia) has presented on this list requires
a global lock, plus as least twice the number of context switches as
otherwise necessary, which are just not acceptable.
The reason I presented this issue in the way no one liked a few days
ago was to highlight the fact that the rest of the specs on wait,
notify, and interrupt force a race condition here. Since this list
mostly discusses races, it is natural venue to consider the
options. (See also Alexander's post on the POSIX response to one
aspect of this.)
The issue here is essentially the same as has been controversial in
concurrent programming for about 15 years now (at least ever since
DEC-SRC Firefly project): On multiprocessors, there are no known
techniques for uniquely agreeing on the "winners" of some of these
wake-up races (in many cases, from the hardware on up), so each level
of a system errs on the side of liveness, and unblocks threads if
there is any question about it. The extra-notification trick proposed
as response to to unknowably lost races between interrupt and notify
falls in this tradition. (Sad but apparently true that it needs to act
as a notifyAll.)
One of problems is that specs are never phrased in a way that makes it
obvious to programmers that these races, and intrinsically
indeterminate outcomes, exist. So many people are very surprised about
spurious notifications.
(I bet more code out there breaks due to spurious notifications than
due to "lost" interrupts, but we have concurrent programming practices
dogma on our side to defend the extra-notification approach.)
-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:50 EDT