> I don't agree that this necessarily follows.
Right. My main point here (that I didn't express well; sorry) is that
we need to establish some simple terminology and phrasings that people
can adapt in method javadocs/specs in cases like this. And to
immediately apply them if possible in core JDK1.5 specs that need
them.
Bart's suggestions for this were all nicely precise, but I think a
little too awkward for everyday use.
One possibility is to use the familiar term "synchronize" for these
purposes. As in, adding to Thread.interrupt() javadoc:
An invocation of interrupt() synchronizes with any subsequent
invocation of interrupted() or isInterrupted().
The intention (that would be further explained in JLS and elsewhere)
is that "synchronize with" indicates the memory semantics of locking,
but doesn't say which lock, or even if it actually uses a lock,
perhaps instead using volatiles and/or atomics with the same effect.
One danger is that people might misinterpret this to mean that these
are all "synchronized" methods, which implies using a common visible
lock (here, the Thread object), hence can be forcibly blocked by
holding that lock. Which won't in general work.
If the phrasing is used and explained in enough contexts, few people
will make this misinterpretation, but maybe there is a better term?
-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