操作系統管理之處理機調度與死鎖

處理機調度與死鎖

處理機調度的層次

高級調度/作業調度/長程調度

  • 作用:將外存后備隊列中的作業調入內存
  • 對象:作業

作業:比程序更泛的一個概念,通常包含程序、數據以及作業說明書,批處理系統中,以作業為基本單位從外存調入內存

作業步:作業中的步驟

作業流:進入系統后,在外存中排隊的作業,形成輸入作業流,在系統控制下進行處理,形成處理作業流

作業控制塊:JCB,是作業在系統中存在的標志,保存了系統對作業進行管理和調度所需要的全部信息

低級調度/進程調度/短程調度

  • 作用:決定哪個進程應該獲得處理機
  • 對象:進程
  • 基本機制
    • 排隊器:提高進程調度的效率,將就緒的進程按照一定的方法排成一個或者多個隊列
    • 分派器:把由進程調度所選中的進程,從就緒隊列中取出,然后進行上下文切換,將處理機分配給它
    • 上下文切換機制:當對處理機進行切換時,會執行兩次上下文切換,1. 保存當前進程的上下文,載入分派程序上下文,2. 移出分派進程,載入新選進程的上下文信息
  • 調度方式
    • 非搶占式方式:只要進程在執行,則不搶占其處理機
    • 搶占方式
      • 優先權原則:允許優先權高的進程搶占當前進程的處理機
      • 短作業/進程優先
      • 時間片原則

中級調度/中程調度

  • 作用:提高內存利用率和系統吞吐量,將暫時不能運行的進程調至外存上等待,也就是將其掛起
  • 對象:進程

調度隊列模型和調度準則

調度隊列模型

  • 僅有進程調度的調度隊列模型
  • 具有高級和低級調度的調度隊列模型
    • 就緒隊列一般采用高優先權優先調度算法
    • 設置多個阻塞隊列
  • 同時具有三級調度的調度隊列模型

選擇調度方式和調度算法的準則

  • 面向用戶的準則
    • 周轉時間短
      • 周轉時間:作業從被提交到作業完成這段時間(作業在外存后備隊列等待調度的時間,進程就緒隊列上等待時間,進程在CPU上執行的時間,進程等待I/O操作完成的時間)
      • 平均帶權周轉時間:W = 1/n * sum(Ti/Ts) 其中Ti 指的是作業的周轉時間,Ts指的是作業的服務時間
    • 響應時間快
      • 響應時間:從請求發出到收到回應的時間
    • 截止時間的保證
      • 截止時間:任務必須開始執行的最遲時間
    • 優先權保證
  • 面向系統的準則
    • 系統吞吐量高
      • 吞吐量:單位時間內完成的作業數
    • 處理機利用率好
    • 各類資源的平均使用

調度算法

先來先服務調度算法(FCFS)

  • 應用場景:作業調度、進程調度
  • 運作方式
    • 作業調度:每次調度都是從后備隊列中選擇一個或者多個最先進入該隊列的作業,將其調入內存
    • 進程調度:從就緒隊列中選擇一個最先進入該隊列的進程,為其分配處理機
  • 特性:有利于長作業/進程,不利于短作業/進程
  • 案例


    先來先服務調度算法

    可以看到,D的要求服務時間只有2,但是其帶權周轉時間到達5.5,而長作業C的周轉時間則只有2,可以得出結論,先來先服務調度算法有利于CPU繁忙型的作業

短作業/進程優先調度算法(SJF/SPF)

  • 應用場景:作業調度、進程調度
  • 運行方式
    • 作業調度:從后備隊列中選擇一個或若干個估計運行時間最短的作業,將其調入內存運行
    • 進程調度:從就緒隊列中選出一個估計運行時間最短的進程,將處理機分配給它,使其一直執行到完成,或者因某事而被阻塞放棄處理機時再重新調度
  • 特性:有效降低作業的平均等待時間,提高系統的吞吐量
  • 案例


    短作業優先調度算法

    可以看到,無論是平均周轉時間還是帶權平均周轉時間,短作業優先調度算法均低于先來先服務調度算法,尤其是短作業D的帶權周轉時間,從5.5下降到1.5

  • 缺點:對長作業不利,可能導致長作業一直未能分配到處理機,完全未考慮作業的緊迫程度,作業長短只是估計值,并不一定準確

