Analyze Golang's WaitGroup trap and solve the problem

This article is introduced to you by the go language tutorial column about Golang’s WaitGroup trap. I hope it will be helpful to friends in need!

Golang's WaitGroup trap

sync.WaitGroup is a very commonly used data structure in a concurrent environment, used to wait for all The end of the coroutine is written according to the example when writing the code, and there is no need to delve into its use. A few days ago, I was wondering whether I could execute the Add() function in a coroutine. The answer is no. Here is an introduction.

The trap lies in the calling sequence of the three functions of WaitGroup. Let’s first review the functions of the three functions:

1. Add(delta int): Add delta to the counter, for example, increase by 1 when starting a coroutine.
2. Done(): Executed before the coroutine exits, decrement the counter by 1.
3. Wait(): The blocking wait counter is 0.

Test a test

The following program creates the coroutine father, and then the father coroutine creates 10 sub-coroutines. The main function waits for all coroutines to finish and then exits. See See if there is anything wrong with the code below?

package main

import (
    "fmt"
    "sync"
)

func father(wg *sync.WaitGroup) {
    wg.Add(1)
    defer wg.Done()

    fmt.Printf("father\n")
    for i := 0; i < 10; i++ {
        go child(wg, i)
    }
}

func child(wg *sync.WaitGroup, id int) {
    wg.Add(1)
    defer wg.Done()

    fmt.Printf("child [%d]\n", id)
}

func main() {
    var wg sync.WaitGroup
    go father(&wg)

    wg.Wait()
    log.Printf("main: father and all chindren exit")
}

Did you find the problem? If you don't see the following running results: the main function starts to end before the sub-coroutine ends.

father
main: father and all chindren exit
child [9]
child [0]
child [4]
child [7]
child [8]

Trap Analysis

The reason for the above problem is that the Add() function is executed within the coroutine after the coroutine is created, and at this time Wait () Function may already be executing, or even the Wait() function is executed before all Add() is executed, Wait( )When executed, the counter of WaitGroup is immediately satisfied to be 0, Wait ends, and the main program exits. As a result, all sub-coroutines have not completely exited, and the main function ends.

Correct approach

The Add function must be executed before the Wait function is executed. This is prompted in the documentation of the Add function: Note that calls with a positive delta that occurs when the counter is zero must happen before a Wait..

How to ensure that the Add function must be executed before the Wait function? In the case of coroutines, we cannot predict whether the execution time of the code in the coroutine is earlier than the execution time of the Wait function. However, we can ensure that by executing the Add function before assigning the coroutine and then executing the Wait function.

The following is the modified program and the output results.

package main

import (
    "fmt"
    "sync"
)

func father(wg *sync.WaitGroup) {
    defer wg.Done()

    fmt.Printf("father\n")
    for i := 0; i < 10; i++ {
        wg.Add(1)
        go child(wg, i)
    }
}

func child(wg *sync.WaitGroup, id int) {
    defer wg.Done()
    fmt.Printf("child [%d]\n", id)
}

func main() {
    var wg sync.WaitGroup
    wg.Add(1)
    go father(&wg)

    wg.Wait()
    fmt.Println("main: father and all chindren exit")
}

rrree

The above is the detailed content of Analyze Golang's WaitGroup trap and solve the problem. For more information, please follow other related articles on the PHP Chinese website!