微控制器實時操作系統實踐3任務信令和通信機制

3任務信令和通信機制

在本章中，將簡要介紹任務信號和任務間通信的核心機制。這些基元是事件驅動的並行編程的基礎，它是基於RTOS的應用程式良好實現的基礎。

與其直接進入FreeRTOS的API，不如將每個基元與一些圖形例子和一些關於每個機制可被使用的建議一起介紹。不要擔心：在後面的章節中，我們將進入使用API的細枝末節。現在，讓我們把註意力集中在基本原理上。

實時操作系統隊列

隊列的概念相當簡單，但它們也非常強大和靈活，特別是如果你傳統上用C語言在裸機上編程的話。 在其核心，隊列只是一個迴圈緩衝區。然而，這個緩衝區包含一些非常特殊的屬性，比如原生的多線程安全，每個隊列可以靈活地容納任何類型的數據，以及喚醒正在等待隊列中出現的項目的其他任務。預設情況下，數據存儲在隊列中使用先進先出（FIFO）排序--第一個被放入隊列的項目就是第一個被從隊列中移除的項目。

我們將首先看看當隊列處於不同狀態和以不同方式使用時的一些簡單行為（發送與接收），然後繼續討論如何用隊列在任務之間傳遞信息。

簡單的隊列發送

第一個隊列例子是簡單地將一個項目添加（也被稱為發送）到有空位的隊列中：

當項目被添加到有可用空間的隊列中時，添加立即發生。因為隊列中的空間是可用的，所以將項目發送到隊列的任務繼續運行，除非有另優先順序更高的任務在等待隊列中出現的項目。

儘管與隊列的交互通常發生在任務內部，但這並不總是這樣的。在一些特殊情況下，隊列也可以從ISR中訪問（但這種行為有不同的規則）。在本章的例子中，我們將假設任務從隊列中發送和接收項目。

簡單的隊列接收

在下圖中，任務被顯從隊列中接收一個項目：

當任務準備從隊列中接收項目時，預設情況下，它將獲得最老的項目。在這個例子中，由於隊列中至少有一個項目，所以接收被立即處理，任務繼續運行。

滿隊列發送

當隊列已滿時，沒有信息被丟棄。相反，試圖將項目發送到隊列的任務將等待隊列中的可用空間，最長時間為預先確定的數量：

當隊列已滿時，試圖向隊列發送項目的任務將等待，直到隊列中的空間變得可用，但只到指定的超時值。

在這個例子中，如果任務試圖向滿的隊列發送，並且它的超時值是10毫秒--它將只等待10毫秒的隊列中的空間變得可用。超時結束後，調用將返回並通知調用代碼發送失敗。如何處理這個失敗是由設置調用代碼的程式員決定的，並將根據使用情況而變化。極大的超時值可以用於真正的非關鍵性功能。只是要註意，這將導致發送任務有效地永遠等待隊列中的空位（這顯然不再是實時的了）

你的代碼通常會被結構化，以便嘗試向隊列中發送不會超時。作為程式員，你應該根據具體情況來決定什麼是可接受的時間量。你也有責任確定超時的嚴重性和糾正措施，如果真的發生超時。潛在的糾正措施可以從什麼都不做（想想視頻通話中的丟幀）到緊急關機。

接收空隊列

訪問隊列可能導致任務阻塞的另一種情況是接收空隊列：

與等待空間的發送類似，從隊列中接收的任務也有可能被延遲。在空隊列的情況下，試圖從隊列中接收的任務將被阻塞，直到隊列中出現項目。如果在超時之前沒有項目出現，調用代碼將被通知失敗。同樣，要採取的確切行動方案也是不同的。

有時，會使用無限期的等待。你經常會遇到一些隊列的等待時間非常長，這些隊列正在接收來自外部介面的輸入，如串列埠，它們可能不會不斷地發送數據。如果串口另一端的人類用戶在很長一段時間內沒有發送數據，那就完全沒有問題。

另一方面，接收超時也可以用來確保你有一個最低可接受的數據量來處理。讓我們使用一個旨在以10赫茲（每秒10個讀數）提供新讀數的感測器。如果你正在實現一個依賴於這個感測器的新鮮讀數的演算法，一個略大於100毫秒的超時可以用來觸發一個錯誤。這個超時將保證該演算法總是在新鮮的感測器讀數上行動。在這種情況下，擊中超時可用於觸發某種類型的糾正措施或通知，說明感測器沒有按照預期執行。

任務間通信的隊列

既然已經介紹了隊列的簡單行為，我們就來看看如何利用它們在任務之間移動數據。隊列的非常常見的用例是讓一個任務填充隊列，而另一個任務則從同一隊列中讀取數據。這通常是直截了當的，但可能有一些細微的差別，這取決於系統是如何設置的：

在前面的例子中，任務1和任務2都在與同一個隊列進行交互。任務1將向隊列發送一個項目。只要任務2的優先順序比任務1高，它就會立即收到該項目。

