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

David Holmes davidcholmes at aapt.net.au
Tue Feb 14 16:49:51 EST 2012


Holger,

ForkJoinPool is designed for supporting fork/join based parallel
decomposition algorithms. It does that well via the work-stealing mechanisms
which reduce the task management overhead. It can only support other styles
of "parallel computation" with varying degrees of success.

ThreadPoolExecutor is a plain old thread pool. It makes no assumptions about
the type or nature of tasks or their dependencies.

Brian's summary is quite correct.

Obviously the two are, within limits, interchangeable, but they operate in
completely different spots in the design space.

David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Holger
> Peine
> Sent: Wednesday, 15 February 2012 1:57 AM
> To: concurrency-interest at cs.oswego.edu
> Subject: [concurrency-interest] What's the advantage of a Java-5
> ThreadPoolExecutor over a Java-7 ForkJoinPool?
>
>
> 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
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>




More information about the Concurrency-interest mailing list