[concurrency-interest] What's the advantage of a Java-5 ThreadPoolExecutor over a Java-7 ForkJoinPool?
joe.bowbeer at gmail.com
Mon Feb 20 15:08:37 EST 2012
Is it (still) also true that it is difficult to manage multiple FJPs (because
each one will try to achieve maximum throughput)?
It would seem that TPE handles this better, because each pool can be
configured to operate with limits placed on its number of threads and
queued tasks. Though I'm not optimistic that that works well in practice
when there are multiple apps running... (For example, choosing a single
TPE configuration that works well for all SwingWorker clients -- providing
plenty of background processing without affecting the responsiveness of the
UI -- is a never-ending battle.)
On Mon, Feb 20, 2012 at 11:07 AM, Doug Lea wrote:
> (Slowly catching up with mail.)
> On 02/16/12 07:06, Mohan Radhakrishnan wrote:
>> Does ... mean that now I can submit independent tasks to the FJ framework
>> without the need for a task and subtask graph and still get the benefits
>> work stealing ?
> You get *some* of the benefits of work-stealing -- mainly decentralized
> queuing and much better scalability.
> The main tradeoff compared to ThreadPoolExecutor is that you have less
> control (for example no direct access to submission queues) and essentially
> no configuration methods. (Although most people seem to agree that
> lack of such methods and options is a feature not a bug. In part because
> it simplifies our ability to improve internal implementations over time
> in ways that we cannot do with TPE because it reveals so much of its
> internal workings.)
> The other tradeoff is that FJP generally uses more CPU cycles
> and memory than TPE.
> All other things being equal, as a rough rule of thumb, if you are
> running with 4 or fewer processors/cores, you probably won't see any
> advantage to using FJP vs TPE as an "plain" ExecutorService. And
> for a singleton (size one) pool, TPE is clearly better.
> On larger platforms, FJP can be almost arbitrarily faster.
> Concurrency-interest mailing list
> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest