在linux和gcc中的C++新的運算符線程安全性4

Question

很快，我將開始研究使用共享內存的並行版本的網格細化算法。

該大學的一位教授指出，我們必須非常小心線程安全性，因爲編譯器和stl都不知道線程。

我搜索了這個問題，答案依賴於編譯器（某些儘量有些線程感知）和plattform（如果由編譯器使用的系統調用是線程安全與否）。

因此，在linux中，gcc 4編譯器爲新運算符生成線程安全代碼？

如果不是，最好的辦法是克服這個問題？也許鎖定每個呼叫到新的運營商？

Answer 1

您將不得不尋找一個支持線程但沒有線程安全的平臺new。實際上，new（和malloc）的線程安全性是它如此之慢的原因之一。

如果你想要一個線程安全的STL另一方面，你可能會考慮Intel TBB其中有線程感知容器（儘管不是所有的操作都是線程安全的）。

Answer 2

通常，new運算符是線程安全的，但是對STL和標準庫的調用的線程安全保證由標準來管理 - 這並不意味着它們是線程不知道的 - 它們往往具有非常明確的保證爲某些操作提供線程安全。例如，以只讀方式迭代列表對於多個讀取器是線程安全的，而遍歷列表並且不更新更新。你必須閱讀文檔，看看各種保證是什麼，儘管它們不那麼繁瑣，而且它們往往有意義。

Answer 3

雖然我在談論我沒有用過的概念，但我覺得我應該提到，如果您使用的是共享內存，那麼您可能希望確保僅使用POD類型，並使用新的展示位置。其次，如果你使用的是共享內存，因爲它通常被理解爲在Linux系統上，那麼你可能使用多個進程而不是線程來分配內存和「做東西」 - 使用共享內存作爲通信層。如果是這種情況，那麼應用程序和庫的線程安全並不重要 - 然而，重要的是使用共享內存分配的任何事情的線程安全性！這與運行一個具有多個線程的進程不同，在這種情況下，詢問新運算符的線程安全性是一個有效的關注點，可以通過放置新的線程來解決，如果不是，或者通過定義自己的分配器來解決。

Answer 4

嗯，這不是我的問題的明確答案，只是我發現谷歌實施了一個高性能多線程malloc。

所以，如果你不確定你的實現是否是線程安全的，也許你應該使用Google Performance Tools。