1、嵌入式軟件與設計模式

思從深而行從簡

軟件開發(fā)，難的不是編寫軟件，而是編寫功能正常的軟件。軟件工程化才能保證軟件質(zhì)量和項目進度，而設計模式使代碼開發(fā)真正工程化，設計模式是軟件工程的基石。

所謂設計模式就是對常見問題的通解，合理地運用設計模式可以很好地解決很多問題，每種模式針對一個通用問題，以及該問題的核心解決方案，這也是設計模式能被廣泛應用的原因。真正的高手能云淡風輕地用最簡單的方法解決最復雜的問題，這也是高級程序員與新手的本質(zhì)區(qū)別之一。

一般常見的是四人幫模式即GOF的23種設計模式，是偏向于可復用的面向?qū)ο蟮能浖?，并不能很完美的契?a href="http://www.wenjunhu.com/soft/data/21-22/" target="_blank">嵌入式軟件，因為嵌入式C語言是結構化的語言，與硬件關聯(lián)。雖然也可強制封裝結構體實現(xiàn)類似效果（復雜的嵌入式應用軟件也可使用，但對于通用PC的高級語言存在差距）。

基于嵌入式系統(tǒng)的工作流，選擇合適的設計模式或代碼框架，將復雜軟件解耦或者分層，提高代碼復用度和可擴展性具有一定意義，當然，代價是對資源和實時性的損耗。

微信公眾號【嵌入式系統(tǒng)】專門針對嵌入式系統(tǒng)軟件，提供四大類設計模式。

微信公眾號【 嵌入式系統(tǒng) 】嵌入式系統(tǒng)軟件設計模式 ：

1、硬件訪問類

2、并發(fā)同步類

3、狀態(tài)與工作流類

4、安全性與可靠性類

設計模式是在已具備一定開發(fā)基礎的前提下，對軟件架構的優(yōu)化，因此部分章節(jié)需要熟悉數(shù)字電路、RTOS實時操作系統(tǒng)等，才能更好的理解。更多理論信息可關注微信公眾號【 嵌入式系統(tǒng) 】的其他文章。

2、硬件訪問類設計模式

2.1 硬件訪問的概念

嵌入式系統(tǒng)最明顯的特性是可直接訪問硬件，硬件操作通常會包括初始化、配置、控制等步驟，嵌入式軟件管理硬件，給硬件提供命令或數(shù)據(jù)，或者從其獲取信息，這塊即是常說的硬件驅(qū)動代碼。這類軟件設計主要是考慮硬件器件的更換與兼容，對業(yè)務層的封裝和隔離。

2.2 硬件代理模式

硬件代理模式（Hardware Proxy Pattem）使用結構體封裝所有硬件設備訪問，無論其硬件接口是怎樣的，代理為客戶提供與硬件形態(tài)無關的接口。

如果應用層直接訪問硬件設備，硬件的變化所導致的問題會加??；一個細節(jié)的改變，應用層均需要重新調(diào)整，通過提供介于應用層和硬件之間的代理，就極大地限制了硬件改變的影響，從而減少這樣的修改。類似常說的代理律師，就是即使不懂法律，但可以請律師，由代理律師去活動。

硬件代理接口可以形如 init、open、close、read、write、control，其內(nèi)部實現(xiàn)無需開放。函數(shù)名稱或者結構體內(nèi)函數(shù)指針名只是參考，也可以自定義諸如config等，這里只是說明，對不同的硬件設備統(tǒng)一訪問接口，封閉細節(jié)。

但是也有一定缺點，硬件細節(jié)已經(jīng)在硬件代理內(nèi)部完全封裝，對運行實時性有不良的影響。其實， 所有的設計模式都是利于軟件維護，而不利于實時性 。代理模式只是簡單封裝接口，不能實現(xiàn)線程安全，除非在封裝時額外增加加臨界區(qū)或者隊列保護。

