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

Ben Evans benjamin.john.evans at gmail.com
Wed Nov 23 11:52:06 EST 2011

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.


>> 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

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

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. We need to keep in
mind that we're producing features for a developer population that
includes quite a few whose attitude to concurrency is either: "Huh?" or,
if you're lucky: "Synchronize All The Things!!!"

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



More information about the Concurrency-interest mailing list