Concurrency Patterns Reference
Intent, fit, trade-offs, and relationships for coordinating concurrent work.
Updated 2026-07-22
Thread Pool
Execute submitted tasks on a reusable, usually bounded set of workers.
| Aspect | Guidance |
|---|---|
| Use when | Task creation is frequent and concurrency must be limited. |
| Trade-offs | Queue policy, blocking tasks, starvation, shutdown, and sizing affect reliability. |
| Related | Producer-Consumer, Work Stealing |
Producer-Consumer
Decouple work production from processing through a buffer or channel.
| Aspect | Guidance |
|---|---|
| Use when | Producers and consumers run at different rates or on different tasks. |
| Trade-offs | Buffer bounds, backpressure, shutdown, and failure handling are essential. |
| Related | Thread Pool, Communicating Sequential Processes |
Future and Promise
Represent a value or failure that will be supplied later.
| Aspect | Guidance |
|---|---|
| Use when | A caller needs to compose asynchronous work without blocking immediately. |
| Trade-offs | Cancellation, timeouts, lost errors, and execution context can be subtle. |
| Related | Fork-Join, Proactor |
Fork-Join
Recursively split work into independent tasks and join their results.
| Aspect | Guidance |
|---|---|
| Use when | CPU-bound work divides into balanced subproblems. |
| Trade-offs | Small tasks add overhead and blocking or skew reduces parallelism. |
| Related | Work Stealing, Future and Promise |
Work Stealing
Let idle workers take queued work from busier workers.
| Aspect | Guidance |
|---|---|
| Use when | Many dynamically generated tasks need adaptive load distribution. |
| Trade-offs | Scheduling is nondeterministic and task locality may suffer. |
| Related | Fork-Join, Thread Pool |
Mutex
Provide exclusive ownership of a critical section or shared invariant.
| Aspect | Guidance |
|---|---|
| Use when | Shared mutable state cannot be updated atomically otherwise. |
| Trade-offs | Contention, deadlock, priority inversion, and forgotten release are risks. |
| Related | Monitor, Semaphore |
Semaphore
Control concurrent access with a count of available permits.
| Aspect | Guidance |
|---|---|
| Use when | A resource supports a bounded number of simultaneous users. |
| Trade-offs | Permit leaks and mismatched acquire/release operations are hard to diagnose. |
| Related | Mutex, Thread Pool |
Monitor
Encapsulate shared state with mutually exclusive methods and condition waiting.
| Aspect | Guidance |
|---|---|
| Use when | Several operations must preserve one state invariant. |
| Trade-offs | Nested calls, signaling rules, and blocking inside the monitor can deadlock. |
| Related | Mutex, Read-Write Lock |
Read-Write Lock
Allow concurrent readers while granting writers exclusive access.
| Aspect | Guidance |
|---|---|
| Use when | Reads dominate and critical sections are long enough to justify coordination cost. |
| Trade-offs | Writers or readers can starve and overhead may exceed a mutex. |
| Related | Mutex, Immutable Object |
Barrier
Hold participants until all have completed the current phase.
| Aspect | Guidance |
|---|---|
| Use when | Parallel phases must advance in lockstep. |
| Trade-offs | One failed or slow participant blocks everyone unless timeout and cancellation exist. |
| Related | Fork-Join, Latch |
Thread-local Storage
Associate an independent value with each thread.
| Aspect | Guidance |
|---|---|
| Use when | Legacy or scoped context cannot be passed explicitly. |
| Trade-offs | Values leak across reused pool threads and do not follow asynchronous tasks reliably. |
| Related | Context Object, Immutable Object |
Immutable Object
Make state safe to share by preventing changes after construction.
| Aspect | Guidance |
|---|---|
| Use when | Many tasks read the same data without coordinated updates. |
| Trade-offs | Updates allocate new values and deep immutability must be enforced. |
| Related | Copy-on-Write, Persistent Data Structure |
Event Loop
Receive events and dispatch their handlers sequentially on one execution context.
| Aspect | Guidance |
|---|---|
| Use when | Many mostly nonblocking operations need high concurrency with simple state ownership. |
| Trade-offs | Blocking handlers stall all work and CPU-heavy tasks need offloading. |
| Related | Reactor, Proactor |
Reactor
Demultiplex readiness notifications and invoke synchronous handlers.
| Aspect | Guidance |
|---|---|
| Use when | Many I/O sources can be processed when they become ready. |
| Trade-offs | State machines and partial I/O complicate code; handlers must not block. |
| Related | Event Loop, Proactor |
Proactor
Start asynchronous operations and dispatch handlers when they complete.
| Aspect | Guidance |
|---|---|
| Use when | The platform supports true asynchronous I/O completion. |
| Trade-offs | Buffers, cancellation, and completion ordering require careful ownership. |
| Related | Reactor, Future and Promise |
Actor
Isolate mutable state inside entities that process asynchronous messages.
| Aspect | Guidance |
|---|---|
| Use when | Independent stateful components communicate without shared-memory locking. |
| Trade-offs | Mailbox growth, message ordering, supervision, and distributed delivery remain concerns. |
| Related | Event Loop, Communicating Sequential Processes |
Communicating Sequential Processes
Compose independent sequential processes that coordinate through explicit channels.
| Aspect | Guidance |
|---|---|
| Use when | Concurrency is clearer as communication rather than shared mutation. |
| Trade-offs | Blocking channel cycles can deadlock and topology design matters. |
| Related | Actor, Producer-Consumer |
Active Object
Separate method invocation from execution by placing requests in a queue owned by an object.
| Aspect | Guidance |
|---|---|
| Use when | A stateful object should process calls asynchronously in controlled order. |
| Trade-offs | Return values become futures and queue saturation or cancellation must be handled. |
| Related | Command, Actor |