例如開啟加速度傳感器，最初需求只有一顆如BMA425，其開啟接口為 gsensor_bma425_open；但后期硬件替換為SCA720，如果是直接操作則需重寫驅(qū)動，將原開啟接口全部替換為gsensor_sc7a20_open。這種方式固然效率高，但也導致代碼維護困難，從驅(qū)動層到業(yè)務層都需要替換接口。而且不能實現(xiàn)軟件自動識別其型號，自動匹配驅(qū)動，對項目維護也是較大工作量。

如果改為硬件代理，則可以先封裝函數(shù)指針結構體，偽代碼形如

typedef struct
{
   *init;
   *open;
   *close;
}gsensor_ops_t;

gsensor_ops_t  bma425;
gsensor_ops_t  sc7a20;
gsensor_ops_t* p_gsensor_ops;

所有業(yè)務層訪問p_gsensor_ops，至于其究竟是哪一顆傳感器則無需關注，擴展或者更換硬件無需修改業(yè)務層。最佳的方案是驅(qū)動層可以根據(jù)硬件固有差異，如芯片ID或者I2C從機地址，識別出具體硬件型號，自動將p_gsensor_ops指向具體的型號的驅(qū)動接口，對軟件版本和生產(chǎn)維護更加友好，不管硬件如何變化，軟件一版即可。

2.3 硬件適配器模式

硬件適配器模式 （Hardware Adapter Patterm) 在兩個接口之間進行轉換，使已經(jīng)存在硬件接口能適應新的期望。

適配器模式的最直觀應用是手機充電器，市電220V的交流電，但手機只支持5V的直流電，要確保手機正常充電，就是在充電鏈路中增加適配器，將220v的交流轉換為5v的直流。

一般來說具有同一個功能的硬件器件，其接口往往相似，比如前面提到的加速度傳感器，不管是哪個廠商，都是提供I2C或者SPI接口。硬件適配器模式則是在業(yè)務層和硬件層之間加入相互轉換，創(chuàng)建適配器提供客戶期望的接口，而不是重寫硬件設備的接口，最少化返工代碼。

在軟件開發(fā)中經(jīng)常有同個物理量，不同硬件的表示數(shù)值不同，前面提到的加速度傳感器，因為量程和精度的差異，加速度大小1g的表示值，不同的傳感器xyz三軸數(shù)值不同，有的是512表示1g，有的是256表示1g；這樣對業(yè)務層的邏輯算法就難以統(tǒng)一標準。所以可以在業(yè)務算法和硬件驅(qū)動之間，增加適配轉換，統(tǒng)一1g的表示值，這樣才能保證硬件的變化不影響算法。

再比如簡單的例子，將第三方庫移植到不同的平臺，因為參數(shù)等信息不完全相同，原來是傳入1-100表示百分比，但新接口是以0.01~1.00表示，則需要在調(diào)用接口前轉換兩者關系。所以，硬件適配器模式一般用在硬件器件更換，或者軟件跨平臺移植，它并沒具體的接口套路，是因地制宜，按接口形式轉換。

2.4 中介者模式

中介者模式（Mediator Pattern）是用來降低多個元素之間的通信復雜性，提供一個中介類，協(xié)調(diào)處理不同類之間的通信，各子類之間不直接通信，松耦合，使代碼易于維護。

比如而二手房交易，有10個買家與10個賣家，如果都直接去溝通對接，每人需要和10人對接，而且信息沒經(jīng)過過濾，溝通效率低；如果有個中介，所有人都只與中介對接，中介再按買家和賣家意愿，轉達有效意見，買家與賣家無需直接交流，就能促成滿意的交易。每添加新元素就需更新中介者，最終可能導致中介者越發(fā)難以維護；如果中介者出現(xiàn)問題，則中介功能包括相關元素程序崩潰，這和房產(chǎn)交易中介卷錢跑路一樣。

軟件中定義兩種角色分別為合作者和中介者，合作者 (Collaborator) 指所有可能被中介者調(diào)用的具體對象，中介者 (Mediaior) 協(xié)調(diào)多個具體合作者。中介者需要明確每個合作者交互的消息，從哪來，到哪去。當感興趣的事件發(fā)生時，合作者可以給中介者發(fā)送消息，中介者提供協(xié)調(diào)邏輯，或者與消息關聯(lián)的合作者通信。

