[concurrency-interest] What's the advantage of a Java-5 ThreadPoolExecutor over a Java-7 ForkJoinPool?
radhakrishnan.mohan at gmail.com
Mon Feb 20 23:38:30 EST 2012
Thanks. Will there be some examples to look at ? Does anyone use it in
a real-time financial message procesor or something that requires high
throughput ? I have only written a simple merge sort example but that
did not fully help me learn.
On Tue, Feb 21, 2012 at 12:37 AM, Doug Lea <dl at cs.oswego.edu> 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
More information about the Concurrency-interest