點(diǎn)擊上方「嵌入式大雜燴」，選擇「置頂公眾號(hào)」第一時(shí)間查看嵌入式筆記！

鏈接：https://www.cnblogs.com/hhao020/p/5018951.html

本來(lái)今晚想寫如何搞動(dòng)態(tài)加載和動(dòng)態(tài)補(bǔ)丁的，但很不幸，翻遍了硬盤，也沒(méi)找到以前的代碼，連網(wǎng)盤里都沒(méi)備份。這時(shí)候，才煥然大悟--半年前我換上現(xiàn)在的筆記本，淘汰了那臺(tái)老掉牙的臺(tái)式機(jī)。

所幸硬盤沒(méi)丟，不過(guò)一時(shí)時(shí)也沒(méi)法讀里面的數(shù)據(jù)了。等過(guò)些日子，讀出里面的數(shù)據(jù)再談動(dòng)態(tài)加載和動(dòng)態(tài)補(bǔ)丁技術(shù)。今天說(shuō)些簡(jiǎn)單的，能在軟件設(shè)計(jì)中立即用得上的，模塊間通信技術(shù)--統(tǒng)一消息。

統(tǒng)一消息模型，最早的啟發(fā)是UT的Wacos SSI。那是一個(gè)很不錯(cuò)的通信模型，允許模塊間的通信統(tǒng)一成隊(duì)列通信；而在物理上，模塊可能位于各種網(wǎng)絡(luò)中的不同的實(shí)體，又或者是不同的進(jìn)程，線程。

記得那會(huì)調(diào)試核心網(wǎng)的程序，在板卡上是沒(méi)有什么調(diào)試環(huán)境的，除了WindShell（同CSHELL）外，就沒(méi)什么支撐了。

于是我們就把軟件用GDB加載到目標(biāo)機(jī)（無(wú)盤工作站），然后開始測(cè)試。有人不理解了，這沒(méi)啥??！現(xiàn)實(shí)是這價(jià)值很大，大型系統(tǒng)的嵌入式開發(fā)，能爭(zhēng)取到的機(jī)房空間、設(shè)備和板卡總是奇缺，就當(dāng)時(shí)的情況來(lái)說(shuō)，我們?nèi)膫€(gè)人才能分到一套設(shè)備。

Wacos_SSI的隊(duì)列通信技術(shù)，讓我們可以把目標(biāo)機(jī)做成功能板塊，且只需要極少量的修改，就能和實(shí)際系統(tǒng)的主控板進(jìn)行通訊聯(lián)測(cè)，工作效率的提升自不待言。

再后來(lái)，哥在Nortel的時(shí)候知道了TIPC協(xié)議，好象是E///和IBM搗騰出來(lái)的東西。思路上，和Wacos SSI很接近。所不同的是，Wacos SSI在消息頭里使用了IP地址，而TIPC則是自定義的節(jié)點(diǎn)地址，也因此包含了一個(gè)額外的節(jié)點(diǎn)地址和特定網(wǎng)絡(luò)間的地址翻譯過(guò)程。

另外一個(gè)區(qū)別是，Wacos SSI考慮了遠(yuǎn)程節(jié)點(diǎn)間通信和本地通信的差別，只有遠(yuǎn)程通信時(shí)才傳遞消息實(shí)體，而本地則是傳遞標(biāo)識(shí)（Handle）來(lái)快速完成。TIPC則沒(méi)講述這個(gè)層次的程序設(shè)計(jì)問(wèn)題，也因此在工程實(shí)踐中應(yīng)用寥寥。

現(xiàn)如今，UT沒(méi)了，Nortel也沒(méi)了。特別是UT，十多年過(guò)去了，哥特別懷念那段日子，和我的那個(gè)團(tuán)隊(duì)。無(wú)奈，哥就是災(zāi)星，跟喜歡的公司相克。很多局外人都說(shuō)UT不咋的，就一個(gè)做小靈通的；可哥的眼里，那的許多軟件開發(fā)團(tuán)隊(duì)，戰(zhàn)斗力一點(diǎn)不比Huawei差。

就說(shuō)哥做的網(wǎng)關(guān)城域交換機(jī)，才十來(lái)個(gè)人，而huawei是幾十人，好幾倍啊，最后市場(chǎng)表現(xiàn)還是平分秋色。當(dāng)然，我還是蠻佩服huawei的，他們的東西真心做的漂亮，維護(hù)界面人性化，不像我們的，很多事情要命令行來(lái)實(shí)現(xiàn)。不過(guò)我們也有特點(diǎn)，就是架構(gòu)做的非常好，以至于客戶的需求，總是能很快實(shí)現(xiàn)，而且基本上對(duì)現(xiàn)有功能是0風(fēng)險(xiǎn)。呵呵，據(jù)說(shuō)氣死不少人！

這當(dāng)中，有三大功臣：

• Wacos SSI；
• 狀態(tài)機(jī)；
• 數(shù)據(jù)驅(qū)動(dòng)模型。

