Communicating Sequential Processes and Channels

Shared-memory concurrency asks several execution contexts to coordinate access to the same objects. Communicating Sequential Processes starts from another vocabulary: independent sequential processes interact through named communication events. A process can be simple when its state changes in one sequential flow; concurrency appears in how those processes compose and synchronize.

Modern channel APIs borrow this idea to different degrees. Some channels rendezvous, some buffer values, some carry types and directional endpoint permissions, and some integrate with a select operation. A language with channels is not automatically a complete implementation of the CSP formalism, but the model remains useful because it turns communication into an explicit protocol rather than an incidental side effect of shared mutation.

The practical thesis is: a channel is both a data path and a synchronization contract. Capacity determines coupling, endpoint ownership determines who may send or close, selection determines how alternatives compete, and termination semantics determine whether a pipeline can finish. Treating a channel as merely a thread-safe queue misses the properties that make channel-based designs understandable.

Model Processes by Their Communication Events #

In CSP, a process is described by the events it can participate in and the choices, sequences, and repetitions that combine those events. Two processes synchronize when they engage in a compatible communication. Internal implementation state can remain private because peers observe the protocol through events.

Consider a validation stage that repeatedly receives a raw record, emits either a valid record or a rejection, and eventually observes end of input. Its useful public behavior is not which thread executes it or which local variables it uses. It is the ordering of receives and sends. A downstream persistence stage can be reasoned about against that behavior without sharing the validator’s maps or locks.

This separation is strongest when messages are immutable values or transfer exclusive ownership. Sending a pointer to a mutable object and continuing to modify it recreates shared-memory races through a channel-shaped API. The communication event should establish what the receiver may assume: a snapshot, a value, or ownership of a resource.

Channels also expose blocking as part of behavior. A send may wait for a receiver or for buffer space. A receive may wait for a value or closure. That waiting is not merely an implementation cost; it creates order between processes. If process A must send configured before process B can receive it and begin serving, the communication edge establishes synchronization without a separate condition variable.

The resulting system is a graph of processes connected by protocol edges:

The graph alone is incomplete. Each edge also needs a message type, capacity, sender and receiver ownership, close rule, and failure rule. Those details determine whether the graph can make progress.

Choose Rendezvous or Buffering Deliberately #

An unbuffered channel performs a rendezvous. A send completes only when a receiver is ready to accept the value, and the matching receive completes as part of the same synchronization. This gives strong handoff semantics: once the send returns, another process has accepted the message. It does not prove that the receiver finished processing it or persisted any resulting effect.

Rendezvous naturally applies backpressure. A fast source cannot outrun the next stage because every item needs a ready receiver. It also couples scheduling and latency: a temporarily paused receiver stops its sender immediately. That can be desirable for a command handoff or a tightly coordinated state transition and unnecessarily restrictive for bursty pipelines.

A buffered channel permits up to a fixed number of unmatched sends. Sending into available capacity can complete before a receiver runs; receiving can consume an earlier value while the sender continues. Capacity absorbs short bursts and lets stages overlap, but it weakens the synchronization meaning of send completion. The value has entered the buffer, not necessarily reached its ultimate owner.

Capacity should represent a domain or resource bound, not an arbitrary large number chosen to hide blocking. A buffer of 100 records might correspond to one database batch or a bounded amount of memory. An unbounded queue severs backpressure: throughput can look healthy while queue age, memory, and cancellation cleanup worsen. The overload appears later and farther from its cause.

Buffers do not increase the sustained capacity of the slowest stage. They change where work waits and how bursts are handled. Observe occupancy and oldest-item age so the buffer remains an intentional elasticity mechanism rather than a latency reservoir.

Encode Ownership in Channel Endpoints #

A good protocol makes sender and receiver roles explicit. Languages with directional channel types can expose send-only and receive-only views. Even without type support, APIs can return a receive endpoint while retaining the only send and close authority internally. Narrow endpoints prevent callers from inventing messages or terminating streams they do not own.

The usual closure rule is simple: the producer that knows no more values can exist closes the channel. A receiver generally cannot know whether another sender is about to produce, so receiver-driven close races with legitimate sends. When there are multiple producers, a coordinator owns closure and waits until every producer has finished before closing the shared output.

