> I think it's arguable that achieving responsiveness to interrupts has more
> to do with the order in which threads are woken (on acquiring the monitor),
> than whether they throw IE when they do.
I don't think this argument gets too far. It is easy to make large
sets of, for example, producer-consumer threads (i.e., threads
repeatedly doing monitor-waits for items or space in shared queues)
that shut down very noticeably faster with prefer-IE. With
prefer-notify, programmers will sometimes need to put in extra
interrupt checks to become responsive enough to cancellation. This is
because threads in such designs spend a significant part of their time
re-acquiring locks after notifications.
You might instead argue that people should prefer designs without so
much lock contention, but they they sometimes have other reasons for
doing things this way. By settling on prefer-notify, we are telling
people writing such code in such contexts that they should put in
extra interruption checks. This is fine, because under the ambiguous
version of spec, they ought to do this anyway, just in case they use a
JVM using prefer-notify.
-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:55 EDT