155.處理機調度與死鎖

 

處理機調度與死鎖

 3.1  處理機調度的層次和調度算法的目標

　　在多道程序系統中，調度的實質是一種資源分配，處理機調度是對處理機資源進行分配。處理機調度算法是指根據處理機分配策略所規定的處理機分配算法。在多道批處理系統中，一個做業從提交到得到處理機執行，直至做業運行完畢，可能須要經歷多級處理機調度，下面先來了解處理機調度的層次。

 

3.1.1  處理機調度的層次

　　1. 高級調度(High Level Scheduling)

　　2. 低級調度(Low Level Scheduling)

　　3. 中級調度(Intermediate Scheduling)

 

3.1.2  處理機調度算法的目標

　　1. 處理機調度算法的共同目標

　　(1) 資源利用率。爲提升系統的資源利用率，應使系統中的處理機和其它全部資源都儘量地保持忙碌狀態，其中最重要的處理機利用率可用如下方法計算：

　　(2) 公平性。公平性是指應使諸進程都得到合理的CPU 時間，不會發生進程飢餓現象。公平性是相對的，對相同類型的進程應得到相同的服務；但對於不一樣類型的進程，因爲其緊急程度或重要性的不一樣，則應提供不一樣的服務。

　　(3) 平衡性。因爲在系統中可能具備多種類型的進程，有的屬於計算型做業，有的屬於I/O型。爲使系統中的CPU和各類外部設備都能常常處於忙碌狀態，調度算法應儘量保持系統資源使用的平衡性。

　　(4) 策略強制執行。對所制訂的策略其中包括安全策略，只要須要，就必須予以準確地執行，即便會形成某些工做的延遲也要執行。

 

　　2. 批處理系統的目標

　　(1) 平均週轉時間短。

　　對每一個用戶而言，都但願本身做業的週轉時間最短。但做爲計算機系統的管理者，則老是但願能使平均週轉時間最短，這不只會有效地提升系統資源的利用率，並且還可以使大多數用戶都感到滿意。應使做業週轉時間和做業的平均週轉時間儘量短。不然，會使許多用戶的等待時間過長，這將會引發用戶特別是短做業用戶的不滿。可把平均週轉時間描述爲：

　　爲了進一步反映調度的性能，更清晰地描述各進程在其週轉時間中，等待和執行時間的具體分配情況，每每使用帶權週轉時間，即做業的週轉時間T與系統爲它提供服務的時間Ts之比，即W=T /Ts。而平均帶權週轉時間則可表示爲：

 

　　(2) 系統吞吐量高。因爲吞吐量是指在單位時間內系統所完成的做業數，於是它與批處理做業的平均長度有關。事實上，若是單純是爲了得到高的系統吞吐量，就應儘可能多地選擇短做業運行。

(3) 處理機利用率高。對於大、中型計算機，CPU價格十分昂貴，導致處理機的利用率成爲衡量系統性能的十分重要的指標；而調度方式和算法又對處理機的利用率起着十分重要的做用。若是單純是爲使處理機利用率高，應儘可能多地選擇計算量大的做業運行。由上所述能夠看出，這些要求之間是存在着必定矛盾的。

 

　　3. 分時系統的目標

　　(1) 響應時間快。

　　(2) 均衡性。

 

　　4. 實時系統的目標

　　(1) 截止時間的保證。

　　(2) 可預測性。

 

3.2  做業與做業調度

　　在多道批處理系統中，做業是用戶提交給系統的一項相對獨立的工做。操做員把用戶提交的做業經過相應的輸入設備輸入到磁盤存儲器，並保存在一個後備做業隊列中。再由做業調度程序將其從外存調入內存。

3.2.1  批處理系統中的做業

　　1. 做業和做業步

　　(1) 做業(Job)。

　　(2) 做業步(Job Step)。

 

　　2. 做業控制塊(Job Control Block，JCB)

爲了管理和調度做業，在多道批處理系統中，爲每一個做業設置了一個做業控制塊JCB，它是做業在系統中存在的標誌，其中保存了系統對做業進行管理和調度所需的所有信息。一般在JCB中包含的內容有：做業標識、用戶名稱、用戶帳號、做業類型(CPU 繁忙型、I/O 繁忙型、批量型、終端型)、做業狀態、調度信息(優先級、做業運行時間)、資源需求(預計運行時間、要求內存大小等)、資源使用狀況等。

 

　　3. 做業運行的三個階段和三種狀態

　　做業從進入系統到運行結束，一般須要經歷收容、運行和完成三個階段。相應的做業也就有「後備狀態」、「運行狀態」和「完成狀態」。

　　(1) 收容階段。

　　(2) 運行階段。　　

　　(3) 完成階段。

 

3.2.2  做業調度的主要任務  

　　做業調度的主要任務是，根據JCB中的信息，檢查系統中的資源可否知足做業對資源的需求，以及按照必定的調度算法，從外存的後備隊列中選取某些做業調入內存，併爲它們建立進程、分配必要的資源。而後再將新建立的進程排在就緒隊列上等待調度。所以，也把做業調度稱爲接納調度(Admission Scheduling)。在每次執行做業調度時，都需作出如下兩個決定。

　　1. 接納多少個做業

　　2. 接納哪些做業

 

3.2.3  先來先服務(FCFS)和短做業優先(SJF)調度算法 

　　1. 先來先服務(first-come first-served，FCFS)調度算法