狀態(tài)機(jī)的代碼，已經(jīng)在昨晚的內(nèi)存泄漏里的鏈接里提供了，有興趣可以下載或是用在喜歡的地方，哥只希望它有更多機(jī)會(huì)發(fā)揮價(jià)值。

嗯，Wacos SSI排在第一！是的，Wacos SSI的消息通信讓我們的系統(tǒng)變得非常柔性，模塊與模塊間幾乎沒(méi)有什么復(fù)雜的耦合。想想現(xiàn)在那些公司招聘需求里，要求什么多任務(wù)多線程編程能力，精通什么信號(hào)量和同步技術(shù)，哥就想哭，這就是我們的軟件水平，時(shí)刻準(zhǔn)備著處在玩死自己。

哥做程序，只考慮CPU有幾個(gè)線程核，至于系統(tǒng)有幾個(gè)進(jìn)程線程，都是這個(gè)決定的，而且合并拆解任務(wù)，都是分分鐘能改代碼實(shí)現(xiàn)的事。

跟哥一起做軟件，就只要記住幾點(diǎn)：無(wú)論你和誰(shuí)通信，你只要知道他的地址，然后發(fā)消息給他就好了；而你也只要看著自己的隊(duì)列，有消息就干活，沒(méi)消息就歇著。

至于發(fā)消息，就一個(gè)標(biāo)準(zhǔn)的函數(shù)，而消息封裝格式，也是統(tǒng)一的。至于系統(tǒng)函數(shù)庫(kù)里提供的什么信號(hào)量，管道啥的，千萬(wàn)別嘗試在應(yīng)用里面使用，否則，編譯器會(huì)用編譯錯(cuò)誤來(lái)告訴你行不通。

有點(diǎn)扯遠(yuǎn)了，回到正題。

統(tǒng)一消息的定義，包含兩個(gè)部分，消息標(biāo)簽和消息頭，具體如下：

typedef?struct?_MSG_TAG_TYPE_
{
zAddr_t?srcAddr;
zAddr_t?dstAddr;
zHandle_t?msgHandle;
}?PACKED?zMsg_t;

typedef?struct?_MSG_HEAD_TYPE_
{
byte_t?sysrsvd[8];?//reserved?for?adding?src?&?dst?addresses?on?network.?
word_t?msgLen;
word_t?msgId;?
dword_t?srcInst;
dword_t?dstInst;
}?PACKED?zMsgHdr_t;

typedef?struct?_MSG_HEAD_EX_TYPE_
{
zAddr_t?srcAddr;
zAddr_t?dstAddr;?
word_t?msgLen;
word_t?msgId;?
dword_t?srcInst;
dword_t?dstInst;
byte_t?msgBuf[1];
}?PACKED?zMsgHdrEx_t;

zMsg_t結(jié)構(gòu)是消息標(biāo)簽，應(yīng)用程序收、發(fā)消息時(shí)，都是收發(fā)的這個(gè)數(shù)據(jù)結(jié)構(gòu)，如下：

int?zMsgSend(zMsg_t?*msg);

通常來(lái)說(shuō)，我們應(yīng)該把這個(gè)消息標(biāo)簽做的比較小，因?yàn)樽龅奶螅瑏?lái)回復(fù)制它的內(nèi)容是需要耗費(fèi)CPU時(shí)間的。比如，你可以將zAddr_t定義成word，zHandle_t定義成dword，這樣只需要8字節(jié)就夠了。不過(guò)記得字節(jié)對(duì)齊，一般來(lái)說(shuō)，要保證長(zhǎng)度是4的倍數(shù)。

消息頭就是消息內(nèi)容的頭部格式段，除了這個(gè)頭部，剩下的就是應(yīng)用自定義的payload部分。zMsgHdr_t和zMsgHdrEx_t實(shí)質(zhì)上是一樣的。這里面的地址部分，不是必須的，只有當(dāng)消息透過(guò)網(wǎng)絡(luò)或是總線傳遞時(shí)，才是必須的，否則沒(méi)法由邊界模塊還原。而對(duì)于應(yīng)用，如無(wú)特別約定，那幾個(gè)字節(jié)是無(wú)意義且內(nèi)容不確定的。

消息標(biāo)簽和消息間是通過(guò)msgHandle關(guān)聯(lián)。這樣，當(dāng)消息在本地傳遞時(shí)，msgHandle指向的是一塊普通內(nèi)存；而當(dāng)消息在本地進(jìn)程間通信時(shí)，則指向共享內(nèi)存；至于網(wǎng)絡(luò)或是某個(gè)總線傳遞，邊界模塊負(fù)責(zé)本地內(nèi)存數(shù)據(jù)和網(wǎng)絡(luò)數(shù)據(jù)間的轉(zhuǎn)換。如此一來(lái)，最大程度的減少實(shí)際消息體的拷貝開銷，讓消息傳遞變得高效，且細(xì)節(jié)處理對(duì)應(yīng)用透明。

