什麼時候更精細的鎖定更好的性能？

Question

我最近採用跳躍列表數據結構來實現併發優先級隊列 - 爲了這個問題，如果你不知道跳過列表是什麼，我相信只是描繪一個鏈表會是足夠回答。我嘗試了最小的鎖定（即允許同時存在多個入隊和出隊，如果需要的話只鎖定節點或它們的前向指針，儘快釋放鎖，使用互鎖的遍歷列表等）。

我對結果感到滿意。然而，編寫一個定期的跳過列表，其中包含一個syncroot鎖定（即在任何給定時間只允許執行一次操作），其實際速度是其兩倍。

我認爲我的執行過程中必須有錯誤。然而，微軟的網站上列出的甚至是「併發優先級隊列」，實際上只允許一個運行在同一時間（即約入隊和出隊SyncRoot上的鎖）

http://code.msdn.microsoft.com/Samples-for-Parallel-b4b76364/sourcecode?fileId=44488&pathId=1696822056

作爲一般規則，（和請原諒我，如果這個問題太籠統了），在更多的細粒度鎖定實際上會導致性能改進的什麼時候？我想在我的情況下，因爲我實際上必須使用Interlocked.Exchange遍歷大型列表（還有更好的方法嗎？）以及多個測試和測試和集合等，這會降低排隊和出隊速度。

此外，有沒有一種工具可以幫助我確定大部分時間都花在哪裏？謝謝。

Answer 1

有不斷地檢查，如果鎖定區域目前是免費的，設置鎖，然後離開時釋放它的開銷。如果在實踐中，你很少真正與其他人競爭訪問該關鍵部分，那麼你就沒有任何有利的理由執行了這些開銷。另一方面，如果有很多線程試圖使用數據結構，那麼您可能會發現並行運行操作（如果擁有多核CPU）會提高性能超過管理鎖的開銷。

對於這些類型的數據結構，有幾十個線程都試圖同時使用數據結構，而執行通常不需要彼此等待的操作時，這種情況並不常見。因此，簡而言之，您可能會生成測試用例，通過添加線程和正確管理他們正在做的事情，從而使較少的鎖定案例表現更好。如果您當前的測試是您實際計劃使用數據結構的合理表示，那麼顯然您的使用不會受益於更復雜的鎖定方案。

Answer 2

你同步越多，你的應用程序就會遭受性能損失。 使用syncroot可能會導致問題不是在複雜情況下去的方法。

特技是在同步中找到合適的平衡;就足以讓它可靠，例如沒有賽跑條件。

看一看在System.Collections.Concurrent命名空間