Any race is a bug. When there is a race, the compiler is free to do whatever it wants.
阅读原文时间:2023年07月11日阅读:2

https://mp.weixin.qq.com/s/pVJiFdDDKVx707eKL19bjA

原创 ms2008 poslua 2019-05-13

我在接手其他同事的 golang 项目时,一般都会习惯性的做一个竞态检测。有时总会得到一些“惊喜”,比如像下面这段代码:

package main

import (
"fmt"
"runtime"
"time"
)

var i = 0

func main() {
runtime.GOMAXPROCS(2)
go func() {
for {
fmt.Println("i is ", i)
time.Sleep(time.Second)
}
}()
for {
i += 1
}
}

当通过 go run-race cmd.go 执行时,可以看到有明显的竞态出现:

go run -race g.go

WARNING: DATA RACE
Read at 0x0000006459c0 by goroutine 7:
main.main.func1()
/home/s/goAction/tDataRace/g.go:15 +0x3e

Previous write at 0x0000006459c0 by main goroutine:
main.main()
/home/s/goAction/tDataRace/g.go:20 +0x84

Goroutine 7 (running) created at:
main.main()

/home/s/goAction/tDataRace/g.go:13 +0x53

i is 380899
i is 33836429

我觉得不同的 goroutine 并发读写同一个变量,需要加锁,这应该是天经地义的常识。但是总有人以为,不加锁导致的问题最多就是读取的数据是修改前的数据,不能保证原子性罢了。是这样的吗?从上面的输出来看,似乎也差不多,其实这些都是典型的误解。

有些朋友可能不知道,在 Go(甚至是大部分语言)中,一条普通的赋值语句其实并不是一个原子操作(语言规范同样没有定义 i++ 是原子操作, 任何变量的赋值都不是原子操作)。例如,在 32 位机器上写 int64类型的变量是有中间状态的,它会被拆成两次写操作 MOV —— 写低 32 位和写高 32 位,如下图所示:

如果一个线程刚写完低 32 位,还没来得及写高 32 位时,另一个线程读取了这个变量,那它得到的就是一个毫无逻辑的中间变量,这很有可能使我们的程序出现诡异的 Bug。

而在 Go 的内存模型中,有 race 的 Go 程序的行为是未定义行为,理论上出现什么情况都是正常的。就拿上面的代码来说,当去掉 -race 参数执行时,大概率会得到这样的输出:

  1. i is: 0

  2. i is: 0

  3. i is: 0

  4. i is: 0

而用较老的 go 版本执行时,基本上执行一段时间,程序就会 HANG 住。所以讨论为什么出现这种现象实际上没有任何意义,不要依赖这种行为。

解决 race 的问题时,无非就是上锁。可能很多人都听说过一个高逼格的词叫「无锁队列」。 都一听到加锁就觉得很 low,那无锁又是怎么一回事?其实就是利用 atomic 特性,那 atomic 会比 mutex 有什么好处呢?Benign Data Races: What Could Possibly Go Wrong? 的作者总结了这两者的一个区别:

Mutexes do no scale. Atomic loads do.

mutex操作系统实现,而 atomic 包中的原子操作则由底层硬件直接提供支持。在 CPU 实现的指令集里,有一些指令被封装进了 atomic 包,这些指令在执行的过程中是不允许中断(interrupt)的,因此原子操作可以在 lock-free 的情况下保证并发安全,并且它的性能也能做到随 CPU 个数的增多而线性扩展。

若实现相同的功能,后者通常会更有效率,并且更能利用计算机多核的优势。所以,以后当我们想并发安全的更新一些变量的时候,我们应该优先选择用 atomic 来实现。

参考资料

  • The Go Memory Model

  • Would this race condition be considered a bug?

  • 理解Go标准库中的atomic.Value类型

