The blocking mechanism of Go's Buffered Channel

In the Go language, there is a special channel type called Buffered Channel, which stores a certain number of elements in the channel. When the number of elements in the channel reaches the set upper limit, the write operation will be blocked until other coroutines read elements from the channel. On the contrary, when the number of elements in the channel is zero, the read operation will also be blocked until another coroutine writes elements to the channel. This blocking mechanism can effectively control synchronization and communication between coroutines. In this article, we will introduce the blocking mechanism of Buffered Channel in Go language in detail.

Question content

In "Tour of Go", the sample code is given like this:

package main

import "fmt"

func main() {
    ch := make(chan int, 2)
    ch <- 1
    ch <- 2
    fmt.Println(<-ch)
    fmt.Println(<-ch)
}

It executes fine and prints it

1
2

This behavior differs from the description of this exercise, which states:

<code>
Sends to a buffered channel block only when the buffer is full. Receives block when the buffer is empty
</code>

After ch <- 2 lines, ch is full, and since we are only running 1 separate Goroutine, the main Goroutine, this Goroutine should be blocked , until ch is consumed by the receiver, so the code should not reach the fmt.Println(<-ch) line, but should say something like

<code>
fatal error: all goroutines are asleep - deadlock!
</code>

However, since this is not the case, I am confused and looking for guidance.

This is another piece of code I wrote

chh := make(chan int, 2)

go func() {
    chh <- 1
    fmt.Printf("chh after 1: %v, %v\n", cap(chh), len(chh))
    chh <- 2
    fmt.Printf("chh after 2: %v, %v\n", cap(chh), len(chh))
    chh <- 3
    fmt.Printf("chh after 3: %v, %v\n", cap(chh), len(chh))
}()

fmt.Println(<-chh)
fmt.Println(<-chh)
fmt.Println(<-chh)

The execution result is

1
chh after 1: 2, 0
chh after 2: 2, 0
chh after 3: 2, 1
2
3

This is even more confusing. This time there is another goroutine doing the sending. My expectation is that the main goroutine should be blocked during the first fmt.Println(<-chh). The scheduler will select the goroutine that runs the anonymous function, and it should execute until chh <- 2, then it will block itself and the scheduler resumes to the main goroutine again. However, as the results show, the second goroutine blocks immediately after chh <- 1. Why is this happening?

edit: I still don't understand why my local prints 1 in the first place. When I try to use go Playground on the remote server, it shows different behavior, now consistent with my expectations.

It is known that the channel is composed of 3 queues (receiving goroutines, sending goroutines ans value buffer). When the anonymous function is running, the status of channel chh is (sending:empty,valuebuffer: empty,receiving:[main] ).

The running child Goroutine just pushes the value directly into the main Goroutine without actually passing it to the value buffer. That's why the length of 1 after chh is pushed is 0.

Solution

This passage can accommodate two people. Two sends can succeed without blocking. The third onecan’t. The send will only block if the channel is full before the send.

The above is the detailed content of The blocking mechanism of Go's Buffered Channel. For more information, please follow other related articles on the PHP Chinese website!