[concurrency-interest] ForkJoinPool seems lead to a worselatencythan traditional ExecutorServices
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:
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.
More information about the Concurrency-interest