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

Andrew Haley aph at redhat.com
Wed Nov 23 12:53:31 EST 2011

On 11/23/2011 04:52 PM, Ben Evans wrote:
> 2011/11/23 Andrew Haley <aph at redhat.com>:
>> On 11/23/2011 01:08 PM, √iktor Ҡlang wrote:
>>> You mean that you have full knowledge of the inner workings of all your 3rd
>>> party (and stdlib for instance) dependencies?
>> No.  It simply means that if you're calling random code from within a
>> transaction you have to expect the worst, which in this case is a
>> relaxed transaction.
> [snip]
>>> I'm just saying that making the transactions completely transparent
>>> without managed references gives the impression that there is no
>>> worries to be had, which is quite to the contrary.
>> Whoever said that?  For STM to work well transactions should be small,
>> short-lived and not do I/O.  I think everyone here knows that, at
>> least.
> This is exactly the crux of the problem. Everyone here knows that. We are
> talking about new language level features, however. The target audience
> for those is not "everyone here" - it is all 10 million (and rising) Java
> developers.
> Any new features have, in my opinion, three key tests to pass:
> 1) They must not be capable of producing "spooky action at a distance"
> damage to an entire JVM process, even if used incorrectly by a novice
> programmer

Please, let's not have "what about the average programmer?", or I'll
be forced to quote Dijkstra's "What about the average mathematician?"
:-)  The problems we have to solve are hard, and we need the best tools
we can get.

> 2) They must not interact badly with existing language features that are
> already widely deployed in the wild. E.g. a new concurrency feature that
> does not play nice with finalizers is one thing. Not playing nice with
> Thread is quite another.
> 3) They must have a use case which is so compelling to a large subset
> of Java developers, that the feature cries out to be included - so much so
> that it's capable of overcoming a default position of not adding any
> new features.
> STM, in my view fails 1) and possibly 2) as well.

I hear you, but the other side of the coin is, per Herlihy and Shavit:

* Locks are hard to manage effectively, especially in large systems.

* Atomic primitives like compareAndSet operate only on one word at at
  time, leading to complex algorithms.

* It is difficult to compose multiple calls to multiple objects into
  atomic units.

> Explaining the caveats around memory transactions to the overall dev
> population is, in my view, neither an achievable nor desirable
> possibility.

If the overall dev population isn't capable of understanding memory
transactions it's certain that it's not capable of handling complex
systems with other tools either.  Herlihy and Shavit again: "No-one
really known how to organize and maintain large systems that rely on
locking."  This includes the population of Java programmers out there,
but they're doing the best they can.

It's going to be very interesting to see how C++ transactions are
received by the community.


More information about the Concurrency-interest mailing list