中介者與每個具體合作者一般通過多個指針連接，如果具體的合作者的接口一致，指針數(shù)組是最好的。兩種角色的結構體定義偽代碼形如下，針對的場景是根據(jù)汽車引擎點火acc狀態(tài)，加速度傳感器gsensor監(jiān)測的震動信息，GPS衛(wèi)星定位獲取運行速度，三組數(shù)據(jù)組合判斷當前車輛是處于什么狀態(tài)。

//中介者管理3個關聯(lián)合作者
typedef struct mediator_t
{
    colleague_t *acc;
    colleague_t *gsensor;
    colleague_t *gps;
    mediator_relay relay;
}mediator_t;

//每個合作者提供2個接口，向中介者發(fā)消息，和接收處理中介者的消息
typedef struct colleague_t
{
    mediator_t *m_mediator;
    colleague_send send;
    colleague_receive receive;
}colleague_t;

合作者發(fā)送消息時不明確是誰執(zhí)行，只管發(fā)送；中介者需要識別類型，按既定規(guī)則轉發(fā)給對應的合作者執(zhí)行。這也是中介者模式的缺點，中介者代碼龐大，隨著合作者數(shù)量的增加會變得復雜難以維護。完整的演示代碼如下。

//微信公眾號：嵌入式系統(tǒng)
#include 

typedef enum
{
    EVENT_1,
    EVENT_2,
    EVENT_3,
    EVENT_MAX
}event_t;//模擬測試消息

struct mediator_t;
typedef int (*mediator_relay)(event_t id,void *data,int len);

struct colleague_t;
typedef int (*colleague_send)(event_t id,void *data,int len);
typedef int (*colleague_receive)(event_t id,void *data,int len);

typedef struct mediator_t
{
    colleague_t *acc;
    colleague_t *gsensor;
    colleague_t *gps;
    mediator_relay relay;
}mediator_t;

typedef struct colleague_t
{
    mediator_t *m_mediator;
    colleague_send send;
    colleague_receive receive;
}colleague_t;

/*******************************************************/
//合作者接口
static colleague_t colleague_acc={0};
static colleague_t colleague_gsensor={0};
static colleague_t colleague_gps={0};
static int colleague_acc_send(event_t id,void *data,int len)
{
    colleague_t *handle=&colleague_acc;
    handle->m_mediator->relay(id,data,len);
}

static int colleague_acc_receive(event_t id,void *data,int len)
{
    printf("ACC recv id=%d,%s\\r\\n",id,data);
}

static int colleague_gsensor_send(event_t id,void *data,int len)
{
    colleague_t *handle=&colleague_gsensor;
    handle->m_mediator->relay(id,data,len);
}

static int colleague_gsensor_receive(event_t id,void *data,int len)
{
    printf("gSensor recv id=%d,%s\\r\\n",id,data);
}

static int colleague_gps_send(event_t id,void *data,int len)
{
    colleague_t *handle=&colleague_gps;
    handle->m_mediator->relay(id,data,len);
}

static int colleague_gps_receive(event_t id,void *data,int len)
{
    printf("GPS recv id=%d,%s\\r\\n",id,data);
}

/*******************************************************/
//中介者接口
static mediator_t mediator_manager={0};

//中介者協(xié)調(diào)全局，將對應的事件轉發(fā)給有需要的合作者，范例只是說明用法，隨意定義的關系
//這個函數(shù)中介者模式維護的重點，也是它的缺點
static int mediator_msg_relay(event_t id,void *data,int len)
{
    mediator_t *handle=&mediator_manager;

    switch(id)
    {
    case EVENT_1:
        handle->gsensor->receive(id,data,len);
        break;
    case EVENT_2:
        handle->gps->receive(id,data,len);
        break;
    case EVENT_3:
        handle->acc->receive(id,data,len);
        break;
    default:
        break;
    }
}