高優先權優先調度算法(FPF)

  • 應用場景:作業調度、進程調度
  • 運行方式
    • 作業調度:從后備隊列中選擇若干個優先權最高的作業裝入內存
    • 進程調度:把處理機分配給就緒隊列中優先權最高的進程
  • 細分
    • 非搶占式優先權調度算法
      • 一旦把處理機分配給就緒隊列中優先權最高的進程后,該進程便可以一直執行下去,直至完成;或者因某事而主動放棄處理機
    • 搶占式優先權調度算法
      • 在執行期間,如果出現了另一個優先權更高的進程,進程調度程序立即停止當前進程,重新將處理機分配給新來的優先權最高的進程
  • 優先權類型
    • 靜態優先權:創建進程時確定,并且在進程運行期間一直保持不變
    • 動態優先權:在運行期間可以動態改變進程的進程的優先權
  • 高響應比優先調度算法
    • 動態地調整優先權的一種基于搶占式的調度算法
    • 響應比:Rp = (等待時間+要求服務時間)/要求服務時間 = (響應時間)/要求服務時間
    • 特點:既照顧了短作業、也考慮了作業到達次序,也能保證長作業能夠得到服務,但是每次調度前,都需要做響應比計算

基于時間片的輪轉調度算法

時間片輪轉法

多級反饋調度算法

  1. 設置多個就緒隊列,并為各個隊列賦予不同的優先級,第一個隊列優先級最高,依次遞減,各個隊列的執行時間片也不同,優先權越高,時間片越短,依次增加一倍
  2. 當一個新的進程進入內存之后,將其放入第一隊列的末尾,按照FCFS原則排隊等待調度,如果在指定時間內未能完成,則轉入第二隊列的末尾...
  3. 只有當第一隊列為空時,調度程序才會啟動第二隊列中的進程運行,僅當第1i-1隊列中均為空時,才會調度第i隊列中,如果處理機此時在為i隊列某進程服務,有新的進程進入1i-1中任意隊列,則發生調度,先執行該進程,并且把當前進程放入i隊列的末尾

性能:滿足多種作業的需求。

實時調度

實現實時調度的基本條件

  • 提供必要的信息
    • 就緒時間
    • 開始截止時間和完成截止時間
    • 處理時間
    • 資源要求
    • 優先級
  • 系統處理能力強
  • 假設有m個硬實時任務,則需要滿足 sum(ci/pi) <=1 ci為執行該進程所需時間,pi為該進程的周期時間
  • 采用搶占式調度機制
  • 具有快速切換機制
    • 對外部中斷的快速響應能力
    • 快速的任務分派能力

實時調度算法的分類

  • 非搶占式調度算法(小型實時系統、要求不太嚴格的實時控制系統)
    • 非搶占式輪轉調度算法
    • 非搶占式優先調度算法
  • 搶占式調度算法(要求比較嚴格)
    • 基于時鐘中斷的搶占式優先權調度算法:時鐘中斷到來才發生切換
    • 立即搶占的優先權調度算法

常用的實時調度算法

  • 最早截止時間優先(EDF)算法
  • 非搶占式調度方式用于非周期性實時任務
  • 搶占式調度方式用于周期性實時任務
  • 最低松弛度/緊急程度優先(LLF)算法
    • 松弛度 = 截止時間 - 完成該任務所需要的時間 - 當前時間
    • 松弛程度越低越先調度

產生死鎖的原因和必要條件

死鎖:多個進程在運行過程中因爭奪資源而造成的一種僵局,在沒有外力的作用下,它們都無法再向前進

產生死鎖的原因

  • 競爭資源:共享資源數量不足以滿足進程的需要
  • 進程間的推進順序非法:請求和釋放資源的順序不當

產生死鎖的必要條件

  • 互斥條件:一段時間內某個資源只能被一個進程占用
  • 請求和釋放:進程至少擁有一個資源,并且又請求了其他資源
  • 不剝奪資源:進程已經擁有的資源,在未使用完之前,不能別剝奪,只能使用完自己釋放
  • 環路等待:發生死鎖時,必然存在一個進程-資源的環形鏈

預防死鎖的產生

所謂預防死鎖,其實就是破壞產生死鎖的四個必要條件之一,使得死鎖條件不成立,從而達到預防死鎖的目的

  • 摒棄請求和保持條件:一次性申請所需要的全部資源,只要有一種資源不滿足,則先等待
    • 缺點:資源利用率低,進程延遲運行
  • 摒棄不剝奪條件:當一個進程申請資源不滿足時,釋放自己擁有的所有資源,以后重新申請
    • 缺點:復雜、代價大
  • 摒棄環路等待條件:所有資源進行線性排隊,賦予不同的序號,請求資源時,只能按照資源序號遞增的次序提出
    • 缺點:資源序號必須穩定、限制編程的簡單性

