Linux和gcc 4中的C ++ new运算符线程安全性

Question

很快我将开始使用共享内存开发并行版本的网格细化算法。

该大学的一位教授指出，我们必须非常小心线程安全，因为编译器和stl都不是线程感知的。

我搜索了这个问题，答案取决于编译器（有些尝试有点线程感知）和平台（如果编译器使用的系统调用是线程安全的或不是）。

那么，在linux中，gcc 4编译器为new运算符生成线程安全的代码吗？

如果没有，克服此问题的最佳方法是什么？也许锁定每个调用新的运算符？

Answer 1

您必须非常努力地找到支持线程但没有线程安全new的平台。实际上，new（和malloc）的线程安全性是它如此缓慢的原因之一。

另一方面，如果你想要一个线程安全的STL，你可以考虑使用具有线程感知容器的Intel TBB（尽管并非它们上的所有操作都是线程安全的）。

Answer 2

通常new运算符是线程安全的 - 但是对于调用STL和标准库的线程安全保证是由标准控制的 - 这并不意味着它们是线程不知道的 - 它们往往非常明确保证某些操作的线程安全。例如，以只读方式遍历列表对于多个读者来说是线程安全的，而迭代列表并进行更新则不是。你必须阅读文档，看看各种保证是什么，虽然它们不是那么繁重而且它们往往是有意义的。

Answer 3

虽然我在谈论我没有使用过的概念，但我觉得我应该提一下，如果你使用共享内存，那么你可能希望确保只使用POD类型，并使用新的位置。

其次，如果您正在使用共享内存，因为它通常被理解为在Linux系统上，那么您可能正在使用多个进程 - 而不是线程，分配内存和'做东西' - 使用共享内存作为通信层。如果是这种情况，那么应用程序和库的线程安全性并不重要 - 然而，重要的是使用共享内存分配的任何东西的线程安全性！这与运行具有多个线程的一个进程的情况不同，在这种情况下，询问新运算符的线程安全性是一个有效的问题，如果不是，可以通过placement new来解决，或者通过定义自己的分配器来解决。 / p>

Answer 4

嗯，这不是我的问题的明确答案，只是我发现Google实施了高性能多线程malloc 。

因此，如果您对您的实现是否是线程安全存在疑问，也许您应该使用Google Performance Tools。