If sleep, join, etc., are defined as I drafted them last year -- see
http://gee.cs.oswego.edu/dl/html/jvms.html (*) -- then I don't think
you need any additional special rules about these methods wrt the
memory model.
It is true that isAlive and interrupt should be guaranteed to be
synchronized (not necessarily synched on any particular object
though). But synch guarantees of particular methods don't seem to
belong in MM spec.
I'm wary of special-casing sleep. Synch/visibility errors associated
with sleep are merely among the most obvious concurrent programming
errors made by non-expert programmers. As Joe says, there are lots
more, and it is hard to draw a line here.
(One idea though is to somehow allow optional JVM modes that people
could switch on that do global barriers on certain methods --
sleep, AWT event dispatch, etc.)
(*) Digressing on this document: This was approvingly reviewed by a
bunch of people (all on this list) last year, but never made it into
JVMS 2nd edition. There are two slightly controversial issues in it:
1. It allows spurious wake-ups; i.e., resumption from
a wait without any notify/notifyAll (as does POSIX).
2. Waiting threads that are notified but then later interrupted
before resumption must return non-exceptionally from
the wait (i.e., not throw InterruptedException).
(1) really needs to be in there because many JVMs are built upon
POSIX threads. (2) is needed to implement some efficient notify-based
designs. It used to seem like a bigger problem though before we all
discovered that the extra-notify-on-interrupt trick usually makes
these tolerable to implement.
-- Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA dl@cs.oswego.edu 315-341-2688 FAX:315-341-5424 http://gee.cs.oswego.edu/
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:20 EDT