[s@s tDataRace]$ ll -as
total 2000
4 drwxr-xr-x 2 s go 4096 Dec 21 08:11 .
4 drwxr-xr-x 13 s go 4096 Dec 21 08:03 ..
1988 -rwxr-xr-x 1 s go 2035035 Dec 21 08:11 g
4 -rw-r--r-- 1 s go 200 Dec 21 08:05 g.go
[s@s tDataRace]$ rm -rf g
[s@s tDataRace]$ go build g.go
[s@s tDataRace]$ ll -as
total 2000
4 drwxr-xr-x 2 s go 4096 Dec 21 08:11 .
4 drwxr-xr-x 13 s go 4096 Dec 21 08:03 ..
1988 -rwxr-xr-x 1 s go 2035035 Dec 21 08:11 g
4 -rw-r--r-- 1 s go 200 Dec 21 08:05 g.go
[s@s tDataRace]$ go tool objdump -s main.main g
TEXT main.main(SB) /home/s/goAction/tDataRace/g.go
g.go:11 0x4992e0 64488b0c25f8ffffff MOVQ FS: 0xfffffff8, CX
g.go:11 0x4992e9 483b6110 CMPQ 0x1 0(CX), SP
g.go:11 0x4992ed 7639 JBE 0x49 9328
g.go:11 0x4992ef 4883ec18 SUBQ $0x 18, SP
g.go:11 0x4992f3 48896c2410 MOVQ BP, 0x10(SP)
g.go:11 0x4992f8 488d6c2410 LEAQ 0x1 0(SP), BP
g.go:12 0x4992fd 48c7042402000000 MOVQ $0x 2, 0(SP)
g.go:12 0x499305 e876d3f6ff CALL run time.GOMAXPROCS(SB)
g.go:13 0x49930a c7042400000000 MOVL $0x 0, 0(SP)
g.go:13 0x499311 488d0598b70200 LEAQ 0x2 b798(IP), AX
g.go:13 0x499318 4889442408 MOVQ AX, 0x8(SP)
g.go:13 0x49931d 0f1f00 NOPL 0(A X)
g.go:13 0x499320 e83b3afaff CALL run time.newproc(SB)
g.go:19 0x499325 90 NOPL
g.go:1 0x499326 ebfd JMP 0x49 9325
g.go:11 0x499328 e87386fcff CALL run time.morestack_noctxt(SB)
g.go:11 0x49932d ebb1 JMP main .main(SB)