避免死鎖的產生

把系統的狀態分為安全狀態和不安全狀態,只要能使系統處理安全狀態,就可以避免死鎖

  • 安全狀態

    • 允許系統動態地申請資源,但系統在進行資源分配之前,應先計算此次資源分配的安全性
    • 安全狀態:系統能按照某種進程順序(p1, p2, p3, ...)稱其為安全序列來為每個進程Pj分配其所需要的資源
  • 銀行家算法 -- 避免死鎖的有效方法

    • 數據結構
      • 可利用資源向量 Available:m個元素的數組,初始值為系統中所分配的該類全部可用資源的數目
      • 最大需求矩陣 Max:n*m矩陣,定義了n個進程中每個進程對m類資源的最大需求
      • 分配矩陣 Allocation:n*m矩陣,定義了系統中每一類資源當前已經分配給進程的資源數
      • 需求矩陣 Need:n*m矩陣,用于表示每一個進程尚需的各類資源數
      • Need[i, j] = Max[i, j] - Allocation[i, j]
    • 銀行家算法
      • 假設:Ri是進程Pi的請求向量,若Ri[j] = k, 則表示Pi需要k個Rj類型的資源
      1. 如果Ri[j] <= Need[i, j],則轉向2,否則出錯:請求資源多于需要的資源
      2. 如果Ri[j] <= Available[j],轉向3,否則,表示目前暫無資源可用,Pi需要等待
      3. 系統嘗試分配資源給Pi,并且修改下面信息
      • Available[j]:= Avaliale[j] - Ri[j]
      • Allocation[i,j] = Allcation[i, j] + Ri[j]
      • Need[i, j] = Need[i, j] - Ri[j]
      1. 執行安全性算法,檢查此次分配后系統是否處于安全狀態,如果安全,才真正將資源分配給進程Pi,否則,將資源恢復為原來的狀態,讓Pi等待
    • 安全性算法
      1. 設置兩個向量
      • 工作向量Work,表示系統可提供給進程所需的各類資源數目,含有m個元素,開始時,Work:= Available
      • Finish,表示系統是否有足夠的資源分配給進程,使之運行完成,初始值為Finish[i]:= false,當有足夠資源時,再令Finish[i]:= true
      1. 從進程集合中找到一個能滿足下述條件的進程
      • Finish[i]:= false
      • Need[i ,j] <= Work[j], 若找到,執行下面步驟3,否則,執行步驟4
      1. 當進程Pi獲得資源后,可順利執行,直至完成,并釋放出給它的資源
      • Work[j]:= Work[j] + Allocation[i ,j]
      • Finish[i]:= true
      • 繼續執行步驟2
      1. 如果所有的Finish[i] = true 滿足,則表示系統處于安全狀態;否則,系統處于不安全狀態
    • 案例


      t0時刻資源分配情況

      求問t0時刻的安全性:


      一種可行的分配順序

      從而可以得出一種滿足條件的順序,也就是說明當前狀態是安全的
      如果P1發出請求向量req(1, 0, 2),問是否可以分配

      先檢查 req(1, 0, 2) <= Need(1, 2, 2) 滿足,
      再檢查req(1, 0, 2) <= Available(3, 3, 2) 滿足,嘗試將該請求的資源進行分配,然后重新計算一下能否滿足安全算法即可,這里省略

死鎖的檢測與解除

  • 資源分配圖:圓圈代表進程,方框代表資源,方框中的點代表資源的數量
  • 死鎖定理:如果能將該資源分配圖簡化到所有的節點都是孤立節點,則說明不存在死鎖,否則,存在死鎖

死鎖解除

  • 剝掉資源:從其他進程剝奪資源,分配給死鎖進程,使其打破死鎖
  • 撤銷進程
    • 撤銷所有死鎖進程
    • 每次選擇代價最小的進程進行撤銷,直至死鎖解除
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 229,732評論 6 539
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,214評論 3 426
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 177,781評論 0 382
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,588評論 1 316
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,315評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,699評論 1 327
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,698評論 3 446
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,882評論 0 289
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,441評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,189評論 3 356
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,388評論 1 372
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,933評論 5 363
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,613評論 3 348
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,023評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,310評論 1 293
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,112評論 3 398
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,334評論 2 377

推薦閱讀更多精彩內容