什麼可能導致死鎖或以其他方式導致此併發測試不一致失敗？

Question

我一直在擺弄CHESS，這似乎是一個非常有用的工具。不過，具有諷刺意味的是，我似乎在用我的一種測試方法處理海森伯。通過CHESS報道，當我運行這個測試的結果是不可預知的：

• 有時候測試會通過
• 有時會導致測試失敗，沒有進一步的說明（簡單地說：「試驗失敗」）
• 有時測試將失敗，並指示覆制*
• 有時候測試會顯示「CHESS檢測僵局」

起初，我以爲這種不一致性必須是由於該測試涉及的事實使用Random對象。一定是不同的種子價值產生了不同的結果，對吧？

所以我更新了測試，以簡單地對預定的一組種子值（0到10）上運行。線程本地Random對象通過共享鎖Random生成的（僞）隨機值生成種子。代碼如下 基本上 正是這樣的：

（更新：我在.NET 3.5上運行這一點，因爲CHESS只支持VS 2008我不知道這個問題可能有一些做this？）

據我瞭解，上面的代碼實際上應該是非常確定的。由於sharedRandom與已知的種子（0和10之間）被初始化，由屬於運行Parallel.For呼叫內的代碼的每個線程的localRandom對象產生的值應該從一個測試運行到下一個相一致（其線程獲得該種子從sharedRandom可能在運行之間有所不同，但在Parallel.For內的5次迭代中，應該使用相同的5粒種子用於localRandom）。

這就是我理解。但是從CHESS的結果來看，我傾向於相信我一定會錯過一些東西。

1. 上面的代碼中是否存在死鎖，我太笨了？
2. 我現在不使用併發相關的測試Random類？
3. 對於那些有使用CHESS經驗的人來說：它是一種可靠的工具嗎？有時會產生誤報嗎？這實際上是一個大問題，就好像事實證明這種情況很普遍（測試結果不一致），那麼對我而言，暫時停止使用CHESS是可取的。

_{* ...我還沒有弄清楚如何使用 - 但這是一個單獨的問題。}

Answer 1

沒有答案，我給它一個鏡頭。對於我來說，張貼的片段如何失敗並不明顯，我懷疑真正的問題在評論中。

我沒有CHESS的實踐經驗，但對它進行了充分研究，知道你不能依靠它來給你重現性的測試結果。發現線程問題的方法非常多，在線程中注入隨機延遲。旨在重新創建受時間，特別是競賽條件嚴重影響的線程問題。

如果代碼執行時間可預測，競爭條件可能在很長一段時間內未檢測到。當它出現時，難以置信地難以診斷。這方面的一個很好的例子就是我聽說隨着日誌記錄一直在打開的大型政府項目。因爲關閉它將不再有效，並且沒有好的方法來診斷沒有記錄信息的問題。

威脅CHESS作爲診斷工具。如果它提出了一個標誌，你可以相當肯定你有一個真實的，但仍然很難解決，線程問題。

Answer 2

我當然沒有看到那裏的僵局。 Random可能有內部鎖定，但應該沒問題。

您可能想嘗試Jinx（www.corensic.com）。 Jinx並沒有編寫報告，而是改變了各種CPU的有效性能。所以它不能真正產生誤報。

如果Jinx下的微小樣本發生死鎖，它在正常使用過程中肯定會發生死鎖。假設它存在死鎖，你應該能夠用Visual Studio打破僵局，並且看看線程在哪裏。

免責聲明。我爲corensic工作。我不認爲你發佈的小片段有真正的僵局。但我很好奇，所以讓我們知道你找到了什麼。