Communicating sequential processes (CSP)

Canonical guidance

• model concurrent components as independently owned processes
• use communication when it expresses coordination or handoff clearly
• choose the simpler primitive when channels would only add ceremony

Use when

• designing pipelines
• handing work or ownership between goroutines
• reasoning about boundaries between concurrent components

Avoid

• turning every shared-state problem into a channel graph
• using channels where one mutex around one invariant is clearer
• talking about CSP while ownership is still vague

Preferred pattern

• one goroutine owns a piece of mutable state and others interact through requests or messages

Anti-pattern

• several goroutines mutating the same structure while channels exist only as side signals

Explanation: This is tempting because channels look idiomatic, but partial communication plus partial sharing usually creates the worst of both models.

Why

• CSP-style boundaries make concurrent code easier to reason about