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

[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

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.

Thanks,

Ben



More information about the Concurrency-interest mailing list