讓我們考慮另一個實例，在實踐中，當多個任務與隊列進行交互時，經常會出現這種情況。由於搶占式調度器總是運行具有最高優先順序的任務，如果該任務總是有數據要寫入隊列，那麼在另一個任務有機會從隊列中讀取數據之前，隊列就會充滿。下麵是一個例子，說明這可能會發生的情況：

下麵的數字與時間軸上的索引相對應：

• 任務2試圖從空隊列中接收一個項目。沒有項目可用，所以任務2阻塞。
• 任務1向隊列添加項目。由於它是系統中優先順序最高的任務，任務1向隊列中添加項目，直到它沒有更多的項目可以添加，或者直到隊列已滿。
• 隊列被填滿了，所以任務1被阻塞了。
• 任務2被調度器賦予上下文，因為它現在是可能運行的最高優先順序任務。
• 一旦有項目從隊列中移出，任務1就會再次被賦予上下文（這是系統中優先順序最高的任務，它現在可以運行了，因為它在等待隊列中的空間時被阻塞了）。在添加一個項目後，隊列已經滿了，任務1被阻塞了。
• 任務2被賦予上下文並從隊列中接收一個項目：

隊列的另一個極其常見的用例是讓隊列接受來自許多不同來源的輸入。這對於像調試串口或日誌文件這樣的東西特別有用。許多不同的任務可以寫入隊列，由一個任務負責從隊列中接收數據並將其推送到共用資源上。

實時操作系統的信號

Semaphores是另一種非常直接的，但卻很強大的結構。semaphore這個詞起源於希臘語--近似的英語翻譯是sign-bearer，這是一種非常直觀的思考方式。信號燈被用來表示某些事情已經發生；它們是事件的信號。一些信號燈的使用案例包括以下內容：

• ISR完成了對外圍設備的服務。它可以給出信號，為任務提供信號，表明數據已經準備好進一步處理。
• 任務到達了關口，它需要等待系統中的其他任務跟上，然後再繼續前進。在這種情況下，可以用semaphore來同步任務。
  限制受限資源的同時使用者的數量。
• 使用RTOS的方便之處在於信號燈的預先存在。它們被包含在每RTOS的實現中，因為它們的功能是如此的基本（和關鍵）。有兩種不同類型的信號燈可供選擇：計數信號燈和二進位信號燈。

計數信號

Counting semaphores最常被用來管理對同時使用的用戶數量有限制的共用資源。在創建時，它們可以被配置為持有最大值，稱為上限。通常給出的計算semaphores的例子是資料庫中的讀者...... 好吧，我們在這裡談論的是基於MCU的嵌入式系統，所以讓我們保持我們的例子的相關性。如果你對資料庫感興趣，你可能最好用通用的操作系統! 對於我們的例子，假設你正在實現基於套接字的通信驅動，而你的系統只有足夠的記憶體來滿足有限數量的同時套接字連接。

在下圖中，我們有一個共用網路資源，可以容納兩個同時進行的套接字連接。然而，有三個任務需要訪問。計數信號被用來限制同時進行的套接字連接的數量。每當任務使用完共用資源（即它的套接字關閉），它必須交出它的信號，以便另一任務能夠獲得對網路的訪問。如果任務碰巧給了已經達到最大計數的信號燈，這個計數將保持不變：

前面的圖演繹了一個共用資源只能同時為兩個任務服務的例子（儘管系統中有三個任務需要使用該資源）。如果任務要使用套接字，而這個套接字受到計數信號的保護，它必須首先從池中獲取一個信號。如果沒有semaphore，那麼該任務必須等待，直到有semaphore可用：

• 最初，semaphore被創建，最大（上限）為2，初始計數為0。
• 當任務A和任務B試圖獲取semaphore時，他們立即成功。這時，他們可以各自打開套接字，通過網路進行通信。
• TaskC稍後，所以它需要等待，直到semaphores的計數小於2，這時網路套接字就可以自由使用了。
• 在TaskB完成了通過其套接字的通信後，它將返回semaphore。
• 現在有了semaphore，TaskC完成了它的取捨，並被允許訪問網路。
• 在TaskC獲得訪問權後不久，TaskB有另一條消息要發送，所以它試圖獲取信號燈，但需要等待可用的信號燈，所以它被置於睡眠狀態。
• 當TaskC在網路上進行通信時，TaskA完成並返回它的semaphore。
• 任務B被喚醒並完成了它的任務，這使得它能夠開始通過網路進行通信。
• 在TaskB得到它的信號後，TaskC完成了它的事務並歸還了它的信號。

等待信號是RTOS與其他大多數信號實現不同的地方--任務在等待信號時可以超時。如果任務未能及時獲得信號，它就不能訪問共用資源。相反，它必須採取另一種行動。這個替代行動可以是任何數量的行動，從嚴重到觸發緊急關機程式的故障，到僅僅在日誌文件中提及或推送到調試串口供以後分析的良性事件。作為一個程式員，應該由你來決定什麼是適當的行動方案，這有時會促使你與其他學科進行一些困難的討論。

二進位信號

