1. 程式人生 > 其它 >計算機作業系統 慕課版 第3章 處理機排程與死鎖

計算機作業系統 慕課版 第3章 處理機排程與死鎖

目錄

第三章 處理機排程與死鎖

在多道程式系統中,一個作業從提交到執行, 通常都要經過多級排程,而系統執行的效能在很大程度上取決於排程,因此排程便成為作業系統設計的一箇中心問題之一。

3.1、 處理機排程概述

3.1.1、 處理機排程的層次

1、高階排程--作業排程,長程排程

作業排程的主要功能是根據作業控制塊中的資訊, 審查系統能否滿足使用者作業的資源需求,以及按照一定的演算法,從外存的後備佇列中選取某些作業調入內 存,併為它們建立程序、分配必要的資源。然後再將新建立的程序插入就緒佇列,準備執行。因此,有時也把作業排程稱為接納排程

(Admission Scheduling)。

2、 低階排程

低階排程的功能---程序排程,短程排程

(1)儲存處理機的現場資訊

(2)按某種演算法選取程序

(3)把處理機分配給程序

3、中級排程---交換排程

1、目的:提高記憶體利用率和系統吞吐量。

2、方法:

(1)將暫時不能執行的程序調至外存上去等待, 此時程序狀態為:就緒駐外存狀態或掛起狀態。

(2)再次滿足執行條件時,由中級排程把外存上 的具備執行條件的程序,調入記憶體,掛在就緒佇列上等待程序排程

3.1.2、作業與作業排程

1 、作業

(1) 作業(Job)。作業是一個比程式更為廣泛的概念,它不僅包含了通常的程式和資料,而且還應配有一份作業說明書, 系統根據該說明書來對程式的執行進行控制。在批處理系統 中,是以作業為基本單位從外存調入記憶體的。

(2) 作業步(Job Step)。通常,在作業執行期間,每個作業都必須經過若干個相對獨立,又相互關聯的順序加工步 驟才能得到結果,我們把其中的每一個加工步驟稱為一個作業步,各作業步之間存在著相互聯絡,往往是把上一個作業 步的輸出作為下一個作業步的輸入。

例如,一個典型的作業 可分成三個作業步:① “編譯”作業步,通過執行編譯程式 對源程式進行編譯,產生若干個目標程式段;② “連結裝配” 作業步,將“編譯”作業步所產生的若干個目標程式段裝配 成可執行的目標程式;③ “執行”作業步,將可執行的目標程式讀入記憶體並控制其執行。

(3)作業流。若干個作業進入系統後,被依次存放在外存 上,這便形成了輸入的作業流;在作業系統的控制下,逐個 作業進行處理,於是便形成了處理作業流。

2、作業控制塊JCB

為了管理和排程作業,在多道批處理系統中為每個作業設定了一個作業控制塊,如同程序控制塊是程序在系統中存 在的標誌一樣,它是作業在系統中存在的標誌,其中儲存了 系統對作業進行管理和排程所需的全部資訊。

在JCB中所包含 的內容因系統而異,通常應包含的內容有:作業標識、使用者 名稱、使用者帳戶、作業型別(CPU 繁忙型、I/O 繁忙型、批量 型、終端型)、作業狀態、排程資訊(優先順序、作業已執行時 間)、資源需求(預計執行時間、要求記憶體大小、要求I/O裝置 的型別和數量等)、進入系統時間、開始處理時間、作業完成時間、作業退出時間、資源使用情況等。

每當作業進入系統時,系統便為每個作業建立一個JCB, 根據作業型別將它插入相應的後備佇列中。作業排程程式依 據一定的排程演算法來排程它們,被排程到的作業將會裝入內 存。在作業執行期間,系統就按照JCB中的資訊對作業進行 控制。當一個作業執行結束進入完成狀態時,系統負責回收分配給它的資源,撤消它的作業控制塊。

3、作業執行的三個階段和三個狀態

