Concurrency Patterns Reference

Patterns for coordinating concurrent work safely.

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.

AspectGuidance
Use whenTask creation is frequent and concurrency must be limited.
Trade-offsQueue policy, blocking tasks, starvation, shutdown, and sizing affect reliability.
RelatedProducer-Consumer, Work Stealing

Producer-Consumer

Decouple work production from processing through a buffer or channel.

AspectGuidance
Use whenProducers and consumers run at different rates or on different tasks.
Trade-offsBuffer bounds, backpressure, shutdown, and failure handling are essential.
RelatedThread Pool, Communicating Sequential Processes

Future and Promise

Represent a value or failure that will be supplied later.

AspectGuidance
Use whenA caller needs to compose asynchronous work without blocking immediately.
Trade-offsCancellation, timeouts, lost errors, and execution context can be subtle.
RelatedFork-Join, Proactor

Fork-Join

Recursively split work into independent tasks and join their results.

AspectGuidance
Use whenCPU-bound work divides into balanced subproblems.
Trade-offsSmall tasks add overhead and blocking or skew reduces parallelism.
RelatedWork Stealing, Future and Promise

Work Stealing

Let idle workers take queued work from busier workers.

AspectGuidance
Use whenMany dynamically generated tasks need adaptive load distribution.
Trade-offsScheduling is nondeterministic and task locality may suffer.
RelatedFork-Join, Thread Pool

Mutex

Provide exclusive ownership of a critical section or shared invariant.

AspectGuidance
Use whenShared mutable state cannot be updated atomically otherwise.
Trade-offsContention, deadlock, priority inversion, and forgotten release are risks.
RelatedMonitor, Semaphore

Semaphore

Control concurrent access with a count of available permits.

AspectGuidance
Use whenA resource supports a bounded number of simultaneous users.
Trade-offsPermit leaks and mismatched acquire/release operations are hard to diagnose.
RelatedMutex, Thread Pool

Monitor

Encapsulate shared state with mutually exclusive methods and condition waiting.

AspectGuidance
Use whenSeveral operations must preserve one state invariant.
Trade-offsNested calls, signaling rules, and blocking inside the monitor can deadlock.
RelatedMutex, Read-Write Lock

Read-Write Lock

Allow concurrent readers while granting writers exclusive access.

AspectGuidance
Use whenReads dominate and critical sections are long enough to justify coordination cost.
Trade-offsWriters or readers can starve and overhead may exceed a mutex.
RelatedMutex, Immutable Object

Barrier

Hold participants until all have completed the current phase.

AspectGuidance
Use whenParallel phases must advance in lockstep.
Trade-offsOne failed or slow participant blocks everyone unless timeout and cancellation exist.
RelatedFork-Join, Latch

Thread-local Storage

Associate an independent value with each thread.

AspectGuidance
Use whenLegacy or scoped context cannot be passed explicitly.
Trade-offsValues leak across reused pool threads and do not follow asynchronous tasks reliably.
RelatedContext Object, Immutable Object

Immutable Object

Make state safe to share by preventing changes after construction.

AspectGuidance
Use whenMany tasks read the same data without coordinated updates.
Trade-offsUpdates allocate new values and deep immutability must be enforced.
RelatedCopy-on-Write, Persistent Data Structure

Event Loop

Receive events and dispatch their handlers sequentially on one execution context.

AspectGuidance
Use whenMany mostly nonblocking operations need high concurrency with simple state ownership.
Trade-offsBlocking handlers stall all work and CPU-heavy tasks need offloading.
RelatedReactor, Proactor

Reactor

Demultiplex readiness notifications and invoke synchronous handlers.

AspectGuidance
Use whenMany I/O sources can be processed when they become ready.
Trade-offsState machines and partial I/O complicate code; handlers must not block.
RelatedEvent Loop, Proactor

Proactor

Start asynchronous operations and dispatch handlers when they complete.

AspectGuidance
Use whenThe platform supports true asynchronous I/O completion.
Trade-offsBuffers, cancellation, and completion ordering require careful ownership.
RelatedReactor, Future and Promise

Actor

Isolate mutable state inside entities that process asynchronous messages.

AspectGuidance
Use whenIndependent stateful components communicate without shared-memory locking.
Trade-offsMailbox growth, message ordering, supervision, and distributed delivery remain concerns.
RelatedEvent Loop, Communicating Sequential Processes

Communicating Sequential Processes

Compose independent sequential processes that coordinate through explicit channels.

AspectGuidance
Use whenConcurrency is clearer as communication rather than shared mutation.
Trade-offsBlocking channel cycles can deadlock and topology design matters.
RelatedActor, Producer-Consumer

Active Object

Separate method invocation from execution by placing requests in a queue owned by an object.

AspectGuidance
Use whenA stateful object should process calls asynchronously in controlled order.
Trade-offsReturn values become futures and queue saturation or cancellation must be handled.
RelatedCommand, Actor

Description

Patterns for coordinating concurrent work safely.

References

Similar or alternative tools

Don't forget to set a bookmark for tool.io!
Privacy | Imprint | Cookies