FCFS是最簡單的調度算法，該算法既可用於做業調度，也可用於進程調度。當在做業調度中採用該算法時，系統將按照做業到達的前後次序來進行調度，或者說它是優先考慮在系統中等待時間最長的做業，而無論該做業所需執行時間的長短，從後備做業隊列中選擇幾個最早進入該隊列的做業，將它們調入內存，爲它們分配資源和建立進程。而後把它放入就緒隊列。

 

　　2. 短做業優先(short job first，SJF)的調度算法

　　因爲在實際狀況中，短做業(進程)佔有很大比例，爲了能使它們能比長做業優先執行，而產生了短做業優先調度算法。

　　1) 短做業優先算法

　　SJF算法是以做業的長短來計算優先級，做業越短，其優先級越高。做業的長短是以做業所要求的運行時間來衡量的。SJF算法能夠分別用於做業調度和進程調度。在把短做業優先調度算法用於做業調度時，它將從外存的做業後備隊列中選擇若干個估計運行時間最短的做業，優先將它們調入內存運行。

　　2) 短做業優先算法的缺點

　　SJF調度算法較之FCFS算法有了明顯的改進，但仍然存在不容忽視的缺點：

　　(1) 必須預知做業的運行時間。在採用這種算法時，要先知道每一個做業的運行時間。即便是程序員也很難準確估計做業的運行時間，若是估計太低，系統就可能按估計的時間終止做業的運行，但此時做業並未完成，故通常都會偏長估計。

　　(2) 對長做業很是不利，長做業的週轉時間會明顯地增加。更嚴重的是，該算法徹底忽視做業的等待時間，可能使做業等待時間過長，出現飢餓現象。

　　(3) 在採用FCFS算法時，人—機沒法實現交互。

　　(4) 該調度算法徹底未考慮做業的緊迫程度，故不能保證緊迫性做業能獲得及時處理。

3.2.4  優先級調度算法和高響應比優先調度算法

　　1. 優先級調度算法(priority-scheduling algorithm，PSA)

　　咱們能夠這樣來看做業的優先級，對於先來先服務調度算法，做業的等待時間就是做業的優先級，等待時間越長，其優先級越高。對於短做業優先調度算法，做業的長短就是做業的優先級，做業所需運行的時間越短，其優先級越高。但上述兩種優先級都不能反映做業的緊迫程度。

　　2. 高響應比優先調度算法(Highest Response Ratio Next，HRRN) 

　　在批處理系統中，FCFS算法所考慮的只是做業的等待時間，而忽視了做業的運行時間。而SJF算法正好與之相反，只考慮做業的運行時間，而忽視了做業的等待時間。高響應比優先調度算法則是既考慮了做業的等待時間，又考慮做業運行時間的調度算法，所以既照顧了短做業，又不導致長做業的等待時間過長，從而改善了處理機調度的性能。

　　高響應比優先算法是如何實現的呢? 若是咱們能爲每一個做業引入一個動態優先級，即優先級是能夠改變的，令它隨等待時間延長而增長，這將使長做業的優先級在等待期間不斷地增長，等到足夠的時間後，必然有機會得到處理機。該優先級的變化規律可描述爲：

 

　　因爲等待時間與服務時間之和就是系統對該做業的響應時間，故該優先級又至關於響應比R_P。據此，優先又可表示爲：

 

3.3  進 程 調 度

　　進程調度是OS中必不可少的一種調度。所以在三種類型的OS中，都無一例外地配置了進程調度。此外它也是對系統性能影響最大的一種處理機調度，相應的，有關進程調度的算法也較多。

3.3.1  進程調度的任務、機制和方式  

　　1. 進程調度的任務

　　進程調度的任務主要有三：

　　(1) 保存處理機的現場信息。

　　(2) 按某種算法選取進程。

　　(3) 把處理器分配給進程。

 

　　2. 進程調度機制

　　爲了實現進程調度，在進程調度機制中，應具備以下三個基本部分，如圖3-1所示。

　　(1) 排隊器。

　　(2) 分派器。

　　(3) 上下文切換器。

 

圖3-1  進程調度機制

 

　　3. 進程調度方式

　　1) 非搶佔方式(Nonpreemptive Mode)

　　在採用這種調度方式時，一旦把處理機分配給某進程後，就一直讓它運行下去，決不會由於時鐘中斷或任何其它緣由去搶佔當前正在運行進程的處理機，直至該進程完成，或發生某事件而被阻塞時，才把處理機分配給其它進程。

 

　　2) 搶佔方式(Preemptive Mode)

　　這種調度方式容許調度程序根據某種原則，去暫停某個正在執行的進程，將已分配給該進程的處理機從新分配給另外一進程。在現代OS中普遍採用搶佔方式，這是由於：對於批處理機系統，能夠防止一個長進程長時間地佔用處理機，以確保處理機能爲全部進程提供更爲公平的服務。在分時系統中，只有採用搶佔方式纔有可能實現人—機交互。在實時系統中，搶佔方式能知足實時任務的需求。但搶佔方式比較複雜，所需付出的系統開銷也較大。

 

3.3.2  輪轉調度算法

　　1. 輪轉法的基本原理

