A thread is the smallest unit of execution within a process. A thread pool comprises of a number of threads, or, a collection of threads to be precise, and it can be used to perform several activities in the background.
Why should I use thread pools?
Threads are expensive as they consume a lot of resources in your system for initialization, switching contexts, and releasing the resources they occupy. Normally, when a thread is performing an I/O operation (file handling, database operation or accessing the network resources, etc.) the thread is blocked by the operating system until the I/O operation is complete. The thread will resume its CPU operation after its I/O operation is complete.
A thread pool is a good choice when you want to limit the number of threads that are running at a given point of time and want to avoid the overhead of creating and destroying threads in your application. It's also a good choice when you have many tasks in your application that need to be executed either in parallel or concurrently and you would like to improve the application's responsiveness by avoiding the context switches. To create a thread pool, you can take advantage of the System.Threading.ThreadPool class.
The following code snippet shows how you can set the minimum number of threads in the thread pool.
ThreadPool.SetMinThreads (50, 50);
However, note that when a long-running task is in execution, the thread pool thread may be blocked for a long time. To make matters worse, incoming requests that depend on the threads from the thread pool may be on hold or may even be rejected primarily because the thread pool may not have available threads with it to handle an incoming request. A thread pool is also not a good choice when you have threads that differ in their priorities or you may need to abort a thread prematurely. A premature termination of a thread implies that the thread has been stopped forcefully before its turnaround time is over.
How does a thread pool work?
In essence, when working with thread pools, you would typically create a collection of threads and store them in a thread pool ahead of using the threads in your application. As and when you need a thread, you would be reusing those threads rather than create new threads each time the application needs to use a thread.
So, the application would make a request to the thread pool to get a thread from it, perform activities using the thread and then return the thread back to the thread pool when done. Thread pools are helpful in situations when you have more tasks to execute than you can create threads (there is a limit on the maximum number of threads you can create per process) in your application.
How can I optimize a thread pool?
When a process starts, it is allocated a pool of threads by the CLR. Note that you can configure the size of the thread pool if you need to. The runtime manages the thread pool intelligently. When the thread pool starts, there is just one thread in the thread pool. From then on, the thread pool manager (a component responsible for managing the thread pool) creates more threads and stores them in the thread pool as the load on the application increases, i.e., the application needs more and more tasks to be executed concurrently.
The number of threads that can be available in the thread pool at any given point of time is governed by the maximum permissible limit of threads in the thread pool. In other words, the number of available threads in the thread pool varies from time to time depending on the consumption of threads by the application. As soon as the maximum limit (maximum number of threads in the thread pool) is reached, the application creates new threads much more infrequently.
You can always set the upper limit permissible threads in the thread pool yourself if need be. To do this, you should take advantage of the ThreadPool.SetMaxThreads property. To set the lower limit of the threads in the thread pool you can use the ThreadPool.SetMinThreads property. The default lower limit of the number of threads in the thread pool is one thread per processor.
This article is published as part of the IDG Contributor Network. Want to Join?