二進位信號燈實際上就是最大計數為1的計數信號燈，它們最常用於同步。當任務需要在事件上進行同步時，它將嘗試使用信號鏈，阻塞直到信號鏈變得可用或直到指定的超時時間結束。系統的另非同步部分（無論是任務還是ISR）將給出信號燈。二進位semaphores可以被多次給出，那段代碼沒有必要返回它們。在下麵的例子中，任務A只給出信號，而任務B只接受信號：

任務B被設置為在繼續履行其職責之前等待信號（信號）：

• 最初，TaskB試圖接受信號，但它並不存在，所以TaskB進入了睡眠狀態。
• 過了一段時間，任務A發出了信號。
• 任務B被喚醒（由調度器喚醒；這發生在後臺），現在有了信號燈。它將進行它所需要的工作，直到完成。然而，請註意，任務B不需要歸還二進位信號。相反，它只是再次等待它。
• 任務B再次被阻塞，因為信號燈不可用（就像第一次一樣），所以它進入睡眠狀態，直到有信號燈可用。
  周而複始。

如果任務B "交還 "二進位信號，它將立即再次運行，而不會收到來自任務A的指令。其結果只是全速運行的迴圈，而不是在任務A發出信號的條件下被提示。

實時操作系統的互斥

術語mutex是相互排斥的簡寫。在共用資源和任務的上下文中，互斥意味著，如果一個任務正在使用共用資源，那麼該任務是唯一被允許使用該資源的任務--所有其他任務都需要等待。

如果這一切聽起來很像二進位信號燈，那是因為它就是。然而，它還有一個額外的功能，我們很快就會介紹。首先，讓我們來看看使用二進位信號燈來提供相互排斥的問題。

優先順序倒置

讓我們來看看在試圖使用二進位信號提供互斥功能時發生的常見問題。
考慮三個任務，A、B和C，其中A的優先順序最高，B的優先順序居中，而C的優先順序最低。任務A和C依靠信號燈來訪問它們之間共用的資源。由於任務A是系統中優先順序最高的任務，它應該總是在其他任務之前運行。然而，由於任務A和任務C都依賴於它們之間共用的資源（由二進位信號燈守護），這裡有意外的依賴關係：

讓我們一步一步地通過這個例子來看看這種情況是如何發生的：

• 任務C（系統中優先順序最低的任務）獲得了二進位信號，開始做一些工作。
• 在任務C完成工作之前，任務A（最高優先順序的任務）中斷並試圖獲得相同的信號，但由於任務C已經獲得了信號而被迫等待。
• 任務B也搶占了任務C，因為任務B的優先順序比任務C高。
• 任務C用共用資源完成了剩餘的工作，這時它把信號燈還給了任務C。
• 任務A終於可以運行了。

任務A最終能夠運行，但要等到兩個低優先順序的任務都運行完了才行。任務C用共用資源完成它的工作是不可避免的（除非在設計上做出改變，以防止它與任務A訪問相同的共用資源）。然而，任務B也有機會運行到完成，儘管任務A在旁邊等待，並且有更高的優先順序！這就是優先順序倒置--更高的優先順序是指任務A在完成工作時，他的任務也在完成！這就是優先順序倒置--系統中優先順序較高的任務正在等待運行，但它被迫等待，而另一個優先順序較低的任務正在運行--在這種情況下，這兩個任務的優先順序實際上是倒置的。

互斥器使優先順序倒置最小化

早些時候，我們曾說過，在FreeRTOS中，突變體是二進位信號，有一個重要的附加功能。這個重要的特性就是優先順序繼承--互斥器有能力暫時改變一個任務的優先順序，以避免在系統中造成重大延誤。當調度員發現一個高優先順序的任務試圖獲取一個已經被低優先順序的任務所持有的突變時，就會出現這種情況。在這種特定情況下，調度器將暫時提高低級任務的優先順序，直到它釋放突變。在這一點上，低級任務的優先順序將被設置回它在優先順序繼承之前的狀態。讓我們來看看上圖中使用互斥（而不是二進位信號）實現的完全相同的例子：

讓我們一步一步地通過這個例子來看看這種情況是如何發生的：

• 任務A仍然在等待任務C返回互斥。
• 任務C的優先順序被提高到與更高優先順序的任務A相同。任務C運行到完成，因為它持有mutex，是一個高優先順序的任務。
• 任務C返回突變，它的優先順序被降到了它持有突變之前的水平，因為突變耽誤了高優先順序任務。
• 任務A拿著mutex並完成了它的工作。
• 任務B被允許運行。

根據任務C在共用資源上花費的時間，以及任務A的時間敏感性，這可能是一個主要的問題，也可能不是什麼大問題。可以進行時間分析，以確保任務A仍然符合最後期限，但跟蹤所有可能的優先順序倒置和其他高優先順序非同步事件的原因可能被證明是具有挑戰性的。至少，用戶應該利用為獲取突變提供的內置超時，併在突變未能及時獲取的情況下執行適當的替代行動。關於如何實現這一目標的更多細節可以在第9章 "任務間通信 "中找到。

Mutexes和semaphores是任務間信號傳遞的相當標準的機制。它們在不同的RTOS之間是非常標準的，並且提供了很好的靈活性。