　　在輪轉(RR)法中，系統將全部的就緒進程按FCFS策略排成一個就緒隊列。系統可設置每隔必定時間(如30 s)便產生一次中斷，去激活進程調度程序進行調度，把CPU分配給隊首進程，並令其執行一個時間片。當它運行完畢後，又把處理機分配給就緒隊列中新的隊首進程，也讓它執行一個時間片。這樣，就能夠保證就緒隊列中的全部進程在肯定的時間段內，都能得到一個時間片的處理機時間。

　　2. 進程切換時機

　　在RR調度算法中，應在什麼時候進行進程的切換，可分爲兩種狀況：① 若一個時間片還沒有用完，正在運行的進程便已經完成，就當即激活調度程序，將它從就緒隊列中刪除，再調度就緒隊列中隊首的進程運行，並啓動一個新的時間片。② 在一個時間片用完時，計時器中斷處理程序被激活。若是進程還沒有運行完畢，調度程序將把它送往就緒隊列的末尾。

　　3. 時間片大小的肯定

　　在輪轉算法中，時間片的大小對系統性能有很大的影響。

　　圖3-2示出了時間片大小對響應時間的影響，其中圖(a)是時間片略大於典型交互的時間，而圖(b)是時間片小於典型交互的時間。圖3-3示出了時間片分別爲q =1 和q=4  時對平均週轉時間的影響。

 

圖3-2  時間片大小對響應時間的影響

圖3-3  q =1 和q=4  時進程的週轉時間

 

3.3.3  優先級調度算法

　　1. 優先級調度算法的類型

　　優先級進程調度算法，是把處理機分配給就緒隊列中優先級最高的進程。這時，又可進一步把該算法分紅以下兩種。

　　(1) 非搶佔式優先級調度算法。

　　(2) 搶佔式優先級調度算法。

 

　　2. 優先級的類型

　　1) 靜態優先級

　　靜態優先級是在建立進程時肯定的，在進程的整個運行期間保持不變。優先級是利用某一範圍內的一個整數來表示的，例如0～255中的某一整數，又把該整數稱爲優先數。肯定進程優先級大小的依據有以下三個：

　　(1) 進程類型。

　　(2) 進程對資源的需求。

　　(3) 用戶要求。

　　2) 動態優先級

　　動態優先級是指在建立進程之初，先賦予其一個優先級，而後其值隨進程的推動或等待時間的增長而改變，以便得到更好的調度性能。

 

3.3.4  多隊列調度算法

　　如前所述的各類調度算法，尤爲在應用於進程調度時，因爲系統中僅設置一個進程的就緒隊列，即低級調度算法是固定的、單一的，沒法知足系統中不一樣用戶對進程調度策略的不一樣要求，在多處理機系統中，這種單一調度策略實現機制的缺點更顯突出，由此，多級隊列調度算法可以在必定程度上彌補這一缺點。

 

3.3.5  多級反饋隊列(multileved feedback queue)調度算法 

　　1. 調度機制

　　多級反饋隊列調度算法的調度機制可描述以下：

 

　　(1) 設置多個就緒隊列。

　　圖3-4是多級反饋隊列算法的示意圖。

圖3-4  多級反饋隊列調度算法

 

　　(2) 每一個隊列都採用FCFS算法。當新進程進入內存後，首先將它放入第一隊列的末尾，按FCFS原則等待調度。當輪到該進程執行時，如它能在該時間片內完成，即可撤離系統。不然，即它在一個時間片結束時還沒有完成，調度程序將其轉入第二隊列的末尾等待調度；若是它在第二隊列中運行一個時間片後仍未完成，再依次將它放入第三隊列，……，依此類推。當進程最後被降到第n隊列後，在第n隊列中便採起按RR方式運行。

 

　　(3) 按隊列優先級調度。調度程序首先調度最高優先級隊列中的諸進程運行，僅當第一隊列空閒時才調度第二隊列中的進程運行；換言之，僅當第1～(i-1)全部隊列均空時，纔會調度第i隊列中的進程運行。若是處理機正在第i隊列中爲某進程服務時又有新進程進入任一優先級較高的隊列，此時須當即把正在運行的進程放回到第i隊列的末尾，而把處理機分配給新到的高優先級進程。

 

　　2. 調度算法的性能

　　在多級反饋隊列調度算法中，若是規定第一個隊列的時間片略大於多數人機交互所需之處理時間時，便能較好地知足各類類型用戶的須要。

　　(1) 終端型用戶。

　　(2) 短批處理做業用戶。

　　(3) 長批處理做業用戶。

 

3.3.6  基於公平原則的調度算法  

　　1. 保證調度算法

　　保證調度算法是另一種類型的調度算法，它向用戶所作出的保證並非優先運行，而是明確的性能保證，該算法能夠作到調度的公平性。一種比較容易實現的性能保證是處理機分配的公平性。若是在系統中有n個相同類型的進程同時運行，爲公平起見，須保證每一個進程都得到相同的處理機時間1/n。

　　在實施公平調度算法時系統中必須具備這樣一些功能：

　　(1) 跟蹤計算每一個進程自建立以來已經執行的處理時間。

　　(2) 計算每一個進程應得到的處理機時間，即自建立以來的時間除以n。

　　(3) 計算進程得到處理機時間的比率，即進程實際執行的處理時間和應得到的處理機時間之比。

　　(4) 比較各進程得到處理機時間的比率。如進程A的比率最低，爲0.5，而進程B的比率爲0.8，進程C的比率爲1.2等。

　　(5) 調度程序應選擇比率最小的進程將處理機分配給它，並讓該進程一直運行，直到超過最接近它的進程比率爲止。

 