/*******************************************************/
//測試接口
//如果覺得這樣有一定耦合度，可以由中介者提供注冊API給合作者調(diào)用，傳入自身地址給中介者
static void init_member(void)
{
    colleague_acc.m_mediator=&mediator_manager;
    colleague_acc.send=colleague_acc_send;
    colleague_acc.receive=colleague_acc_receive;

    colleague_gsensor.m_mediator=&mediator_manager;
    colleague_gsensor.send=colleague_gsensor_send;
    colleague_gsensor.receive=colleague_gsensor_receive;

    colleague_gps.m_mediator=&mediator_manager;
    colleague_gps.send=colleague_gps_send;
    colleague_gps.receive=colleague_gps_receive;

    mediator_manager.acc=&colleague_acc;
    mediator_manager.gsensor=&colleague_gsensor;
    mediator_manager.gps=&colleague_gps;
    mediator_manager.relay=mediator_msg_relay;
}

//微信公眾號：嵌入式系統(tǒng)
int main(void)
{
    printf("embedded-system\\r\\n");
    init_member();
    colleague_acc.send(EVENT_1,(void*)"from acc",0);
    colleague_gsensor.send(EVENT_2,(void*)"from gsensor",0);
    colleague_gps.send(EVENT_3,(void*)"from gps",0);
    return 0;
}

看懂范例才能更好的理解中介者模式的價值。

//微信公眾號：嵌入式系統(tǒng)
//運行結果：
embedded-system
gSensor recv id=0,from acc
GPS recv id=1,from gsensor
ACC recv id=2,from gps

三個關聯(lián)合作者互相交互，只處理與自己關聯(lián)的事件，對外或者app有問題就找中介，不與具體的合作者通信。

2.5 觀察者模式

觀察者模式提供一種方法來使對象“監(jiān)聽”其他對象，而不需要修改任何數(shù)據(jù)服務器。在嵌入式領域，適合傳感器采樣或者某些周期更新的數(shù)據(jù)，轉發(fā)給關注它的元素，比較類似發(fā)布--訂閱模式。

好比在紅綠燈路口，交通信號燈由綠變紅，整條車道的車都會收到該信息并進行制動處理。信號燈本身不關注外界，只是按自己的節(jié)奏控制燈的變化；而眾多車主觀察到紅燈，都進行停車動作。

一個目標對象的狀態(tài)發(fā)生改變，所有的依賴對象（觀察者對象）都將得到通知。在嵌入式軟件的實現(xiàn)上，觀察者模式通過在數(shù)據(jù)生產(chǎn)服務器添加訂閱和取消訂閱，服務器端不需要任何客戶的先驗信息。數(shù)據(jù)服務器按一定的更新策略，通知對其感興趣的客戶。

軟件上，通知列表最簡單的方式是定義一個足夠大的數(shù)組來包含所有潛在的客戶，在有很多客戶的高度動態(tài)的系統(tǒng)中這會浪費內(nèi)存，另一種方案是用鏈表構建一個系統(tǒng)。數(shù)據(jù)產(chǎn)生服務提供眾多函數(shù)指針，有需求的客戶提供自身句柄，一般是回調(diào)函數(shù)指針；當響應數(shù)據(jù)變化按既定策略執(zhí)行回調(diào)，實現(xiàn)數(shù)據(jù)源的變化信息廣播到所有觀察者的效果。

例如設備支持GPS衛(wèi)星定位，在驅(qū)動上報GPS信息的接口，底層提供一個函數(shù)指針數(shù)組，上層用自身的回調(diào)函數(shù)填充數(shù)組。底層獲取到GPS信息后，查詢數(shù)組，若回調(diào)函數(shù)非空則執(zhí)行。每個回調(diào)函數(shù)由各模塊分別實現(xiàn)，代碼整潔，耦合性低。

//微信公眾號：嵌入式系統(tǒng)
#include 
#include 

#define PAL_GNSS_SUBSCRIPTIONS_MAX 5

typedef unsigned char uint8_t;
typedef void (*gnss_info_callback)(void* data);

