If you have used the ThreadPool in .NET 1.x, you know that the threadpool defaults to ( 25 * number of processors ) threads per process. It can be changed, but it is kinda complicated to track down how to change this. Well, MS has made changing the threadpool to make this easily changeable. Here is some example code:ThreadPool.GetMaxThreads(out iMaxThrds, out iThrdCompletionPT);
ThreadPool.SetMaxThreads(Environment.ProcessorCount * 50, iThrdCompletionPT);ThreadPool.GetMaxThreads(out iMaxThrds, out iThrdCompletionPT);
For .Net 2.0 / 3.0
The first time that ThreadPool.GetMaxThreads is called, the value I recieved is 25, which is what I would expect from a system with 1 cpu. I then call back to SetMaxThreads with the value of 50 times the number of cpus. when I make the second call into ThreadPool.GetMaxThreads(), i get back the value of 50.
So, if you have exhausted your threadpoll threads, this is a way to get more threads into your threadpool.
One thing that I want to mention, this will not change the number of threads that are used by the threadpool. If the threadpool still thinks that you don't need any more threads, then you won't really get anything by increasing the number of threads in the threadpool. This is only going to be useful if you have depleted the number of threads in your threadpool.
Use caution when changing the maximum number of threads in the thread pool. While your code might benefit, the changes might have an adverse effect on code libraries you use.
Setting the thread pool size too large can cause performance problems. If too many threads are executing at the same time, the task switching overhead becomes a significant factor.
For .Net 3.5
ThreadPool.GetMaxThreads(out iMaxThrds, out iThrdCompletionPT);
will return 500 for iMaxThrds and 1000 for iThrdCompletionPT (for 2 cores processor)
This is amazing !!! So If your machine runs .Net 3.5 you do not have to increase the thread pool…
The primary reason for this change was to minimize the possibility of deadlocking the entire thread pool. Apparently, the CLR team has been receiving many support requests from customers who have used all the thread pool threads for tasks (such as processing ASP.NET requests) and deadlocked while waiting for these requests to complete.
For example, consider a parallel processing pipeline in which task N1 runs and then waits until task N2 completes, which runs and waits until task N3 completes and so forth (N1…NP). If there are more tasks (P) than thread pool threads, the thread pool will eventually deadlock. Introducing more thread pool threads means statistically reducing the frequency of a deadlock
While it is true that each thread consumes stack memory, it's not committed memory but reserved memory only. Which means that 500 threads are not actively using 500MB of physical memory; they are reserving 500MB of virtual memory and actively using only a tiny part of it (perhaps even a single page per thread). This is definitely not a problem on 64-bit because the virtual address space is practically infinite; on 32-bit, the reservation itself might be problematic and hence you might want to tune the behavior.