監視程式中的死鎖及其他

每天回家路上總有一段比較長的路一片漆黑無法看書。這種時候，如果我有興致則會用手機上上網，但是大部分情況下還是用來想問題的。剛才在路上想起今天的工作之一是讓乙個型別中的所有方法對多執行緒「完全互斥」——我不知道如何為它命名，我的意思是乙個類中任意兩個方法a或b，在a沒有退出前，另乙個執行緒是無法訪問b的（當然也無法訪問a）。最簡單的方式應該是把每個方法標記為：

[methodimpl(methodimploptions.synchronized)]
public void somemethod()

private object m_mutex = new object();
private void lock(action action)

但是，這又意味著每個公開方法內部都要使用lock方法，這和直接使用lock(this.m_mutex)又有什麼區別呢？區別當然是有的，硬要說起來，使用lock方法意味著「如果某一天」我要把「互斥」這個條件去掉的話，我只要修改lock方法乙個就可以了——否則我需要修改所有的公開方法。

當然，我覺得就這點理論上的「優勢」是不足以修改**的，那麼我還是繼續使用methodimploptions.synchronized方式吧。

經過了上面這一圈沒有帶來多大價值的思考之後，我又回憶起今天園子首頁的一篇文章談到死鎖。死鎖很容易出現，例如下面的**引發死鎖的概率幾乎是100%：

var mutexa = new object();
var mutexb = new object();
threadpool.queueuserworkitem(_ =>
}});threadpool.queueuserworkitem(_ =>
}});

這種情況下兩個內層lock中的**都無法執行，因為每個執行緒都在等待對方釋放才能繼續下去，這種mutex鎖定順序不一致的情況導致死鎖。那麼概括下來，什麼情況下會出現死鎖呢？其實就是：「如果執行緒a正持有物件a而請求鎖定b，同時執行緒b持有b而請求鎖定c，同時執行緒c持有c而請求……鎖定a」，無論這個迴圈有多長，其中涉及到多少個執行緒，一旦出現這種迴圈，則進入死鎖。其實我想任何一本講作業系統的書都會談到到如何檢查死鎖——以及解開死鎖。既然lock語句只能讓我們靜悄悄地等待下去，那麼不如由我們自己提供乙個實現，避免發生死鎖的情況。例如：

public static class 
lock
}

於是原本使用lock的語句現在就可以變成：

//lock (mutex)
() =>
);

而在lock.with方法中，我們除了呼叫monitor.enter/exit方法來實現真正的鎖之外，還需要在enter之前判斷這個mutex能否正確獲得。其實就是檢視一點：於此同時是否有另乙個執行緒正持有當前mutex物件，並且（經過乙個「鏈」）也在等待當前執行緒正持有的其他mutex物件。如果出現了這樣的情況，則lock.with不會呼叫monitor.enter，而是丟擲異常。這樣做肯定是可行的，問題的關鍵在於如何設計乙個方便使用，效能優越，並且執行緒安全的資料結構。

當然，這種做法只適合在測試環境中「檢查」是否有可能出現死鎖情況，在實際情況下這種做法還是非常消耗效能的。不過，我們可以在編譯產品環境的時候使用特別的編譯選項，把用於檢查死鎖的**給短路掉，這自然就沒有任何問題了。

監視程式中的死鎖及其他

在C 中如何監視其他程式

哈根達斯的價格及其他

Python中呼叫其他程式的方式

監視程式中的死鎖及其他

在C 中如何監視其他程式

哈根達斯的價格及其他

Python中呼叫其他程式的方式

相關推薦