typedef struct
{
    gnss_info_callback m_cb;
} pal_gnss_subscription_info;

//訂閱池
static pal_gnss_subscription_info g_gnss_subscription_pool[PAL_GNSS_SUBSCRIPTIONS_MAX] = {0};

//訂閱
uint8_t pal_gnss_subscribe(gnss_info_callback callback)
{
    uint8_t i;
    uint8_t ret=0;

    if(callback != NULL)
    {
        for(i = 0; i < PAL_GNSS_SUBSCRIPTIONS_MAX; i++)
        {
            if(g_gnss_subscription_pool[i].m_cb == NULL)
            {
                //RTOS注意競爭
                g_gnss_subscription_pool[i].m_cb = callback;
                ret = 1;
                break;
            }
        }
    }
    else
    {
        ret = 0;
    }
    return ret;
}

//取消訂閱
void pal_gnss_unsubscribe(gnss_info_callback callback)
{
    uint8_t i;

    for(i = 0; i < PAL_GNSS_SUBSCRIPTIONS_MAX; i++)
    {
        if(g_gnss_subscription_pool[i].m_cb == callback)
        {
            //RTOS注意競爭
            g_gnss_subscription_pool[i].m_cb = NULL;
            break;
        }
    }
}

//廣播給觀察者，執(zhí)行回調(diào)
void pal_gnss_info_update(void)
{
    uint8_t i;
    uint8_t data=1;//test

    for(i = 0; i < PAL_GNSS_SUBSCRIPTIONS_MAX; i++)
    {
        if(g_gnss_subscription_pool[i].m_cb != NULL)
        {
            //RTOS中使用消息隊列更好，這里只是演示效果
            g_gnss_subscription_pool[i].m_cb((void*)&data);
        }
    }
}

//微信公眾號：嵌入式系統(tǒng)
int main(void)
{
    printf("embedded-system\\r\\n");
    return 0;
}

觀察者模式，訂閱-發(fā)布機制尤其傳感器采集數(shù)據(jù)，分發(fā)給不同模塊，各模塊收到廣播后按自身需求處理數(shù)據(jù)的場景。

2.6 消抖過濾模式

這個簡單的模式用于消除來自于金屬表面間歇性連接引起的多個假事件。

按鈕、撥動開關和機電式繼電器等機械式輸入設備，它們都有一個共同的問題，即接觸金屬產(chǎn)生連接，金屬變形或“彈性”在開關轉換時產(chǎn)生間歇連接。從而導致控制系統(tǒng)中有多個電子信號。消抖過濾模式通過在首次檢測到異常信號后，等待一段時間將多個信號減少到一個信號。簡單且常見的場景就是按鍵消抖，這也是嵌入式入門的基礎。

嵌入式系統(tǒng)軟件檢測到首次跳變事件，設置延遲定時器 〈如果需要關閉設備中斷) ，隨后檢查設備狀態(tài)。一定時間后（去抖動時間），如果狀態(tài)不同，則事件一定是真實的，則發(fā)送相應的信息給應用層。因為按鍵防抖屬于嵌入式軟件入門基礎，這里不做詳細描述，重點關注定時器，可以采用CPU延時等待，也可以采用硬件定時實現(xiàn)，后者更合理。

關于按鍵檢測，底層區(qū)分按鍵碼和按鍵事件類型（短按、長按、連續(xù)按），可以參考 《按鍵檢測》，結合觀察者模式，使用二維數(shù)據(jù)管理按鍵回調(diào)函數(shù)，可以實現(xiàn)按鍵檢測驅(qū)動與業(yè)務的隔離。

2.7 中斷模式

物理世界從根本上來說是并發(fā)與異步的，事情該發(fā)生時它就會發(fā)生，如果嵌入式系統(tǒng)不加以注意，這些事件可能丟失。為了及時監(jiān)測感興趣的事件，硬件中斷模式，即中斷中斷服務程序是最有效的方法。

