General usage of ThreadPool

ThreadPool is a .NET implementation of the thread pool pattern. What it does is it allows a number of threads to be run independently in a thread queue for the current application.

How it works

Let’s take a look at this image first:

Each .NET application has its own ThreadPool instance that allows managing various processes by putting the operational part inside multiple threads that are later on queued inside the ThreadPool. The ThreadPool can contain both worker and asynchronous I/O threads.

The developer decides if he wants to put some limits on the existing ThreadPool – the maximum and minimum number of threads that should be available for the application. There is a specific limit of the maximum (actively working threads) and minimum (idle threads) numbers for a ThreadPool instance.

If a process is delegated to ThreadPool, then it tries to find a spot for that process. In case there is an empty spot (depending on the designated limits), a new thread is created inside the ThreadPool and is executed. If not – the process stands in the queue until a free spot becomes available.

Let’s take a detailed look at how it works inside your .NET application.

Getting available threads

As you already know, the ThreadPool instance specific to an application has a limited number of threads available, either set by the application (using the default settings) or by the developer. Getting the number of available worker and asynchronous I/O threads is possible through the GetAvailableThreads method.

Sample code:

int availableWorkers = 0;
int availableAsyncIO = 0;

ThreadPool.GetAvailableThreads(out availableWorkers, out availableAsyncIO);

The default number of available workers is 1023 and 1000 for asynchronous I/O threads. These values are flexible, so that the developer can dynamically adapt them to the current needs.

Getting and setting the maximum and minimum numbers for threads in the ThreadPool

The maximum number of threads in the ThreadPool (applies both to workers and asynchronous I/O threads) is the number of threads that will concurrently run performing various operations. If there are more processes that need to be placed in the ThreadPool, but there are not enough slots (therefore, the maximum number of threads is exceeded), additional processes are put into the queue, waiting for free slots in the ThreadPool.

The maximum number of threads is returned by the GetMaxThreads method:

int availableWorkers = 0;
int availableAsyncIO = 0;

ThreadPool.GetMaxThreads(out availableWorkers, out availableAsyncIO);

The developer is able to adapt this value to minimize the resource consumption via the SetMaxThreads method:

int availableWorkers = 0;
int availableAsyncIO = 0;
ThreadPool.SetMaxThreads(9000, 9000);

NOTE: The maximum number of possible worker threads is 32,767. For asynchronous I/O threads, this number is as high as 2,147,483,647. This, however, does not mean that you should ever be using max values here. This has a negative impact on the application performance later on, when there are too many threads running.

The minimum value represents the minimum number of threads that should be idle waiting for assigned workers and asynchronous I/O threads. According to this document, the default minimum number of threads depends on the number of processors for the current computer plus one thread for each thread type (worker and asynchronous I/O). This applies to multi-core processors as well. For example, if I am running a dual-core machine, then the minimum number of threads will be 2 for each type.

The minimum value is retrieved via the GetMinThreads method:

int availableWorkers = 0;
int availableAsyncIO = 0;
ThreadPool.GetMinThreads(out availableWorkers, out availableAsyncIO);

To change this value, the SetMinThreads method is used:

int availableWorkers = 0;
int availableAsyncIO = 0;
ThreadPool.SetMinThreads(20, 20);

You have to carefully adjust the number of minimum threads to avoid performance issues, since you are basically manipulating the number of idle threads. However, a lot of bottlenecks can be avoided if the minimum number of threads is adjusted correctly, depending on individual needs.

NOTE: You cannot set a minimum value that is less than the default one.

Get ThreadPool working

Now it is time to see ThreadPool in action. You, as the developer, can queue work items to be passed to the ThreadPool via the QueueUserWorkItem method:

ThreadPool.QueueUserWorkItem(new WaitCallback(GetList));

This automatically separates the method in a new thread and queues it as a worker background thread. In case the method you are going to pass requires specific parameters, you can use the overloaded QueueUserWorkItem method that accepts an object as a second parameter. That way you can use the passed object from inside the method.

Asynchronous I/O threads are not instantiated directly via ThreadPool, but instead are automatically put there once created by the application.

Conclusion

Using ThreadPool might be an efficient solution if you have multiple tasks that should run concurrently and that should be inside background threads. However, there is no control over the thread execution order – there is no guarantee that the first thread inserted in the queue will also be the first one to finish its execution. There is also no control on whether the threads created are foreground or background or need to be stopped – this can be a serious drawback when you want to make a set of threads as the main ones that should complete before the application exits.