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