> >The Object.wait spec can just add three words:
> >> If the current thread is interrupted by another thread while it is
> >> waiting FOR A NOTIFICATION...
>
> Surely this makes concrete implementation tricky ?
It turns out not to ADD any trickiness. To support interrupt, you must
have a way for Thread.interrupt() to signal the appropriate cond_var
(or whatever) to release ongoing waits. Given this, controlling the
policy under which you do this should be straightforward, modulo the
nit-picky issues being discussed by Sylvia, David, and me about how to
define/determine which state you are in.
More generally, my main goal in trying to force settlement of issues
lately has been to make guarantees simpler and stronger (only) when we
are confident that that this won't make things slower or more
complicated.
It would be a good idea here for us to put together a "cookbook" on
monitor (including interrupts etc) implementation under JSR133,
similar to the one I did on memory model issues. I did that one last
year to make it clear that the new memory model did not impose
implementation or performance problems, and to provide some ready-made
recipes for compliance, which was pragmatically important for gaining
consensus for adoption. We have the same need for monitors. The best
strategies are surely not obvious to people scanning all the mail
traffic among those discussing details.
One snag in putting toghether a monitor cookbook is that there is even
less published material out there about how JVMs deal with monitors
than there is about how processors deal with memory barriers.
For the time being, the (open source) JSR166 ReentrantLock and
ReentrantLock.Condition code is available to show one set of compliant
implementation choices. (I've revised this to uniformly use
prefer-notify policy.) Even though these are in Java, they rely only
on low-level atomics (compareAndSet) and thread-blocking support
(park/unpark -- mappable to per-thread cond_vars, Win32 events, etc),
so can serve as a realistic guide for within-JVM versions. (On the
other hand, because they are in Java, they use more scalable and more
tunable internal data structures (in part because they can rely on GC)
than you can normally implement inside JVMs. (Further digressing: JVMs
could even use such pure Java code for monitors if they could figure
out some way to deal with JNI monitorEnter/exit calls, along with
interactions between JVM-level and Java-level locking.)
-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