[concurrency-interest] Transactional memory on GCC 4.7.0, what about Java?

Boehm, Hans hans.boehm at hp.com
Wed Nov 23 15:00:04 EST 2011


From: Guy Korland

> >Explaining the caveats around memory transactions to the overall dev
> >population is, in my view, neither an achievable nor desirable possibility.
> Don't you think that explaining the curt JMM, Synchronized, Lock semantics and etc. is more difficult.
> I saw concurrency experts which stood with puzzled eyes when they tried to explain the result of a concurrent run or even were wrong > when asked.
> The STM with all its performance limitation and I/O issues is much more clear to the average user than the current JMM.

Although I agree with the conclusion, I think we're comparing things here that are completely orthogonal and incomparable.

The Java memory model does have a simple core, which I think is as easy to explain as concurrent programming ever is.  If you write programs without data races, you get sequential consistency.  And you can decide whether your program has a data race without understanding any memory consistency issues beyond sequential consistency.  And this doesn't depend on whether you have locks or C++-style STM.  The difficulty with the Java memory model is that we can't quite get away with ignoring data races, for a variety of reasons, stemming in large part from Java's security model and legacy issues.  But none of those are likely to apply to code written by beginners.

I do think that the C++ approach to STM that we've been discussing here, at least as I view it, significantly simplifies the programming model.  The presence of relaxed transactions essentially allows you to program as though you had a single lock, avoiding deadlock, while potentially preserving significantly more concurrency than an implementation that actually used a single lock for all transactions.  Arbitrary code in transactions, including I/O, works correctly (if by "correctly" you mean single global lock semantics, as you should :-) ), though potentially slowly.  I think that's fundamentally a very good thing, especially for less experienced programmers.  However, I also think that verdicts on a lot of the details here are still out.

Hans



More information about the Concurrency-interest mailing list