中斷模式是一種構造系統(tǒng)的方式，用于對傳入事件作出適當?shù)姆磻Ｔ谇度胧较到y(tǒng)中，事件分為不同等級的緊急度，即使在系統(tǒng)非常繁忙地處理其它事件時也必須處理。在本章其他內(nèi)容中討論的輪詢模式中，在系統(tǒng)方便的時候查詢感興趣的事件；雖然這是有好處的，不中斷當前正在執(zhí)行的過程，但它的缺點是高緊急度和高頻率的事件可能得不到及時處理。中斷模式通過立即停止當前的過程，處理傳入事件來解決這個問題，并且隨后返回原來的流程。

通常情況下，當中斷服務程序ISR執(zhí)行時，關閉中斷，這意味著中斷服務程序必須快速執(zhí)行以確保不會丟失其他中斷。因為中斷服務程序必須很短，當它們調(diào)用其他的系統(tǒng)服務時必須非常小心。如果ISR 處理占用太長時間，在共享資源上出現(xiàn)競爭條件或發(fā)生死鎖，問題很難跟蹤。

中斷模式是嵌入式軟件特有的，硬件中斷的特點是響應及時，處理要簡短，尤其是在RTOS中。

2.8 輪詢模式

另一種從硬件獲取傳感器數(shù)據(jù)或信號的常用模式是定期檢查，稱為輪詢過程。當數(shù)據(jù)或信號不是非常緊急到不能等待到下一個輪詢時段來收取，或當數(shù)據(jù)或信號可用時，硬件沒有能力生成中斷（或缺乏中斷檢測口），這時輪詢非常有用。

輪詢分定期或者不定期進行，定期輪詢使用定時器按固定間隔查詢，不定期即機會輪詢是當系統(tǒng)方便的時候才輪詢，沒有固定間隔。

定期輪詢主要用于周期性的變化，或者變化很緩慢的狀態(tài)，按合適的間隔定時查詢設備狀態(tài)，如果數(shù)據(jù)或信號輪詢時間加上反應處理時間，比數(shù)據(jù)更新間隔長，那就必須引起注意，否則數(shù)據(jù)將會丟失。因為定期輪流，其本身檢查綁定一個定時器中斷，因此定期輪詢模式其實是中斷模式的特殊情況。

不定期輪詢是當系統(tǒng)方便的時候才輪詢，如在主系統(tǒng)功能或在重復執(zhí)行的周期點之間，在低端單片機上比較常見，對其他系統(tǒng)從事的活動的及時性影響也小。非定期的模式如果時間非常短，也可以嵌套在其它驅(qū)動中，諸如死循環(huán)循環(huán)等待某個狀態(tài)，比如查詢UART發(fā)送完成，IIC的ACK響應，但是這種循環(huán)體一定要注意，必須留有一定會退出循環(huán)的條件。

2.9 小結

硬件代理模式關注指定硬件細節(jié)的封裝，解決硬件元件更新迭代和多個同類器件的兼容。

而硬件適配器模式為適應不同但是相似的硬件，也解決跨平臺移植。

硬件器件組合工作，或者軟件需求的復雜交互則適合中介者模式。

觀察者模式為硬件數(shù)據(jù)支持動態(tài)添加和刪除客戶，適合多個模塊共享傳感器數(shù)據(jù)的場景。

消抖過濾模式、中斷模式、輪詢模式用于解決與硬件交互的低層次問題。

軟件模式的選擇，與硬件框架、資源和軟件需求、應用場景相關，合適的才是最好的。

3、并發(fā)同步類設計模式

3.1 并發(fā)和RTOS概念

基于RTOS的軟件，宏觀上多個任務并行，實際是多任務的分時調(diào)度，對應著硬件資源可能就是前任務還未完成訪問，后任務要搶占使用，這切換過程中就存在競爭。若沒有RTOS相關基礎，可以先參考基于[《RTOS的軟件開發(fā)理論》]和 [《FreeRTOS及其應用，萬字長文，基礎入門》]，否則本章信息可能無法理解。當任務調(diào)度啟動后，所有的任務獨立運行，如何設計避免一個資源被多個任務搶占使用，按串行訪問共享資源？

