Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Presentations From Concurrent to Parallel

From Concurrent to Parallel



Multiprocessor systems have gone from being rare and expensive to being ubiquitous. As the hardware reality changes, so do the programs we want to write and so must the platform and libraries we rely on. In Java SE 7, the java.util.concurent package will grow to address the need to exploit finer-grained concurrency, in the form of the fork-join framework.


Brian Goetz is the author of over 75 articles on software development, and the book, Java Concurrency In Practice. He serves on the JCP Expert Groups and is a Sr. Staff Engineer at Sun Microsystems.

About the conference

QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community. QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.

Recorded at:

Jun 19, 2009

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Excellent overview of the forkjoin framework provided by Brian.

    by Jayaram Vundavalli,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yet I'm still confused of how the work stealing would work when multiple workers compele to steal the task from the tail of a single workers dequeue?

  • Terrible!

    by Daniel Sobral,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    God, that was awful. I'll paraphrase it here: Java sucks as a language for massive concurrency, but we don't want to face that, so, instead, we'll talk about some ad-hoc approaches to various problems that are already solved and working, and build a library for them as if it were original. Only those problems are not the everyday problems most of us face, and, as said, are solved for those who need them.

    I particularly liked when he mentioned that threads are expensive, as if this was basic truth, instead of a consequence of various characteristics of Java.

    Now, the library is nice -- actually, very good, and if I hadn't read about it before and the presentation was a bit more honest about the very limited scope of what they were doing, it would be a great presentation.

    For those still left looking for effective massive concurrency, it seems Erlang and the like are still it.

  • Re: Terrible!

    by Aaron Hamid,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Daniel, while I also have some qualms as to the utility and applicability of this particular library, I have to take issue with your criticism of this presentation.

    First, if Java "sucks as a language for massive concurrency", it's because all mainstream languages, which are largely imperative and OO, "suck for massive concurrency".

    I'm not sure what you mean when you say the approach described is "ad hoc", or that anybody claimed that it was original. In fact the speaker alluded to previous approaches implemented in other languages at the beginning of the talk. My reservation is that this is not applicable to "everyday problems" but I believe the point the speaker is trying to make is that this WILL be the everyday problem as we face the challenge of massively parallel hardware.

    The fact that threads are expensive is a basic truth (they are more expensive than not using threads). This truth stems from operating system implementation, and is possibly worsened by language implementation. If you could say anything about Java, it is not that it does not have a superb VM. Java's VM is best in class, has had massive engineering years poured into it by some really brilliant engineers, and beats the pants of other languages/VMs that could be considered alternatives to Java/JVM: Ruby, Python (both of which have been plagued by infamous "global interpreter locks"), and probably anything else out there.

    Perhaps you have some antiquated ideas about Java from 1997? Let's say the Java runtime was perfect, there is still thread overhead at the OS level. This is not specific to Java. All languages that use threads (including natively compiled languages) have to deal with this. There are of course many alternatives available: fibers, events, async IO, etc. But your claim seems to be that threads are expensive specifically due to characteristics of Java, not that other approaches should be used.

    Of course if you are looking for "massive concurrency" look at Erlang. Look at a lot of things. Erlang is conspicuously NON-mainstream, so Erlang developers are obviously NOT the target of this talk. If you have been writing massively concurrent Erlang for the last 10 years, well, I guess you get a pat on the back, but you are certainly the exception and I don't get what your beef is with the Java community building new libraries for themselves.

    By the way there are languages that suck less for concurrency on the JVM, including Clojure and (gasp) Erjang.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p