　　2. 公平分享調度算法

　　分配給每一個進程相同的處理機時間，顯然，這對諸進程而言，是體現了必定程度的公平，但若是各個用戶所擁有的進程數不一樣，就會發生對用戶的不公平問題。

 

3.4  實時調度

　　在實時系統中，可能存在着兩類不一樣性質的實時任務，即HRT任務和SRT任務，它們都聯繫着一個截止時間。爲保證系統能正常工做，實時調度必須能知足實時任務對截止時間的要求。爲此，實現實時調度應具有必定的條件。

 

3.4.1  實現實時調度的基本條件

　　1. 提供必要的信息

　　爲了實現實時調度，系統應向調度程序提供有關任務的信息：

　　(1) 就緒時間，是指某任務成爲就緒狀態的起始時間，在週期任務的狀況下，它是事先預知的一串時間序列。

　　(2) 開始截止時間和完成截止時間，對於典型的實時應用，只須知道開始截止時間，或者完成截止時間。

　　(3) 處理時間，一個任務從開始執行，直至完成時所需的時間。

　　(4) 資源要求，任務執行時所需的一組資源。

　　(5) 優先級，若是某任務的開始截止時間錯過，勢必引發故障，則應爲該任務賦予「絕對」優先級；若是其開始截止時間的錯過，對任務的繼續運行無重大影響，則可爲其賦予「相對」優先級，供調度程序參考。

 

　　2. 系統處理能力強

　　在實時系統中，若處理機的處理能力不夠強，則有可能因處理機忙不過，而導致某些實時任務不能獲得及時處理，從而致使發生難以預料的後果。假定系統中有m個週期性的硬實時任務HRT，它們的處理時間可表示爲Ci，週期時間表示爲Pi，則在單處理機狀況下，必須知足下面的限制條件系統纔是可調度的：

 

　　提升系統處理能力的途徑有二：一是採用單處理機系統，但須加強其處理能力，以顯著地減小對每個任務的處理時間；二是採用多處理機系統。假定系統中的處理機數爲N，則應將上述的限制條件改成：

 

 

　　3. 採用搶佔式調度機制

　　在含有HRT任務的實時系統中，普遍採用搶佔機制。這樣即可知足HRT任務對截止時間的要求。但這種調度機制比較複雜。

　　4. 具備快速切換機制

　　爲保證硬實時任務能及時運行，在系統中還應具備快速切換機制，使之能進行任務的快速切換。該機制應具備以下兩方面的能力：

　　(1) 對中斷的快速響應能力。對緊迫的外部事件請求中斷能及時響應，要求系統具備快速硬件中斷機構，還應使禁止中斷的時間間隔儘可能短，以避免耽誤時機(其它緊迫任務)。

　　(2) 快速的任務分派能力。爲了提升分派程序進行任務切換時的速度，應使系統中的每一個運行功能單位適當的小，以減小任務切換的時間開銷。

 

3.4.2  實時調度算法的分類     

　　能夠按不一樣方式對實時調度算法加以分類：① 根據實時任務性質，可將實時調度的算法分爲硬實時調度算法和軟實時調度算法；② 按調度方式，則可分爲非搶佔調度算法和搶佔調度算法。

　　1. 非搶佔式調度算法

　　(1) 非搶佔式輪轉調度算法。

　　(2) 非搶佔式優先調度算法。

 

　　2. 搶佔式調度算法

　　可根據搶佔發生時間的不一樣而進一步分紅如下兩種調度算法：

　　(1) 基於時鐘中斷的搶佔式優先級調度算法。

　　(2) 當即搶佔(Immediate Preemption)的優先級調度算法。　　

　　圖3-5中的(a)、(b)、(c)、(d)分別示出了四種狀況的調度時間。

圖3-5  實時進程調度

 

 

3.4.3  最先截止時間優先EDF(Earliest Deadline First)算法 

　　1. 非搶佔式調度方式用於非週期實時任務

　　圖3-6示出了將該算法用於非搶佔調度方式之例。

圖3-6　EDF算法用於非搶佔調度方式

 

　　2. 搶佔式調度方式用於週期實時任務

　　圖3-7示出了將該算法用於搶佔調度方式之例。在該例中有兩個週期任務，任務A和任務B的週期時間分別爲20 ms和50 ms，每一個週期的處理時間分別爲10 s和25 s。

圖3-7  最先截止時間優先算法用於搶佔調度方式之例

 

3.4.4  最低鬆弛度優先LLF(Least Laxity First)算法

　　該算法在肯定任務的優先級時，根據的是任務的緊急(或鬆弛)程度。任務緊急程度愈高，賦予該任務的優先級就愈高，以使之優先執行。

　　該算法主要用於可搶佔調度方式中。假如在一個實時系統中有兩個週期性實時任務A和B，任務A要求每20 s執行一次，執行時間爲10 s，任務B要求每50 s執行一次，執行時間爲25 s。由此可知，任務A和B每次必須完成的時間分別爲：A一、A二、A三、…和B一、B二、B三、…，見圖3-8。

圖3-8  A和B任務每次必須完成的時間

圖3-9示出了具備兩個週期性實時任務的調度狀況。

圖3-9  利用ELLF算法進行調度的狀況

 

3.4.5  優先級倒置(priority inversion problem)  

　　1. 優先級倒置的造成

