Library · paper

Communicating Sequential Processes

C.A.R. Hoare
1978·Communications of the ACM

Source: https://dl.acm.org/doi/10.1145/359576.359585

The paper that originated the concurrency model behind Go, Erlang, and large parts of Rust.

Hoare proposed that parallel processes should communicate by passing messages through channels rather than sharing memory — an idea so good that the industry took forty years to adopt it widely.

The formalism is precise but the core insight is intuitive: coordinating independent agents is safer when they talk to each other than when they reach into each other's state.

Every modern distributed system, every microservice boundary, every event-driven architecture traces back to this paper.

For product leaders managing teams that build concurrent systems, CSP explains why some architectural decisions make failures catastrophic and others make them recoverable.

Central argument

Hoare argues that concurrent programs should be structured as independent sequential processes that coordinate exclusively by passing messages through named channels, rather than by sharing and mutating common memory. He formalizes this model mathematically, showing that complex parallel behavior can be described and reasoned about as compositions of simpler, well-defined communicating processes. The central finding is that eliminating shared state as the coordination mechanism removes an entire class of race conditions and deadlocks, making concurrent systems compositionally safer.

Critique

CSP's formal elegance depends on processes that are genuinely independent and communicate through well-defined, synchronous channels — assumptions that become strained in systems where latency, partial failure, and backpressure must be handled explicitly. The model is cleaner than shared-memory concurrency but does not eliminate distributed systems' hardest problems: it displaces complexity from memory contention into channel protocol design, where failures can be just as subtle and far harder to observe. A practitioner could reasonably argue that CSP trades one class of invisible errors for another that is equally difficult to reason about at scale.

Why it matters for product

For a product leader, CSP's core principle — that coordinating independent agents through explicit message passing is safer than letting them reach into each other's state — maps directly onto organizational design: teams with clear, narrow interfaces between them fail more gracefully and locally than teams entangled around shared ownership of data or systems. When an architecture review surfaces a debate between a shared database and an event-driven boundary, or when a team topology decision is framed around platform APIs versus embedded specialists, the same tradeoff Hoare identified in 1978 is on the table. Understanding why message-passing makes failures recoverable rather than catastrophic gives a CPO the conceptual vocabulary to push back on architectural choices that optimize for short-term velocity at the cost of long-term system resilience.