[concurrency-interest] [Javamemorymodel-discussion] Java7 Fences API

Bill Pugh pugh at cs.umd.edu
Tue Jan 13 20:46:12 EST 2009


yow.

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.

Thread 1:

r1 = x
Fence().postLoadFence()
y = 1
r3 = z

Thread 2:
z = 1
r2 = y
Fence().postLoadFence()
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  
semantics?

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.

Bill



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090113/71bd55e4/attachment.html>


More information about the Concurrency-interest mailing list