iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 28
1
自我挑戰組

30天~作業系統學習系列 第 28

第二十八天 死結(Deadlock)

  • 分享至 

  • xImage
  •  

System Model

每一種資源都有一定的instances,像是可能有五個disk,不止一個的I/O devices,每一個process 要利用資源都有以下三種階段

1.要求資源
2.使用資源
3.釋放資源

Deadlock Character

要死結必須要滿足以下四個條件

1.Mutual exclusion:一個資源一次只能被一個process所使用
2.Hold and Wait: process取得一個資源之後等待其他的資源
3.No preemption:資源只能由process自己釋放,不能由其他方式釋放
4.Circular wait:每個process都握有另一個process請求的資源,導致每一個process都在等待另一個process釋放資源

System Model可以用Resource-Allocation Graph(RAG)的方式去用圖表描述,如果圖表中沒有cycle,就不會發生死結,如果有cycle,則看資源的是不是只有一個instances,若只有一個,則會發生deadlock,若不只一個,則有可能發生deadlock。

Method for handling

一般而言,我們可以處理deadlock problem使用下列三個方式其中之一我們可以使用一個protocol去預防或是避免deadlocks,確定系統永遠不會進入deadlocked state。
我們可以允許系統進入deadlocked state,然後偵測它,恢復它。
我們可以完全無視這些問題,假裝這些問題從來不曾發生過。
第三種方法是其中最多作業系統使用的方式,包括Linux、Windows,它讓程式開發者自己來處理這些問題。

接下來我們簡單解釋這三個處理deadlocks的方法。

在開始前,我們應該提到有些學者認為沒有任何單獨的基本方法可以符合所有範圍的作業系統resource-allocation problems。然而基本的方法可以組合,讓我們可以選擇一個最佳的方法針對系統的個別資源。

為了確認deadlocks永遠不會存在,系統可以使用deadlock-prevention跟deadlock-avoidance方案。

Deadlock prevention提供一組方法去確認至少一個必要的死結情況不會發生。這些方法靠著限制資源的需求來達成預防死結。

Deadlock avoidance要求作業系統給出額外的資訊,關於一個process在他的lifetime裡會要求的resource。有了這些額外的資訊,作業系統可以決定是否讓程序的要求繼續等候。為了決定現在的要求是否能滿足,作業系統必須考慮現在資源的存量、資源的分配量、和未來資源的要求與釋放。

如果一個系統沒有使用deadlock-prevention或deadlock-avoidance演算法,那deadlock situation就有可能產生。在這種環境底下系統可以提供一個演算法進入一個狀態來判斷死結是否產生,並且加以恢復。

在我們連偵測跟恢復的演算法都沒有的情況下,我們可能發生一個情形,系統正在一個deadlocked state之下,但是我們無法發現。

在這個情形之下,沒被發現的死結可能導致系統效能的惡化,因為資源被程序掌握了,會有越來越多的程序進入死結狀態,直到你的電腦超過負荷。

雖然這個方法沒有一個可見的形式針對死結問題,但他還是最常被使用在作業系統,無視死結的可能性是比其他的方法更加的有效率,因為在大多數的系統上死結的情形並不常發生。除此之外用來恢復其他狀況的方法有可能被用來處理死結狀況。在有些環境下,系統是在frozen state而非死結狀態。系統必須有手動恢復方法來處理這些狀況,而且也能簡單的利用這些技術來恢復死結狀態。


上一篇
第二十七天 多媒體作業系統 (Multimedia Operating System)
下一篇
第二十九天 死結(Deadlock)
系列文
30天~作業系統學習30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言