[concurrency-interest] What's the advantage of a Java-5 ThreadPoolExecutor over a Java-7 ForkJoinPool?

Holger Peine Holger.Peine at fh-hannover.de
Tue Feb 14 10:57:06 EST 2012

Dear colleagues,

looking at their respective API, ForkJoinPool provides a superset of
ThreadPoolExecutor's functionality in standard scenarios (though
strictly speaking ThreadPoolExecutor offers more opportunities for
tuning than ForkJoinPool). Adding to this the observation that fork/join
tasks seem to be faster (possibly due to the work stealing scheduler),
need definitely fewer threads (due to the non-blocking join operation),
one might get the impression that ThreadPoolExecutor has been superseded
by ForkJoinPool.

But is this really correct? All the material I have read (the best
being Brian Goetz's article
http://www.ibm.com/developerworks/java/library/j-jtp11137 and the
official JDK API doc) seems to sum up to a rather vague distinction
between the two types of thread pools:
- ForkJoinPool is for many, dependent, task-generated, short, hardly
  ever blocking (i.e. compute-intensive) tasks
- ThreadPoolExecutor is for few, independent, externally-generated,
  long, sometimes blocking tasks

Is this distinction correct at all? Can we say anything more specific
about this?

Thanks for your opinion,
Holger Peine

Prof. Dr. Holger Peine
Hochschule Hannover, Fakultät IV, Abt. Informatik
Tel: +49(511)9296-1830  Fax: -1810 (shared, please state my name)
Ricklinger Stadtweg 120, D-30459 Hannover, Germany

More information about the Concurrency-interest mailing list