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

Joe Bowbeer joe.bowbeer at gmail.com
Wed Feb 15 07:17:34 EST 2012


2012/2/15 √iktor Ҡlang

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


Cool.  I also recommend Doug's paper:

http://gee.cs.oswego.edu/dl/papers/fj.pdf

and I think this interview is informative:

http://www.infoq.com/interviews/doug-lea-fork-join

Joe


> On Wed, Feb 15, 2012 at 9:31 AM, Joe Bowbeer 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 [are]
>> 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
>>> >
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120215/32e75d1a/attachment.html>


More information about the Concurrency-interest mailing list