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

+1

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
Experts

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