　　當前OS普遍採用優先級調度算法和搶佔方式，然而在系統中存在着影響進程運行的資源而可能產生「優先級倒置」的現象，即高優先級進程(或線程)被低優先級進程(或線程)延遲或阻塞。咱們經過一個例子來講明該問題。

　　假如P3最早執行，在執行了P(mutex)操做後，進入到臨界區CS-3。在時刻a，P2就緒，由於它比P3的優先級高，P2搶佔了P3的處理機而運行，如圖3-10所示。

 

圖3-10  優先級倒置示意圖

 

　　2. 優先級倒置的解決方法

　　一種簡單的解決方法是規定：假如進程P3在進入臨界區後P3所佔用的處理機就不容許被搶佔。

　　圖3-11示出了採用動態優先級繼承方法後，P一、P二、P3三個進程的運行狀況。

 

圖3-11   採用了動態優先級繼承方法的運行狀況

 

 

3.5  死 鎖 概 述

3.5.1  資源問題

　　在系統中有許多不一樣類型的資源，其中能夠引發死鎖的主要是，須要採用互斥訪問方法的、不能夠被搶佔的資源，即在前面介紹的臨界資源。系統中這類資源有不少，如打印機、數據文件、隊列、信號量等。

　　1. 可重用性資源和消耗性資源

　　1) 可重用性資源

　　可重用性資源是一種可供用戶重複使用屢次的資源，它具備以下性質：

　　(1) 每個可重用性資源中的單元只能分配給一個進程使用，不容許多個進程共享。

　　(2) 進程在使用可重用性資源時，須按照這樣的順序：① 請求資源。若是請求資源失敗，請求進程將會被阻塞或循環等待。② 使用資源。進程對資源進行操做，如用打印機進行打印；③ 釋放資源。當進程使用完後本身釋放資源。

　　(3) 系統中每一類可重用性資源中的單元數目是相對固定的，進程在運行期間既不能建立也不能刪除它。

 

　　2) 可消耗性資源

　　可消耗性資源又稱爲臨時性資源，它是在進程運行期間，由進程動態地建立和消耗的，它具備以下性質：

① 每一類可消耗性資源的單元數目在進程運行期間是能夠不斷變化的，有時它能夠有許多，有時可能爲0；

② 進程在運行過程當中，能夠不斷地創造可消耗性資源的單元，將它們放入該資源類的緩衝區中，以增長該資源類的單元數目。

③ 進程在運行過程當中，能夠請求若干個可消耗性資源單元，用於進程本身的消耗，再也不將它們返回給該資源類中。

 

　　2. 可搶佔性資源和不可搶佔性資源

　　1) 可搶佔性資源

　　可把系統中的資源分紅兩類，一類是可搶佔性資源，是指某進程在得到這類資源後，該資源能夠再被其它進程或系統搶佔。

　　2) 不可搶佔性資源

　　另外一類資源是不可搶佔性資源，即一旦系統把某資源分配給該進程後，就不能將它強行收回，只能在進程用完後自行釋放。

 

3.5.2  計算機系統中的死鎖

　　1. 競爭不可搶佔性資源引發死鎖

　　一般系統中所擁有的不可搶佔性資源其數量不足以知足多個進程運行的須要，使得進程在運行過程當中，會因爭奪資源而陷入僵局。

　　咱們可將上面的問題利用資源分配圖進行描述，用方塊表明可重用的資源(文件)，用圓圈表明進程，見圖3-12所示。

 

圖3-12　共享文件時的死鎖狀況

 

　　2. 競爭可消耗資源引發死鎖

　　如今進一步介紹競爭可消耗資源所引發的死鎖。圖3-13示出了在三個進程之間，在利用消息通訊機制進行通訊時所造成的死鎖狀況。

 圖3-13  進程之間通訊時的死鎖

 

　　3. 進程推動順序不當引發死鎖

　　除了系統中多個進程對資源的競爭會引起死鎖外，進程在運行過程當中，對資源進行申請和釋放的順序是否合法，也是在系統中是否會產生死鎖的一個重要因素。

　　1) 進程推動順序合法

　　在進程P1和P2併發執行時，若是按圖3-14中的曲線①所示的順序推動：P1：Request(R1)→P1：Request(R2)→P1：Releast(R1)→P1：Release(R2)→P2：Request(R2)→P2：Request(R1)→P2：Release(R2)→P2：Release(R1)，兩個進程可順利完成。相似地，若按圖中曲線②和③所示的順序推動，兩進程也能夠順利完成。咱們稱這種不會引發進程死鎖的推動順序是合法的。

　　2) 進程推動順序非法

　　若併發進程P1和P2按圖3-14中曲線④所示的順序推動，它們將進入不安全區D內。此時P1保持了資源R1，P2保持了資源R2，系統處於不安全狀態。此刻，若是兩個進程繼續向前推動，就可能發生死鎖。例如，當P1運行到P1：Request(R2)時，將因R2已被P2佔用而阻塞；當P2運行到P2：Request(R1)時，也將因R1已被P1佔用而阻塞，因而發生了進程死鎖，這樣的進程推動順序就是非法的。

 

圖3-14　進程推動順序對死鎖的影響

 

3.5.3  死鎖的定義、必要條件和處理方法    

　　1. 死鎖的定義

　　在一組進程發生死鎖的狀況下，這組死鎖進程中的每個進程，都在等待另外一個死鎖進程所佔有的資源。

 

　　2. 產生死鎖的必要條件

　　雖然進程在運行過程當中可能會發生死鎖，但產生進程死鎖是必須具有必定條件的。綜上所述不難看出，產生死鎖必須同時具有下面四個必要條件，只要其中任一個條件不成立，死鎖就不會發生：

　　(1) 互斥條件。

　　(2) 請求和保持條件。

　　(3) 不可搶佔條件。

　　(4) 循環等待條件。

 

　　3. 處理死鎖的方法

　　目前處理死鎖的方法可歸結爲四種：

　　(1) 預防死鎖。

　　(2) 避免死鎖。

　　(3) 檢測死鎖。

　　(4) 解除死鎖。

 

3.6  預防死鎖

　　預防死鎖的方法是經過破壞產生死鎖的四個必要條件中的一個或幾個，以免發生死鎖。因爲互斥條件是非共享設備所必須的，不只不能改變，還應加以保證，所以主要是破壞產生死鎖的後三個條件。

 

3.6.1  破壞「請求和保持」條件 

　　爲了能破壞「請求和保持」條件，系統必須保證作到：當一個進程在請求資源時，它不能持有不可搶佔資源。該保證可經過以下兩個不一樣的協議實現：

　　1. 第一種協議

　　該協議規定，全部進程在開始運行以前，必須一次性地申請其在整個運行過程當中所需的所有資源。

　　2. 第二種協議

　　該協議是對第一種協議的改進，它容許一個進程只得到運行初期所需的資源後，便開始運行。

 

3.6.2  破壞「不可搶佔」條件 

　　爲了能破壞「不可搶佔」條件，協議中規定，當一個已經保持了某些不可被搶佔資源的進程，提出新的資源請求而不能獲得知足時，它必須釋放已經保持的全部資源，待之後須要時再從新申請。這意味着進程已佔有的資源會被暫時地釋放，或者說是被搶佔了，從而破壞了「不可搶佔」條件。

 

3.6.3  破壞「循環等待」條件     

　　一個能保證「循環等待」條件不成立的方法是，對系統全部資源類型進行線性排序，並賦予不一樣的序號。

 

3.7 避免死鎖

　　避免死鎖一樣是屬於事先預防的策略，但並非事先採起某種限制措施，破壞產生死鎖的必要條件，而是在資源動態分配過程當中，防止系統進入不安全狀態，以免發生死鎖。這種方法所施加的限制條件較弱，可能得到較好的系統性能，目前經常使用此方法來避免發生死鎖。

 

3.7.1　系統安全狀態

　　在死鎖避免方法中，把系統的狀態分爲安全狀態和不安全狀態。當系統處於安全狀態時，可避免發生死鎖。反之，當系統處於不安全狀態時，則可能進入到死鎖狀態。

　　1. 安全狀態

　　在該方法中，容許進程動態地申請資源，但系統在進行資源分配以前，應先計算這次資源分配的安全性。

 

　　2. 安全狀態之例

　　假定系統中有三個進程P一、P2和P3，共有12臺磁帶機。進程P1總共要求10臺磁帶機，P2和P3分別要求4臺和9臺。假設在T0時刻，進程P一、P2和P3已分別得到5臺、2臺和2臺磁帶機，尚有3臺空閒未分配，以下表所示：

 

　　3. 由安全狀態向不安全狀態的轉換

　　若是不按照安全序列分配資源，則系統可能會由安全狀態進入不安全狀態。

 

3.7.2  利用銀行家算法避免死鎖

　　最有表明性的避免死鎖的算法是Dijkstra的銀行家算法。起這樣的名字是因爲該算法本來是爲銀行系統設計的，以確保銀行在發放現金貸款時，不會發生不能知足全部客戶須要的狀況。在OS中也可用它來實現避免死鎖。

 

　　1. 銀行家算法中的數據結構

　　爲了實現銀行家算法，在系統中必須設置這樣四個數據結構，分別用來描述系統中可利用的資源、全部進程對資源的最大需求、系統中的資源分配，以及全部進程還須要多少資源的狀況。

　　(1) 可利用資源向量Available。

　　(2) 最大需求矩陣Max。

　　(3) 分配矩陣Allocation。

　　(4) 需求矩陣Need。

 

　　2. 銀行家算法

　　設Requesti是進程Pi的請求向量，若是Request [j]=K，表示進程Pi須要K個Rj類型的資源。當Pi發出資源請求後，系統按下述步驟進行檢查：

　　(1) 若是Request [j]≤Need[i, j]，便轉向步驟(2)； 不然認爲出錯，由於它所須要的資源數已超過它所宣佈的最大值。

　　(2) 若是Request [j]≤Available[j]，便轉向步驟(3)； 不然，表示尚無足夠資源，Pi須等待。

　　(3) 系統試探着把資源分配給進程Pi，並修改下面數據結構中的數值：

      　Available[j] = Available[j]  equest [j];

　  　Allocation[i, j] = Allocation[i, j]  equest [j];

  　　Need[i, j] = Need[i, j]  equest [j];

　　(4) 系統執行安全性算法，檢查這次資源分配後系統是否處於安全狀態。若安全，才正式將資源分配給進程Pi，以完成本次分配；不然，將本次的試探分配做廢，恢復原來的資源分配狀態，讓進程Pi等待。

 

　　3. 安全性算法

　　系統所執行的安全性算法可描述以下：

