Thread Pooling

Introduction

Having multiple threads expedites application execution, in theory. The program would use the CPU’s multiple cores. However, the practical benefit of multithreading depends on a number of factors. First of all, creating and starting a thread is a taxing operation. If our program is constantly instantiating the Thread class in an effort to parallelize the execution of several methods, run a single method several times in parallel, or perform some long-running jobs in the background, we can be sure that performance will be affected (not always in a good way). Secondly, constant context switching negatively affects performance.

When we need to execute some method in the background or parallelize a job, we should reuse threads when they’re done performing their tasks, instead of creating a new thread each time. Thread pooling allows us to do this.

Thread pool

A thread pool is the collection of threads available for use by an application. Upon completion of its task, a thread from the pool isn’t destroyed, but is returned to the pool to await its next request. Performance is unaffected because the thread isn’t destroyed.

Each .NET application has one thread pool at its disposal. The pool’s threads are created when the application launches, and the number of threads depends on the system’s specifications. Developers can modify the number of threads in the pool, but doing so may lead to performance issues, so it’s not recommended.

We use the static ThreadPool class in the System.Threading namespace to work with the pool. This class is static because we don’t instantiate a thread pool. It’s created by default upon app startup.

The most important method of this class is QueueUserWorkItem(WaitCallback callBack). It adds a method to be executed by a thread pool thread. If there are no free threads at the moment, then the method waits in the queue until one of the threads completes its task and is returned back to the pool.