4、作業排程的任務

  1. 接納多少個作業
  2. 接納哪些作業

對使用者而言,總希望自己作業的週轉時間儘可能的少, 最好週轉時間就等於作業的執行時間。然而對系統來說,則希望作業的平均週轉時間儘可能少,有利於提高CPU 的利用率和系統的吞吐量。為此,每個系統在選擇作業排程演算法時, 既應考慮使用者的要求,又能確保系統具有較高的效率。在每次執行作業排程時,都須做出以下兩個決定。

1) 決定接納多少個作業作業排程每次要接納多少個作業進入記憶體,取決於多道 程式度(Degree of Multiprogramming),即允許多少個作業同時 在記憶體中執行。當記憶體中同時執行的作業數目太多時,可能 會影響到系統的服務質量,比如,使週轉時間太長。但如果 在記憶體中同時執行作業的數量太少時,又會導致系統的資源 利用率和系統吞吐量太低,因此,多道程式度的確定應根據 系統的規模和執行速度等情況做適當的折中。

2)決定接納哪些作業 應將哪些作業從外存調入記憶體,這將取決於所採用的排程演算法。最簡單的是先來先服務排程演算法,這是指將最早進 入外存的作業最先調入記憶體;較常用的一種演算法是短作業優先排程演算法,是將外存上最短的作業最先調入記憶體;另一種 較常用的是基於作業優先順序的排程演算法,該演算法是將外存上 優先順序最高的作業優先調入記憶體;比較好的一種演算法是“響 應比高者優先”的排程演算法。我們將在後面對上述幾種演算法 作較為詳細的介紹。

在批處理系統中,作業進入系統後,總是先駐留在外存的後備佇列上,因此需要有作業排程的過程,以便將它們分批地裝入記憶體。然而在分時系統中,為了做到及時響應,用 戶通過鍵盤輸入的命令或資料等都是被直接送入記憶體的,因 而無需再配置上述的作業排程機制,但也需要有某些限制性措施來限制進入系統的使用者數。即,如果系統尚未飽和,將接納所有授權使用者,否則,將拒絕接納。類似地,在實時系統中通常也不需要作業排程。

3.1.3、程序排程

1、低階排程的任務

(1)儲存處理機的現場資訊

(2)按某種演算法選取程序

(3)把處理機分配給程序

2、程序排程的三個基本機制

(1)排隊器(程序佇列);

(2)分派器(分派程式)(排程程式)

(3)上下文切換機制(環境資訊切換)

3、程序排程的方式

(1)非搶佔方式(Non-preemptive Mode)

引發排程的事件:

① 正在執行的程序執行完畢;

② 發生某事件而不能再繼續執行;

③ 執行中的程序因提出I/O請求而暫停執行;

④ 執行了某種原語操作。

特點:實現簡單、系統開銷小,適用於大多數的批 處理系統環境,難以滿足緊急任務的要求。

(2) 搶佔方式 (Preemptive Mode)

搶佔的原則:

(1) 優先權原則

(2) 短作業(程序)優先原則

(3) 時間片原則

3.1.4、處理機排程演算法的目標

1、處理機排程演算法的共同目標

(1) 資源利用率

(2) 公平性

(3) 平衡性

(4) 策略強制執行

2、批處理系統的目標

(1)週轉時間:從作業提 交給系統開始,到作業完成這 段時間間隔。

3、分時系統的目標

1)響應時間快

2)均衡性

4、實時系統的目標

1)截止時間的保證

2)可預測性

3.2、排程演算法

3.3.1、先來先服務和短作業(程序)優先排程演算法

1、先來先服務排程演算法(FCFS)

2、短作業(程序)優先排程演算法(SJF / SPF)

SJF/SPF演算法的缺點:

(1) 對長作業(程序)不利。排程程式總是優先調 度那些(即使是後進來的)短作業(程序),可能使 長作業(程序)長期不被排程。

