第二章實時系統的相關研究<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
儘管現在的作業系統變得種類繁多，但是unix及其相容的系統仍然是工業和學術領域標準的作業系統。一些非unix系統，比如windows nt，也是與posix.1003標準相容，這個標準無疑是基於unix。這個系統的成功是由於它的開放性、穩定性和事實的標準。隨著posix1003.1b實時擴充套件標準的發布，unix有機會成為分布最廣泛的實時處理平台。linux作為乙個類unix的系統，憑藉其開放原始碼的優勢，獲得越來越廣泛的應用。
由於以上的原因，在這一章我將集中討論與linux相關的實時系統。我將討論在linux上進行實時運算的問題，和在一些系統中如何解決這些問題。
2.1 linux的分時特性
unix最初是作為乙個分時系統設計的[17]。linux作為unix的轉殖，很多當前的實現中仍然保留了這些特點。它們力爭最優的平均效能。這個目標通常與實時系統的低延遲和高可預言的要求相勃的。為了說明這個問題，讓我們考慮乙個通過揚聲器發聲的程式（程式2.1）。
#define delay 10000
main()
}程式2.1簡單的發聲程式
揚聲器的驅動程式假定為只有兩種狀態on或off。初看起來這個程式可以按給定的週期輸出方波，使揚聲器正常的發聲。然而，當執行乙個標準的linux程式時，它將不能正確的發聲。
我在乙個有412mhz celeron處理器的linux作業系統上執行這個程式。當在系統沒有別的程式在執行時，揚聲器發出穩定的聲音。每乙個滴答聲都可以聽到。當有按鍵動作或者移動滑鼠時，都會引起聲音的斷續。在執行磁碟操作或高運算量的程式時，聲音將變得嚴重失真。最後，起動乙個大的程式，比如x-windows，揚聲器將持續大約半秒的時間不能發聲。假如這個程式是控制步進電機的，而不是使揚聲器發聲，那麼程式將不能使電機穩定地執行。
linux的設計和實現的原理大體上與unix是相同的[12]。它們都是採用分時的排程，低的計時解析度，非佔先式核心，關中斷和虛擬記憶體。我們在細節上來考慮這些問題。
排程程式是內建在作業系統內部的一組策略和機制，它決定哪一項工作將由計算機來完成[4]。
大部分的unix作業系統，尤其是linux作業系統，它們的排程程式追求的是平均響應時間、吞吐量和在程序之間的公平的cpu時間分配[16]。每個程序的優先順序是動態的基於程序已經花費的cpu時間，輸入/輸出強度和別的一些因素來決定。
linux系統使用固定的時間片(time slices)來排程cpu時間。最開始程序賦予乙個高的優先順序。如果在某個程序的時間片內，這個程序放棄cpu，它的優先順序將不會變，或者變的更高。另一方面，如果乙個程序使用完它的時間片，它的優先順序將會變低。這種策略關心的是互動式程式，比如說編輯器，由於這類程式更多的把時間花費在等待i/o輸入輸出的完成。雖然對在終端前的使用者來說是有利的。由於程式的執行完全依賴於複雜的、不可預知的系統負荷與別的程序的活動，這種排程方式對於實時程序而言完全沒有用。
linux中加進了posix實時擴充套件部分，引進了實時程序的概念，允許乙個程序定義為乙個實時程序。linux區分實時程序和普通程序，採用不同的排程策略。即先來先服務排程(sched_fifo)和時間片輪轉排程(sched_rr)。在sched_rr排程中，任務一旦時間片用完就被移動到優先順序佇列的隊尾，並允許同一優先順序的其它任務執行。如果同一優先順序沒有其它任務，該任務繼續執行下乙個時間片。sched_fifo是執行直至阻塞的策略。sched_fifo任務按優先順序排程，一旦開始就一直執行到結束或阻塞在某種資源上。不像sched_rr任務那樣共享處理器。
另外還有計時器的精度問題。以前提供給使用者程序警報訊號和sleep()系統呼叫只有1秒的精度，如此粗糙的計時精度是不適合大多數的實時程序。當前的版本提供了更高精度的時間間隔，然而，內在的時鐘實現限制了計時的正確性。這方面的內容在後面將由更詳細的論述。
大部分的linux的核心程序是不能中斷的[10]。換句話說，一旦乙個程序進入到核心模式，它將執行到系統呼叫的完成或者被阻塞為止。假如在這期間有乙個更高優先順序的實時程序準備好執行了，它將不得不等待。由於不需要考慮核心重入的問題，這種設計的方式使核心的開發更為簡單。然而，乙個系統呼叫可能花費很長時間來完成，對於乙個實時程序來說長的延遲是不能接受的。
於非佔先式核心相關的問題是系統的同步。為了保護資料可能被非同步的操作，比方說中斷處理函式，系統設計者通常在臨界區**中選擇關中斷的方式來處理。比起訊號量(semaphores)或者自旋鎖(spinlocks)這是更為簡單有效的技術。但是，禁止中斷是系統能力與系統對外部事件的快速響應的乙個折中。這種方法還是不能解決多處理器系統的同步化問題。
linux系統使用了虛擬記憶體用於分頁[10]。虛擬記憶體技術只是保護程式在執行部分在ram中，可以使執行的程式超過系統ram的容量。這種方式在分時系統中將很好的執行。然而，對於實時系統來說，虛擬記憶體引起的系統不可確定性達到乙個無法忍受的地步。
所有考慮的這些因素來看，顯然傳統的linux是不可能用於實時處理。我們需要一些根本的改變。
2.2 linux效能測試
為了對linux的效能有乙個直觀的了解，我對linux系統進行了測試。測試的內容包括中斷延遲時間和上下文切換。對測試的結果進行分析，以尋找提高linux延時間效能的途徑。
2.2.1 中斷延遲測試
中斷可以分為兩種不同型別：同步和非同步中斷。對應用程式來說，重要的是非同步中斷。非同步中斷發生的情況如圖2.1所示。中斷響應時間是中斷發生到中斷處理程式開始執行之間的時間差。這個時間差包括直到在執行任務停止和中斷分派時間。
<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />
圖2.1非同步中斷和中斷響應時間
中斷響應時間並不是乙個常量。它與作業系統和硬體平台有關。要測量精確的關閉中斷的時間，並不是通過上面的定義來進行。因為從中斷到來到當前任務停止屬於中斷延遲時間。在linux中，核心或驅動程式顯式地關/開中斷，一般是通過呼叫__cli()/__sti()來進行操作。中斷延遲程式計算一對__cli()/__sti()呼叫之間的時間。在呼叫__cli()時，記錄系統時間值，讀出__sti()被呼叫時的系統時間值。他們之間的時間差就是關中斷時間。linux下的關中斷時間如圖2.2所示：
關中斷時間測試程式重新寫了__cli()/__sti()巨集，以允許記錄呼叫它們的檔案以及在何處呼叫。記錄這些資訊以分析在linux中那些關中斷時間是比較長。（中斷測試程式的**在附錄a）
我對linux進行了大約3個小時的測試，測試的結果如表。在測試中執行一些程式，其中包括乙個磁碟迴圈拷貝程式，開啟一些應用程式。可以發現系統負載比較重時，系統的頁面排程花了比較多的時間，將近500微秒。表2.1表2.2是統計結果。
圖2.2關中斷時間
表2.1中斷關閉時間直方圖
表2.2中斷關閉時間概率密度函式直方圖
可以看出在我的測試系統中系統中斷關閉時間最大達到496微秒，一般中斷關閉時間是在250微秒到300微秒左右。這次測試並沒有進行所有情況下的測試，從這些結果我們就可以看出：linux的系統設計人員採用分時的排程、低的計時解析度、非佔先式核心、關中斷和虛擬記憶體是造成系統關中斷時間過於長的原因。
2.2.2 上下文切換測試
上下文切換時間是儲存乙個程序狀態，然後恢復另外乙個程序狀態的時間。我寫了乙個測試程式來測試這個時間（程式見附錄b）。程式執行時，根據輸入的引數來決定建立多少個程序。所有的程序用乙個環形的unix管道連線。程式中實現乙個令牌在這些程序之間傳遞，迫使進行程序間的上下文切換。程式記錄在程序間傳遞令牌2000次所花的時間。每一次令牌的傳遞有兩個開銷：上下文切換開銷和令牌傳遞開銷。程式首先計算令牌在環形管道中傳遞的開銷，在輸出的結果已經除去了這部分開銷。
為了計算更真實的切換時間，我加入了人為的資料在裡面，程序切換時間包括儲存使用者級資料狀態的時間。測試的結果在表2.3所示，y軸表示切換時間，x軸表示程序數目，size表示程序的大小。
從結果看，程序的隨著程序的大小變化，切換時間在增加，在16k以內增加幅度不大，是因為此時程序的大小還沒有超出一級快取的大小，超過16k時，增加幅度比較大，程序大小達到64k時，切換時間達到300微秒。linux切換時間過於大的原因是系統儲存了過於多的狀態。在上下文切換過程中，系統是關中斷的，意味著此時的系統關中斷時間超過300微秒。對於實時應用來所是不能接受的。
表2.3上下文切換時間
嵌入式 實時作業系統導論
排程任務和資料 訊號量和共享資料 可重入性和訊號量 多個訊號量 訊號量作為訊號裝置 使用訊號量的易出現問題 訊號量變數 所謂任務，是指在乙個rtos中所寫的軟體的基本構造塊，也就是通常所說的子程式。有關任務是如何呼叫 它與rots是如何配合工作的等問題稍後再討論。在rtos中乙個任務總是處在下列三種...
嵌入式系統 實時作業系統 RTOS
一 rtos中的基本概念 背景 rtos具有的功能 作業系統中的程序與執行緒 二 嵌入式作業系統的主要種類 1 uc os ii 2 linux 作業系統 3 vxworks 4 wince os 作業系統，operating system 是嵌入式系統中的靈魂，是其軟體系統中的重要組成部分，嵌入式...
嵌入式實時作業系統的移植 ！
所謂移植，就是使選用的實時核心能在某個特定的微處理器上執行。為了方便移植，大部分的實時作業系統 是用c語言編寫的，但仍需要用c和組合語言編寫一些與微處理器相關的 這是因為有一些操作只能通過組合語言來實現。由於所有的實時作業系統在設計時就已經充分考慮了可移植性，所以移植相對來說是比較容易的。以ucos...