I don't think it would be a good precedent to explicitly include
Thread.{interrupt, interrupted, isInterrupted} in JMM spec
happens-before relation. Any method that affects the state of some
other thread must somehow guarantee that its effects are visible to
that thread in order to fulfil its basic contract. And because the
only inter-thread updates addressed by the JMM ultimately rely on
unlocks and volatile writes, it seems to follow that interrupts must
provide associated hb edges. I don't see anything that makes the
interrupt methods special in this respect. There are lots of other
methods in JDK and elsewhere that fall in the same category.
This does raise the issue though of how to document methods in a way
that makes all of this clearer, so people don't have to step through
series of inferences and/or guesses about intent to see that
implementations must somehow entail locking and/or volatiles that
provide the required happens-before guarantees. We do NOT want people
to explicitly document methods as being "synchronized", but no
standard phrasings or documentation conventions have emerged to
otherwise specify memory/ordering properties. Any ideas?
(Note that Thread.start and Thread termination do need to be mentioned
in JMM, because nothing else forces/explains their memory properties.)
-Doug
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:01 EDT