Doug Lea wrote:
> 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 agree that this necessarily follows. The VM can do this
communication at the C level using atomic instructions that provide weaker
memory synchronization semantics than those needed by either Java-level
unlocks, or Java-level volatile writes.
In terms of general documentation I do not think methods should overspecify
their behaviour by referring to hb edges and the like. There may well be
hb-relationships introduced by a method's/classes use of synchronization and
volatiles, but only those aspects of the behaviour relevent to the semantics
of that method/class should be documented.
We should not do anything that encourages reliance upon incidental
synchronization to achieve correctness.
David Holmes
-------------------------------
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