Thread pool

From Infogalactic: the planetary knowledge core
Jump to: navigation, search

Lua error in package.lua at line 80: module 'strict' not found.

A sample thread pool (green boxes) with waiting tasks (blue) and completed tasks (yellow)

In computer programming, a thread pool pattern (also replicated workers or worker-crew model)[1] consists of a number m of threads, created to perform a number n of tasks concurrently. Typically m is not equal to n; instead, the number of threads is tuned to the computing resources available to handle tasks in parallel (processors, cores, memory) while the number of tasks dependents on the problem and may not be known upfront.

Reasons for using a thread pool, rather than the obvious alternative of spawning one thread per task, are to prevent the time and memory overhead inherent in thread creation,[2] and to avoid running out of resources such as open files or network connections (of which operating systems allocate a limited number to running programs).[3] A common way of distributing the tasks to threads is by means of a synchronized queue. The threads in the pool take tasks off the queue, perform them, then return to the queue for their next task.

Overview

The number of threads used is a parameter that can be tuned to provide the best performance. Additionally, the number of threads can be dynamic based on the number of waiting tasks. For example, a web server can add threads if numerous web page requests come in and can remove threads when those requests taper down.[disputed ] The cost of having a larger thread pool is increased resource usage. The algorithm used to determine when to create or destroy threads will have an impact on the overall performance:

  • create too many threads, and resources are wasted and time also wasted creating any unused threads
  • destroy too many threads and more time will be spent later creating them again
  • creating threads too slowly might result in poor client performance (long wait times)
  • destroying threads too slowly may starve other processes of resources

The algorithm chosen will depend on the problem and the expected usage patterns.

A major advantage of using a thread pool over creating a new thread for each task is thread creation and destruction overhead is negated, which may result in better performance and better system stability. Creating and destroying a thread and its associated resources is an expensive process in terms of time. An excessive number of threads will also waste memory, and context-switching between the runnable threads also damages performance. For example, a socket connection to another machine—which might take thousands (or even millions) of cycles to drop and re-establish—can be avoided by associating it with a thread which lives over the course of more than one transaction.

Typically, a thread pool executes on a single computer. However, thread pools are conceptually related to server farms in which a master process, which might be a thread pool itself, distributes tasks to worker processes on different computers, in order to increase the overall throughput. Embarrassingly parallel problems are highly amenable to this approach.

See also

References

  1. Garg, Rajat P. & Sharapov, Ilya Techniques for Optimizing Applications - High Performance Computing Prentice-Hall 2002, p. 394
  2. Lua error in package.lua at line 80: module 'strict' not found.
  3. Lua error in package.lua at line 80: module 'strict' not found.

External links