Incomputer programming, athread pool is asoftware design pattern for achievingconcurrency of execution in a computer program. Often also called areplicated workers orworker-crew model,[1] a thread pool maintains multiplethreads waiting fortasks to be allocated forconcurrent execution by the supervising program. By maintaining a pool of threads, the model increases performance and avoids latency in execution due to frequent creation and destruction of threads for short-lived tasks.[2] Another good property - the ability to limit system load, when we use fewer threads than available. The number of available threads is tuned to the computing resources available to the program, such as a parallel task queue after completion of execution.
The size of a thread pool is the number of threads kept in reserve for executing tasks. It is usually a tuneable parameter of the application, adjusted to optimize program performance.[3] Deciding the optimal thread pool size is crucial to optimize performance.
One benefit of a thread pool over creating a new thread for each task is that thread creation and destruction overhead is restricted to the initial creation of the pool, which may result in betterperformance and better systemstability. Creating and destroying a thread and its associated resources can be an expensive process in terms of time. An excessive number of threads in reserve, however, wastes memory, and context-switching between the runnable threads invokes performance penalties. A socket connection to another network host, which might take many CPU cycles to drop and re-establish, can be maintained more efficiently by associating it with a thread that lives over the course of more than one network transaction.
Using a thread pool may be useful even putting aside thread startup time. There are implementations of thread pools that make it trivial to queue up work, control concurrency and sync threads at a higher level than can be done easily when manually managing threads.[4][5] In these cases the performance benefits of use may be secondary.
Typically, a thread pool executes on a single computer. However, thread pools are conceptually related toserver 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.[citation needed]
The number of threads may be dynamically adjusted during the lifetime of an application based on the number of waiting tasks. For example, aweb server can add threads if numerousweb page requests come in and can remove threads when those requests taper down.[disputed –discuss] The cost of having a larger thread pool is increased resource usage. The algorithm used to determine when to create or destroy threads affects the overall performance:
Inbash implemented by--max-procs /-P inxargs, for example:
# Fetch 5 URLs in parallelurls=("https://example.com/file1.txt""https://example.com/file2.txt""https://example.com/file3.txt""https://example.com/file4.txt""https://example.com/file5.txt")printf'%s\n'"${urls[@]}"|xargs-P5-I{}curl-sI{}|grep-i"content-length:"
InGo, called worker pool:
packagemainimport("fmt""time")funcworker(idint,jobs<-chanint,resultschan<-int){forj:=rangejobs{fmt.Println("worker",id,"started job",j)time.Sleep(time.Second)fmt.Println("worker",id,"finished job",j)results<-j*2}}funcmain(){constnumJobs=5jobs:=make(chanint,numJobs)results:=make(chanint,numJobs)forw:=1;w<=3;w++{goworker(w,jobs,results)}forj:=1;j<=numJobs;j++{jobs<-j}close(jobs)fora:=1;a<=numJobs;a++{<-results}}
It will print:
$timegorunworker-pools.goworker 1 started job 1worker 2 started job 2worker 3 started job 3worker 1 finished job 1worker 1 started job 4worker 2 finished job 2worker 2 started job 5worker 3 finished job 3worker 1 finished job 4worker 2 finished job 5real 0m2.358s
another approach that manages resources well is to start a fixed number of handle goroutines all reading from the request channel. The number of goroutines limits the number of simultaneous calls to process
Worker pools are a model in which a fixed number of m workers (implemented in Go with goroutines) work their way through n tasks in a work queue (implemented in Go with a channel). Work stays in a queue until a worker finishes up its current task and pulls a new one off.
