river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: TaskManager
Date Fri, 01 Jul 2011 08:27:10 GMT
Inline....

On 1 July 2011 08:44, Patricia Shanahan <pats@acm.org> wrote:
> On 6/30/2011 11:38 PM, Dan Creswell wrote:
>>
>> On 1 July 2011 03:22, Gregg Wonderly<gregg@wonderly.org>  wrote:
>>>
>>> On 6/30/2011 9:02 PM, Patricia Shanahan wrote:
>
> ...
>>>>
>>>> loadLevel permits specification of a ratio between threads and tasks, so
>>>> that threads are only created up to e.g. one third of the number of
>>>> tasks. I'm not sure that is a really good idea. It means leaving tasks
>>>> to wait even if we could create another thread.
>>>
>>
>> Yes, but tasks are waiting because you're choosing to limit resources.
>> That always happens. The choices are to increase the limit and utilise
>> more processor (assuming you have it) or have fewer tasks (often a
>> function of user-load so needs admission control etc to make that
>> stick).
>>
>>> I don't like this thought at all in a distributed system.  A vast
>>> majority
>>> of tasks really need to be invoked immediately to maintain a reasonable
>>> chance at throughput.
>>>
>>
>> Equally a vast majority of tasks can only have a reasonable chance of
>> throughput in the presence of sufficient resource. The point of
>> TaskManager is to control resource consumption (including processor
>> utilisation) which naturally asserts a limit on throughput.
>
> ...
>
> Some resource limitation is definitely necessary, and supported by both
> TaskManager and ThreadPoolExecutor. In either implementation one can say
> "Use no more than 30 threads for this purpose.".
>
> That makes sense to me. Running too many threads increases resource
> utilization without increasing throughput. Even before that limit is
> reached, the need to share the system resources with other pools may
> limit the number of threads that can be allowed for one pool.
>
> The additional type of limitation that TaskManager supports and
> ThreadPoolExecutor does not is much weirder than that. TaskManager
> allows specification of a "load level" which is a ratio between the
> number of runnable tasks and the number of threads. For example, if the
> ratio is 3, then with 30 tasks it is limited to 10 threads. With 300
> tasks it is limited to 100 threads.
>
> If the system could efficiently accommodate 100 threads devoted to that
> pool, why not create 30 of them when there are 30 runnable tasks that
> could use them, rather than limiting the 30 tasks to 10 threads, keeping
> some of them waiting?

I can't recall specific discussion about this but I would imagine this
could be an attempt at handling context switching costs. Basically if
task execution time is small relative to context switch cost
"clamping" the number of threads down to some ratio of tasks might
make sense. It's overall faster for those tasks to wait just a little
in a queue whilst an already running thread comes back around to pick
them up than it is to context switch out a thread with a task, pull
another in (and start it up) and start dispatching that new task.

>
> Patricia
>

Mime
View raw message