Doug Lea wrote:
> Bart's suggestions for this were all nicely precise, but I think a
> little too awkward for everyday use.
Most programmers should never have to write multithreaded code. Those
that do should be willing to try and know what they're doing.
> 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?
How about "happens-before"? Why is that so bad? It seems to fit the shoe
you're sketching here. If this term is used everywhere, people will be
willing to learn what it means. And it's precise.
-------------------------------
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