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

Boehm, Hans hans.boehm at hp.com
Wed Jan 14 00:43:44 EST 2009

I think this can probably be expressed in terms of happens-before relationships.  That's what the C++ version does.

See http://wiki.dinkumware.com/twiki/pub/Wg21sanFrancisco/FormalMotions/n2752.html, section 29.6.

(This is a reference to a proposal that has been merged into the C++ committee draft, which is N2800 at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/ )

I doubt this negates your concerns, however.  I think all of us share those to some extent.

For C++, the main argument for fences was that there are use cases for which they result in more efficient code on current architectures, and fences are often so expensive that avoiding one is a big deal.  Releases of multiple locks in a row are one example.

And there are cases like seq_locks that are hard to express otherwise.  Consider the following code:

initial_version = version;
final_version = version;

where potentially interfering writers set a lock bit in the version during the update and increment the version at the end, and I then check version1 and version2 at the end to make sure I read a consistent snapshot.  Even if version is volatile, this doesn't give me the ordering I want.  A fence before the final load does.  (Making all the reads in the middle volatile gives me SC, but this is often impractical, for both performance and software engineering reasons.  Actually, this example doesn't quite work in C++ either, but for relatively minor reasons that don't apply to Java.)

For Java, there's the added problem that we don't have volatile array elements, and it's linguistically hard to specify weaker ordering for volatile accesses, which some people insist on, again for performance reasons.


From: javamemorymodel-discussion-bounces at cs.umd.edu [mailto:javamemorymodel-discussion-bounces at cs.umd.edu] On Behalf Of Bill Pugh
Sent: Tuesday, January 13, 2009 5:46 PM
To: Doug Lea
Cc: Concurrency-interest at cs.oswego.edu; javamemorymodel-discussion at cs.umd.edu
Subject: Re: [Javamemorymodel-discussion] Java7 Fences API


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<http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/Fences.html#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
y = 1
r3 = z

Thread 2:
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 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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090114/47d2ef4d/attachment.html>

More information about the Concurrency-interest mailing list