The Artima Developer Community
Sponsored Link

Weblogs Forum
Odersky Explains Shared-Memory Concurrency

5 replies on 1 page. Most recent reply: Sep 19, 2011 5:35 PM by Slava Imeshev

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 5 replies on 1 page
Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Odersky Explains Shared-Memory Concurrency (View in Weblogs)
Posted: Aug 4, 2011 11:51 AM
Reply to this message Reply
Summary
In his 17-minute keynote at O'Reilly OSCON Java 2011, Martin Odersky gives one of the more succinct and clear explanations I've seen on why shared-memory concurrency is virtually impossible to get right.
Advertisement

Here's the link.

Years ago at one of the CodeMash conferences, Brian Goetz gave a more in-depth presentation on the subject. This was, I think, a little before he published Java Concurrency in Practice. In his presentation, he made a very convincing case that showed how nearly-impossible it is to write correct code for shared-memory concurrency (Java threads, in his speech). More importantly, even if you do get it right it's incredibly fragile, so that any change in your code can easily introduce new concurrency bugs, and because testing is not possible, you don't know when these bugs appear.

For some reason, Brian didn't want the talk to be filmed or otherwise distributed. This is unfortunate because it was a great explanation of the difficulties; from my own experiences I was already mostly convinced that shared-memory concurrency was the wrong path but Goetz' talk finished the process.


Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Odersky Explains Shared-Memory Concurrency Posted: Aug 5, 2011 4:33 AM
Reply to this message Reply
So when it is impossible to get Java concurrency right, almost all Java programs are broken, simply by using threads? This would surprise me.

Michael Chermside

Posts: 17
Nickname: mcherm
Registered: Jan, 2004

Re: Odersky Explains Shared-Memory Concurrency Posted: Aug 5, 2011 12:10 PM
Reply to this message Reply
> So when it is impossible to get Java concurrency right,
> almost all Java programs are broken, simply by using
> threads? This would surprise me.

Well, many Java programs do not use threading, so those are probably OK. And in my experience (>10 yrs doing professional Java programming full time) it really IS true that nearly 100% of Java programs using threading are "broken".

Note that "broken" means it is possible for them to experience unintended behavior when the timing of threading is especially unlucky. Which could, for instance, result in one out of every 10,000 runs doing things wrong because of threading issues. Honestly, most Java programs have enough OTHER bugs in them that the threading bugs get mixed in with the background of other issues. But the threading bugs ARE there, and if you are trying to write bug-free code then using shared-memory threading is almost certainly going to prevent that unless you invest an obscene amount of time and specialized expertise into it.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Odersky Explains Shared-Memory Concurrency Posted: Aug 6, 2011 12:08 PM
Reply to this message Reply
> Well, many Java programs do not use threading, so those
> are probably OK. And in my experience (>10 yrs doing
> professional Java programming full time) it really IS true
> that nearly 100% of Java programs using threading are
> "broken".
>
> Note that "broken" means it is possible for them to
> experience unintended behavior when the timing of
> threading is especially unlucky. Which could, for
> instance, result in one out of every 10,000 runs doing
> things wrong because of threading issues. Honestly, most
> Java programs have enough OTHER bugs in them that the
> threading bugs get mixed in with the background of other
> issues. But the threading bugs ARE there, and if you are
> trying to write bug-free code then using shared-memory
> threading is almost certainly going to prevent that unless
> you invest an obscene amount of time and specialized
> expertise into it.

Outstanding explanation. Unfortunately the threading learning curve is steep and long, and to get to the point where you understand the fragility is no small undertaking. So most seem stuck at this level of disbelief.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Odersky Explains Shared-Memory Concurrency Posted: Aug 9, 2011 2:21 PM
Reply to this message Reply
The Java Memory Model, as I understand it from Java Concurrency in Practice, seems optimized for fast, single-core machines from 10 years ago. And extremely hostile to multi-threaded apps.

If "they" had to do it over again, would it be different?

Is this something that could be changed in future versions of the JVM, or would that break a gazillion apps so we are stuck with it?

Slava Imeshev

Posts: 114
Nickname: imeshev
Registered: Sep, 2004

Re: Odersky Explains Shared-Memory Concurrency Posted: Sep 19, 2011 5:35 PM
Reply to this message Reply
I don't see why it's problem. Java threading is a low-level facility, of course it requires caution and a lot of smarts to be used effectively. Don't want to mess with treading? Use J2EE.

Regards,

Slava Imeshev
Cacheonix | Clustered Java Cache

Flat View: This topic has 5 replies on 1 page
Topic: User Interface Programming in the (Near) Future Previous Topic   Next Topic Topic: More on Remote Procedure Calls


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us