[concurrency-interest] ForkJoinPool seems lead to a worselatencythan traditional ExecutorServices

Gregg Wonderly gregg at cytetech.com
Tue Apr 17 09:47:48 EDT 2012

On 4/17/2012 8:22 AM, √iktor Ҡlang wrote:
> On Tue, Apr 17, 2012 at 2:51 PM, David Holmes <davidcholmes at aapt.net.au
> <mailto:davidcholmes at aapt.net.au>> wrote:
>     __
>     Sorry that was somewhat terse.
>     ForkJoinPool is not a drop-in replacement as an arbitrary ExecutorService.
>     It is specifically design to efficiently execute tasks that implement
>     fork/join parallelism. If your tasks don't perform fork/join parallelism but
>     are plain old Runnables/callables that do blocking I/O and other "regular"
>     programming operations then they will not likely see any benefit from using
>     a ForkJoinPool.
> I disagree:
> http://letitcrash.com/post/20397701710/50-million-messages-per-second-on-a-single-machine

That has nothing to do with the use of ForkJoin it appears to me.  It is simply 
a thread use efficiency change that causes a scheduled thread to do enough work 
that the latency of scheduling becomes a small enough component that it 
disappears from view because the other thread is running (2 are available per 
core) while scheduling occurs.

This would happen no matter what kind of thread pool was used, with appropriate 
timings/thread-scheduling that created the same effect.

Gregg Wonderly

More information about the Concurrency-interest mailing list