TEXT main.main.func1(SB) /home/s/goAction/tDataRace/g.go
g.go:13 0x499340 64488b0c25f8ffffff MOVQ FS: 0xfffffff8, CX
g.go:13 0x499349 483b6110 CMPQ 0x1 0(CX), SP
g.go:13 0x49934d 0f86a4000000 JBE 0x49 93f7
g.go:13 0x499353 4883ec68 SUBQ $0x 68, SP
g.go:13 0x499357 48896c2460 MOVQ BP, 0x60(SP)
g.go:13 0x49935c 488d6c2460 LEAQ 0x6 0(SP), BP
g.go:15 0x499361 488b0598af0e00 MOVQ mai n.i(SB), AX
g.go:15 0x499368 48890424 MOVQ AX, 0(SP)
g.go:15 0x49936c e86f0df7ff CALL run time.convT64(SB)
g.go:15 0x499371 488b442408 MOVQ 0x8 (SP), AX
g.go:15 0x499376 0f57c0 XORPS X0 , X0
g.go:15 0x499379 0f11442440 MOVUPS X 0, 0x40(SP)
g.go:15 0x49937e 0f11442450 MOVUPS X 0, 0x50(SP)
g.go:15 0x499383 488d0d16b50000 LEAQ 0xb 516(IP), CX
g.go:15 0x49938a 48894c2440 MOVQ CX, 0x40(SP)
g.go:15 0x49938f 488d157a170400 LEAQ 0x4 177a(IP), DX
g.go:15 0x499396 4889542448 MOVQ DX, 0x48(SP)
g.go:15 0x49939b 488d1d7eae0000 LEAQ 0xa e7e(IP), BX
g.go:15 0x4993a2 48895c2450 MOVQ BX, 0x50(SP)
g.go:15 0x4993a7 4889442458 MOVQ AX, 0x58(SP)
print.go:274 0x4993ac 488b05fdb50b00 MOVQ os. Stdout(SB), AX
print.go:274 0x4993b3 488d35662d0400 LEAQ go. itab.*os.File,io.Writer(SB), SI
print.go:274 0x4993ba 48893424 MOVQ SI, 0(SP)
print.go:274 0x4993be 4889442408 MOVQ AX, 0x8(SP)
print.go:274 0x4993c3 488d442440 LEAQ 0x4 0(SP), AX
print.go:274 0x4993c8 4889442410 MOVQ AX, 0x10(SP)
print.go:274 0x4993cd 48c744241802000000 MOVQ $0x 2, 0x18(SP)
print.go:274 0x4993d6 48c744242002000000 MOVQ $0x 2, 0x20(SP)
print.go:274 0x4993df 90 NOPL
print.go:274 0x4993e0 e85b9affff CALL fmt .Fprintln(SB)
g.go:16 0x4993e5 48c7042400ca9a3b MOVQ $0x 3b9aca00, 0(SP)
g.go:16 0x4993ed e86e72fcff CALL tim e.Sleep(SB)
g.go:15 0x4993f2 e96affffff JMP 0x49 9361
g.go:13 0x4993f7 e8a485fcff CALL run time.morestack_noctxt(SB)
g.go:13 0x4993fc 0f1f4000 NOPL 0(A X)
g.go:13 0x499400 e93bffffff JMP main .main.func1(SB)
[s@s tDataRace]$ go build -race g.go
[s@s tDataRace]$ go tool objdump -s main.main g
TEXT main.main(SB) /home/s/goAction/tDataRace/g.go
g.go:11 0x512ba0 64488b0c25f8ffffff MOVQ FS:0xfffffff8, CX
g.go:11 0x512ba9 483b6110 CMPQ 0x10(CX), SP
g.go:11 0x512bad 0f8683000000 JBE 0x512c36
g.go:11 0x512bb3 4883ec20 SUBQ $0x20, SP
g.go:11 0x512bb7 48896c2418 MOVQ BP, 0x18(SP)
g.go:11 0x512bbc 488d6c2418 LEAQ 0x18(SP), BP
g.go:11 0x512bc1 488b442420 MOVQ 0x20(SP), AX
g.go:11 0x512bc6 48890424 MOVQ AX, 0(SP)
g.go:11 0x512bca e8315cf8ff CALL runtime.racefuncenter(SB)
g.go:12 0x512bcf 48c7042402000000 MOVQ $0x2, 0(SP)
g.go:12 0x512bd7 e8e454f2ff CALL runtime.GOMAXPROCS(SB)
g.go:13 0x512bdc c7042400000000 MOVL $0x0, 0(SP)
g.go:13 0x512be3 488d050e310300 LEAQ 0x3310e(IP), AX
g.go:13 0x512bea 4889442408 MOVQ AX, 0x8(SP)
g.go:13 0x512bef e88cc2f5ff CALL runtime.newproc(SB)
g.go:20 0x512bf4 488d05c52d1300 LEAQ main.i(SB), AX
g.go:20 0x512bfb 48890424 MOVQ AX, 0(SP)
g.go:20 0x512bff 90 NOPL
g.go:20 0x512c00 e8db5af8ff CALL runtime.raceread(SB)
g.go:20 0x512c05 488b05b42d1300 MOVQ main.i(SB), AX
g.go:20 0x512c0c 4889442410 MOVQ AX, 0x10(SP)
g.go:20 0x512c11 488d0da82d1300 LEAQ main.i(SB), CX
g.go:20 0x512c18 48890c24 MOVQ CX, 0(SP)
g.go:20 0x512c1c 0f1f4000 NOPL 0(AX)
g.go:20 0x512c20 e8fb5af8ff CALL runtime.racewrite(SB)
g.go:20 0x512c25 488b442410 MOVQ 0x10(SP), AX
g.go:20 0x512c2a 48ffc0 INCQ AX
g.go:20 0x512c2d 4889058c2d1300 MOVQ AX, main.i(SB)
g.go:20 0x512c34 ebbe JMP 0x512bf4
g.go:11 0x512c36 e8a526f8ff CALL runtime.morestack_noctxt(SB)
g.go:11 0x512c3b 0f1f440000 NOPL 0(AX)(AX*1)
g.go:11 0x512c40 e95bffffff JMP main.main(SB)

