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’s supported in the Java EE land;
- Roger Brinkley presents Java Spotlight Episode 79: Dr Fujio Maruyama on Japanese Java User Community;
- Chris Mayer reports Jenkins CI and JFrog unite for cloud artifact repository solution;
- JUG Chennai announcesChennai Java Summit-12 | Java User Group Chennai | Conferences | 21 Apr 2012;
- Kelly O'Hair shares JDK Build Musings;
- Arun Gupta presents JavaOne Moscow/Russia Trip Report;
- Ludovic Poitou shares A timeline of LDAP directory services…;
- Arun Gupta shares Configuring JMS and Message Queues in GlassFish - Sample Chapter;
- John Yeary demonstrates JSF 2 on JBoss AS 5.1.0;
- Micha Kops demonstrates Wiring made easy using OSGi Blueprint and Apache Karaf;
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 java.net Editor's Blog Feed. You can also subscribe to the Java Today RSS feed and the java.net blogs feed. You can find historical archives of what has appeared the front page of Java.net in the java.net home page archive.