Multithread Programming Versus Parallel Programming; or, What's Wrong with Java Threads?
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!
- Abdel Martinez, String Searching Algorithms (Part I);
- Jitendra Kotamraju, Server-Sent Events (SSE) in GlassFish;
- Bhakti Mehta, Server Sent Events Sample with Glassfish; and
- Otavio Santana, Easy-Cassandra 1.0.9: With annotations jpa and JPQL.
Our current Java.net poll asks Are you aware of Oracle Enterprise Pack for Eclipse (OEPE)?. Voting will be open until Friday, April 27.
Here are the stories we've recently featured in our Java news section:
- Terrence Barr presents JavaFX 2: Making Client Apps Sexy Again!;
- Geertjan Wielenga illustrates JavaFX for Corporate Desktop Apps Too? (Not Just Games?);
- Jean-Francois Arcand documents Websockets or Comet or Both? What
Related Topics >>