操作系統要實現多進程，進程調度必不可少。有人說，進程調度是操作系統中最為重要的一個部分。我覺得這種說法說得太絕對了一點，就像很多人動輒就說"某某函數比某某函數效率高XX倍"一樣，脫離了實際環境，這些結論是比較片面的。

而進程調度究竟有多重要呢? 首先，我們需要明確一點：進程調度是對TASK_RUNNING狀態的進程進行調度。如果進程不可執行(正在睡眠或其他)，那么它跟進程調度沒多大關系。

[[231027]]

所以，如果你的系統負載非常低，盼星星盼月亮才出現一個可執行狀態的進程。那么進程調度也就不會太重要。哪個進程可執行，就讓它執行去，沒有什么需要多考慮的。

反之，如果系統負載非常高，時時刻刻都有N多個進程處于可執行狀態，等待被調度運行。那么進程調度程序為了協調這N個進程的執行，必定得做很多工作。協調得不好，系統的性能就會大打折扣。這個時候，進程調度就是非常重要的。

盡管我們平常接觸的很多計算機(如桌面系統、網絡服務器、等)負載都比較低，但是linux作為一個通用操作系統，不能假設系統負載低，必須為應付高負載下的進程調度做精心的設計。

當然，這些設計對于低負載(且沒有什么實時性要求)的環境，沒多大用。極端情況下，如果CPU的負載始終保持0或1(永遠都只有一個進程或沒有進程需要在CPU上運行)，那么這些設計基本上都是徒勞的。

優先級

現在的操作系統為了協調多個進程的“同時”運行，最基本的手段就是給進程定義優先級。定義了進程的優先級，如果有多個進程同時處于可執行狀態，那么誰優先級高誰就去執行，沒有什么好糾結的了。

那么，進程的優先級該如何確定呢?有兩種方式：由用戶程序指定、由內核的調度程序動態調整。(下面會說到)

linux內核將進程分成兩個級別：普通進程和實時進程。實時進程的優先級都高于普通進程，除此之外，它們的調度策略也有所不同。

實時進程的調度

實時，原本的涵義是“給定的操作一定要在確定的時間內完成”。重點并不在于操作一定要處理得多快，而是時間要可控(在最壞情況下也不能突破給定的時間)。

這樣的“實時”稱為“硬實時”，多用于很精密的系統之中(比如什么火箭、導彈之類的)。一般來說，硬實時的系統是相對比較專用的。

像linux這樣的通用操作系統顯然沒法滿足這樣的要求，中斷處理、虛擬內存、等機制的存在給處理時間帶來了很大的不確定性。硬件的cache、磁盤尋道、總線爭用、也會帶來不確定性。

比如考慮“i++;”這么一句C代碼。絕大多數情況下，它執行得很快。但是極端情況下還是有這樣的可能：

1、i的內存空間未分配，CPU觸發缺頁異常。而linux在缺頁異常的處理代碼中試圖分配內存時，又可能由于系統內存緊缺而分配失敗，導致進程進入睡眠;

2、代碼執行過程中硬件產生中斷，linux進入中斷處理程序而擱置當前進程。而中斷處理程序的處理過程中又可能發生新的硬件中斷，中斷永遠嵌套不止……;

等等……

而像linux這樣號稱實現了“實時”的通用操作系統，其實只是實現了“軟實時”，即盡可能地滿足進程的實時需求。

如果一個進程有實時需求(它是一個實時進程)，則只要它是可執行狀態的，內核就一直讓它執行，以盡可能地滿足它對CPU的需要，直到它完成所需要做的事情，然后睡眠或退出(變為非可執行狀態)。

而如果有多個實時進程都處于可執行狀態，則內核會先滿足優先級最高的實時進程對CPU的需要，直到它變為非可執行狀態。

于是，只要高優先級的實時進程一直處于可執行狀態，低優先級的實時進程就一直不能得到CPU;只要一直有實時進程處于可執行狀態，普通進程就一直不能得到CPU。

那么，如果多個相同優先級的實時進程都處于可執行狀態呢?這時就有兩種調度策略可供選擇：

1、SCHED_FIFO：先進先出。直到先被執行的進程變為非可執行狀態，后來的進程才被調度執行。在這種策略下，先來的進程可以執行sched_yield系統調用，自愿放棄CPU，以讓權給后來的進程;

2、SCHED_RR：輪轉調度。內核為實時進程分配時間片，在時間片用完時，讓下一個進程使用CPU;

強調一下，這兩種調度策略以及sched_yield系統調用都僅僅針對于相同優先級的多個實時進程同時處于可執行狀態的情況。