[concurrency-interest] ForkJoinPool with custom number of WorkQueues
nigro.fra at gmail.com
Fri Nov 9 02:52:25 EST 2018
In the past implementations of the FJ pool there was a SPIN static variable
used for this purpose that where quite good (with parallelism<available
cores) to not park immediately the executor threads where is nothing to do.
I have the same problem of Carl and I have found a similar "solution":
reduce the parallelism hoping to get the queues more busy, but it would in
incour in an higher contention on offer side.
It wouldn't make sense to inject some WaitStrategy to allow the user to
choose what to do before parking (if parking)?
Il giorno ven 9 nov 2018, 00:18 Carl Mastrangelo via Concurrency-interest <
concurrency-interest at cs.oswego.edu> ha scritto:
> I am using ForkJoinPool as a means to avoid lock contention for submitting
> tasks to an executor. FJP is much faster than before, but has some
> unexpected slowdown when there is not enough work. In particular, A
> significant amount of time is spent waiting parking and unparking threads
> when there no work to do. When there is no active work, it seems each
> worker scans the other work queues looking for work before going to sleep.
> In my program I have a parallelism of 64, because when the work load is
> high, each of the threads can be active. However, when work load is low,
> the workers spend too much time looking for more work.
> One way to fix this (I think) is to lower the number of worker queues, but
> keep the same number of workers. In my case, having 32 or 16 queues
> rather than having exactly 64 might help, but I have no way of testing it
> out. Has this ever been brought up, or is it possible for me to easily
> patch FJP to see if it would help?
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest