在标准输出线程上并发写入是安全的吗？

Question

以下代码不会引发数据竞争

package main

import (
    "fmt"
    "os"
    "strings"
)

func main() {
    x := strings.Repeat(" ", 1024)
    go func() {
        for {
            fmt.Fprintf(os.Stdout, x+"aa\n")
        }
    }()

    go func() {
        for {
            fmt.Fprintf(os.Stdout, x+"bb\n")
        }
    }()

    go func() {
        for {
            fmt.Fprintf(os.Stdout, x+"cc\n")
        }
    }()

    go func() {
        for {
            fmt.Fprintf(os.Stdout, x+"dd\n")
        }
    }()

    <-make(chan bool)
}

我尝试了多个长度的数据，变体https://play.golang.org/p/29Cnwqj5K30

This post 表示不是 TS。

This mail 没有真正回答问题，或者我没听懂。

os 和 fmt 的包文档对此没有过多提及。我承认我没有挖掘这两个包的源代码来寻找进一步的解释，它们对我来说似乎太复杂了。

有哪些建议和参考？

Answer 1

我不确定它是否有资格作为一个明确的答案，但我会尝试提供一些见解。

fmt 包的F* 函数仅声明它们采用实现io.Writer 接口的类型的值并在其上调用Write。 这些函数本身对于并发使用是安全的——从某种意义上说，可以同时调用任意数量的fmt.Fwhaveter：包本身已经为此做好了准备， 但是在 Go 中对接口的支持并没有说明真正的并发类型。

换句话说，可能允许或不允许并发的真正点被推迟到fmt 的函数写入的“作者”。 （还应该记住，fmt.*Print* 函数可以在其目的地调用Write 任意次数——这与stock 包log 提供的相反。）

所以，我们基本上有两种情况：

• io.Writer 的自定义实现。
• 它的库存实现，例如*os.File 或由net 包的函数生成的套接字周围的包装器。

第一种情况很简单：无论实现者做什么。

第二种情况更难：据我了解，Go 标准库对此的立场（尽管文档中没有明确说明）在于它围绕操作系统提供的“事物”提供的包装器——例如文件描述符和套接字——相当“瘦”，因此无论它们实现什么语义，都由运行在特定系统上的 stdlib 代码传递实现。

例如，POSIX requires that write(2) calls are atomic with regard to one another 当它们对常规文件或符号链接进行操作时。这意味着，因为任何对包装文件描述符或套接字的事物的 Write 调用实际上都会导致单个tagret 系统的 "write" 系统调用，您可以查阅目标操作系统的文档并了解会发生什么。

注意，POSIX 只告诉文件系统对象，如果os.Stdout 被打开到终端（或伪终端）或管道或任何其他支持write(2) 系统调用的东西，结果将取决于相关子系统和/或驱动程序实现了什么——例如，来自多个并发调用的数据可能散布在其中，或者其中一个调用或两者都可能被操作系统失败——不太可能，但仍然如此。

回到 Go，根据我的收集，以下事实适用于包装文件描述符和套接字的 Go stdlib 类型：

• 它们本身可以安全地并发使用（我的意思是，在 Go 级别上）。
• 它们将Write 和Read 一对一调用“映射”到底层对象——也就是说，Write 调用永远不会拆分为两个或多个底层系统调用，Read 调用永远不会从多个底层系统调用的结果中返回“粘合”的数据。 （顺便说一句，人们偶尔会被这种朴实无华的行为绊倒——例如，请参阅 this 或 this 作为示例。）

所以基本上当我们考虑到这一点时，fmt.*Print* 可以在每次调用中任意多次调用Write，您使用os.Stdout 的示例将：

• 永远不要导致数据争用 — 除非您为变量 os.Stdout 分配了一些自定义实现，但是
• 实际写入底层 FD 的数据将以不可预知的顺序混合，这可能取决于许多因素，包括 OS 内核版本和设置、用于构建程序的 Go 版本、硬件和系统负载.

---

TL;DR

• 对fmt.Fprint* 的多个并发调用写入相同的“writer”值会将它们的并发性推迟到“writer”的实现（类型）。
• 在您在问题中提供的设置中，不可能与 Go 标准库提供的“类文件”对象发生数据竞争。
• 真正的问题不在于 Go 程序级别的数据竞争，而在于操作系统级别上发生的对单个资源的并发访问。在那里，我们（通常）不谈论数据竞争，因为 Go 支持的商品操作系统将人们可能“写入”的东西暴露为抽象，其中真正的数据竞争可能表明内核或驱动程序中存在错误（以及Go 的竞争检测器无论如何都无法检测到它，因为该内存不属于为进程提供动力的 Go 运行时）。

基本上，在您的情况下，如果您需要确保对fmt.Fprint* 的任何特定调用产生的数据作为操作系统提供的实际数据接收器的单个连续片段，您需要将这些调用序列化为fmt 包不保证其导出的函数在提供的“编写器”上调用 Write 的次数。
序列化可以是外部的（显式的，即“获取锁，调用fmt.Fprint*，释放锁”）或内部的 - 通过将os.Stdout 包装在可以管理锁的自定义类型中并使用它）。 当我们使用它时，log 包就是这样做的，并且可以立即用作它提供的“记录器”，包括默认的，允许禁止输出“日志头”（例如时间戳和文件名）。