river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: TaskManager
Date Fri, 08 Jul 2011 14:11:50 GMT
On 7/7/2011 2:26 PM, Mike Sobolewski wrote:

>>> I'm curious about why the load factor option is desirable. Suppose
>>> you have 30 tasks waiting, and you have could afford 30 threads for
>>> the function, then why not allow 30 threads? The load factor has
>>> the effect of limiting the throughput even when you would create
>>> more threads if there were more tasks.
>> On 7/7/2011 9:11 AM, Mike Sobolewski wrote:
>> The issue is not in having enough threads to process all existing
>> tasks but in a reasonably "smooth" number of threads over long time
>> so temporary peaks of many tasks can be handled by smaller number of
>> threads with no need to create additional many threads for a short
>> moment and release them after that temporary peak over and over.

I agree that smoothing is a reasonable objective. The load factor does
have some smoothing effect - if the load factor is L, the rate of change
in the number of threads is 1/L times the rate of change in the number
of runnable tasks. However, it converges to 1/L times the number of
threads that are needed to run the tasks without unnecessary slow down.

ThreadPoolExecutor does half the job, by having a settable delay between
a thread becoming idle and the thread being destroyed if it remains
idle. I'm looking at extending it to cover the other side, a time delay
between an increase in the number of runnable tasks that are waiting for
tasks and an increase in the number of threads if the task waiting persists.

Of course, this is subject to an optional upper bound on the number of
threads, regardless of the number of tasks.


View raw message