3.2 臨界區(qū)模式

臨界區(qū)模式是與任務協(xié)調(diào)相關的最簡單粗暴的模式。禁止任務在區(qū)域內(nèi)轉換，通過禁用任務轉換甚至禁止中斷來處理競爭關系，保證當前任務不間斷的執(zhí)行，直到完成相關操作退出臨界區(qū)。

臨界區(qū)模式結構簡單，受保護的元素是資源而不是任務，在臨界區(qū)開始之前禁止任務切換，并在服務結束后重新可用。RTOS提供臨界區(qū)進出時的任務切換使能處理，或者直接在硬件級別配置中斷等方式開關中斷處理。

臨界區(qū)模式關閉任務調(diào)度或者中斷響應，實際會影響其他任務的時序。因此要求臨界區(qū)持續(xù)時間很短，一般是在同一個任務內(nèi)使用互斥鎖或者臨界區(qū)接口，快速完成相應操作，否則可能導致系統(tǒng)異常。例如有2個任務模塊共享讀寫某一塊內(nèi)存數(shù)據(jù)，或者操作某個寄存器，就比較適合臨界區(qū)。

3.3 守衛(wèi)調(diào)用模式

守衛(wèi)調(diào)用模式，通過提供的鎖定機制串行訪問，以阻止鎖定后其他線程的調(diào)用服務，簡單描述就是A任務占用某個資源后，將其鎖定；優(yōu)先級高于A的B任務想要使用它，得先咨詢能否使用，如果資源處于鎖定狀態(tài)則延時等待（相應的任務阻塞，即使優(yōu)先級更高），等到前一個任務使用結束，解鎖釋放資源，B任務才能執(zhí)行。

這里面存在一定問題，如果還有任務C，其優(yōu)先級介于A和B之間，表面上C會先執(zhí)行，導致優(yōu)先級低的C竟然比任務B先執(zhí)行，即優(yōu)先級反轉，實際不會這樣。

一般RTOS信號量支持優(yōu)先級繼承，即任務B使用某個信號量等待A任務時，臨時會將A任務的優(yōu)先級提高，和B相等，實際執(zhí)行順序是B-A-C。

通過信號量的獲取和釋放，來獨占的訪問某個硬件或者軟件資源，其對時間沒有太嚴格要求，這種在業(yè)務層開發(fā)更常見。一般在兩個任務或者任務與中斷間，進行鎖定，確保共享資源按順序使用，也可用于同步交互。

兩個任務同步處理的場景，AT指令的發(fā)送任務和接收解析任務適合信號量，發(fā)送任務必須等前一AT回復，發(fā)出AT后阻塞等待信號量；接收解析任務確認接收完成，釋放信號量；這時發(fā)送任務才能退出阻塞，發(fā)送下一個AT。

3.3 隊列模式

隊列模式是任務間異步通信最常見的實現(xiàn)，在非耦合的任務間及時通信，通過隊列先進先出的數(shù)據(jù)結構，發(fā)送者將消息存入隊列，接收者從隊列中取出消息。它也提供一種簡單方法串行訪問共享資源，將訪問消息排隊，并且在稍后的時間中處理，這就避免了共享資源常見的相互排斥的問題。

消息隊列使用異步通信，并且不會遇到互斥問題，這是因為沒有引用共享資源。消息隊列以單一的形式避免并發(fā)系統(tǒng)中通過傳遞引用共享信息產(chǎn)生的資源損壞的問題。在傳值共享中，制作一個信息的副本，并且發(fā)送給接收線程進行處理。接收線程完全擁有收到的數(shù)據(jù)，并且因此能夠自由修改，而不需要考慮由于多個寫者，或者在一個寫者和多個讀者中共享它們造成信息損壞。其缺點之一是發(fā)送者傳遞消息后不能立即處理，需要進程等待，直到接收者任務運行，并且能夠處理正等待的消息。

