Build fluency in the vocabulary of idle workers stealing tasks from busier workers' queues instead of contending on one shared queue.
0 / 5 completed
1 / 5
A teammate explains that each worker thread maintains its own local queue of tasks, and whenever a worker's queue runs empty, it randomly picks another worker's queue and takes a task from the opposite end to keep itself busy, instead of all workers pulling from one shared, contended queue. What scheduling technique is being described?
Work stealing is exactly this: each worker thread owns its own local task queue, normally pushing and popping from one end for cache-friendly access, and whenever a worker's own queue is empty, it steals a task from the opposite end of another, busier worker's queue, keeping every worker productive without funneling all task hand-offs through one heavily contended shared queue. A DNS zone transfer is an unrelated concept about replicating name server records. This local-queue-with-occasional-stealing approach is exactly why work stealing scales well for irregular, dynamically generated parallel workloads.
2 / 5
During a design review, the team adopts a work-stealing scheduler for a parallel task framework where tasks recursively spawn unpredictable numbers of subtasks, specifically so idle workers can absorb the uneven load without contending on one shared queue. Which capability does this provide?
A work-stealing scheduler here provides dynamic load balancing across workers with minimal contention, since most task access stays on a worker's own local queue and only idle workers occasionally steal from busier ones, which is exactly suited to a workload where recursive spawning makes the number of subtasks per worker unpredictable. Every worker pushing and popping from one single shared task queue would create heavy contention on that one queue as parallelism increases. This mostly-local-occasionally-steal behavior is exactly why work stealing scales well for irregular, recursively parallel workloads.
3 / 5
In a code review, a dev notices a parallel task framework routes every worker's task creation and consumption through one single shared queue protected by a global lock, instead of giving each worker its own local queue with occasional stealing from idle workers. What does this represent?
This is a missed work-stealing opportunity, since per-worker local queues with occasional stealing would reduce contention instead of funneling every task through one globally locked queue. A cache eviction policy is an unrelated concept about discarded cache entries. This single-globally-locked-queue pattern is exactly the kind of contention bottleneck a reviewer flags once parallelism scales up.
4 / 5
An incident report shows a parallel task framework's throughput plateaued and then declined as more worker threads were added, because every worker contended on one single globally locked task queue for every task creation and consumption. What practice would prevent this?
Switching to a work-stealing scheduler where each worker uses its own local queue and only steals from other workers when idle removes the single point of contention entirely. Continuing to route every task through the one globally locked shared queue regardless of how many workers contend on it is exactly what caused the throughput plateau described in this incident. This local-queue-with-stealing approach is the standard fix once a single shared queue is confirmed to be the scaling bottleneck.
5 / 5
During a PR review, a teammate asks why the team reaches for work stealing instead of a central dispatcher thread that explicitly assigns each task to whichever worker is least busy, given that a central dispatcher can make more globally optimal assignment decisions. What is the reasoning?
Work stealing trades some assignment optimality for far less contention and no single dispatcher bottleneck, since workers mostly operate on their own local queues, while a central dispatcher can make smarter assignments but becomes a serialized bottleneck as worker count grows. This is exactly why work stealing is favored for highly parallel, dynamically spawning workloads, while a central dispatcher remains viable only when worker counts stay small enough that its serialized decision-making does not become the bottleneck.