炸彈問題一種會引發死鎖的情景模式

有這樣一種炸彈，它有乙個控制中心，時不時傳送訊息給它；當它被引爆的時候，它將告訴控制中心，並把自己從控制中心的聯絡列表中移除。在通常的**中，由於接受訊息或者引爆的時候，都會引起炸彈的狀態變化，所以，我們會使用乙個鎖來保證這兩個操作是有順序的；另外，控制中心的控制列表也是會有鎖來控制訪問。下面是其中乙個實現：

執行過程中將會出現死鎖的情況。原因是：

bomb:
public void fire()
}

bombcenter：    
public void removebomb(bomb bomb)
}

上面的過程需要的鎖的順序是：bomb.mcorelock->bombcenter.mbombslock

而控制中心呼叫炸彈的過程：

bombcenter:     
public void callbombs()
}}


bomb:
public void oncommandreceived()
}

需要的鎖的順序是: bombcetner.mbombslock->bomb.mcorelock

當這兩個過程併發進行的話，就有可能會造成死鎖的情況。本質上來說，這是"哲學家吃飯問題"的變種，但是它比較隱蔽，一般來說，會有乙個訊息的訂閱者的基本模式，而訂閱者會自我銷毀，並主動要求訊息中心從列表中移除自己。這樣的套路用的還是蠻多的，但是有可能會產生死鎖的問題。

一種解決方案是，炸彈不直接要求控制中心移除自己，而是設定自己乙個「可以被廢棄」的標誌，而由控制中心在適當的時候移除。

bombcenter:
public void callbombs()
);log("bombcenter firebombs: lock bombs end");
foreach (var bomb in mbombs)
}}

但是如果賬單中心沒有所謂的合適的地方放置移除標記了的炸彈（沒有自己的執行緒），那麼另外一種解決方案就是，使用"非同步移除"。

bomb:
public void fire());}
}

炸彈問題的本質是，炸彈的事件引起控制中心的某個資料集合發生變化，而控制中心的執行緒會遍歷集合，對炸彈進行操作。如果控制中心弱化成只是單純的資料集合，那麼就不屬於炸彈問題。

炸彈問題一種會引發死鎖的情景模式

mysql 死鎖 MySql 死鎖時的一種解決辦法

一種簡單的死鎖檢測演算法

mysql死鎖檢測演算法一種簡單的死鎖檢測演算法

炸彈問題 一種會引發死鎖的情景模式

mysql 死鎖 MySql 死鎖時的一種解決辦法

一種簡單的死鎖檢測演算法

mysql死鎖檢測演算法 一種簡單的死鎖檢測演算法

相關推薦

炸彈問題一種會引發死鎖的情景模式

mysql死鎖檢測演算法一種簡單的死鎖檢測演算法