> On the other hand, it might be a good idea if most of the Thread methods
> were explicitly prevented from moving into a locked region:
>
> Thread.interrupted()
> Thread.yield()
> Thread.sleep()
>
> thread.start()
> thread.join()
> thread.interrupt()
> thread.setPriority()
>
I believe that each of these would already be somehow covered, modulo
the lack of sufficient specification to be sure that they do somehow
intrinsically require visible memory effects (and thus synch,
volatile, or something equivalent). Current documentation on the
yield() and setPriority() methods are the least clear about this, but
even here strongly suggest that they should be OK. For example,
getPriority() says it returns the thread's priority, which could only
hold in general if setPriority() employs synch or equivalent.
This reasoning ignores the inconvenient fact that in the most recent
Sun jdk src.jar I have, the internal Thread.priority field is not
volatile and getPriority is not synchronized. Depending on how the
native setPriority() method is implemented, this is still probably OK
on sparc and IA32, at least until compilers fully exploit JMM
rules. But it is otherwise very suspicious.
More generally, I think these methods fall under the same set of
concerns that many other jdk classes do/will under JMM proposal. Bill
has recommended that there be an audit of java.* packages to ensure
that specifications and implementations make sense under new JMM. I
suspect that all such problems are also problems under the current JLS
ch17 JMM. But by changing the JMM, the burden falls on us to recommend
spec/code changes.
-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:29 EDT