在我前面的一篇博客（查看“Adam Taylor玩轉MicroZed系列40：MicroZed操作系統第二部分”）中，大家已經見識了不同類型的實時操作系統。我認為我們應該了解一下操作系統執行的進程之間是如何進行通信的，它們是怎樣共享可用的硬件資源和潛在的陷阱（計算機異常的一個類別）。

當兩個或者更多的進程想要共享同一個資源——以Zynq SoC 的XADC組件為例——很多進程很可能會在同一時間要求使用這個資源。資源的訪問使用需要被控制來阻止出現爭奪資源的現象，這是操作系統最重要的職責之一。如果不能正確有效的實現資源的管理，“死鎖”（deadlock）或者“饑餓”（starvation）現象可能會發生。

下面給出的是“死鎖”和“饑餓”的定義：
? 死鎖——當一個進程占有一個資源，直到這個進程結束才會釋放這個資源，但是因為它需要一個被另一個的進程占用的資源導致它不能被執行完畢。如果第二個進程需要調用第一個進程占用的資源，那么系統就永遠保持在死鎖狀態。死鎖現象是RTOS（實時操作系統）自身的一個比較糟糕的情況。
? 饑餓——進程不能夠運行，因為這個進程所需的資源總是被分配給另一個進程，這個進程就會因為缺乏資源而被“餓死”，俗話說“巧婦難為無米之炊?！?/p>

正如你能夠想象到的，歷年來很多文章介紹和討論了關于死鎖和饑餓現象這個主題，涌現出了很多可行性的解決方案。例如：Dekker算法，這個算法是首先被認為是解決互斥現象的正確方案。它是一個共享內存的機制，不需要特定的“測試與設置”指令（但是僅限于管理兩個競爭的進程），這都要歸功于荷蘭數學家Theodorus Dekker。處理死鎖現象最普遍的方法是利用semaphores（信號量），主要有兩種形式：二進制信號量和計數器信號量。二進制信號量用于控制對一個資源的訪問，例如一個硬件資源。計數器信號量用于控制對一堆相同的可以內部互換的資源的訪問，例如內存的緩沖區。

通常情況下每個資源都會分配一個二進制的信號量，調用這個資源的進程將會等待，直到這個資源變成可利用的，進程才會執行，一旦這個進程執行完畢，它將會釋放這個資源。二進制信號量通常使用WAIT和SIGNAL操作。進程會根據一個信號量執行WAIT操作，當這個資源處于空閑狀態（可能是立即空閑或者不是） ，操作系統會把資源的控制權交給進程。

當進程執行完畢，會產生SIGNAL完成信號并且釋放資源。然而，當進程根據信號量等待時，如果資源是被占用的，操作系統會暫停進程直到資源處于空閑狀態。這個執行WAIT操作的進程可能不得不一直等待，直到占用這個資源的正在執行的進程結束，或者這個等待可能會更長，如果這個資源已經被更高優先級的進程請求調用。

介紹進程優先級的概念會引出優先級反轉這個問題。存在一個更加靈活的二進制信號量的類被稱作“mutex’s”（單詞mutex是“mutual exclusion”的縮寫），這些類經常會被現代操作系統使用，用來防止優先級反轉。

計數器信號量的工作方式與二進制信號量的工作方式相，當不止一個資源師是可利用的時候它們會被調用，例如數據的存儲。隨著每個資源被分配給請求的進程，計數器的值會減少來反映出剩余的空閑資源的數量。當信號量計數器的值變為零，就不會存在可利用的資源。當計數器的值變為零以后任何請求一個或者更多資源的進程都將會被暫停，直到所需數量的資源被釋放。

進程之間需要經常的進行通信，又很多的方法來實現這個操作。最簡單的方法是使用數據存儲，數據存儲是用上面描述的信號量進行管理的，更復雜的通信方法包括消息隊列。

當使用消息隊列時，一個進程想要發送信息給另一個進程要發布一個消息到這個隊列里面。當一個進程想要從隊列里接收消息，他就會依賴于這個隊列。因此消息隊列的工作方式像FIFO。然而在 ?C/OS-III操作系統會配置消息隊列以LIFO方式工作。消息隊列和它們所屬的組織可能很復雜，想要深入探討這個話題可能需要寫更多的博客。幸運的是通過借助操作系統中預先寫入的程序，這些編程工具更加的容易使用，不用再去從頭創建。

已經解釋了一點兒關于資源共享和進程間通信的知識，我的下一篇博客將會介紹?C/OS-III OS的一個演示例子，并且在MicroZed上運行起來。

原文鏈接：

? Copyright 2014 Xilinx Inc
如需轉載，請注明出處