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

David Holmes davidcholmes at aapt.net.au
Wed Nov 23 17:30:22 EST 2011

Let's not compare apples with fruit baskets here. The complete package of
multi-threaded concurrent programming is indeed complex. But the simple
transactional model really only matches to the basic need for mutual
exclusion. Afterall the logical/conceptual model of STM is "one giant
lock" - if you couldn't code it using synchronized(theLock) then you won't
be able to code it using the simple transactional model. STMs have to add
back complexity to deal with the other synchronization issues in concurrent
programming and that impacts on the simplicity of the model.

David Holmes
  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Guy Korland
  Sent: Thursday, 24 November 2011 4:56 AM
  To: Ben Evans; Andrew Haley
  Cc: concurrency-interest
  Subject: Re: [concurrency-interest] Transactional memory on GCC 4.7.0,
what about Java?

  >Explaining the caveats around memory transactions to the overall dev
  >population is, in my view, neither an achievable nor desirable
  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?
           <CABKW8Rhtz3NkrgqyjwOWCHd4f-qmC_aKDRPjO5LFw5iYUA-GMQ at mail.gmail.c
    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.


    >> 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
    talking about new language level features, however. The target audience
    for those is not "everyone here" - it is all 10 million (and rising)

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111124/f2cfcdd2/attachment.html>

More information about the Concurrency-interest mailing list