[concurrency-interest] [Javamemorymodel-discussion] Java7 Fences API
pugh at cs.umd.edu
Tue Jan 13 20:46:12 EST 2009
I think this is a much harder problem than Doug seems to think it is.
Or I don't understand want Doug wants.
Consider, for example,
static void postLoadFence()
Ensures that any read or write performed subsequent to a
call to this method is ordered strictly after any read performed prior
to the call.
So, if we have:
Initially, x = y = z = 0 and none are volatile.
r1 = x
y = 1
r3 = z
z = 1
r2 = y
x = 1
So, it seems to me that we'd be saying that r1 = r2 = 1 it not a
possible behavior. On the other hand, no happens-before edges would be
established by anything in the code.
Thus, we could have r1 = 1 and r2 = r3 = 0.
It seems to me that with this, we will be encouraging people to write
subtle concurrent algorithms in which conflicting memory accesses are
not ordered by happens before ordering. Which means we can will no
longer be able to effectively use data race detection tools.
Final fields were hard as hell to try to get into the spec, and
mutable final fields _really_ pushed the boundaries. Now Doug wants
to be able to declare that arbitrary writes have the special semantics
associated with final writes.
The entire JMM was designed around the idea that there wasn't a unique
global order over all memory operations, and that you couldn't talk
about fences, because that just described ordering constraints on how
operations performed by a thread could be reordered as they were seen
by the global memory order.
For my sanity, can we back away from what kind of API or language
features we might design/provide, and go through the compelling use
cases that require something other than the currently provided memory
If only 5 people in the world could effectively and correctly use the
new API, I don't think it should be added to the public JVM.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest