Go Channels

Internal

• Go Concurrency

TODO

Deplete Go_Channels into this.

Overview

Go channels provide a composable, concurrent-safer way to communicate between concurrent processes.

Because channels are composable with other channels, this makes writing large systems simpler. You can coordinate the input from multiple subsystems by easily composing the output together. You can combine input channels with timeouts, cancellations, or message to other subsystems. The select statement is the complement to Go's channels. It is what enables all the difficult parts of composing channels. select statement allows you to wait for events, select a message from competing channels in a uniform random way, continue on if there are no messages waiting, and more.

Also see:

Go Concurrency Programming Models

R chan W

R chan W

Declaration and Instantiation

The channel variables are declared with the usual var keyword declaration syntax, where tThe channel type can be a Go built-in type or a user-defined type:

var c chan <channel_type>

This declaration assigns a zero value channel to the variable. However, because there is no valid zero value for a channel, the actual channel instances must be created with make(). The short variable declaration syntax is also available.

var c chan int // creates a zero value channel
c = make(chan int) // assigns a valid channel instance to the channel variable
c2 := make(chan int) // short variable declaration

Channel Zero Value

A channel variable declaration creates a zero value channel, but that instance cannot be used for sending or receiving data, and it is represented with the predeclared identifier nil. Attempts to send on such channel instances block even if there are readers, so they simply cannot be used.

make()

Channel instances are created with the built-in function make():

c := make(chan string)

Invoking make() with only the chan keyword and the payload type makes an unbuffered channel: its capacity to hold objects in transit is 0. To make a buffered channel, specify an integer capacity as the third argument:

c := make(chan string, 3)

Unbuffered and Buffered Channels

An unbuffered channel cannot hold data in transit. This is the default mode for creating the channel instances. The sending operation blocks on an unbuffered channel until some other goroutine reads the data from the channel on the receiving end. For the same reason, the receiving operation blocks until some data is sent on the sending end.

Because of the blocking behavior, an unbuffered channel provides communication between threads, but also execution synchronization: the unbuffered channel can be used as a synchronization mechanism only, and the data passing on the channel simply thrown away. The language syntax supports that by allowing receiving from a channel without storing the result in any variable - which means the result will be simply discarded:

<- c

This syntax has a synchronization "wait" semantics. Also see WaitGroup.Wait().

A buffered channel can be configured to contain a limited number of objects in transit, making them "buffered channels". The capacity is specified as an argument of the make() function when the channel is initialized:

c := make(chan string, 3)

The sending operation on a buffered channel only blocks if the buffer is full. The receiving operation blocks only if the buffer is empty. The main reason for buffering is to allow sender and receiver to operate at different speeds, at least from time to time. For unbuffered channels, the sender and the receiver will work in lockstep, which reduces the concurrency of the code. For a buffered channel, the buffer can temporarily absorb some of the differences in speed between the producer and the consumer. It cannot do that forever, for its capacity is finite.

Channel Patterns

Transferring the Ownership of Data

If you have a bit of code that produces a result and wants to share that result with another bit of code, what you are really doing is transferring the ownership of that data. Data has an owner, and one way to make concurrent programs safe is to ensure only one concurrent context has ownership of data at a time. Channels are the recommended way to implement this pattern in Go, as they help us communicate this concept by encoding the intent into the channel's type. You can create buffered channels to implement a cheap in-memory queue and thus decouple the producer from consumer. This pattern also makes you code composable with other concurrent code.

Coordinate Multiple Pieces of Logic

Channels are inherently composable and preferred when communicating between different parts of your object graph. Having locks scattered throughout the object graph is far worse. Having channels everywhere is expected and encouraged. Channels can be easily composed, which is not what can be said about locks or methods that return values. It is much easier to control the emergent complexity that arises in your project if you use channels.