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

Doug Lea dl at cs.oswego.edu
Mon Feb 20 17:22:31 EST 2012


On 02/20/12 15:08, Joe Bowbeer wrote:
> Is it (still) also true that it is difficult to manage multiple FJPs (because
> each one will try to achieve maximum throughput)?

While it is almost always best to use only one FJP, if your objective is
to maximize throughput, then multiple FJPs is probably still
better than alternatives. You are right that there is not usually
a simple answer when  mixing with latency concerns (as in SwingWorker)
though.

-Doug

>
> 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.)
>
> Joe
>
> 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 of
>         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.
>
>     -Doug
>
>
>
>
>
>
>     _________________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.__oswego.edu <mailto:Concurrency-interest at cs.oswego.edu>
>     http://cs.oswego.edu/mailman/__listinfo/concurrency-interest
>     <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list