Doug Lea wrote:
> Bart nicely expanded on my suggestion to use "synchronizes with"
> instead here. I think we can adopt an equally rigorous usage that
> will still also allow use of "happens before" in main spec, by
> identifying "synchronizes-with" with the second clause of the HB
> definition. As in:
>
> I happens-before J if:
> 1) I is before J in program order
> 2) I synchronizes-with J
> 3) I happens-before K happens-before J for some K
>
> I synchronizes-with J if:
> I is an unlock or volatile write, and J is a matching unlock or
> volatile read that comes after I in the total order of
> synchronization actions.
> [Or whatever exact wording JSR133 decides to go with here.]
I find this surprising.
- (Is "allowing the use of happens-before" a valid motivation for anything?)
- With your definition, "synchronizes-with" is much less useful.
Importantly, it cannot be used in documentation for class libraries. A
client of a class library is interested in the actions of starting a
method invocation and returning from a method invocation, and the edges
between those actions; however, there are no synchronizes-with edges
between such actions since these are not synchronization actions
(unlocks, volatile writes, locks, volatile reads). Therefore, you need
program order and you need transitivity.
I suspect that your reply might be: program order and transitivity are
implied. But then, there is no difference between happens-before and
synchronizes-with? Except that in the latter case you require at least
one cross-thread edge (or even exactly one)? What would be the benefit
of such a requirement?
-------------------------------
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