Jeroen
Sat Apr 19 14:15:03 CDT 2008
Michael D. Ober wrote:
> Does the ThreadPool in framework 3.5 honor the SetMaxThreads method?
> The reason I ask is that I started a program that queued 256 worker
> threads in the threadpool
You can't queue worker threads, you queue work items. The thread pool then
decides to allocate threads for those items as it sees fit.
> and after a few minutes, task manager (and the
> console output) showed all of them working.
You mean to say that task manager showed that the process had 256+ threads
running? That would be surprising to me. I ran this little test program:
static void Main(string[] args) {
ThreadPool.SetMaxThreads(20, 20);
int i = 0;
while (true) {
ThreadPool.QueueUserWorkItem(
delegate(object o) {
while (true) {
Console.WriteLine("Work item {0} reporting in", o);
Thread.Sleep(1000);
}
},
++i
);
Thread.Sleep(100);
}
}
Basically this is the worst way to use the thread pool; I'm queueing up
items forever that additionally never complete. Process Explorer shows the
number of threads stabilizing at 27 and indeed the output never progresses
beyond "worker item 20 reporting in"; the additional work items are simply
queued up but never executed.
If I remove the loop in the thread delegate (ensuring that worker items
finish quickly) the number of threads never goes above 9 and no additional
worker threads are allocated.
> I have situations where I need to limit the number of active tasks
> because they are resource intensive on a different system but not on the
> local workstation and I need to ensure I don't kill the other system's
> responsiveness.
>
Well, to begin with, the thread pool is not a limiting mechanism on
concurrency nor is it supposed to be used for work items that take a lot of
time to complete. It's intended to utilize the system's potential for
concurrency as much as possible. If you need to limit the maximum number of
outstanding tasks, you should do so yourself (with a semaphore, for example).
--
J.
http://symbolsprose.blogspot.com