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

√iktor Ҡlang viktor.klang at gmail.com
Wed Nov 23 12:16:18 EST 2011

On Wed, Nov 23, 2011 at 5:52 PM, Ben Evans <benjamin.john.evans at gmail.com>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
> 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.


Also, what does language integration buy over the library support that
already exists out there for STMs on the JVM?

> Thanks,
> Ben

Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - Enterprise-Grade Scala from the

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111123/ae3cfa2c/attachment.html>

More information about the Concurrency-interest mailing list