使用 WaitGroup 从阻止当前变量的不同 go 例程写入堆栈变量是否安全？

使用 WaitGroup 从阻止当前变量的不同 Go 例程写入堆栈变量是否安全？答案是肯定的。WaitGroup 确保了 Go 内存模型中 a, b = a+1, b+1 已执行，保证了对 a 和 b 的非活泼访问。WaitGroup 的工作原理与实现细节无关，即使将来编译器将变量保留在堆栈上，它也能保证有效性。

任务执行器有多种，具有不同的属性，其中一些仅支持非阻塞调用。所以，我在想，是否需要使用mutex/channel来安全地将任务结果传递给调用go-routine，或者waitgroup是否足够简单？

为了简单起见，以及问题的特殊性，使用非常简单的任务执行器启动函数直接作为 go 例程的示例：

func TestRace(t *testing.T) {
    var wg sync.WaitGroup

    a, b := 1, 2

    wg.Add(1)

    // this func would be passed to real executor
    go func() {
        a, b = a+1, b+1
        wg.Done()
    }()

    wg.Wait()

    assert.Equal(t, a, 2)
    assert.Equal(t, b, 3)
}

在我的机器上使用 -race 选项执行上述测试没有失败。然而，这样就足够保证了吗？如果 go-routine 在不同的 cpu 核心、cpu 核心块 (amd ccx) 或多插槽设置中的不同 cpu 上执行会怎样？

那么，问题是，我可以使用 waitgroup 为非阻塞执行器提供同步（块和返回值）吗？

解决方案

JimB 也许应该提供这个作为答案，但我将从 his comments 复制它，从 this one 开始：

这里的 WaitGroup 是为了确保 a, b = a+1, b+1 已经执行，所以没有理由假设它没有执行。

[和]

[T]他保证您已经按照 Go 内存模型进行了布局，该模型有详细记录 [here]。 [具体来说，示例中 wg.Done() 和 wg.Wait() 的组合足以保证对两个变量 a 和 b 的非活泼访问。]

只要这个问题存在，复制 Adrian's comment 可能也是个好主意：

正如 @JimB 指出的，如果一个值在 goroutine 之间共享，它就不能被堆栈分配，所以这个问题没有实际意义（参见 How are Go closures layed out in memory?）。 WaitGroup 工作正常。

闭包变量是堆分配的事实是一个实现细节：将来可能不是这样。但 sync.WaitGroup 保证在未来仍然有效，即使未来某些聪明的 Go 编译器能够将这些变量保留在某个堆栈上。

（“哪个堆栈？”完全是另一个问题，但这个问题需要假设的未来聪明的 Go 编译器来回答。WaitGroup 和内存模型提供了规则。）

今天关于《使用 WaitGroup 从阻止当前变量的不同 go 例程写入堆栈变量是否安全？》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！