[concurrency-interest] What's the advantage of a Java-5 ThreadPoolExecutor over a Java-7 ForkJoinPool?
Holger.Peine at fh-hannover.de
Wed Feb 15 02:13:16 EST 2012
Am 14.02.2012 22:49, schrieb David Holmes:
> 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.
Thanks for your reply, David. This reassures me that ...
(1) my "vague" understanding of the differences between the two thread
pools was correct
(2) you cannot draw a clear line between the two beyond the criteria
I had already named.
- Regarding the implementation of ForkJoinPool, I have the impression
that it has a global "entrance" task queue where the tasks submitted
"from the outside" go, and one task queue per thread where the tasks
generated "internally" (i.e. by the pool threads when executing tasks)
go and where the stealing happens. If that is correct, then a
ForkJoinPool whose tasks never generate child tasks would degenerate to
a ThreadPoolExecutor, and perform no better (nor, which is my point
here, any worse) than a ThreadPoolExecutor. Consequently, one could
argue that you should always use a ForkJoinPool: If your tasks are
actually fork/join tasks, then you get the benefit of ForkJoinPool,
but if they are not (i.e. if they are completely independent),
then you haven't lost anything compared using a ThreadPoolExecutor.
So, always using a ForkJoinPool would make your program more
flexible at no additional cost.
Is this correct?
Thanks for your opionion,
>> -----Original Message-----
>> From: concurrency-interest-bounces at cs.oswego.edu
>> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Holger
>> 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
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