为什么 Go 在这段代码中检测到 Printf 存在竞争条件
Why is there a race condition detected on Printf in this code by Go
我写了一些简单的 Go 代码来理解竞争条件,如下所示:
package main
import (
"fmt"
"sync"
)
type outer struct {
sync.Mutex
num int
foo string
}
func (outer *outer) modify(wg *sync.WaitGroup) {
outer.Lock()
defer outer.Unlock()
outer.num = outer.num + 1
wg.Done()
}
func main() {
outer := outer{
num: 2,
foo: "hi",
}
var w sync.WaitGroup
for j := 0; j < 5000; j++ {
w.Add(1)
go outer.modify(&w)
}
w.Wait()
fmt.Printf("Final is %+v", outer)
}
当我在上面运行时,打印的答案总是正确的,即num总是5002。
没有锁,由于 forloop 中创建的 goroutine 之间的竞争,答案如预期的那样不可预测。
但是,当我 运行 使用 -race 时,会检测到以下竞争条件:
go run -race random.go
==================
WARNING: DATA RACE
Read at 0x00c00000c060 by main goroutine:
main.main()
random.go:32 +0x15d
Previous write at 0x00c00000c060 by goroutine 22:
sync/atomic.AddInt32()
/usr/local/go/src/runtime/race_amd64.s:269 +0xb
sync.(*Mutex).Unlock()
/usr/local/go/src/sync/mutex.go:182 +0x54
main.(*outer).modify()
random.go:19 +0xb7
Goroutine 22 (finished) created at:
main.main()
random.go:29 +0x126
==================
Final is {Mutex:{state:0 sema:0} num:5002 foo:hi}Found 1 data race(s)
exit status 66
即。它正在检测最终 Printf 和在它之前创建的一个随机 go 例程之间的竞争。
由于我正在使用等待同步,所以所有的例程都在我们到达 Printf 时完成。
比赛被举报的原因是什么?
打印结构时是否也需要锁定?
sync.WaitGroup
的不当使用是导致您出现竞争状况的原因。这些中的任何一个都应该正常工作:
func (outer *outer) modify(wg *sync.WaitGroup) {
outer.Lock()
outer.num = outer.num + 1
outer.Unlock()
wg.Done()
}
func (outer *outer) modify(wg *sync.WaitGroup) {
outer.Lock()
defer wg.Done()
defer outer.Unlock()
outer.num = outer.num + 1
}
wg.Done()
应该在解锁互斥锁之后调用(延迟调用以 LIFO 方式进行),因为之前调用它会导致 Printf()
调用与最后一个 outer.Unlock()
调用竞争用于访问 outer
.
package main
import (
"fmt"
"sync"
)
type outer struct {
*sync.Mutex
num int
foo string
}
func (outer *outer) modify(wg *sync.WaitGroup) {
outer.Lock()
defer outer.Unlock()
outer.num++
wg.Done()
}
func main() {
outer := outer{
Mutex: &sync.Mutex{},
num: 2,
foo: "hi",
}
w := &sync.WaitGroup{}
for j := 0; j < 5000; j++ {
w.Add(1)
go outer.modify(w)
}
w.Wait()
fmt.Printf("Final is %+v", outer)
}
将sync.Mutex更改为指针。
我认为这是因为 sync.Mutex 在您的版本中很有价值
我写了一些简单的 Go 代码来理解竞争条件,如下所示:
package main
import (
"fmt"
"sync"
)
type outer struct {
sync.Mutex
num int
foo string
}
func (outer *outer) modify(wg *sync.WaitGroup) {
outer.Lock()
defer outer.Unlock()
outer.num = outer.num + 1
wg.Done()
}
func main() {
outer := outer{
num: 2,
foo: "hi",
}
var w sync.WaitGroup
for j := 0; j < 5000; j++ {
w.Add(1)
go outer.modify(&w)
}
w.Wait()
fmt.Printf("Final is %+v", outer)
}
当我在上面运行时,打印的答案总是正确的,即num总是5002。 没有锁,由于 forloop 中创建的 goroutine 之间的竞争,答案如预期的那样不可预测。
但是,当我 运行 使用 -race 时,会检测到以下竞争条件:
go run -race random.go
==================
WARNING: DATA RACE
Read at 0x00c00000c060 by main goroutine:
main.main()
random.go:32 +0x15d
Previous write at 0x00c00000c060 by goroutine 22:
sync/atomic.AddInt32()
/usr/local/go/src/runtime/race_amd64.s:269 +0xb
sync.(*Mutex).Unlock()
/usr/local/go/src/sync/mutex.go:182 +0x54
main.(*outer).modify()
random.go:19 +0xb7
Goroutine 22 (finished) created at:
main.main()
random.go:29 +0x126
==================
Final is {Mutex:{state:0 sema:0} num:5002 foo:hi}Found 1 data race(s)
exit status 66
即。它正在检测最终 Printf 和在它之前创建的一个随机 go 例程之间的竞争。 由于我正在使用等待同步,所以所有的例程都在我们到达 Printf 时完成。
比赛被举报的原因是什么?
打印结构时是否也需要锁定?
sync.WaitGroup
的不当使用是导致您出现竞争状况的原因。这些中的任何一个都应该正常工作:
func (outer *outer) modify(wg *sync.WaitGroup) {
outer.Lock()
outer.num = outer.num + 1
outer.Unlock()
wg.Done()
}
func (outer *outer) modify(wg *sync.WaitGroup) {
outer.Lock()
defer wg.Done()
defer outer.Unlock()
outer.num = outer.num + 1
}
wg.Done()
应该在解锁互斥锁之后调用(延迟调用以 LIFO 方式进行),因为之前调用它会导致 Printf()
调用与最后一个 outer.Unlock()
调用竞争用于访问 outer
.
package main
import (
"fmt"
"sync"
)
type outer struct {
*sync.Mutex
num int
foo string
}
func (outer *outer) modify(wg *sync.WaitGroup) {
outer.Lock()
defer outer.Unlock()
outer.num++
wg.Done()
}
func main() {
outer := outer{
Mutex: &sync.Mutex{},
num: 2,
foo: "hi",
}
w := &sync.WaitGroup{}
for j := 0; j < 5000; j++ {
w.Add(1)
go outer.modify(w)
}
w.Wait()
fmt.Printf("Final is %+v", outer)
}
将sync.Mutex更改为指针。
我认为这是因为 sync.Mutex 在您的版本中很有价值