问题描述
假设我有这个:
go func() {
for range time.Tick(1 * time.Millisecond) {
a, b = b, a
}
}()
其他地方:
i := a // <-- Is this safe?
对于这个问题，i 相对于原始a 或b 的值是什么并不重要.唯一的问题是阅读a 是否安全.也就是说，a 是否有可能是 nil、部分赋值、无效、未定义、...除了有效值之外的任何其他内容?
For this question, it's unimportant what the value of i is with respect to the original a or b. The only question is whether reading a is safe. That is, is it possible for a to be nil, partially assigned, invalid, undefined, ... anything other than a valid value?
我试图让它失败 但到目前为止它总是成功(在我的 Mac 上)).
I've tried to make it fail but so far it always succeeds (on my Mac).
我在 Go 内存模型 文档:
读取和写入大于单个机器字的值的行为如下未指定顺序的多个机器字大小的操作.
Reads and writes of values larger than a single machine word behave as multiple machine-word-sized operations in an unspecified order.
这是否意味着单个机器字写入实际上是原子的?并且，如果是这样，Go 中的函数指针写入是单机字操作吗?
Is this implying that a single machine word write is effectively atomic? And, if so, are function pointer writes in Go a single machine word operation?
更新:这是a正确同步的解决方案
Update: Here's a properly synchronized solution
推荐答案
来自多个 goroutines 的任何变量的非同步、并发访问，其中至少一个是写入是 未定义行为 by Go 内存模型.
Unsynchronized, concurrent access to any variable from multiple goroutines where at least one of them is a write is undefined behavior by The Go Memory Model.
未定义的意思是:未定义.可能是您的程序可以正常运行，也可能是它运行不正常.它可能会导致丢失 Go 运行时提供的内存和类型安全(请参见下面的示例).它甚至可能使您的程序崩溃.或者它甚至可能导致地球爆炸(这种可能性非常小，甚至可能低于 1e-40，但仍然......).
Undefined means what it says: undefined. It may be that your program will work correctly, it may be it will work incorrectly. It may result in losing memory and type safety provided by the Go runtime (see example below). It may even crash your program. Or it may even cause the Earth to explode (probability of that is extremely small, maybe even less than 1e-40, but still...).
这个 undefined 在你的情况下意味着是的，i 可能是 nil，部分分配，无效，未定义，......任何其他而不是 a 或 b.这个列表只是所有可能结果的一小部分.
This undefined in your case means that yes, i may be nil, partially assigned, invalid, undefined, ... anything other than either a or b. This list is just a tiny subset of all the possible outcomes.
不要再认为某些数据竞争是(或可能是)良性或无害的.如果无人看管，它们可能成为最糟糕事情的根源.
Stop thinking that some data races are (or may be) benign or unharmful. They can be the source of the worst things if left unattended.
由于您的代码在一个 goroutine 中写入变量 a 并在另一个 goroutine 中读取它(它试图将其值分配给另一个变量 i)，因此它是一个数据比赛，因此它不安全.在您的测试中它是否正确"工作并不重要.人们可以将您的代码作为起点，在其上扩展/构建并由于最初无害"的数据竞争而导致灾难.
Since your code writes to the variable a in one goroutine and reads it in another goroutine (which tries to assign its value to another variable i), it's a data race and as such it's not safe. It doesn't matter if in your tests it works "correctly". One could take your code as a starting point, extend / build on it and result in a catastrophe due to your initially "unharmful" data race.
相关问题请阅读并发读/写操作的 Golang 映射有多安全? 和 不正确golang中的同步.
As related questions, read How safe are Golang maps for concurrent Read/Write operations? and Incorrect synchronization in go lang.
强烈推荐阅读 Dmitry Vyukov 的博文:良性数据竞争:什么地方可能出错?
Strongly recommended to read the blog post by Dmitry Vyukov: Benign data races: what could possibly go wrong?
还有一篇非常有趣的博客文章，其中展示了一个通过故意数据竞争破坏 Go 内存安全的示例:Golang 数据竞相破坏内存安全
Also a very interesting blog post which shows an example which breaks Go's memory safety with intentional data race: Golang data races to break memory safety
这篇关于在没有锁的情况下并发读取函数指针是否安全?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，WP2