headers
Alexander.Berger | 4 Jun 2012 15:13
Picon
Favicon

How to dynamically adapt the pool size of a ForkJoinPool

Hello everybody
 
I am experimenting with a special kind of ForkJoinPool which uses some heuristics to detect if
some of its worker threads are blocked (by other means than ManagedBlocker, e.g. sleeping, waiting, I/O, ...) and
which will automatically add new worker threads to compensate for blocked threads.
 
To add new worker threads I use tryCompensate(null,null) which works as expected, but I found no way
to later on decrease the number of worker threads (once there are no blocked workers anymore). I tried
using incrementActiveCount() but without any success. I just don't get rid of the extra threads.
 
So here comes my question:
 
How can I instruct a ForkJoinPool instance to release its extra worker threads (those that exceed parallelism)?
 
Please note, I have read the comments (in ForkJoinPool.java) about the problems such an approach
could cause (unwanted positive feedback control loops, etc.). Nevertheless I want to experiment
with such a solution as in our use case we want to share a ForkJoinPool instance with some legacy
and third party code, over which we have no control and which might submit blocking tasks to
the ExecutorService represented by that ForkJoinPool instance.
 
Alex
 
 
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest <at> cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Permalink | Reply |
headers
Doug Lea | 4 Jun 2012 15:36
Favicon

Re: How to dynamically adapt the pool size of a ForkJoinPool

On 06/04/12 09:13, Alexander.Berger <at> finnova.ch wrote:

> How can I instruct a ForkJoinPool instance to release its extra worker threads
> (those that exceed parallelism)?

Assuming you are hacking on FJ source code...
Workers can only be removed after running idleness consensus.
They then wait SHRINK_RATE ns after last idleness or removal.
SHRINK_RATE is set to a relatively high value (about 4sec)
in part to avoid some (uncommon) hysteresis effects.
You could try lowering it.

Also note that unless there are a huge number of them
(so cause a resource problem), these extra workers are
probably not doing you enough harm in terms of throughput
to warrant intervention.

-Doug
Permalink | Reply |

Gmane