(2) 未考慮作業(程序)的緊迫程度。不能保證緊 迫性作業(程序)被及時處理。

(3) 作業(程序)的長短沒有客觀標準。可能有失 公平,損害演算法初衷。

3.2.3、優先順序排程演算法

1、優先權排程演算法的型別

(1)非搶佔式優先權演算法

主要用於批處理系統中;

(2) 搶佔式優先權排程演算法

能更好地滿足緊迫作業的要求,常用於要求比較嚴格的實時系統中, 以及對效能要求較高的批處理系統 和分時系統中。

2、優先權的型別

(1)靜態優先權

優先權是在建立程序時確定,在程序的整個執行期間 保持不變。

優先權的確定依據:程序型別,程序對資源的需求, 使用者要求。

(2) 動態優先權

動態優先權是指,在建立程序時所賦予的優先權,是 可以隨程序的推進或隨其等待時間的增加而改變的,以便 獲得更好的排程效能。

3、高響應比優先排程演算法

(2)高響應比優先排程演算法優點:

*等待時間相同,要求服務的時間愈短,優先權愈高,演算法有利於短作業。

*要求服務的時間相同,等待時間愈長,其優先權愈高,實現了先來先服務。

*長作業優先順序隨等待時間的增加而提高,最終也可獲得處理機,確保了長作業的執行。

3.2.4、基於時間片的輪轉排程演算法

1、 時間片輪轉法基本原理

(1)把CPU按時間片分配給程序,程序按時間片 大小輪流執行。

(2)保證就緒佇列中的所有程序,在一給定的時 間內,均能獲得一時間片的處理機執行時間。(響應 時間)

(3)時間片的大小從幾ms到幾百ms.

2、程序切換時機

(1)若一個時間片尚未用完,正在執行的程序已經完成,則排程啟用程式,將已經完成的程序從就緒佇列中刪除,再排程就緒佇列中隊首程序執行,並啟動一個新的時間片。

(2)當一個時間片用完,計時器中斷處理程式被啟用。此時,若程序尚未執行完成,排程程式把它送到就緒佇列末尾。

3、 時間片大小確定

3.2.5、多級佇列排程演算法

在程序容易分成不同組的情況下,可以有另一類排程演算法。例如, 程序通常分為前臺程序(或互動程序)和後臺程序(或批處理程序)。 這兩種型別的程序具有不同的響應時間要求,進而也有不同調度需要。 另外,與後臺程序相比,前臺程序可能要有更高的優先順序(外部定 義)。多級佇列排程演算法將就緒佇列分成多個單獨佇列根據程序屬性, 如記憶體大小、程序優先順序、程序型別等,一個程序永久分到一個佇列, 每個佇列有自己的排程演算法。

3.2.6、多級反饋佇列排程演算法

3.3.7、基於公平原則的排程演算法

1、 保證排程演算法

2、公平分享排程演算法

3.3、實 時 調 度

不做要求

3.5、死鎖概述

3.5.1、資源問題

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

1)可重用性資源

2)可消耗性資源

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

1)可搶佔性資源

2)不可搶佔性資源

3.5.2、計算機系統中的死鎖

死鎖: 指多個程序因競爭資源而造成的一種僵局,若無外力作用,這些程序都將永遠不能再向前推進。

產生死鎖的原因:

  1. 競爭資源
  2. 程序間推進順序非法

1、競爭不可搶佔性資源引起程序死鎖

2 、競爭可消耗性資源

3、程序推進順序不當引起的死鎖

當程序P1、P2共享資源A、B時,若推進順序合法則不會產生死鎖, 否則會產生死鎖。

合法的推進路線:①②③ 不合法的推進線路:④

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

1、死鎖的定義

如果系統中的每一個程序都在等待僅由該組進 程中的其他程序才能引發的事件,那麼該組程序就是死鎖的。

2、 產生死鎖的必要條件

(1) 互斥條件

