Doug Lea wrote:
> 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?
I agree that a term that is less confusing than "happens-before" is
called for.
In fact, "synchronizes with" seems like a very good candidate for this
to me.
I think a phrase like "A synchronizes with B and A goes before B" could
be used as a less confusing and more intuitive, but equally precise,
synonym for "A happens-before B".
With the "goes before" part, I try to appeal to the intuition that the
act of synchronizing induces an order between A and B.
Often, the "goes before" part can be omitted because it is clear from
the context whether A goes before B or B goes before A.
The symmetry of "synchronizes with" is sometimes useful. For example,
the definition of data race can be phrased as: "a data race is when two
conflicting actions do not synchronize with each other."
Happens-before consistency can be phrased using "synchronizes with" as
follows:
A read R can return the value of any write W, unless 1) R synchronizes
with W and R goes before W, or 2) R synchronizes with some write W' and
W' goes before R and W' synchronizes with W and W goes before W'.
Of course, transitivity is somewhat unintuitive: "if A synchronizes with
B and A goes before B, and B synchronizes with C and B goes before C,
then A synchronizes with C and A goes before C". This is unintuitive
because A does not "actively" synchronize with C directly. We could
counter this by using the words "directly" and "indirectly" (as happens
many times in the JLS).
- An action synchronizes directly with the action that precedes it in
the program order.
- A lock synchronizes directly with the unlock that precedes it in the
synchronization order.
- A volatile read synchronizes directly with the volatile write that
precedes it in the synchronization order whose value it returns.
- An action A synchronizes with an action B and A goes before B if A
synchronizes directly with B and A goes before B or if there is some
action C such that A synchronizes with C and A goes before C and C
synchronizes with B and C goes before B.
If a programmer directly synchronizes an action A with an action B, for
example by putting A as the next statement after B in the program order,
then often the intention is to (indirectly) synchronize A with some
action C that B synchronizes with and that goes before B. Therefore, the
programmer may validly be said to be synchronizing A with C.
Maybe we should just throw happens-before out the window and use swagb
(or sg) exclusively?
-------------------------------
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