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

问题描述：

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

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

我搜索了这个问题，答案取决于编译器（有些尝试在某种程度上感知线程）和平台（编译器使用的系统调用是否是线程安全的）。

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

如果没有，那么解决这个问题的最佳方法是什么？也许将每个呼叫锁定到新操作员？

解决方案 1：

您将很难找到支持线程但没有线程安全的平台new。事实上，new（和malloc）的线程安全性是它如此缓慢的原因之一。

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

解决方案 2：

通常，new运算符是线程安全的 - 但是对 STL 和标准库的调用的线程安全保证受标准约束 - 这并不意味着它们不了解线程 - 它们往往对某些操作具有非常明确的线程安全保证。例如，以只读方式迭代列表对于多个读取器来说是线程安全的，而迭代列表并进行更新则不是。您必须阅读文档并了解各种保证是什么，尽管它们并不那么繁重，而且往往很有意义。

解决方案 3：

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

其次，如果您使用的是 Linux 系统上通常理解的共享内存，那么您可能正在使用多个进程（而不是线程）来分配内存并“执行操作” - 使用共享内存作为通信层。如果是这种情况，那么您的应用程序和库的线程安全性就不重要了 - 但重要的是使用共享内存分配的任何内容的线程安全性！这与运行一个具有多个线程的进程的情况不同，在这种情况下，询问 new 运算符的线程安全性是一个有效的问题，如果不是，可以通过放置 new 来解决，或者通过定义您自己的分配器来解决。

解决方案 4：

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

因此，如果您怀疑您的实现是否是线程安全的，也许您应该使用Google 性能工具。