任務間通信和同步有三種廣泛的范式：

任務擁有的設施 ——RTOS 賦予提供通信（輸入）設施的任務的屬性。我們將再看的例子是信號。

內核對象 ——由 RTOS 提供的工具，代表獨立的通信或同步工具。示例包括：事件標志、郵箱、隊列/管道、信號量和互斥體。

消息傳遞 ——一種合理化的方案，其中 RTOS 允許創建消息對象，這些對象可以從一個任務發送到另一個任務或多個其他任務。這是內核設計的基礎，并導致將此類產品描述為“消息傳遞 RTOS”。

適合每種應用的設施會有所不同。它們的功能也有一些重疊，一些關于可擴展性的思考是值得的。例如，如果一個應用程序需要多個隊列，但只需要一個郵箱，那么實現具有單項隊列的郵箱可能會更高效。這個對象會有點不理想，但所有郵箱處理代碼都不會包含在應用程序中，因此，可伸縮性將減少 RTOS 內存占用。

共享變量或內存區域

任務間通信的一種簡單方法是只擁有所有相關任務都可以訪問的變量或內存區域。雖然它非常原始，但這種方法可能適用于某些應用程序。需要控制訪問。如果變量只是一個字節，那么對它的寫入或讀取可能是“原子”（即不可中斷）操作，但如果處理器允許對內存字節進行其他操作，則需要小心，因為它們可能是可中斷的并且可能會導致時間問題。實現鎖定/解鎖的一種方法是在短時間內禁用中斷。

如果您正在使用內存區域，當然您仍然需要鎖定。使用第一個字節作為鎖定標志是可能的，假設內存體系結構促進對該字節的原子訪問。一個任務將數據加載到內存區域，設置標志，然后等待它清除。另一個任務等待設置標志，讀取數據并清除標志。使用中斷禁用作為鎖定不太明智，因為移動整個數據緩沖區可能需要時間。

這種類型的共享內存使用方式類似于在多核系統中實現許多處理器間通信設施的方式。在某些情況下，硬件鎖和/或中斷被合并到處理器間共享存儲器接口中。

信號

信號可能是傳統 RTOS 中提供的最簡單的任務間通信工具。它們由一組位標志組成——可能有 8、16 或 32 個，具體取決于具體實現——與特定任務相關聯。

任何任務都可以使用 OR 類型的操作設置一個信號標志（或多個標志）。只有擁有信號的任務才能讀取它們。讀取過程通常是破壞性的——即標志也被清除。

在某些系統中，信號以更復雜的方式實現，以便在設置任何信號標志時自動執行由信號擁有任務指定的特殊功能。這消除了任務監控標志本身的必要性。這有點類似于中斷服務程序。

在以后的文章中將有更多關于信號的信息，其中描述了它們在 Nucleus SE 中的實現。

事件標志組

事件標志組類似于信號，因為它們是面向位的任務間通信設施。它們可以類似地以 8、16 或 32 位的組來實現。它們與信號的不同之處在于它們是獨立的內核對象；它們不“屬于”任何特定任務。

任何任務都可以使用 OR 和 AND 操作設置和清除事件標志。同樣，任何任務都可以使用相同類型的操作詢問事件標志。在許多 RTOS 中，可以對事件標志組合進行阻塞 API 調用；這意味著任務可能會暫停，直到設置了特定的事件標志組合。當詢問事件標志時，還可能有一個“使用”選項可用，以便清除所有讀取標志。

在以后的文章中提供有關事件標志組的更多信息，其中描述了它們在 Nucleus SE 中的實現。

信號

量 信號量是獨立的內核對象，它提供了一種標記機制，通常用于控制對資源的訪問。大致有兩種類型：二進制信號量（只有兩種狀態）和計數信號量（具有任意數量的狀態）。一些處理器支持便于輕松實現二進制信號量的（原子）指令。二進制信號量也可以被視為計數限制為 1 的計數信號量。

任何任務都可能嘗試獲取信號量以獲取對資源的訪問權。如果當前信號量值大于0，則獲取成功，信號量值遞減。在許多操作系統中，可以通過阻塞調用來獲取信號量；這意味著一個任務可能會被掛起，直到另一個任務釋放信號量。任何任務都可以釋放一個信號量，這會增加它的值。

在以后的文章中有更多關于信號量的信息，其中描述了它們在 Nucleus SE 中的實現。

