[concurrency-interest] What's the advantage of a Java-5 ThreadPoolExecutor over a Java-7 ForkJoinPool?
joe.bowbeer at gmail.com
Wed Feb 15 03:31:06 EST 2012
ThreadPoolExecutor provides a lot of different options for configuring the
worker threads. The Executors tool class provides convenience methods to
create many of the useful configurations:
The single-threaded variant, for example, is quite different from any
ForkJoinPool. The CachedThreadPool is more like a ForkJoinPool.
It's difficult to manage multiple ForkJoinPools because each one will try
to achieve maximum throughput, whereas the classic thread pools can
designed to operate within limits.
ThreadPoolExecutor also supports custom BlockingQueue implementations, and
direct access to its queue.
On Tue, Feb 14, 2012 at 11:13 PM, Holger Peine wrote:
> Am 14.02.2012 22:49, schrieb David Holmes:
> > Holger,
> > ForkJoinPool is designed for supporting fork/join based parallel
> > decomposition algorithms. It does that well via the work-stealing
> > which reduce the task management overhead. It can only support other
> > of "parallel computation" with varying degrees of success.
> > ThreadPoolExecutor is a plain old thread pool. It makes no assumptions
> > 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
> > 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
> >> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest