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

我不确定它是否有资格作为一个明确的答案，但我会尝试提供一些见解。包的F*-functionsfmt仅声明它们采用实现io.Writer接口的类型的值并调用Write它。函数本身对于并发使用是安全的——从某种意义上说，可以同时调用任意数量的函数fmt.Fwhaveter：包本身已经为此做好了准备，但是当同时写入实现的类型的相同值时io.Writer，问题变得更加复杂因为在 Go 中对接口的支持并没有说明真正的并发类型。换句话说，可能允许或不允许并发的真正点被推迟到写入函数的“作者” fmt。（还应该记住，这些fmt.*Print*函数可以Write在一次调用期间连续多次调用其目的地，而不是那些由 stock 包提供的函数log。）所以，我们基本上有两种情况：的自定义实现io.Writer。它的股票实现，例如*os.File由 package.json 函数产生的套接字或围绕套接字的net包装器。第一种情况很简单：无论实现者做了什么。第二种情况更难：据我了解，Go 标准库对此的立场（尽管文档中没有明确说明）因为它围绕操作系统提供的“事物”（例如文件描述符和套接字）提供的包装是合理的“瘦”，因此无论它们实现什么语义，都由运行在特定系统上的 stdlib 代码传递实现。例如，POSIX要求write(2) 在对常规文件或符号链接进行操作时，调用彼此之间是原子的。这意味着，由于Write对包装文件描述符或套接字的事物的任何调用实际上都会导致目标系统的单个“写入”系统调用，因此您可以查阅目标操作系统的文档并了解会发生什么。请注意，POSIX 只告诉文件系统对象，如果os.Stdout打开到终端（或伪终端）或管道或任何其他支持write(2)系统调用的东西，结果将取决于相关子系统和/或驱动程序实现——例如，来自多个并发调用的数据可能散布在其中，或者其中一个调用或两者都可能被操作系统失败——不太可能，但仍然如此。回到 Go，根据我的收集，以下事实适用于包装文件描述符和套接字的 Go stdlib 类型：它们本身可以安全地并发使用（我的意思是，在 Go 级别上）。它们“映射”Write并Read一对一地调用底层对象——也就是说，一个Write调用永远不会分成两个或多个底层系统调用，并且一个Read调用永远不会从多个底层系统调用的结果中返回“粘合”的数据。（顺便说一句，人们偶尔会被这种朴素的行为绊倒——例如，把这个或这个作为例子。）因此，基本上，当我们考虑这一点时，每次fmt.*Print*调用都可以自由调用Write任意次数，您使用os.Stdout, 的示例将：永远不要导致数据竞争——除非你已经为变量分配了os.Stdout一些自定义实现——但是实际写入底层 FD 的数据将以不可预知的顺序混合，这可能取决于许多因素，包括操作系统内核版本和设置、用于构建程序的 Go 版本、硬件和系统上的负载。TL;博士多个并发调用fmt.Fprint*写入相同的“writer”值将它们的并发性推迟到“writer”的实现（类型）。在您在问题中提出的设置中，不可能与 Go stdlib 提供的“类文件”对象进行数据竞争。真正的问题不在于 Go 程序级别的数据竞争，而是在 OS 级别发生的对单个资源的并发访问。在那里，我们（通常）不谈论数据竞争，因为 Go 支持的商品操作系统将人们可能“写入”的东西暴露为抽象，其中真正的数据竞争可能表明内核或驱动程序中存在错误（以及Go 的竞争检测器无论如何都无法检测到它，因为该内存不会由为进程提供动力的 Go 运行时拥有）。基本上，在您的情况下，如果您需要确保任何特定调用生成的数据fmt.Fprint*作为操作系统提供的实际数据接收器的单个连续片段出现，您需要序列化这些调用，因为fmt包不提供关于Write为其导出的函数调用提供的“编写器”的次数。序列化可以是外部的（显式的，即“获取锁，调用fmt.Fprint*，释放锁”）或内部的——通过os.Stdout将管理锁的自定义类型包装并使用它）。当我们在做的时候，log包就是这样做的，并且可以直接用作它提供的“记录器”，包括默认的，允许禁止输出“日志头”（例如时间戳和文件名）。

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

1回答