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

Dan Berindei dan.berindei at gmail.com
Wed Nov 23 14:36:37 EST 2011


On Wed, Nov 23, 2011 at 8:56 PM, Guy Korland <gkorland at gmail.com> wrote:
>>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.

What happens when I add a logger.debug("bla") statement at the
beginning of a transaction?
Is that easier to explain then what happens when I add a
logger.debug("bla") statement in a synchronized block?

> 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
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>



More information about the Concurrency-interest mailing list