(2) 請求和保持條件

(3) 不剝奪條件

(4) 環路等待條件

3、處理死鎖的基本方法

(1) 預防死鎖

(2) 避免死鎖

(3) 檢測死鎖

(4) 解除死鎖

3.5.4、資源分配圖

3.6、預防死鎖的方法

3.6.1、破壞“請求和保持”條件

1、第一種協議

系統要求所有程序要一次性地申請在整個執行過程所需要的全部資源。

摒棄請求條件:程序在整個執行期間,不再提 出資源要求。

摒棄保持條件:等待期間程序不佔有任何資源。

優點:簡單、易於實現、且安全。

缺點: (1)資源嚴重浪費 (2)程序延遲執行

2、第二種協議

思想:允許一個程序只獲得執行初期所需的資源後,便開始執行。程序執行過程中再逐步釋放已分配給自己、且已用完的全部資源,然後再請求新的所需資源。

3.6.2、摒棄“不可搶佔”條件

思想:允許程序還未執行完成時釋放已經佔有的資源。

方法:

  1. 如果得不到滿足,則先釋放所佔有的所有資源。
  2. 高優先順序的程序優先請求相同資源,並能剝奪低優先順序程序的資源。

侷限: 實現複雜,代價較大,為了恢復現場需要耗費很多時間和空間。只適合類似CPU、儲存器這樣的資源。

3.6.3、破壞“迴圈等待”條件

方法:

給資源編號,程序必須按序申請資源。

侷限:

  1. 資源編號困難
  2. 申請資源的順序很難和資源編號順序相一致
  3. 限制了使用者對資源呼叫的靈活性

3.7、死鎖避免

3.7.1、系統安全狀態

所謂安全狀態,是指系統能按某種程序順序(P1, P2, …, Pn)(稱ǿP1, P2, …, PnȀ序列為安全序列),來為每個程序Pi 分配其所需資源,直至滿足每個程序對資源的最大需求,使每個程序都可順利地完成。

如果系統無法找到這樣一個安全序列,則稱系統處於不安全狀態。

避免死鎖的關鍵就是:讓系統在動態分配資源的過程中,不要進入不安全狀態。

2、安全狀態之例

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

如果不按照安全序列分配資源,則系統可能會由安全狀態進入不安全狀態,進而可能造成死鎖。

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

1965年由Dijkstra為T.H.E系統設計

基本思想:借用了銀行借貸系統的分配策略。

基本規則:

(1)第一次申請需要宣告最大資金需求量

(2)滿足最大需求後要及時歸還資金

(3)客戶申請的貸款數量不超過它自己擁有的最大值時,銀行要儘量滿足客戶需求

客戶---->資金

銀行---->程序

資源---->作業系統

1、 銀行家演算法中的資料結構

(1) 可利用資源向量Available,表示系統中可利用的資 源的數目;如Available[j]=K,表示系統中Rj 類資源有K 個。

(2) 最大需求矩陣Max,表示n個程序中的各程序對m類 資源的最大需求,如Max[i, j]=K,表示程序i需要Rj 類資 源的最大數目為K個。

(3) 分配矩陣Allocation,表示各程序當前已分得各類資源 的數目;如Allocation[i, j]=K,表示程序i當前已分得K 個Rj 類資源。

(4) 需求矩陣Need,表示各程序尚需的各類資源的數目; 如Need[i, j]=K,表示程序i還需要K個Rj類資源,方能完成其任務。

Need[i,j]=Max[i,j]-Allocation[i,j]

2、銀行家演算法

(1) 如果Requesti [j]≤Need[i,j],便轉向步驟2;否則 認為出錯,因為它所需要的資源數已超過它所宣佈的最大值。

(2) 如果Requesti [j]≤Available[j],便轉向步驟3; 否則, 表示尚無足夠資源,Pi 須等待。

