In-depth analysis of the operation results of Go Channel in each state

Hello everyone, I am Fisherman.

Channel is a unique feature of Golang and is often asked in interviews. I believe everyone has seen the following picture, which shows the results of operations on channels in different states.

This diagram summarizes it very well. But we can't just memorize these results. We need to understand the underlying principles to understand how these results came about.

We will talk about this in three parts. First, the basic usage of channels, which highlights the characteristics of channels. Then we will introduce the underlying data structure of channels. The underlying data structure is built around these characteristics. Finally, we will see how Go implements these characteristics based on the underlying data structure.

Basic usage of channels

Channel definition and initialization

Define channels via var

A channel variable ch is defined by var, which can receive integer data. Of course, any other data type can also be specified.

 var ch chan int

• ch represents the variable name
• chan fixed value. Indicates that ch is the channel type
• int means that the data stored in channel ch is integer data.
• The default value of the ch variable is nil. There are special scenarios when operating with nil channels, which we will explain later.

Initialize the channel by making

Make can be used to initialize a non-buffered channel and a buffered channel. The difference lies in whether the buffer size is specified in make. As follows:

 var ch = make(chan int) //初始化无缓冲通道var ch = make(chan int, 10) //缓冲区通道，缓冲区可以存10个元素

The difference between unbuffered channels and buffered channels can be reflected in both properties and behaviors:

• Distinguish from the attributes: whether the channel has a buffer to temporarily store elements.
• The difference is in behavior: whether the sender and receiver are synchronous or asynchronous.
• The difference is based on the underlying data structure: whether there is a buffer to temporarily store data. This will be explained in detail later.

Channel Operations

There are three operations on channels in golang: sending elements to the channel, receiving elements from the channel, and closing the channel.

 var ch chan int = make(chan int, 10) 2 ->ch //发送元素var item int item <-ch //接收元素close(ch) //关闭元素

To summarize:

• Channels have three operations: send, receive, and close.
• There are three types of channels: nil channels, unbuffered channels, and buffered channels.
• There are two states for a channel: closed and open.
• The unclosed state of the buffer channel can be divided into buffer full state and buffer not full state.

So, what kind of data structure does the channel use to complete these actions?

Channel Data Structure

