Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (athena.apache.org: domain of pats@acm.org designates
 209.86.89.68 as permitted sender)
Message-ID: <4E0D7AEF.8020801@acm.org>
Date: Fri, 01 Jul 2011 00:44:47 -0700
From: Patricia Shanahan <pats@acm.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US;
 rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: dev@river.apache.org
Subject: Re: TaskManager
References: <4E079538.5010108@zeus.net.au>	<4E079896.20908@acm.org>
	<4E079D5D.3000901@zeus.net.au>	<4E07AFA4.5040203@acm.org>
	<4E07B023.1040902@zeus.net.au>
	<77F1E32F67C8D5479858C0C7E93EB465077B0573@WAL-MAIL.global.avidww.com>
	<4E0D2AA9.1030504@acm.org>	<4E0D2F81.2050905@wonderly.org>
 <BANLkTik3iWs7PcUXC1ncWMp-K12EpvA2mA@mail.gmail.com>
In-Reply-To: <BANLkTik3iWs7PcUXC1ncWMp-K12EpvA2mA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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?

Patricia