在没有互斥体的情况下并发读取或写入时会发生什么

Juv*_*uve -2 concurrency mutex atomic shared-memory go

在 Go 中,使用sync.Mutexor来防止共享对象的并发访问。chan但是,在某些情况下,我只对对象的变量或字段的“最新”值感兴趣。或者我喜欢写一个值,并不关心另一个 go 例程稍后会覆盖它还是之前刚刚覆盖它。

更新: TLDR;只是不要这样做。这是不安全的。阅读答案、评论和链接文档!

2021 年更新: Go 内存模型将被更彻底地指定, Russ Cox 撰写的三篇精彩文章将教您更多关于不同步内存访问的令人惊讶的影响。这些文章总结了以下许多讨论和学习内容。

以下是示例程序的两个变体,两者似乎都使用当前的 Go 运行时产生“正确”的good输出:bad

package main

import (
    "flag"
    "fmt"
    "math/rand"
    "time"
)

var bogus = flag.Bool("bogus", false, "use bogus code")

func pause() {
    time.Sleep(time.Duration(rand.Uint32()%100) * time.Millisecond)
}

func bad() {
    stop := time.After(100 * time.Millisecond)
    var name string

    // start some producers doing concurrent writes (DANGER!)
    for i := 0; i < 10; i++ {
        go func(i int) {
            pause()
            name = fmt.Sprintf("name = %d", i)
        }(i)
    }

    // start consumer that shows the current value every 10ms
    go func() {
        tick := time.Tick(10 * time.Millisecond)
        for {
            select {
            case <-stop:
                return
            case <-tick:
                fmt.Println("read:", name)
            }
        }
    }()

    <-stop
}

func good() {
    stop := time.After(100 * time.Millisecond)
    names := make(chan string, 10)

    // start some producers concurrently writing to a channel (GOOD!)
    for i := 0; i < 10; i++ {
        go func(i int) {
            pause()
            names <- fmt.Sprintf("name = %d", i)
        }(i)
    }

    // start consumer that shows the current value every 10ms
    go func() {
        tick := time.Tick(10 * time.Millisecond)
        var name string
        for {
            select {
            case name = <-names:
            case <-stop:
                return
            case <-tick:
                fmt.Println("read:", name)
            }
        }
    }()

    <-stop
}

func main() {
    flag.Parse()
    if *bogus {
        bad()
    } else {
        good()
    }
}

Run Code Online (Sandbox Code Playgroud)

预期输出如下:

...
read: name = 3
read: name = 3
read: name = 5
read: name = 4
...
Run Code Online (Sandbox Code Playgroud)

read: 和的任何组合read: name=[0-9]都是该程序的正确输出。接收任何其他字符串作为输出都会出错。

当用它运行这个程序时go run --race bogus.go是安全的。

但是,go run --race bogus.go -bogus会警告并发读取和写入。

对于map类型以及附加到切片时,我总是需要互斥体或类似的保护方法,以避免段错误或意外行为。然而,读取和写入变量或字段值的文字(原子值)似乎是安全的。

问题:我可以安全地并发读取和写入哪些 Go 数据类型,而无需互斥,不会产生段错误,也不会从内存中读取垃圾?

请在您的答案中解释为什么Go 中的某些内容是安全或不安全的

更新:我重写了示例以更好地反映原始代码,其中我遇到了并发写入问题。重要的倾向已经在评论中了。我会接受一个答案,该答案足够详细地总结了这些知识(尤其是在 Go 运行时)。

tor*_*rek 5

\n

但是,在某些情况下,我只对对象的变量或字段的最新值感兴趣。

\n
\n\n

这是根本问题:“最新”一词是什么意思?

\n\n

假设,从数学上来说,我们有一个值序列X i,其中0 <= i < N。那么显然,如果j > i ,则X j “晚于” X i。这是“最新”的一个很好的简单定义,并且可能就是您想要的。

\n\n

但是当一台机器中的两个独立的CPU\xe2\x80\x94(包括Go程序\xe2\x80\x94中的两个goroutine)同时工作时时间本身就失去了意义。我们不能说 i < j、i == j 或 i > j。因此, “最新”一词没有正确的定义。

\n\n

为了解决此类问题,现代 CPU 硬件和 Go 作为编程语言,为我们提供了某些同步原语。如果CPU A和B执行存储器栅栏指令或同步指令,或使用存在的任何其他硬件规定,则CPU(和/或某些外部硬件)将插入“时间”概念重新获得其含义所需的任何内容。也就是说,如果CPU使用屏障指令,我们可以说在屏障之前执行的内存加载或存储是“之前”,而在屏障之后执行的内存加载或存储是“之后”。

\n\n

(在某些现代硬件中,实际的实现由加载和存储缓冲区组成,它们可以重新排列加载和存储进入内存的顺序。屏障指令要么同步缓冲区,要么在其中放置一个实际的屏障,以便加载和存储存储无法跨越屏障。这个特定的具体实现提供了一种简单的方法来思考这个问题,但并不完整:您应该认为时间根本不存在于硬件提供的同步之外,即来自以下位置的所有负载:和存储到某些位置是同时发生的,而不是按顺序发生,除了这些障碍。)

\n\n

无论如何,Go 的sync包为您提供了一种简单的高级访问方法来克服这些障碍。在互斥锁调用之前执行的编译代码实际上Lock锁定函数返回之前完成,而在调用之后执行的代码实际上直到锁定函数返回之后才开始。

\n\n

Go 的通道提供相同类型的之前/之后时间保证。

\n\n

Go 的sync/atomic包提供了低得多的级别保证。一般来说,您应该避免这种情况,以支持更高级别的渠道或sync.Mutex风格保证。(编辑添加注释:您可以在此处使用sync/atomic\ 的Pointer操作,但不能string直接使用类型,因为 Go 字符串实际上是作为包含两个单独值的标头实现的:指针和长度。您可以使用另一层来解决此问题通过更新指向对象的指针来实现间接寻址string。但是在考虑这样做之前,您应该对语言的首选方法的使用进行基准测试并验证这些方法是否存在问题,因为在该级别工作的代码sync/atomic是很难编写,也很难调试。)

\n

  • **没有“最后”,在硬件层面上没有。**时间不再意味着任何事情,没有障碍指令。由于 write-behind write-buffering,两个 CPU 对于“最后写入”的值可能存在分歧!请参阅 https://software.intel.com/content/dam/develop/public/us/en/documents/253668-sdm-vol-3a.pdf (2认同)