7.1 什麼是CPU調度呢？
假設系統內此時有三個進程需要執行，進程1因爲時間片到了或者被阻塞了，那麼接下來需要從就緒態的進程2和進程3中選擇一個執行，到底選擇哪一個？這個選擇就叫作調度。如下圖所示
7.2 CPU調度（進程調度）的直觀想法
FIFO？
- 誰先進入，先調度誰：簡單，公平 銀行、食堂
- 一個只簡短詢問的業務怎麼辦？等待五小時，辦事五分鐘似乎不太合適
Priority(優先級）？
- 任務短可以適當優先
- 這人的詢問時間越來越長怎麼辦
- 如果一個銀行業務長是因爲客戶需要填一張很長的表怎麼辦？
7.3設計調度算法的原則
我們的算法設計目標？
- 面對銀行客戶：銀行調度算法的設計目標是讓用戶滿意，比如等待時間短
- 面對進程：CPU調度的目標應該是讓進程滿意，比如響應快，週轉時間短
讓進程滿意的三大指標
- 週轉時間（任務從進入到結束）短，即儘快結束任務
- 響應時間（任務從進入到開始執行）短，這樣用戶的操作能儘快響應
- 系統內耗時間少：系統內耗指不在具體執行任務的時間，比如進程切換時保存中斷現場這些操作。內耗時間短，才能使CPU吞吐量大（完成的任務量）
總的原則是：系統專注於任務執行，又能合理調配任務
如何做到合理調配任務？先看不同指標之間的關聯
- 吞吐量與響應時間之間的矛盾：響應時間小——》切換次數多——》系統內耗大——》吞吐量小
- 前臺任務和後臺任務關注點不同：前臺任務如打字，放PPT等更關注響應時間，後臺任務如圖像壓縮，數據解碼等更關注週轉時間
- I/O約束型任務和CPU約束型任務特點不同
如上圖所示，CPU約束型任務指CPU佔用時間長的任務，如程序編譯，矩陣運算這些計算任務，開始了就一直執行不停。I/O約束型任務指CPU佔用時間短的高發任務，如讀數據，保存數據。
很顯然，如果優先CPU約束型任務，那麼I/O約束型要等待很長時間，直到CPU約束性執行完，而如果優先I/O約束型任務，那麼只需簡單操作，如開始讀後就阻塞該任務，馬上切到CPU約束型任務，等讀完了再切回I/O約束性任務，相當於實現並行。
因此CPU調度策略需要在各種指標之間折中和綜合，同時又要求儘量簡單。
7.4幾種典型的CPU調度算法思想
- 隊列模型
即先到達先服務，這樣保證了公平，但存在什麼問題呢？
![]()
按先到達先服務策略執行，那麼平均週轉時間爲40.2（忽略0.001z等到達時間，認爲同時到達）
假如我們把P2和P3順序對換，那麼P1及P4、P5週轉時間不變。原本P2週轉時間爲39，P3爲42.兌換後，P3爲13，P2爲42。總的週轉時間減少了36，那麼平均週轉時間也就下降了。
![]()
也就是說先到達先服務的調度算法簡單公平，但週轉時間長 - SJF：短作業優先
![]()
可以證明：按照上圖所示的按任務時間長短升序排列的平均週轉週期最短 - RR：時間片輪轉調度算法
先進先出和短任務優先都沒有考慮響應時間。那麼排在最後的任務將會一直等待很長時間。
我們給每個任務分配時間片，輪流執行，這樣每個任務都能儘可能快響應。
此處設計時間片大小仍需要折中考慮：
時間片大：平均響應時間長；時間片短：切換頻繁，內耗大造成吞吐量小 - 優先級調度
前臺任務和後臺任務同時存在怎麼辦？前面說了前臺任務關注響應時間，後臺任務關注週轉時間。現有word和visual stdio編譯兩個任務存在。那麼需要讓這兩種任務都合理執行，就得同時考慮響應時間和週轉時間
直觀想法：將前臺任務定義爲輪轉調度隊列，將後臺任務定義爲短任務優先調度隊列。並且將前臺任務優先級設爲高優先級，只要有前臺任務存在時就不調度後臺任務
插入一個小故事：1973年關閉的MIT的IBM7094時，發現一個進程在1967年提交但一直未運行
如果不斷有前臺任務執行，那麼後臺任務一直得不到執行。
因此實用的調度算法應該是：首先考慮用戶體驗，不能等待太久，因此以輪轉調度爲核心，同時考慮優先級調度和短任務優先調度，保證後臺任務也會得到執行，折中平衡。