TEXT main.main.func1(SB) /home/s/goAction/tDataRace/g.go
g.go:13 0x512c60 64488b0c25f8ffffff MOVQ FS:0xfffffff8, CX
g.go:13 0x512c69 483b6110 CMPQ 0x10(CX), SP
g.go:13 0x512c6d 0f86d2000000 JBE 0x512d45
g.go:13 0x512c73 4883ec68 SUBQ $0x68, SP
g.go:13 0x512c77 48896c2460 MOVQ BP, 0x60(SP)
g.go:13 0x512c7c 488d6c2460 LEAQ 0x60(SP), BP
g.go:13 0x512c81 488b442468 MOVQ 0x68(SP), AX
g.go:13 0x512c86 48890424 MOVQ AX, 0(SP)
g.go:13 0x512c8a e8715bf8ff CALL runtime.racefuncenter(SB)
g.go:15 0x512c8f 488d052a2d1300 LEAQ main.i(SB), AX
g.go:15 0x512c96 48890424 MOVQ AX, 0(SP)
g.go:15 0x512c9a e8415af8ff CALL runtime.raceread(SB)
g.go:15 0x512c9f 488b051a2d1300 MOVQ main.i(SB), AX
g.go:15 0x512ca6 48890424 MOVQ AX, 0(SP)
g.go:15 0x512caa e8b18ef2ff CALL runtime.convT64(SB)
g.go:15 0x512caf 488b442408 MOVQ 0x8(SP), AX
g.go:15 0x512cb4 0f57c0 XORPS X0, X0
g.go:15 0x512cb7 0f11442440 MOVUPS X0, 0x40(SP)
g.go:15 0x512cbc 0f11442450 MOVUPS X0, 0x50(SP)
g.go:15 0x512cc1 488d0d58c40000 LEAQ 0xc458(IP), CX
g.go:15 0x512cc8 48894c2440 MOVQ CX, 0x40(SP)
g.go:15 0x512ccd 488d151ce20400 LEAQ 0x4e21c(IP), DX
g.go:15 0x512cd4 4889542448 MOVQ DX, 0x48(SP)
g.go:15 0x512cd9 488d1d40bd0000 LEAQ 0xbd40(IP), BX
g.go:15 0x512ce0 48895c2450 MOVQ BX, 0x50(SP)
g.go:15 0x512ce5 4889442458 MOVQ AX, 0x58(SP)
print.go:274 0x512cea 488d057f331000 LEAQ os.Stdout(SB), AX
print.go:274 0x512cf1 48890424 MOVQ AX, 0(SP)
print.go:274 0x512cf5 e8e659f8ff CALL runtime.raceread(SB)
print.go:274 0x512cfa 488b056f331000 MOVQ os.Stdout(SB), AX
print.go:274 0x512d01 488d0db8fa0400 LEAQ go.itab.*os.File,io.Writer(SB), CX
print.go:274 0x512d08 48890c24 MOVQ CX, 0(SP)
print.go:274 0x512d0c 4889442408 MOVQ AX, 0x8(SP)
print.go:274 0x512d11 488d442440 LEAQ 0x40(SP), AX
print.go:274 0x512d16 4889442410 MOVQ AX, 0x10(SP)
print.go:274 0x512d1b 48c744241802000000 MOVQ $0x2, 0x18(SP)
print.go:274 0x512d24 48c744242002000000 MOVQ $0x2, 0x20(SP)
print.go:274 0x512d2d e88e60ffff CALL fmt.Fprintln(SB)
g.go:16 0x512d32 48c7042400ca9a3b MOVQ $0x3b9aca00, 0(SP)
g.go:16 0x512d3a e8a111f8ff CALL time.Sleep(SB)
g.go:16 0x512d3f 90 NOPL
g.go:15 0x512d40 e94affffff JMP 0x512c8f
g.go:13 0x512d45 e89625f8ff CALL runtime.morestack_noctxt(SB)
g.go:13 0x512d4a e911ffffff JMP main.main.func1(SB)
[s@s tDataRace]$

当通过 go run cmd.go 执行时,大概率会得到下面这样的输出:

  1. i is: 0

  2. i is: 0

  3. i is: 0

  4. i is: 0

然而有些同学提到:之所以输出 0 是因为 i+=1 所在的 goroutine 没有新的栈帧创建,因此没有被调度器调度到。解释似乎也合理,但是事实却不是这样的。真实的原因是:编译器把那段自增的 for 循环给全部优化掉了

要验证这一点,我们要先从编译器优化说起。传统的编译器通常分为三个部分,前端(frontEnd),优化器(Optimizer)和后端(backEnd)。在编译过程中,前端主要负责词法和语法分析,将源代码转化为抽象语法树;优化器则是在前端的基础上,对得到的中间代码进行优化,使代码更加高效;后端则是将已经优化的中间代码转化为针对各自平台的机器代码。

go 的编译器也一样,在生成目标代码的时候会做很多优化,重要的有:

  • 指令重排

  • 逃逸分析

  • 函数内联

  • 死码消除

查看编译出的二进制可执行文件的汇编代码:

显然,下面这一段直接被优化没了:

  1. for {

  2. i += 1

  3. }

why? 因为这段代码是有竞态的,没有任何同步机制。go 编译器认为这一段是 dead code,索性直接优化掉了。

而当我们通过 go build-race g.go 编译后:

可以明显看到有 INCQ 指令了,这是因为 -race 选项打开了 data race detector 用来检查这个错误而关闭了相关的编译器优化:

此,运行结果就“看似正确”了。

最后再引用一句 golang-nuts 上的评论:

Any race is a bug. When there is a race, the compiler is free to do whatever it wants.

参考资料

  • Go compiler - Loop transformations

  • Would this race condition be considered a bug?

