微控制器實時作業系統實踐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之間是非常標準的，并且提供了很好的靈活性，

標籤：其他

上一篇：微控制器實時作業系統實踐3任務信令和通信機制

下一篇：返回列表