郵箱

郵箱是獨立的內核對象，它為任務提供了一種傳輸消息的方法。消息大小取決于實現，但通常是固定的。一到四個指針大小的項目是典型的消息大小。通常，指向一些更復雜數據的指針是通過郵箱發送的。一些內核實現了郵箱，因此數據只存儲在一個常規變量中，內核管理對它的訪問。郵箱也可以稱為“交換”，盡管這個名字現在已經不常見了。

任何任務都可以發送到郵箱，然后郵箱已滿。如果一個任務然后嘗試發送到一個完整的郵箱，它將收到一個錯誤響應。在許多 RTOS 中，可以進行阻塞調用以發送到郵箱；這意味著一個任務可能會被掛起，直到郵箱被另一個任務讀取。任何任務都可以從郵箱中讀取，這會再次使其為空。如果任務嘗試從空郵箱讀取，它將收到錯誤響應。在許多 RTOS 中，可以進行阻塞調用以讀取郵箱；這意味著一個任務可能會被掛起，直到郵箱被另一個任務填滿。

一些 RTOS 支持“廣播”功能。這使消息能夠發送到當前在讀取特定郵箱時暫停的所有任務。

某些 RTOS 根本不支持郵箱。建議改為使用單條目隊列（見下文）。這在功能上是等效的，但會帶來額外的內存和運行時開銷。

在以后的文章中會提供有關郵箱的更多信息，該文章描述了它們在 Nucleus SE 中的實現。

隊列

隊列是獨立的內核對象，它為任務提供了一種傳輸消息的方法。它們比郵箱更靈活、更復雜。消息大小取決于實現，但通常是固定大小和面向字/指針的。

任何任務都可能發送到隊列，并且這可能會重復發生，直到隊列已滿，此后任何發送嘗試都將導致錯誤。隊列的深度通常是用戶在創建或配置系統時指定的。在許多 RTOS 中，可以進行阻塞調用以發送到隊列；這意味著，如果隊列已滿，一個任務可能會被掛起，直到隊列被另一個任務讀取。任何任務都可以從隊列中讀取。消息的讀取順序與發送順序相同——先進先出 （FIFO）。如果一個任務試圖從一個空隊列中讀取，它將收到一個錯誤響應。在許多 RTOS 中，可以進行阻塞調用以從隊列中讀取；這意味著，如果隊列為空，則任務可能會暫停，直到另一個任務將消息發送到隊列。

RTOS 可能會支持將消息發送到隊列前面的功能——這也稱為“干擾”。一些 RTOS 還支持“廣播”功能。這使消息能夠發送到在讀取隊列時暫停的所有任務。此外，RTOS 可以支持可變長度消息的發送和讀取；這提供了更大的靈活性，但會帶來一些額外的開銷。

許多 RTOS 支持另一種稱為“管道”的內核對象類型。管道本質上與隊列相同，但處理面向字節的數據。

隊列的內部操作在這里不感興趣，但應該理解它們在內存和運行時的開銷比郵箱要多。這主要是因為需要維護兩個指針——指向隊列的頭部和尾部。

在以后的文章中有更多關于隊列和管道的信息，這些文章描述了它們在 Nucleus SE 中的實現。

互斥

信號量互斥信號量——互斥量——是獨立的內核對象，其行為方式與正常的二進制信號量非常相似。它們稍微復雜一些，并包含臨時所有權的概念（資源的，對其的訪問受到控制）。如果一個任務獲得了一個互斥鎖，那么只有同一個任務才能再次釋放它——互斥鎖（以及資源??）暫時歸任務所有。

并非所有 RTOS 都提供互斥鎖，但調整常規二進制信號量非常簡單。有必要編寫一個“互斥量獲取”函數，該函數獲取信號量并記錄任務標識符。然后一個互補的“互斥釋放”函數將檢查調用任務的標識符，只有當它與存儲的值匹配時才釋放信號量，否則它將返回錯誤。

Colin Walls 在電子行業擁有超過 30 年的經驗，主要致力于嵌入式軟件。Colin 經常在會議和研討會上發表演講，并著有大量技術文章和兩本關于嵌入式軟件的書籍，他是 Mentor Embedded ［Mentor Graphics Embedded Software Division］ 的嵌入式軟件技術專家，常駐英國。