boost :: shared_mutex比Linux上的std :: mutex慢

Question

我有一個std::unordered_map ，它承受着來自多個線程的非常繁重的工作量。 我可以使用std::mutex進行同步，但是由於並發讀取應該很好，所以我想改用boost::shared_mutex 。 為了測試性能改進，我首先用一堆值預填充了一個映射，然后讓一堆線程運行讀取測試 ：

for (int i = 0; i < iters; ++i) map.count(random_uint(0, key_max));

我將其用於我的粗鎖實現（其中count由std::lock_guard<std::mutex>和我的共享鎖實現（其中boost::shared_lock<boost::shared_mutex> 。

在具有GCC 6.1.1的Arch Linux x86_64系統上， boost::shared_lock版本始終較慢！ 在我朋友使用MSVC 2013的Windows 10系統上， boost::shared_lock 總是更快！ 完整的可編譯代碼在github上： https : //github.com/silverhammermba/sanity

編輯

這似乎是特定於平台的問題。 往上看。 如果有人能構建並運行此代碼並報告他們看到的是正輸出（ shared_lock更快）還是負輸出（課程互斥更快），以及您使用的平台，我將非常感謝。

Answer 1

事實證明，在Linux上boost::shared_mutex是“次優”的 。

'pthread'的boost :: shared_mutex的當前實現（自增強1.59起）是次優的，因為它使用重量級互斥量來保護內部互斥量狀態[當訪問並發性很高時]共享互斥量實際上是排他的。

萬歲助力，我的許多小時都被偷了。

Answer 2

一些注意事項：

1. 如果您的數據結構面臨高爭用，強烈建議使用具有無鎖實現的相同數據結構

2. 當讀取很常見時，讀寫器鎖通常可以提高性能，但是寫入很少。 從哲學上講，如果鎖必須確定其他線程是在讀取模式還是在寫入模式下捕獲了該鎖，則比僅等待釋放鎖要慢。 因此，如果讀取是常見的而寫入是罕見的，則其他線程不會被阻塞。 如果寫操作很普遍，那么不僅線程被阻塞，而且它們還必須執行額外的邏輯以弄清楚如何鎖定什么。

因此，對於夏季而言，您的示例以一種不好的方式使用了鎖。 另外，如果性能適合您，請使用無鎖編程。