　　(1) 設置兩個向量：① 工做向量Work，它表示系統可提供給進程繼續運行所需的各種資源數目，它含有m個元素，在執行安全算法開始時，Work := Available；② Finish：它表示系統是否有足夠的資源分配給進程，使之運行完成。開始時先作Finish[i] := false；當有足夠資源分配給進程時，再令Finish[i] := true。

　　(2) 從進程集合中找到一個能知足下述條件的進程：

　　① Finish[i]=false;

　　② Need[i, j]≤Work[j];

　　若找到，執行步驟(3)，不然，執行步驟(4)。

　　(3) 當進程Pi得到資源後，可順利執行，直至完成，並釋放出分配給它的資源，故應執行：

　　　　Work[j] = Work[j]+Allocation[i, j];

　　　　Finish[i] =true;

　　　　go to step 2;

　　(4) 若是全部進程的Finish[i]=true都知足，則表示系統處於安全狀態；不然，系統處於不安全狀態。

 

　　4. 銀行家算法之例

　　假定系統中有五個進程{P0, P1, P2, P3, P4}和三類資源{A, B, C}，各類資源的數量分別爲十、五、7，在T0時刻的資源分配狀況如圖3-15所示。

圖3-15  T0時刻的資源分配表

　　(1)  0時刻的安全性：利用安全性算法對T0時刻的資源分配狀況進行分析(如圖3-16所示)可知，在T0時刻存在着一個安全序列{P1, P3, P4, P2, P0}，故系統是安全的。

圖3-16  T0時刻的安全序列

　　(2)  1請求資源：P1發出請求向量Request1(1, 0, 2)，系統按銀行家算法進行檢查：

　　① Request1(1, 0, 2)≤Need1(1, 2, 2)；

　　② Request1(1, 0, 2)≤Available1(3, 3, 2)；

　　③ 系統先假定可爲P1分配資源，並修改Available，Allocation1和Need1向量，由此造成的資源變化狀況如圖3-15中的圓括號所示；

　　④ 再利用安全性算法檢查此時系統是否安全，如圖3-17所示。

圖3-17  P1申請資源時的安全性檢查

　　(3)  4請求資源：P4發出請求向量Request4(3，3，0)，系統按銀行家算法進行檢查：

　　① Request4(3，3，0)≤Need4(4，3，1)；

　　② Request4(3，3，0)＞Available(2，3，0)，讓P4等待。

　　(4)  0請求資源：P0發出請求向量Request0(0，2，0)，系統按銀行家算法進行檢查：

　　① Request0(0，2，0)≤Need0(7，4，3)；

　　② Request0(0，2，0)≤Available(2，3，0)；

　　③ 系統暫時先假定可爲P0分配資源，並修改有關數據，如圖3-18所示。

圖3-18  爲P0分配資源後的有關資源數據

　　(5) 進行安全性檢查：可用資源Available(2，1，0)已不能知足任何進程的須要，故系統進入不安全狀態，此時系統不分配資源。

 

3.8  死鎖的檢測與解除

　　若是在系統中，既不採起死鎖預防措施，也未配有死鎖避免算法，系統極可能會發生死鎖。在這種狀況下，系統應當提供兩個算法：

　　① 死鎖檢測算法。該方法用於檢測系統狀態，以肯定系統中是否發生了死鎖。

　　② 死鎖解除算法。當認定系統中已發生了死鎖，利用該算法可將系統從死鎖狀態中解脫出來。

 

3.8.1  死鎖的檢測

　　爲了能對系統中是否已發生了死鎖進行檢測，在系統中必須：

① 保存有關資源的請求和分配信息；

② 提供一種算法，它利用這些信息來檢測系統是否已進入死鎖狀態。

 

　　1. 資源分配圖(Resource Allocation Graph)

　　系統死鎖，可利用資源分配圖來描述。

　　該圖是由一組結點N和一組邊E所組成的一個對偶G  N, E)，它具備下述形式的定義和限制：

　　(1) 把N分爲兩個互斥的子集，即一組進程結點P={P1, P2, …, Pn}和一組資源結點R={R1, R2, …, Rn}，N  ∪R。在圖3-19所示的例子中，P  P1, P2}，R  R1, R2}，N  R1, R2}∪{P1, P2}。

　　(2) 凡屬於E中的一個邊e∈E，都鏈接着P中的一個結點和R中的一個結點，e  Pi, Rj}是資源請求邊，由進程Pi指向資源Rj，它表示進程Pi請求一個單位的Rj資源。E  Rj, Pi}是資源分配邊，由資源Rj指向進程Pi，它表示把一個單位的資源Rj分配給進程Pi。圖3-19中示出了兩個請求邊和兩個分配邊，即E  (P1, R2), (R2, P2), (P2, R1), (R1, P1)}。

圖3-19  每類資源有多個時的狀況

 

　　2．死鎖定理

　　咱們能夠利用把資源分配圖加以簡化的方法(圖3-19)，來檢測當系統處於S狀態時，是否爲死鎖狀態。簡化方法以下：

　　(1) 在資源分配圖中，找出一個既不阻塞又非獨立的進程結點Pi。在順利的狀況下，Pi可得到所需資源而繼續運行，直至運行完畢，再釋放其所佔有的所有資源，這至關於消去Pi的請求邊和分配邊，使之成爲孤立的結點。在圖3-20(a)中，將P1的兩個分配邊和一個請求邊消去，便造成圖(b)所示的狀況。

