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

√iktor Ҡlang viktor.klang at gmail.com
Wed Feb 15 03:38:04 EST 2012


You guys should have a look at the latest post at letitcrash.com

Cheers,
√

On Wed, Feb 15, 2012 at 9:31 AM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> 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:
>
>
> http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/Executors.html
>
>
> 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.
>
> Joe
>
> 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
>> 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,
>> Holger.
>>
>>
>> >> -----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
>> >
>>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>


-- 
Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - The software stack for applications
that scale

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120215/3afe89b3/attachment-0001.html>


More information about the Concurrency-interest mailing list