Concurrency behavior of Go language without buffering channels: Why are there two possibilities for running results?

Detailed explanation of the concurrent behavior and non-blocking characteristics of Go language channels

This article explores the running results of a piece of Go language code when using unbuffered channels and explains the concurrent programming principle behind it. The code utilizes the Go language channel characteristics, but shows different behaviors in different situations, which triggers discussions on issues such as channel blocking and coroutine startup time.

The code is as follows:

 package main

import "fmt"

func main() {
    chanInt := make(chan int)
    defer close(chanInt)
    go func() {
        for {
            res, ok := <p> This code creates an unbuffered channel <code>chanInt</code> and starts a goroutine to receive data from the channel and print it. The main goroutine sends 1 and 10 to the channel. However, there are two possibilities for running results: print "1 true" and "10 true", or just print "1 true". This raises the following questions:</p><ol><li> <strong>There are two reasons for the unbuffered channel output:</strong>
</li></ol><p> The characteristics of unbuffered channels are: the sending operation is blocked until a goroutine receives data; the receiving operation is also blocked until a goroutine sends data. The main goroutine sends 1 and 10 in turn. Sub-goroutines are received and printed. If the child goroutine receives 1 fast enough, printing "1 true" is completed before the main goroutine sends 10, then receiving 10 and printing "10 true". But if the child goroutine receives 1 slower, the child goroutine may only have time to receive and print 1 before the main goroutine sends 10 and ends. This is because the main goroutine ends causing the channel to be closed, and the child goroutine receives a signal of the channel to be closed ( <code>ok</code> is <code>false</code> ), thus stopping the operation.</p><ol start="2"><li> <strong>Reasons for no output with buffered channels ( <code>chanInt := make(chan int, 2)</code> ):</strong>
</li></ol><p> After changing the channel to a buffered channel with capacity 2, the sending operation of the main goroutine will not block because it has enough space to accommodate two values. The main goroutine ends after sending 1 and 10, while the child goroutine may not have started or started receiving data. This is because the coroutine takes time to start. If the main goroutine ends much faster than the child goroutine starts, the child goroutine will not be able to receive data from the closed channel, resulting in no output.</p><p> Through analysis, we understand that in concurrent programming of Go language, coroutine startup time, channel blocking/non-blocking characteristics, and main goroutine end time jointly determine the final output result. The interaction of these factors leads to uncertainty in the outcome. To ensure that the sub-goroutine can handle all sent data, a wait mechanism should be added after the data is sent, such as synchronizing goroutines using <code>WaitGroup</code> .</p>

The above is the detailed content of Concurrency behavior of Go language without buffering channels: Why are there two possibilities for running results?. For more information, please follow other related articles on the PHP Chinese website!