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

Guy Korland gkorland at gmail.com
Wed Nov 23 13:56:25 EST 2011

>Explaining the caveats around memory transactions to the overall dev
>population is, in my view, neither an achievable nor desirable possibility.
Don't you think that explaining the curt JMM, Synchronized, Lock semantics
and etc. is more difficult.
I saw concurrency experts which stood with puzzled eyes when they tried to
explain the result of a concurrent run or even were wrong when asked.
The STM with all its performance limitation and I/O issues is much more
clear to the average user than the current JMM.

On Wed, Nov 23, 2011 at 7:00 PM, <concurrency-interest-request at cs.oswego.edu
> wrote:

> Date: Wed, 23 Nov 2011 16:52:06 +0000
> From: Ben Evans <benjamin.john.evans at gmail.com>
> To: Andrew Haley <aph at redhat.com>
> Cc: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Transactional memory on GCC 4.7.0,
>        what about Java?
> Message-ID:
>        <CABKW8Rhtz3NkrgqyjwOWCHd4f-qmC_aKDRPjO5LFw5iYUA-GMQ at mail.gmail.com
> >
> Content-Type: text/plain; charset=UTF-8
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111123/f790cdff/attachment-0001.html>

More information about the Concurrency-interest mailing list