Spin-Locks vs. Atomic Instructions - Intel Community https://community.intel.com/t5/Intel-oneAPI-Threading-Building/Spin-Locks-vs-Atomic-Instructions/td-p/894992

c++ - Why is std::mutex faster than std::atomic? - Stack Overflow https://stackoverflow.com/questions/29533755/why-is-stdmutex-faster-than-stdatomic

Benign Data Races: What Could Possibly Go Wrong? https://software.intel.com/content/www/us/en/develop/blogs/benign-data-races-what-could-possibly-go-wrong.html

Comparing the performance of atomic, spinlock and mutex https://demin.ws/blog/english/2012/05/05/atomic-spinlock-mutex/

https://tour.go-zh.org/concurrency/9

我们已经看到信道非常适合在各个 Go 程间进行通信。

但是如果我们并不需要通信呢?比如说,若我们只是想保证每次只有一个 Go 程能够访问一个共享的变量,从而避免冲突?

这里涉及的概念叫做 *互斥(mutual*exclusion)* ,我们通常使用 *互斥锁(Mutex)* 这一数据结构来提供这种机制。

Go 标准库中提供了 sync.Mutex 互斥锁类型及其两个方法:

  • Lock
  • Unlock

我们可以通过在代码前调用 Lock 方法,在代码后调用 Unlock 方法来保证一段代码的互斥执行。参见 Inc 方法。

我们也可以用 defer 语句来保证互斥锁一定会被解锁。参见 Value 方法。

package main

import (
"fmt"
"sync"
"time"
)

// SafeCounter 的并发使用是安全的。
type SafeCounter struct {
v map[string]int
mux sync.Mutex
}

// Inc 增加给定 key 的计数器的值。
func (c *SafeCounter) Inc(key string) {
c.mux.Lock()
// Lock 之后同一时刻只有一个 goroutine 能访问 c.v
c.v[key]++
c.mux.Unlock()
}

// Value 返回给定 key 的计数器的当前值。
func (c *SafeCounter) Value(key string) int {
c.mux.Lock()
// Lock 之后同一时刻只有一个 goroutine 能访问 c.v
defer c.mux.Unlock()
return c.v[key]
}

func main() {
c := SafeCounter{v: make(map[string]int)}
for i := 0; i < 1000; i++ {
go c.Inc("somekey")
}

time.Sleep(time.Second)  
fmt.Println(c.Value("somekey"))  

}

// 2021/1/4 20:50 Shawn
package main

import (
"fmt"
"time"
)

type UnSafeCounter struct {
v map[string]int
}

func (c *UnSafeCounter) Inc(key string) {
c.v[key]++
time.Sleep(10 * time.Millisecond)
}
func (c *UnSafeCounter) Value(key string) int {
return c.v[key]
}

func main() {
c := UnSafeCounter{v: make(map[string]int)}
for i := 0; i < 1000; i++ {
go c.Inc("somekey")
}
time.Sleep(time.Second)
fmt.Println(c.Value("somekey"))
}

go run -race g.go
1000

go run -race g.go
==================
WARNING: DATA RACE
Read at 0x00c000078150 by goroutine 778:
runtime.mapaccess1_faststr()
/home/shawn/go/src/runtime/map_faststr.go:12 +0x0
main.(*UnSafeCounter).Inc()
/home/shawn/gokit/goAction/tMutex2/g.go:14 +0x74

Previous write at 0x00c000078150 by goroutine 1005:
runtime.mapassign_faststr()
/home/shawn/go/src/runtime/map_faststr.go:202 +0x0
main.(*UnSafeCounter).Inc()
/home/shawn/gokit/goAction/tMutex2/g.go:14 +0xc4

Goroutine 778 (running) created at:
main.main()
/home/shawn/gokit/goAction/tMutex2/g.go:24 +0xb9

Goroutine 1005 (running) created at:
main.main()
/home/shawn/gokit/goAction/tMutex2/g.go:24 +0xb9
==================
==================
WARNING: DATA RACE
Read at 0x00c00007a978 by goroutine 778:
main.(*UnSafeCounter).Inc()
/home/shawn/gokit/goAction/tMutex2/g.go:14 +0x87

Previous write at 0x00c00007a978 by goroutine 1005:
main.(*UnSafeCounter).Inc()
/home/shawn/gokit/goAction/tMutex2/g.go:14 +0xd9

Goroutine 778 (running) created at:
main.main()
/home/shawn/gokit/goAction/tMutex2/g.go:24 +0xb9

Goroutine 1005 (running) created at:
main.main()
/home/shawn/gokit/goAction/tMutex2/g.go:24 +0xb9
==================
1000
Found 2 data race(s)
exit status 66