It's Getting Crowded in the ThreadPool

It seems everybody loves the thread pool. The default scheduler in Windows Workflow uses the thread pool, as does ASP.NET and the BeginInvoke method of every delegate. There is only one pool per process, which seems a bit limiting with such a big party inside.

Joe Duffy says there is a lot of work going into improving the ThreadPool in future versions of the base class library, I wonder if future versions will allow for some partitioning of work. .

A couple people have asked me about custom thread pools. I do see the need in some scenarios, but writing a custom thread pool is hard. I generally point people to custom thread pools that smart people have already built:

Jon Skeet has a custom thread pool class on this page. The pool is configurable and allows you to separate your threads from the threads in the system pool.

Mike Woodring has a custom thread pool available on this page. The thread pool is configurable, instrumented, and has a great many features.

posted on Sunday, July 23, 2006 10:30 PM by scott

Comments

Monday, July 24, 2006 1:50 AM by Eran Sandler

# re: It's Getting Crowded in the ThreadPool

Don't forget that timers also use the thread pool.

While you have only one thread pool per process, its size depends on the number of CPUs you have (logical ones, which means HyperThreading will get you an "extra CPU").

You have 25 threads per CPU and 1000 I/O completion threads.

If you have an ASP.NET application (which uses the thread pool) and some async calls (which uses the thread pool) and you use Windows Workflow scheduler (which uses the thread pool) and maybe you also have a timer (which uses the thread pool), you are in deep ***...

Even if you do use a custom thread pool you should be aware of the total number of threads you have in your process. Having too many threads will simply mean you'll spend too much time context switching. In addition to that, threads themselves takes a bit memory. Having a stack to each thread also takes memory.

I actually got a draft post that I'll soon post on <a href="http://dotnetdebug.blogspot.com>my blog</a> about timers and ASP.NET applications. I hope to finish it soon :-)
Monday, July 24, 2006 5:38 AM by Josh

# re: It's Getting Crowded in the ThreadPool

Hi Scott,

I did some tests with Jon Skeet's threadpool which I wrote about here: http://www.thejoyofcode.com/More_fun_with_Thread_Pools.aspx

It makes for interesting reading. (We also talked about tuning the threadpool for burst load here: http://www.thejoyofcode.com/Tuning_the_ThreadPool.aspx)
Monday, July 24, 2006 7:08 AM by scott

# re: It's Getting Crowded in the ThreadPool

Eran: I look forward to seeing that article.
Josh: Those are two good, detailed posts you have there. Thanks for the links.
Monday, July 24, 2006 9:42 AM by Thomas Freudenberg

# re: It's Getting Crowded in the ThreadPool

I'm pretty satisfied with SmartThreadPool [1], which I use in several projects.

[1] http://codeproject.com/csharp/smartthreadpool.asp