The Runtime Theory

Thread Pool Scheduling

Thread pool scheduling: task queues, condition-variable wakeups, LIFO dequeues, work stealing, and idle workers.

The Runtime Theory Team07 stages

trace / request.md

TASK SUBMITTEDIDLE WORKERSIGNALEDWORKER DEQUEUESTASK RUNS ONTHE WORKERWORK STEALINGBLOCKING TASKQUEUE EMPTY,WORKERS SLEEP

readyCode enqueues a job onto the pool's queue structure — often one queue per worker, rather than one shared queue, to avoid a single lock-hot point.

A thread pool is a queue with workers asleep around it. This diagram follows a task from submission to completion: it lands on a queue, a sleeping worker is woken via a condition variable, the worker dequeues — preferably from its own queue, LIFO, to keep the cache warm — runs the job on its own stack, and then either takes the next task or steals from another worker's queue when its own is empty. The ordering matters for two reasons: work stealing is what balances load without a single lock-hot shared queue, and sleeping workers are what keep an idle pool cheap. The blocking-task stage shows what happens when a job waits on I/O: the worker idles and the pool may compensate. The done state: the queue is empty and the workers have parked again.