很快我将开始研究使用共享内存的网格细化算法的并行版本。
大学的一位教授指出，我们必须非常小心线程安全，因为编译器和 stl 都不是线程感知的。
我搜索了这个问题，答案取决于编译器（有些尝试有点线程感知）和平台（编译器使用的系统调用是否是线程安全的)。
那么，在 linux 中，gcc 4 编译器为 new 运算符生成线程安全代码？
如果没有，克服这个问题的最佳方法是什么？也许将每个呼叫锁定到新的操作员？
【问题讨论】：
标签： c++ linux gcc thread-safety
您将不得不非常努力地找到支持线程但没有线程安全new 的平台。事实上，new（和malloc）的线程安全是它这么慢的原因之一。
另一方面，如果您想要一个线程安全的 STL，您可以考虑 Intel TBB，它具有线程感知容器（尽管并非所有对它们的操作都是线程安全的）。
【讨论】：
通常new 操作符是线程安全的 - 但是调用 STL 和标准库的线程安全保证由标准管理 - 这并不意味着它们是线程不知道的 - 它们往往有很好的定义保证某些操作的线程安全。例如，以只读方式遍历列表对于多个读取器来说是线程安全的，而遍历列表并进行更新则不是。您必须阅读文档并了解各种保证是什么，尽管它们并没有那么繁重而且它们往往是有意义的。
【讨论】：
虽然我在谈论我没有使用过的概念，但我觉得我应该提一下，如果您使用的是共享内存，那么您可能希望确保只使用 POD 类型，并使用 Placement new。
其次，如果您使用共享内存（通常理解为在 linux 系统上），那么您可能会使用多个进程（而不是线程）来分配内存并“做事”——使用共享内存作为通信层.如果是这种情况，那么您的应用程序和库的线程安全性并不重要 - 然而，重要的是使用共享内存分配的任何事物的线程安全性！这是与运行一个具有多个线程的进程不同的情况，在这种情况下，询问 new 运算符的线程安全性是一个有效的问题，如果不是，可以通过放置 new 或定义您自己的分配器来解决。
【讨论】：
嗯，这不是我问题的明确答案，只是我发现 Google 实现了一个高性能多线程 malloc。
所以，如果您不确定您的实现是否是线程安全的，也许您应该使用Google Performance Tools。
【讨论】：