隊列模式通過對數(shù)據(jù)和命令排隊串行訪問數(shù)據(jù)，允許接收者每次處理一個。由于它是異步完成，所以消息發(fā)送和處理之間的時間是非耦合的。這可能不滿足系統(tǒng)的性能需求。守衛(wèi)調(diào)用模式也串行訪問，但是同步執(zhí)行，以便數(shù)據(jù)和命令傳輸發(fā)生在時間上更加接近。但關于信號量的釋放使用出現(xiàn)問題，會導致較嚴重的錯誤。

隊列的最簡單的實現(xiàn)策略是消息元素數(shù)組。這具有簡單性的優(yōu)點，但是缺乏鏈表的靈活性隊列是很容易實現(xiàn)的，但是有很多可能的變體。有時一些消息比其他的更加緊急或者重要，并且應該在等待的低優(yōu)先級消息之前處理。擴展添加多個緩沖區(qū) (每個優(yōu)先級一個) 實現(xiàn)優(yōu)先級修改，或者基于消息優(yōu)先級 ，但是這樣會很麻煩。

一般還是固定長度的數(shù)組隊列，但是可以向隊列頭或者尾插入新數(shù)據(jù)，這種滿足絕大部分需求，這種情況下需要注意的是接收處理要及時，避免隊列溢出。

例如只有1個UART，通過開關切換分時復用接2個外設，就比較適合隊列模式，讀寫請求緩存到隊列，按序取出執(zhí)行，避免出現(xiàn)收發(fā)數(shù)據(jù)不完整的問題。

3.4 匯合模式

任務同步發(fā)生在簡單的函數(shù)調(diào)用、共享單一資源或者傳遞數(shù)據(jù)，可用隊列模式或守衛(wèi)調(diào)用模式，但如果同步需要的條件更加復雜，涉及多個任務間的同步，匯合模式更適合解決任務間復雜形式同步的問題。

在這個模式中，兩個或更多的任務通過操作類似全局變量的位，按變量相應位的狀態(tài)執(zhí)行不同動作。在RTOS內(nèi)核中，如freeRTOS，這個全局變量叫事件組，其讀寫操作也有相應的API。

例如3個子任務各自監(jiān)測不同外設，主任務收到3個子任務反饋的外設連接正常的事件，主任務才在UI界面提示所有外設連接正常。

3.5 小結

并發(fā)才是嵌入式軟件開發(fā)的常態(tài)，事情并行發(fā)生必須預防競爭與沖突，這也是實時操作系統(tǒng) (RTOS) 的基本要求。

臨界區(qū)模式、守衛(wèi)調(diào)用模式和隊列模式解決在多任務環(huán)境下串行訪問資源的問題。臨界區(qū)模式在資源訪問期間關閉任務轉換，因此防止可能的資源數(shù)據(jù)損壞，但是阻塞了更高優(yōu)先級任務，使它們永遠不能訪問資源。

守衛(wèi)調(diào)用模式通過信號量完成相同的資源保護目標，該模式可能能夠?qū)е聝?yōu)先級倒置，所以該模式需要使用支持優(yōu)先級繼承的方式。

隊列模式串行訪問資源，通過將請求放在隊列中，并且按照先進先出 (FIFO) 的順序從隊列取出，隊列模式概念上非常簡單，但是導致資源的請求響應延遲，影響時效性。

看起來這些模式很高級，其實主流的實時操作系統(tǒng)，其內(nèi)核都支持這些模式相關的接口。內(nèi)核開發(fā)的大佬們，早就洞悉了并發(fā)的風險與模式，使用內(nèi)核的互斥鎖、信號量、隊列和事件組，可以很容易的實現(xiàn)這些模式。

如果基于裸機開發(fā)，主程序和中斷程序也近似存在共享沖突，可以自定義全局變量、循環(huán)數(shù)組實現(xiàn)守衛(wèi)調(diào)用模式或隊列模式；其他模式，裸機基本上也用不上。

PS

全文四類設計模式篇幅過長，拆分發(fā)布，其他模式稍后。文中提到的RTOS開發(fā)相關可閱讀其它文章，并發(fā)同步類相關的理論比較重要。