Message ownership matters separately. Values should be immutable after send, copied, or transferred under a rule that the sender no longer accesses them. For a reusable byte buffer, the protocol might have two channels: filled transfers buffers to a consumer, and empty returns ownership to the producer. The round trip is an explicit pool; both sides can be tested for double-send or use-after-transfer.

Avoid using channels as globally discoverable service locators. A channel passed to the processes that participate in one protocol is easier to close and replace than a package-level channel reachable by unrelated code. Scope the channel to the lifetime of its communication graph and include cancellation or shutdown paths in the same ownership design.

Message types should express protocol states rather than use magic values. An empty string might be valid data and should not also mean end-of-stream. Closure, a tagged union, or a separate control channel carries termination unambiguously. If errors are values, include enough context to attribute them and define whether the stream continues after one.

Compose Alternatives with Select #

Real processes often have several possible next events: receive work, send a pending result, observe shutdown, or react to a timer. A select-style operation waits until one of several channel operations can proceed and commits to one ready alternative. This avoids dedicating a task to each wait merely to race their results.

Selection is protocol control flow. A server loop can receive a command or a stop signal. A merge process can receive from either input. A bounded stage can alternate between accepting new data and forwarding a queued result. The cases should correspond to legal next states; adding every available channel to every select creates a difficult implicit state machine.

Fairness must not be assumed beyond the runtime’s contract. When several cases are continuously ready, implementations may choose pseudo-randomly, rotate, or make weaker guarantees. A high-volume data channel can starve a maintenance case if code repeatedly prefers it. If fairness is required, encode it with quotas, phases, or an explicit scheduler state and test under continuous readiness.

A default case makes selection non-blocking. Used carefully, it can poll optional work or attempt a lossy notification. Used in a tight loop, it burns CPU and repeatedly observes “not ready” without allowing peers to run. Blocking until a communication or a real wake-up is usually the correct process behavior.

Dynamic selection has another edge: disabling a case. In Go, a nil channel never becomes ready, so assigning an exhausted input to nil removes its case while other inputs continue. Other runtimes provide explicit case registration. The state transition should remain visible; accidentally selecting forever on a closed channel or disabled endpoint can create a hot loop.

Worked Example: A Bounded Import Pipeline #

Consider an import that reads lines, validates each record, and writes valid records in batches. Rejections must be reported, all accepted data must be flushed, and a consumer cancellation should stop upstream work. Each stage owns its output channel, and both data edges are bounded.

package importdata

import (
	"context"
	"errors"
)

type Raw struct {
	Line int
	Text string
}

type Record struct {
	ID string
}

type Rejection struct {
	Line   int
	Reason string
}

func validate(
	ctx context.Context,
	in <-chan Raw,
) (<-chan Record, <-chan Rejection) {
	valid := make(chan Record, 64)
	rejected := make(chan Rejection, 16)

	go func() {
		defer close(valid)
		defer close(rejected)

		for raw := range in {
			record, err := parse(raw.Text)
			if err != nil {
				select {
				case rejected <- Rejection{Line: raw.Line, Reason: err.Error()}:
				case <-ctx.Done():
					return
				}
				continue
			}

			select {
			case valid <- record:
			case <-ctx.Done():
				return
			}
		}
	}()

	return valid, rejected
}

func persist(ctx context.Context, in <-chan Record, store Store) error {
	batch := make([]Record, 0, 100)

	flush := func() error {
		if len(batch) == 0 {
			return nil
		}
		if err := store.Insert(ctx, batch); err != nil {
			return err
		}
		batch = batch[:0]
		return nil
	}

	for {
		select {
		case record, ok := <-in:
			if !ok {
				return flush()
			}
			batch = append(batch, record)
			if len(batch) == cap(batch) {
				if err := flush(); err != nil {
					return err
				}
			}
		case <-ctx.Done():
			return context.Cause(ctx)
		}
	}
}

var ErrInvalid = errors.New("invalid record")

The validator is the sole sender on valid and rejected, so it closes both when its input ends or cancellation makes further output impossible. It never closes in, which belongs to the reader. Every blocking send also selects cancellation; otherwise a stopped downstream consumer could leave the validator blocked forever on a full buffer.

The persistence stage distinguishes a value from closure using the two-result receive. It flushes the final partial batch only on clean input exhaustion. On cancellation it returns without claiming the remaining batch was stored. A real import coordinator would own the context, start the reader and rejection reporter, collect their outcomes, and cancel the whole graph if persistence fails. The channels express data handoff; the coordinator still owns process lifetime and error policy.