Wacos SSI的地址部分，填的是IP地址；當(dāng)然，它還定義了一個(gè)模塊號(hào)來(lái)配合這個(gè)地址使用。整個(gè)通信過(guò)程很簡(jiǎn)單，應(yīng)用只需要申請(qǐng)一個(gè)隊(duì)列，并告知SSI，這個(gè)隊(duì)列和哪個(gè)目的模塊號(hào)使用。

正常情況下，這個(gè)做法都能滿足需求，但碰上程序模塊重新規(guī)劃或是特俗測(cè)試目的，就有點(diǎn)力不從心了。因此，哥在zMsg_t標(biāo)簽里徹底放棄了IP+module的地址組成，改為TIPC的地址方式。不過(guò)這也就讓系統(tǒng)必須維護(hù)一個(gè)路由表，用來(lái)完成特定目的地址到隊(duì)列的映射。

統(tǒng)一消息路由表定義如下：

typedef?struct?Z_UDP_ADDR_TYPE
{
dword_t?ip;
word_t?port;
}?zUDPAddr_t;
typedef?struct?Z_MSGQ_ADDR_TYPE
{
void?*qid;
}?zQueAddr_t;

typedef?struct?Z_MSGQ_OUT_TYPE
{
zAddr_t?addr;?
zUDPAddr_t?udpAddr;
zQueAddr_t?queAddr;?
}?zMsgRoute_t;

路由表項(xiàng)里首先是地址，對(duì)應(yīng)的是消息的目的地址。接下來(lái)是網(wǎng)絡(luò)地址和隊(duì)列地址，可以有一個(gè)或是都有。

• 僅隊(duì)列地址：說(shuō)明是本地（或者是需要經(jīng)隱形邊界代理轉(zhuǎn)發(fā)）的消息，目的地址為隊(duì)列所有者；
• 僅網(wǎng)絡(luò)地址：說(shuō)明是遠(yuǎn)程消息，且應(yīng)該直接網(wǎng)絡(luò)發(fā)送，無(wú)需經(jīng)過(guò)邊界代理，目的地址為遠(yuǎn)端模塊地址；
• 含兩類地址：遠(yuǎn)程消息，應(yīng)用發(fā)送時(shí)通過(guò)隊(duì)列地址送入邊界模塊，再通過(guò)網(wǎng)絡(luò)地址發(fā)送，，目的地址為遠(yuǎn)端模塊地址。

總上面的關(guān)系可以看出，隊(duì)列和地址間的關(guān)系是一對(duì)多的關(guān)系，即多個(gè)地址的消息可能被投送到同一個(gè)隊(duì)列。

這就讓模塊合并變得異常容易，當(dāng)然，不安規(guī)則出牌的模塊什么時(shí)候什么方法都白搭。通常來(lái)說(shuō)，如果有IP網(wǎng)絡(luò)的通信要求，系統(tǒng)就需要?jiǎng)?chuàng)建一個(gè)基礎(chǔ)的網(wǎng)絡(luò)邊界模塊。

這個(gè)模塊本身可能并不需要地址，而只需要提供一個(gè)消息聚合的隊(duì)列。當(dāng)然，在一個(gè)開放的網(wǎng)絡(luò)環(huán)境下，這個(gè)邊界模塊可能還需要做些安全性的工作，比如過(guò)濾非法消息等，這可以通過(guò)在模塊內(nèi)額外配置源IP地址，端口或是源目的地址等實(shí)現(xiàn)。

如果遠(yuǎn)端并不支持zMsg_t工作，則這時(shí)候的邊界模塊就需要做好消息的翻譯過(guò)程，為遠(yuǎn)端模塊分配映射模塊地址。當(dāng)然，這些都是本地的，不屬于路由表內(nèi)容。

從地址映射到真實(shí)的目的隊(duì)列或是網(wǎng)絡(luò)地址，是個(gè)頻繁的操作，設(shè)計(jì)上必須要非常高效。對(duì)于地址非常少的系統(tǒng)，比如總共才七八個(gè)模塊，可以用一個(gè)緊湊的數(shù)據(jù)來(lái)做，簡(jiǎn)單且不妨礙效率。但對(duì)于有數(shù)十或是上百個(gè)地址的系統(tǒng)來(lái)說(shuō)，遍歷方法就不可取了。這時(shí)應(yīng)該用二分搜索，或是平衡二叉樹。

比如城域交換機(jī)，有十來(lái)塊子功能卡，每張卡上有十來(lái)個(gè)模塊，整個(gè)系統(tǒng)的地址空間有一百多，采用二分搜索，最多8次就夠了！相比消息處理函數(shù)的指令數(shù)，這部分開銷完全可以接受。而從另一個(gè)角度來(lái)說(shuō)，統(tǒng)一消息讓程序變得簡(jiǎn)單可控，系統(tǒng)內(nèi)減少了消息的拷貝操作，所帶來(lái)的系統(tǒng)效率和性能提升，遠(yuǎn)遠(yuǎn)大于查詢路由表的開銷。

當(dāng)嵌入式世界有了統(tǒng)一消息后，哪些多線程的開發(fā)技巧還有很大價(jià)值么？一般應(yīng)用開發(fā)者真的需要理解這些知識(shí)么？