(3) 系統試探著把資源分配給程序Pi ,並修改下面資料結 構中的數值: Available[j]: =Available[j]- Requesti [j]; Allocation[i,j]: =Allocation[i,j]+ Requesti [j]; Need[i,j]: =Need[i,j]- Requesti [j];

(4) 系統執行安全性演算法,檢查此次資源分配後,系統 是否處於安全狀態。若安全,才正式將資源分配給程序Pi ; 否則,恢復原來的資源分配狀態,讓程序Pi 等待。

3、 安全性演算法

(1)設定兩個向量:

① 工作向量Work: 表示系統可提供給程序繼續執行 的各 類 資源 數 目 , 在 執行安全演算法開始時 , 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[i]+ Allocation[i,j]; Finish[i]:= true; go to step 2;

(4) 如果所有程序的Finish[i]=true都滿足, 則表示系統處於安全狀態;否則,系統處於不安全狀態。

設定兩個向量: work、 Finish

從程序集合中找到一個能滿足下述條件的程序: Finish[i] = false & Needi <= work

執行:

Work := Work + Allocation;

Finish[i] := true;

迴圈,如果所有程序的Finish[i] = true則安全。

5、 銀行家演算法的優缺點

優點:

  1. 提高了資源利用程度
  2. 系統總是處於安全狀態

缺點:

  1. 被分配的每類資源的數量是固定不變的;
  2. 使用者數保持固定不變;
  3. 要求使用者事先說明其最大資源要求。

3.8、死鎖的檢測與解除

3.8.1、死鎖的檢測

要求:

  1. 資源請求與分配資訊
  2. 檢測演算法和解除演算法

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

資源分配圖化簡:



2、死鎖定理

當且僅當系統某狀態S所對 應的資源分配圖是不可完全化簡的,則S是死鎖狀態,而相應程序被死鎖。

如果資源分配圖中沒有環路,則系統中沒有死鎖,如果圖中存在環路則系統中可能存在死鎖

如果每個資源類中只包含一個資源例項,則環路是死鎖存在的充分必要條件。

有環有死鎖

有環無死鎖

3、 死鎖檢測中的資料結構

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

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

(3) 從程序集合中找到一個Requesti ≤Work的程序,做如下處理:

① 將其資源分配圖簡化,釋放出資源,增加工作向 量Work∶=Work+Allocationi 。

② 將它記入L表中。

(4) 若不能把所有程序都記入L表中, 便表明系統狀態S 的資源分配圖是不可完全簡化的。 因此,該系統狀態將發生死鎖。

3.8.2、死鎖的解除

重新啟動:這是一種常用但比較粗暴的方法,雖然實現簡單,但會使之前的工作全部白費,造成很大的損失和浪費。

撤消程序:死鎖發生時,系統撤消造成死鎖的程序, 解除死鎖。 一次性撤消所有的死鎖程序。損失較大。 逐個撤消,分別收回資源。

具體做法:系統 可以先撤消那些優先順序低的、已佔有資源少 或已執行時間短的、還需執行時間較長的進 程,儘量減少系統的損失。

剝奪資源:死鎖時,系統保留死鎖程序,只剝奪死 鎖程序佔有的資源,直到解除死鎖。選擇被剝奪資源程序的方法和選擇被撤消程序相同。

程序回退:死鎖時,系統可以根據保留的歷史資訊, 讓死鎖的程序從當前狀態向後退回到某種狀態,直到死鎖解除。

實現方法:可以通過結合檢查點或回退機制實現。

最後分享一首自己很喜歡的詩(姑且算是吧)。我欲乘風向北行,雪落軒轅大如席,我欲借船向東遊,綽約仙子迎風立,我欲踏雲千萬裡,廟堂龍吟耐我何,崑崙之巔沐日光,滄海絕境見青山,長風萬里燕歸來,不見天涯人不回。

本文來自部落格園,作者:NotYourferry,轉載請註明原文連結:https://www.cnblogs.com/pinghuimolu/p/15456134.html