The capacities have meanings: 64 valid records absorb a small parse/write mismatch, 16 rejection records tolerate reporting bursts, and 100 records form a storage batch. Under sustained slow storage, valid fills, validation blocks, then the reader’s output fills, propagating pressure to the input source.

Close Protocols Without Leaks or Panics #

Closure communicates that no future values will be sent. It does not revoke values already buffered; receivers normally drain them before observing exhaustion. It also does not communicate success by itself. If a producer can fail, return an error through an owned result, an error channel, or the coordinator’s task result. Otherwise a consumer cannot distinguish complete input from an upstream crash that happened to close the stream.

In Go, receiving from a closed channel immediately yields buffered values and then zero values with ok == false. A loop that ignores ok inside select can repeatedly receive zero values and spin. Sending on or closing an already closed channel panics. These behaviors make single close ownership important. Other channel libraries differ, so state the local contract instead of generalizing one runtime’s rules.

Early consumer exit is a frequent leak. If a consumer finds the first matching item and returns, producers may remain blocked trying to send the second. The protocol needs a stop path that producers select while sending, or the consumer must drain input under an owner that can guarantee completion. Garbage collection does not unblock a live task waiting on a channel operation.

Fan-in requires coordinated closure. If three producers share one output, none can close it independently. A fourth coordination task waits for all three producer completions and closes output exactly once. Fan-out requires a semantic decision: competing receivers divide work, while broadcast requires separate subscriptions or a multicast abstraction. Multiple receivers on one ordinary channel do not each receive every value.

Deadlock is possible even without locks. Two processes can each wait to send before either receives; a pipeline can wait for an error consumer that was never started; a cycle of full bounded channels can stop all participants. Draw a wait-for graph for blocked operations and ensure every reachable state has at least one event that can proceed or an external cancellation path.

Keep Channels Distinct from Actors #

Channels and actors both avoid unrestricted shared-state mutation, but their organizing abstractions differ. A channel is a communication object that processes can share, and rendezvous may symmetrically synchronize sender and receiver. CSP-style design emphasizes composition of process behaviors over named events. An actor has an identity and private state, receives asynchronous messages through its own mailbox, and commonly participates in supervision and location-aware routing.

A channel pipeline is often a good fit when values flow through stages, when backpressure should follow the edges, or when a process must select among several communication partners. Actors are often a better fit when a durable logical entity owns evolving state and needs an address, lifecycle, and supervision policy. The models can coexist: an actor runtime may expose streams, or an application may put a channel-driven pipeline behind one actor boundary.

Do not claim they are equivalent because both send messages. Replacing a rendezvous with an actor send removes the sender-receiver synchronization point. Replacing an actor mailbox with a shared channel removes the invariant that one addressed entity owns that queue and state. Choose according to the protocol property needed, not syntax preference.

Test Progress, Pressure, and Protocol Invariants #

Channel tests should control events rather than sleep and hope. Use test endpoints to signal when a process reaches a send or receive, then advance peers deliberately. Verify an unbuffered send cannot complete before a receive, a bounded sender blocks exactly at capacity, and cancellation releases every blocked operation. For select, make multiple cases ready and test required policy without asserting an order the runtime does not guarantee.

Exercise closure at every stage: empty input, one buffered value, normal drain, producer failure, consumer early exit, cancellation while sending, and cancellation while receiving. At teardown, assert no protocol task remains. Run the language’s race detector where available, because channels do not protect mutable objects retained on both sides of a send.

Property and model-based tests are particularly effective. Generate short event sequences and assert invariants such as “every accepted record is persisted or reported as failed,” “output closes once after all producers finish,” and “buffer occupancy never exceeds capacity.” A small explicit-state model can reveal deadlocks by exploring alternate scheduling choices that ordinary tests rarely hit.

Operations should expose send wait time, receive wait time, occupancy, oldest buffered item, close reason, cancellation count, and process completion. These signals distinguish a healthy rendezvous from downstream saturation. Avoid labeling metrics by channel instance; use stable protocol names and traces for individual flows.

Channels make communication visible, but visibility alone does not guarantee progress. A sound design gives each endpoint an owner, gives every buffer a reason, gives every blocking operation a termination path, and tests the system under alternate schedules. With those contracts in place, CSP’s enduring lesson becomes practical: concurrent components can remain sequential inside while their interactions form an explicit, composable protocol.