Skip to main content

Multithread Programming Versus Parallel Programming; or, What's Wrong with Java Threads?

Posted by editor on April 22, 2012 at 11:46 AM PDT

A few nights ago, I was browsing the chapters about concurrent programming in Herbert Schildt's excellent Java: The Complete Reference, 8th Edition, and I was struck by the evolution of concurrency in Java over the years, from threads, through the richness of Java 5's Concurrency Utilities, and on to Java 7's Fork/Join Framework. The Java language truly has grown, adapted to the changing world, to the innovations of the hardware platforms on which it runs. And, of course, Java 8 will include Lambda Expressions, or "closures" (JSR 335).

One thing I've wondered is: in what ways are Java threads inadequate? Yes, manual thread management is a pain, fraught with potential for trouble, strange difficult-to-reproduce problems, etc. As I wrote in my last blog post, I have personal experience working on an application where the app ran flawlessly on our own corporate development and test platforms, but keeled over onto itself and brought our customer's much faster, more powerful systems to a halt a few minutes after the program was started up. Concurrent programming is a strange universe, indeed.

The Concurrency Utilities made things easier by adding features like java.util.concurrent.atomic, java.util.concurrent.CyclicBarrier, and perhaps most notably java.util.concurrent.ThreadPoolExecutor. So, with all these convenient new java.util.concurrency features making programming using threads easier, why did we need something like the Fork/Join Framework? Why do we think we need Lambda Expressions?

On page 893 of his book, in the section titled "Parallel Programming via the Fork/Join Framework," Herb Schildt explains:

The Fork/Join Framework enhances multithreaded programming in two important ways. First, it simplifies the creation and use of multiple threads. Second, it automatically makes use of multiple processors.

But, from this description, we still don't have a clear idea of what was "wrong" with plain old Java threads, do we?

On the next page, Herb says:

it is important to point out the distinction between traditional multithreading and parallel programming. In the past, most computers had a single CPU and multithreading was primarily used to take advantage of idle time, such as when a program is waiting for user input. Using this approach, one thread can execute while another is waiting... Although this tyupe of multithreading will always remain quite useful, it was not optimized for situations in which two or more CPUs are available (multicore computers).

So, that's the answer to my question. Java threads are not optimized for parallel computing. The Fork/Join Framework is.

Indeed, in his paper "A Java Fork/Join Framework" Doug Lea reports that his Fork/Join implementation of a class that computes the Fibonacci Function "runs at least thirty times faster than an equivalent program in which each new task is run in a new java.lang.Thread." That's a remarkable difference!

I'll be experimenting with the Fork/Join Framework very soon. Among my first tests will be developing Fork/Join Framework implementations of some of the experiments I did earlier with Java threads (documented in my blog posts "Multicore Desktop Application Experimentation, Part 1: Java Threads" and "A Look at Java Thread Overhead"). I'm looking forward to this! Weblogs

Since my last blog post, several people have posted new blogs:


Our current poll asks Are you aware of Oracle Enterprise Pack for Eclipse (OEPE)?. Voting will be open until Friday, April 27.

Java News

Here are the stories we've recently featured in our Java news section:


Our latest Spotlight is Geertjan Wielenga's JavaOne Moscow:

JavaOne Moscow has come and gone. I was one of the lucky people able to be there as a speaker, together with several others I've known for some years, including [Duke]. It was a great conference, extremely well attended, people walking around everywhere, going to sessions, booths, and long lines at lunch...

Before that, we featured James L. Weaver's Best Practices for JavaFX 2.0 Enterprise Applications (Part One):

This article, which is part one of a two-part series, focuses on using best practices for developing enterprise applications in JavaFX 2.0. To illustrate some best practices for enterprise application development in JavaFX 2.0, a sample application named TweetBrowser will be examined. As shown in Figure 1, this application contains the following...

Subscriptions and Archives: You can subscribe to this blog using the Editor's Blog Feed. You can also subscribe to the Java Today RSS feed and the blogs feed. You can find historical archives of what has appeared the front page of in the home page archive.

-- Kevin Farnham

Twitter: @kevin_farnham