What is a Thread Pool and Why Use One?
Learn what a thread pool is, how the worker-queue model works, and how to size one, with an interview question and C code example.
Expected Interview Answer
A thread pool is a fixed or bounded group of pre-created worker threads that pull tasks from a shared queue, so an application avoids the cost of spawning and tearing down a new OS thread for every unit of work.
Creating a thread involves the kernel allocating a stack, a thread control block, and scheduler bookkeeping, which is expensive if done per-request under high load. A thread pool amortizes that cost by starting N worker threads once, each looping on a shared task queue: submit a task, and whichever worker is free dequeues and runs it, then loops back for the next task instead of exiting. This bounds the number of concurrently running threads, which protects the system from unbounded memory and context-switch overhead when thousands of requests arrive at once, and lets the pool size be tuned to the number of CPU cores for CPU-bound work or higher for I/O-bound work. The trade-off is that pool sizing itself becomes a tuning problem — too few threads underutilizes the CPU, too many reintroduces the scheduling overhead the pool was meant to avoid.
- Avoids per-task thread creation and teardown overhead
- Bounds concurrent thread count to protect system resources
- Reuses threads, keeping their stacks and cache state warm
- Provides a natural point to apply backpressure via queue limits
AI Mentor Explanation
A thread pool is like a franchise keeping a fixed squad of net bowlers on retainer instead of hiring a brand-new bowler for every single delivery in practice. Whichever net bowler is free steps up when a batter is ready, delivers the ball, and immediately returns to the queue for the next batter rather than being paid off and replaced. Keeping the squad size fixed means the ground never gets overcrowded with idle bowlers, but too small a squad leaves batters waiting for a free bowler.
Step-by-Step Explanation
Step 1
Pool creation
A fixed number of worker threads are created up front and each begins looping on a shared task queue.
Step 2
Task submission
The application enqueues a unit of work instead of spawning a new thread for it.
Step 3
Dequeue and execute
Whichever worker thread is idle dequeues the next task and runs it to completion.
Step 4
Return to pool
The worker loops back to the queue instead of exiting, ready for the next task.
What Interviewer Expects
- Understanding that thread creation/teardown is the cost being avoided
- Knowledge of the shared task queue and worker-loop model
- Ability to reason about pool sizing for CPU-bound vs I/O-bound work
- Awareness of backpressure when the queue itself is bounded
Common Mistakes
- Assuming more threads in the pool always means more throughput
- Not knowing how to size a pool differently for CPU-bound vs I/O-bound tasks
- Forgetting that a thread pool can still deadlock if tasks block on other pool tasks
- Confusing a thread pool with a connection pool (different resource, similar pattern)
Best Answer (HR Friendly)
“A thread pool is a set of worker threads that a program keeps ready and reuses instead of creating a brand-new thread every time there is work to do. It saves the overhead of constantly starting and stopping threads, and it keeps the number of things running at once under control so the system does not get overwhelmed.”
Code Example
#include <pthread.h>
#define POOL_SIZE 4
#define QUEUE_CAP 64
typedef void (*task_fn)(void *arg);
struct task { task_fn fn; void *arg; };
static struct task queue[QUEUE_CAP];
static int head = 0, tail = 0, count = 0;
static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
static pthread_cond_t not_empty = PTHREAD_COND_INITIALIZER;
void submit_task(task_fn fn, void *arg) {
pthread_mutex_lock(&lock);
queue[tail] = (struct task){ fn, arg };
tail = (tail + 1) % QUEUE_CAP;
count++;
pthread_cond_signal(¬_empty);
pthread_mutex_unlock(&lock);
}
void *worker_loop(void *unused) {
for (;;) {
pthread_mutex_lock(&lock);
while (count == 0) pthread_cond_wait(¬_empty, &lock);
struct task t = queue[head];
head = (head + 1) % QUEUE_CAP;
count--;
pthread_mutex_unlock(&lock);
t.fn(t.arg); /* run task outside the lock */
}
return NULL;
}
void start_pool(void) {
pthread_t workers[POOL_SIZE];
for (int i = 0; i < POOL_SIZE; i++)
pthread_create(&workers[i], NULL, worker_loop, NULL);
}Follow-up Questions
- How would you size a thread pool for a CPU-bound workload versus an I/O-bound workload?
- What happens if a task submitted to the pool blocks waiting on another task in the same pool?
- How does a bounded task queue provide backpressure to callers?
- What is the difference between a thread pool and thread-per-request?
MCQ Practice
1. What is the primary motivation for using a thread pool?
Thread pools reuse a fixed set of worker threads to amortize the cost of thread creation and teardown across many tasks.
2. A thread pool sized far larger than the CPU core count for CPU-bound work typically causes?
For CPU-bound tasks, once threads exceed available cores, extra threads mostly add scheduling and context-switch overhead rather than useful parallelism.
3. What structure do thread pool workers typically pull work from?
Worker threads loop, dequeuing tasks from a shared, synchronized task queue and executing them.
Flash Cards
What is a thread pool? — A fixed set of reusable worker threads that pull tasks from a shared queue instead of being created per task.
What cost does a thread pool avoid? — The overhead of creating and tearing down an OS thread for every unit of work.
How should a CPU-bound pool be sized? — Roughly to the number of available CPU cores.
What provides backpressure in a thread pool design? — A bounded task queue that rejects or blocks new submissions once full.