[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