圖3-20  資源分配圖的簡化

 

　　(2)  1釋放資源後，即可使P2得到資源而繼續運行，直至P2完成後又釋放出它所佔有的所有資源，造成圖(c)所示的狀況，即將P2的兩條請求邊和一條分配邊消去。

 

　　(3) 在進行一系列的簡化後，若能消去圖中全部的邊，使全部的進程結點都成爲孤立結點，則稱該圖是可徹底簡化的；若不能經過任何過程使該圖徹底簡化，則稱該圖是不可徹底簡化的。

 

　　3．死鎖檢測中的數據結構

　　死鎖檢測中的數據結構相似於銀行家算法中的數據結構：

　　(1) 可利用資源向量Available，它表示了m類資源中每一類資源的可用數目。

　　(2) 把不佔用資源的進程(向量Allocation=0)記入L表中，即Li∪L。

　　(3) 從進程集合中找到一個Requesti≤Work的進程，作以下處理：① 將其資源分配圖簡化，釋放出資源，增長工做向量Work =Work + Allocation i。② 將它記入L表中。

　　(4) 若不能把全部進程都記入L表中，便代表系統狀態S的資源分配圖是不可徹底簡化的。所以，該系統狀態將發生死鎖。

 

3.8.2  死鎖的解除

　　1. 終止進程的方法

　　1) 終止全部死鎖進程

　　這是一種最簡單的方法，便是終止全部的死鎖進程，死鎖天然也就解除了，但所付出的代價可能會很大。由於其中有些進程可能已經運行了很長時間，已接近結束，一旦被終止真可謂「功虧一簣」，之後還得從頭再來。還可能會有其它方面的代價，在此再也不一一列舉。

　　2) 逐個終止進程

　　稍微溫和的方法是，按照某種順序，逐個地終止進程，直至有足夠的資源，以打破循環等待，把系統從死鎖狀態解脫出來爲止。但該方法所付出的代價也可能很大。由於每終止一個進程，都須要用死鎖檢測算法肯定系統死鎖是否已經被解除，若未解除還需再終止另外一個進程。另外，在採起逐個終止進程策略時，還涉及到應採用什麼策略選擇一個要終止的進程。選擇策略最主要的依據是，爲死鎖解除所付出的「代價最小」。但怎麼樣纔算是「代價最小」，很難有一個精確的度量。

 

　　2. 付出代價最小的死鎖解除算法

　　一種付出代價最小的死鎖解除算法如圖3-21所示。

圖3-21  付出代價最小的死鎖解除算法

 

 

習題 8:

　　1. 高級調度與低級調度的主要任務是什麼? 爲何要引入中級調度?

　　2. 處理機調度算法的共同目標是什麼? 批處理系統的調度目標又是什麼?

　　3. 何謂做業、做業步和做業流?

　　4. 在什麼狀況下須要使用做業控制塊JCB，其中包含了哪些內容?

　　5. 在做業調度中應如何肯定接納多少個做業和接納哪些做業?

　　6. 爲何要引入高響應比優先調度算法? 它有何優勢?

　　7. 試說明低級調度的主要功能。

　　8. 在搶佔調度方式中，搶佔的原則是什麼?

　　9. 在選擇調度方式和調度算法時，應遵循的準則是什麼?

　　10. 在批處理系統、分時系統和實時系統中，各採用哪幾種進程(做業)調度算法?

　　11. 何謂靜態和動態優先級? 肯定靜態優先級的依據是什麼?

　　12. 試比較FCFS和SJF兩種進程調度算法。

　　13. 在時間片輪轉法中，應如何肯定時間片的大小?

　　14. 經過一個例子來講明一般的優先級調度算法爲何不能適用於實時系統?

　　15. 爲何說多級反饋隊列調度算法能較好地知足各方面用戶的須要?

　　16. 爲何說傳統的幾種調度算法都不能算是公平調度算法?

　　17. 保證調度算法是如何作到調度的公平性的?

　　18. 公平分享調度算法又是如何作到調度的公平性的?

　　19. 爲何在實時系統中，要求系統(尤爲是CPU)具備較強的處理能力?

　　20. 按調度方式可將實時調度算法分爲哪幾種?

　　21. 什麼是最先截止時間優先調度算法? 舉例說明之。

　　22. 什麼是最低鬆弛度優先調度算法? 舉例說明之。

　　23. 何謂「優先級倒置」現象，可採起什麼方法來解決?

　　24. 試分別說明可重用資源和可消耗資源的性質。

　　25. 試舉例說明競爭不可搶佔資源所引發的死鎖。

　　26. 爲了破壞「請求和保持」條件而提出了兩種協議，試比較這兩種協議。

　　27. 何謂死鎖? 產生死鎖的緣由和必要條件是什麼?

　　28. 在解決死鎖問題的幾個方法中，哪一種方法最易於實現? 哪一種方法使資源利用率最高?

　　29. 請詳細說明可經過哪些途徑預防死鎖。

　　30. 在銀行家算法的例子中，若是P0發出的請求向量由Request(0, 2, 0)改成Request(0, 1, 0)，問系統能否將資源分配給它?

　　31. 在銀行家算法中，若出現下述資源分配狀況，試問：

　　(1) 該狀態是否安全?

　　(2) 若進程P2提出請求Request(1, 2, 2, 2)後，系統可否將資源分配給它?