使用 WaitGroup 测试竞争条件时的意外行为

Question

我有一个任务是在围棋中模拟竞争条件。但是，我遇到了一个无法解释的案例运行。下面的代码片段

package main

import (
    "fmt"
    "sync"
)

var value, totalOps, totalIncOps, totalDecOps int

func main() {
    fmt.Println("Total value: ", simulateRacing(10000))
    fmt.Print("Total iterations: ", totalOps)
    fmt.Print(" of it, increments: ", totalIncOps)
    fmt.Print(", decrements: ", totalDecOps)
}

// Function to simulate racing condition
func simulateRacing(iterationsNumber int) int {
    value = 0
    // Define WaitGroup
    var waitGroup sync.WaitGroup
    waitGroup.Add(2)

    go increaseByOne(iterationsNumber, &waitGroup)
    go decreaseByOne(iterationsNumber, &waitGroup)

    waitGroup.Wait()

    return value
}

// Function to do N iterations, each time increasing value by 1
func increaseByOne(N int, waitGroup *sync.WaitGroup) {
    for i := 0; i < N; i++ {
        value++
        // Collecting stats
        totalOps++
        totalIncOps++
    }
    waitGroup.Done()
}

// Same with decrease
func decreaseByOne(N int, waitGroup *sync.WaitGroup) {
    for i := 0; i < N; i++ {
        value--
        // Collecting stats
        totalOps++
        totalDecOps++
    }
    waitGroup.Done()
}

根据我的理解，它每次都应该产生一致的（确定性的）结果，因为我们正在执行相同数量的递增和递减，WaitGroup 确保两个函数都将执行。

然而，每次输出都不同，只有增量和减量计数器保持不变。 总价值：2113 总迭代次数：17738 次，增量：10000，减量：10000 和 总价值：35 总迭代次数：10741 次，增量：10000，减量：10000

也许你能帮我解释一下这种行为？为什么总迭代计数器和值本身是不确定的？

Answer 1

因为对变量value、totalOps、totalIncOps和totalDecOps的操作没有被锁定

添加互斥锁应该会有帮助。 Go race detector 功能会发现这个错误

var m sync.Mutex

func increaseByOne(N int, waitGroup *sync.WaitGroup) {
    for i := 0; i < N; i++ {
        m.Lock()
value++
        // Collecting stats
        totalOps++
        totalIncOps++
        m.Unlock()
    }
    waitGroup.Done()
}

// Same with decrease
func decreaseByOne(N int, waitGroup *sync.WaitGroup) {
    for i := 0; i < N; i++ {
        m.Lock()
        value--
        // Collecting stats
        totalOps++
        totalDecOps++
        m.Unlock()
    }
    waitGroup.Done()
}

上面的替代方法是使用 Sync.Atomic 作为计数器

Answer 2

这是竞争条件的典型例子。 value++ 不是原子操作，因此无法保证在没有同步的情况下从多个线程调用时它会正确或确定地工作。

为了直观起见，value++ 或多或少等同于 value = value + 1。您可以将其视为三个操作，而不是一个：从内存加载 value 到 CPU 寄存器，增加寄存器中的值（您不能直接修改内存), 将值存回内存。两个线程可能同时加载相同的值，增加它，得到相同的结果，然后将其写回，所以它有效地将 value 增加 1，而不是两个。

由于线程之间的操作顺序是不确定的，结果也是不确定的。

totalOps 也有同样的效果。但是，totalIncOps 和 totalDecOps 仅在单个线程中 modified/read，因此这里没有竞争，它们的最终值是确定的。

使用 WaitGroup 测试竞争条件时的意外行为

Unexpected behaviour whilst testing race condition with WaitGroup

go

race-condition