We first give the underlying data structure of the channel, as follows:

 type hchan struct { qcount uint // total data in the queue dataqsiz uint // size of the circular queue buf unsafe.Pointer // points to an array of dataqsiz elements elemsize uint16 closed uint32 elemtype *_type // element type sendx uint // send index recvx uint // receive index recvq waitq // list of recv waiters sendq waitq // list of send waiters // lock protects all fields in hchan, as well as several // fields in sudogs blocked on this channel. // // Do not change another G's status while holding this lock // (in particular, do not ready a G), as this can deadlock // with stack shrinking. lock mutex } type waitq struct { first *sudog last *sudog }

According to the above structure definition, the meaning of each field is explained in turn:

• buf: points to an array, representing a queue, combining sendx and recvx fields to implement a circular queue. Cache the corresponding elements. The buffer channel is implemented using this field.
• qcount: How many elements are currently in the buf queue.
• dataqsiz: represents the capacity of the queue buf. When using make to initialize, the specified number of elements is stored in this field.
• elemsize: The byte size of an element. Based on the size of the element, the capacity of buf can be initialized. By using elemsize*capacity, we can know how many bytes of space to allocate to buf.
• closed: Indicates whether the channel is closed. Its value is only 0 and 1. 1 means the channel is closed. 0 means it is not closed.
• elemtype: represents the type of element.
• sendx: represents the location where the next element should be stored
• recvx: represents the position of the next received element.
• recvq: represents the coroutine queue waiting to receive elements
• sendq: represents the coroutine queue for sending elements.

Based on the above results, it is easier to understand the points by drawing a graph, as follows:

Difference between buffered and unbuffered channels

By definition, both buffered and unbuffered channels are initialized by make. The difference lies in whether the channel capacity is specified in the make function.

 unbufferCh := make(chan int) //初始化非缓冲区通道bufferCh := make(chan int, 10) //初始化一个能缓冲10个元素的通道

From the perspective of the underlying data structure of the channel, the non-buffered channel will not initialize the buf field in the structure. The buffered channel will initialize the buf field. This field points to a memory area. As shown below:

Channel sending and receiving process

Through the source code, we have sorted out the flow chart of sending data to the channel and receiving data from the channel. This flow chart includes the sending and receiving processes in both buffered and unbuffered channels, so it looks complicated. But it doesn't matter, we will break down this chart below.

From the above process, one thing you need to pay attention to is that no matter when sending or receiving, the corresponding thread is obtained from the waiting queue first. If there is one, it is directly received or sent; if there is no coroutine in the waiting queue, then it is checked whether there is a buffer. This requires extra attention.

Operations of each state channel

Unbuffered Channel

According to the above, the unbuffered channel actually has no buffer in essence. You don't need to specify the capacity of make during initialization. In fact, this is also called synchronous sending and receiving. For a channel in this state, when sending data, if there is a waiting receiving coroutine in the receiving queue, then the data can be sent successfully; otherwise, it enters a blocking state. Vice versa. Its flow chart is the red arrow part in the figure, as follows:

To simplify it further:

• When sending data to an unbuffered buffer, if there is a coroutine waiting to receive, the sending is successful; otherwise, the sending coroutine enters a blocked state.
• When receiving data from an unbuffered data source, if there is a coroutine waiting to send, the reception is successful; otherwise, the receiving coroutine enters a blocked state.

Then, the above diagram can be simplified as follows:

Another thing to note is that for the sending and receiving operations of non-buffer channels, if the sending and receiving are performed in the main function, a deadlock will occur. As follows:

 func main() { var ch = make(chan int) <-ch fmt.Println("the End") } //或func main() { var ch = make(chan int) ch <- 2 fmt.Println("the End") }

Therefore, the main problem with sending and receiving operations on non-buffered channels is that they may cause blocking, unless both the sending and receiving goroutines exist and are in different goroutines.

Buffered channel

A buffered channel has a buffer in the channel, and both sending and receiving can operate on the buffer. It is also called asynchronous sending and receiving. In the state of a buffered channel, for the sending operation, the state of the buffered channel is divided into two states: full and not full. According to the sending flowchart above, when the buffer is full, it can no longer be sent, and it will enter the waiting queue for sending. At the same time, it is blocked, waiting to be awakened by the receiving coroutine.

For receiving operations, the states of buffered channels are divided into two states: buffer empty and not full. Similarly, if the buffer is empty, there is no data to receive, and it will naturally enter the receiving waiting queue. At the same time, it will enter blocking and wait to be awakened by the sending coroutine.

Closed channel

Closing a channel is done through the **close** function. Essentially, closing a channel means setting the closed field in the channel structure to 1. From the source code, we can see that:

• Closing a nil channel: panic
• Close a closed channel: panic. This can be understood in this way. Closing a closed channel is meaningless.

Sending a message to a closed channel

Sending a message to a closed channel will cause a panic. This is easy to understand, because the channel has been closed to prevent messages from being sent. The following code:

Receiving a message from a closed channel

When receiving messages from a closed channel, the operation is successful. However, the following differences will occur depending on whether there are elements in the channel:

• If there are no elements in the channel, a false status is returned.
• If there are elements in the channel, it will continue to receive elements in the channel until they are all received and return false.

You see, the code is actually very simple. If we disassemble the code, we will see the flowchart on the right.

nil channel

The default value of a channel type variable defined in the following way is nil.

 var ch chan int

A nil channel is equivalent to an underlying structure with no channel allocated.

The following are the operations and corresponding results captured from the source code. From the source code, we can know:

• Closing a nil channel will cause panic
• Receiving and sending messages from a nil channel will block

Summarize

The channel in golang is used for communication between coroutines. We have derived the results of operations on each state of the channel from the source code level. Finally, let's summarize: Buffer channel:

• As long as there is buffer space, the transmission will be successful, unless the buffer space is full, in which case blocking will occur.
• As long as there are elements in the buffer space, the reception will be successful, unless there are no elements, in which case blocking will occur.

nil channel:

• A nil channel is a channel without an initialized underlying data structure. Because there is no space to store any elements, both sending and receiving will be blocked. Closing a nil channel will cause a panic.

Closed channels:

• Sending a message to a closed channel will cause a panic.
• Receiving a message from a closed channel will succeed.
• Closing a closed channel will also cause a panic.