cout是否同步/线程安全？

如何解决cout是否同步/线程安全？

| 通常，我假定流不同步，这取决于用户进行适当的锁定。但是，诸如library0之类的东西在标准库中是否得到特殊对待？也就是说，如果多个线程正在写入cout，它们是否可以破坏cout对象？我了解，即使同步，您仍然会获得随机交错的输出，但这可以保证交错。也就是说，从多个线程使用cout是否安全？该供应商依赖吗？ gcc是做什么的？重要提示：如果您说“是”，请提供某种参考，因为我需要某种证明。我也不在乎底层的系统调用，它们很好，但是流在顶部增加了一层缓冲。

解决方法

C ++ 03标准对此没有任何说明。如果不能保证某事物的线程安全，则应将其视为不是线程安全的。这里特别令人感兴趣的是“ 0”被缓冲的事实。即使保证对“ 5”的调用（或在特定实现中实现此效果的任何方法）是互斥的，缓冲区也可能由不同的线程共享。这将迅速导致流的内部状态损坏。即使保证对缓冲区的访问是线程安全的，您认为这段代码还会发生什么？

// in one thread
cout << \"The operation took \" << result << \" seconds.\";

// in another thread
cout << \"Hello world! Hello \" << name << \"!\";

您可能希望此处的每一行相互排斥。但是实现如何保证呢？在C ++ 11中，我们确实有一些保证。 FDIS在§27.4.1[iostream.objects.overview]中指出以下内容：多个线程并不会同时访问同步（第27.5.3.4节）标准iostream对象的格式化和未格式化的输入（第27.7.2.1节）和输出（第27.7.3.1节）功能或标准C流在数据竞赛中（第1.10节）。 [注意：用户仍然必须通过以下方式同步并发使用这些对象和流多线程，如果他们希望避免交错字符。 —尾注] 因此，您不会受到损坏的流，但是如果您不希望输出成为垃圾，则仍然需要手动对其进行同步。 , 这是一个很好的问题。首先，C ++ 98 / C ++ 03没有“线程”的概念。因此，在那个世界上，这个问题毫无意义。 C ++ 0x呢？参见马丁尼奥的答案（我承认让我感到惊讶）。 C ++ 0x之前的具体实现如何？好吧，例如，这是来自GCC 4.5.2的basic_streambuf<...>:sputc的源代码（\“ streambuf \”标头）：

 int_type
 sputc(char_type __c)
 {
   int_type __ret;
   if (__builtin_expect(this->pptr() < this->epptr(),true)) {
       *this->pptr() = __c;
        this->pbump(1);
        __ret = traits_type::to_int_type(__c);
      }
    else
        __ret = this->overflow(traits_type::to_int_type(__c));
    return __ret;
 }

显然，这不会执行锁定。 xsputn也没有。这绝对是cout使用的streambuf的类型。据我所知，libstdc ++不会对任何流操作进行锁定。我不会指望任何东西，因为那样会很慢。因此，通过这种实现方式，很明显两个线程的输出可能会相互破坏（而不仅仅是交错）。这段代码会破坏数据结构本身吗？答案取决于这些功能的可能相互作用。例如，如果一个线程试图刷新缓冲区而另一个线程试图调用xsputn或类似的东西，会发生什么。这可能取决于您的编译器和CPU如何决定对内存加载和存储进行重新排序。需要仔细分析才能确定。如果两个线程尝试同时修改同一位置，这也取决于您的CPU的工作。换句话说，即使它在您当前的环境中正常运行，当您更新任何运行时，编译器或CPU时，它也可能会中断。执行摘要：“我不会”。构建一个执行适当锁定的日志记录类，或移至C ++ 0x。作为一种较弱的选择，您可以将cout设置为unbuffered。可能（尽管不能保证）会跳过与缓冲区有关的所有逻辑并直接调用write。尽管那可能会太慢了。 , C ++标准未指定写入流是否是线程安全的，但通常不是。 www.techrepublic.com/article/use-stl-streams-for-easy-c-plus-plus-thread-safe-logging 并且：C ++线程安全的标准输出流（cout，cerr，clog）是否安全？更新请查看@Martinho Fernandes的答案，以了解新标准C ++ 11对此的解释。 ,就像其他答案提到的那样，这肯定是特定于供应商的，因为C ++标准没有提及线程（C ++ 0x中的更改）。 GCC并未对线程安全性和I / O做出很多承诺。但是它所承诺的文档在这里： http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_concurrency.html#manual.intro.using.concurrency.io 关键的东西可能是： __basic_file类型只是一个周围的小包装的集合 C stdio层（同样，请参见链接在结构下）。我们不锁定自己，但只需通过调用fopen，fwrite等。因此，对于3.0，“ I / O安全的多线程”必须是回答：“是您平台的C吗？库线程安全的I / O吗？\“有些是默认情况下，有些不是；许多报价 C的多种实现权衡不同的图书馆线程安全性和效率。你，程序员，总是需要注意多线程。（例如，POSIX标准需要C stdio FILE *操作是原子的。符合POSIX的C 库（例如，在Solaris和 GNU / Linux）具有一个内部互斥体序列化FILE * s上的操作。但是，您仍然不需要做像调用fclose（fs）这样的愚蠢的事情在一个线程中，然后访问 fs在另一个。）因此，如果您平台的C库是线程安全，那么您的fstream I / O 操作将在最低级别。对于更高级别操作，例如操作流中包含的数据格式化类别（例如，设置 std :: ofstream内部的回调），您需要保护诸如任何其他关键共享资源。我不知道在提到的3.0时间框架内是否有任何变化。可以在以下位置找到MSVC的“ѭ12”线程安全文档：http://msdn.microsoft.com/zh-cn/library/c9ceah3b.aspx：单个对象是线程安全的从多个线程读取。对于例如，给定对象A，它是安全的从线程1和A读取A 同时线程2。如果要写入单个对象由一个线程，然后所有读取和在同一对象上写入该对象其他线程必须受到保护。对于例如，给定对象A，如果线程 1正在写入A，则线程2必须阻止从或中读取写信给A。读和写一个是安全的一个类型的实例，即使另一个线程正在读取或写入相同类型的不同实例。例如，给定的对象A和B 相同的类型，如果A为被写在线程1和B是在线程2中读取。 ... iostream类 iostream类遵循相同的规则和其他类别一样例外。写一个来自多个线程的对象。对于例如，线程1可以在以下位置写入cout 与线程2同时进行。但是，这可能会导致两个线程混合在一起。注意：从流缓冲区读取是不被视为读操作。应该认为是写操作，因为这会改变类的状态。请注意，该信息适用于MSVC的最新版本（当前适用于VS 2010 / MSVC 10 /cl.exe16.x）。您可以使用页面上的下拉控件为MSVC的较早版本选择信息（该信息对于较早版本是不同的）。

cout是否同步/线程安全？

如何解决cout是否同步/线程安全？

解决方法

相关推荐