Also known as: goroutines
A goroutine is a lightweight task managed by the Go runtime rather than the operating system. They are so cheap that you can run hundreds of thousands at once, and they communicate over channels instead of sharing memory directly.1
How it works
You start a goroutine by prefixing a function call with go. Each begins with a tiny
stack that grows as needed, and the Go runtime’s scheduler multiplexes many goroutines
onto a small pool of OS threads, so they cost almost nothing
compared with one OS thread per task.1 Goroutines coordinate through channels — typed
pipes where one goroutine sends a value and another receives it. The channel handles
synchronization, so there is no explicit lock and no data race on the data that flows
through it. This is the Communicating Sequential Processes (CSP) model, captured by the
slogan: “Do not communicate by sharing memory; share memory by communicating.”1
Trade-offs
Goroutines make concurrent pipelines natural to express and are cheap enough that you can spawn one per connection or per work item without worrying about cost. The runtime can spread them across cores for real parallelism when work is CPU-bound, and channels make whole categories of race bugs impossible by design. The trade-offs are the small runtime scheduler overhead and the garbage collector that supports them, plus the discipline of choosing channels over shared state.
In practice
Goroutines and channels are central to Go’s character and a big reason it is common in networked and streaming systems. In GopherTrunk they map cleanly onto the concurrent decode pipelines an SDR scanner runs at once — a capture stage feeding a DSP stage feeding a decode stage, each a goroutine, glued together by channels.
Sources
-
Go (programming language) — Concurrency — Wikipedia, on goroutines, channels, and Go’s CSP-based “share memory by communicating” model. ↩ ↩2 ↩3