> it's a
> prerequisite that an interrupted thread know whether or not it was woken by
> a notify.
I think "know" is a little too strong. How about "can consistently
interpret"?
If the underlying thread blocking/unblocking mechanism does not report
the "reason" for wakeup, and/or sometimes misreports it (both of which
occur in practice), then the monitor support code must decide this on
its own. So, in the main case at hand, if a thread wakes up and its
interrupt status is true, the monitor can arbitrarily decide that the
wakeup was due to an interrupt, even if it "really" wasn't -- maybe it
was spurious but would have been immediately followed by an
interrupt-driven wakeup in an alternate universe in which the spurious
wakeup did not occur. The looseness of the Thread.interrupt spec makes
this interpretation acceptable so long as you are consistent. If
interrupt were guaranteed to have synchronous effects, it might not be
possible to get away with this. In other words, the intrinsic race I
once claimed precluded solution is not actually a problem given the
wording of the interrupt spec.
-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