μC／OS－II和LWIP的并發服務器與代理線程設計模式

蔣俊，鐘偉勝

（1.長沙 410081；2.江蘇省淮安技師學院）

蔣俊（自由職業者），從事嵌入式開發6年，擅長μC／OS－II和LWIP，熟悉DSP和ARM開發，自主開發過GUI庫，精通電能計量、測量、諧波分析；鐘偉勝（講師），主要研究方向為計算機網絡。

引 言

現有一嵌入式設備具備網絡通信功能，它要求設計成支持多臺數據采集器同時進行通信，如圖1所示。多種原因（價格，功耗和尺寸）的限制導致該嵌入式設備的處理能力和存儲空間有限，因此選用μC／OS－II操作系統和LWIP協議棧。在通信過程中，數據采集器充當客戶端，嵌入式設備是服務器，顯然，需要將該嵌入式設備設計成并發服務器，另外為節省內存，需要設計代理線程模式。

圖1 多臺采集器與嵌入式設備通信

1 基于μC／OS－II動態生成線程

一般來說OS都支持動態生成線程（或進程），μC／OS－II也不例外，對于程序員來說，要處理4方面的問題：線程的正文、優先級、堆棧空間和檢測堆棧占用率。

正文（text）即線程的執行代碼，經常組織成一個無限循環的函數，更具普遍規律的是，在網絡開發中多個線程的正文都是同一個函數，因為這些線程基本上完成相同的任務，差異只是連接的主機不同。

μC／OS－II中的優先級具有十分重要的意義，不僅影響該線程的調度，而且在整個系統中它是唯一的ID，可以分配一段ID號給動態線程。

最重要的工作是堆棧的處理，當生成一個線程時需要給它分配一段內存充當堆棧，當刪除該線程時需要回收這段內存。

根據線程個數與每個線程堆棧大小定義一塊內存區，然后使用OS提供的OSMemCreate（）生成動態內存區，每當生成一個線程時，調用OSMemGet（）來獲取一塊內存，將該內存的句柄保存；刪除一個線程時，調用OSMemPut（）將該內存回收。這里有一個問題，怎么查找被刪除線程的堆棧呢？其實它是根據該線程的優先級號來完成的。

一個線程可以調用OSTaskDel（）來刪除自己，那么它可以回收自己的堆棧嗎？事實上，這樣做很危險！當一個線程沒有完全刪除時，它是依賴堆棧來運行的，如果此時回收了堆棧空間，可能會帶來致命的錯誤。假設一個線程回收自己的堆棧且該內存立即被別的線程使用，那么當它還想使用這個堆棧執行最后一些工作時，堆棧里的有效數據已經被破壞了，這可能會帶來程序的崩潰，而且這種錯誤很難查找。

一個安全可行的辦法是，一個線程向創建者發送消息——請回收我的堆棧空間，然后刪除自己，注意這2個動作必然是“原子的”，否則上述的錯誤就不可避免了。μC／OS－II在刪除線程的函數 OSTaskDel（）中提供鉤子函數App＿TaskDelHook（），并且調用該鉤子函數時中斷被關閉，從而保證原子操作，可以在該函數中發送消息。

最后，一個強大的嵌入式系統需要檢測線程的堆棧占用率，以防止堆棧溢出帶來的內存錯誤。引入動態線程后，線程個數是未知的，該如何檢測堆棧占用率呢？這個工作可以交給OS來完成，因為它最了解哪些線程已經被創建（通過查看OS＿TCB來完成），可以簡單地調用OSTaskStkChk（）遍歷所有優先級號，對于已創建線程會返回堆棧使用數據，不存在的線程會返回錯誤信息（如該線程不存在）。［1］

2 基于LWIP的并發服務器

我們先來解決一個理論問題：為什么網絡通信多連接需要設計并發線程，用一個線程來查詢并處理多連接是否可以呢？回答這個問題需要看看處理一個網絡連接的線程到底在干什么。在LWIP協議棧中，當線程調用netconn＿recv（）等待連接主機的報文時會被阻塞在郵箱recvmbox上，直到接收成功該線程才進行下一步處理。阻塞在OS中是通過切換CPU來實現的，阻塞時間內該線程什么也干不了，查詢并處理多連接是不可能的。因此，一個線程處理一個網絡連接，這種模式最自然，也最科學。

這里有一個主線程負責偵聽網絡，每建立一個網絡連接時創建一個新線程并傳遞網絡連接句柄，新線程開始處理對應網絡連接上的所有事務，直到該網絡連接斷開時才刪除自己，并通知主線程回收堆棧空間，整個工作過程如圖2所示。

圖2 多線程與并發連接

結合LWIP看上述過程的實現，主線程阻塞在netconn＿accept（）上，每接收一個新連接句柄struct netconn＊p＿stNetConn，就會創建一個新線程并傳遞該句柄。新線程將阻塞在netconn＿recv（）上，每接收一個網絡數據包struct netbuf＊p＿stNetBuf后進行處理，新線程通過查詢ERR＿IS＿FATAL（p＿stNetConn－＞err）來得知網絡連接是否有效，如果無效，則刪除自己并通知主線程回收堆棧空間。［3］

3 代理線程設計模式

從圖1中可以看出，無論多少個數據采集器，嵌入式設備的數據都是一致的，即數據與客戶端連接個數無關；另外，每個數據采集器與設備通信的操作是相同的（一個優秀架構會保證通信操作的同構性）。因此，引入代理線程設計模式，至少具備2方面的優點：

①節省內存。假設解析通信協議需要N字節內存，如果新建M個線程，那么采用代理線程將節省N×（M－1）字節內存，除代理線程外其他都不需要解析協議，這對于嵌入式系統寶貴內存來說是一個極大的優勢。

② 避免競態。一份數據如果被多個線程共享，那必定會帶來令人頭痛的競態問題，設計者不得不花費大量精力來保證線程安全；采用代理線程后，該數據只被一個線程操作，從源頭避免共享，降低設計復雜度。［2］

圖3描述了代理線程的工作原理，當客戶端Client＿i向線程Thread＿i發起通信請求時，線程把該請求委托給Proxy－Thread來完成，Proxy－Thread解析該委托任務并回應客戶端Client＿i。同時，也顯示了這種設計模式的缺點，需要線程之間通信和少量的時間開銷。

圖3 代理線程通信原理

在多線程設計中不得不提的是時序問題，它可以清晰地反映線程之間是如何交互的，OS是如何調度線程的以及系統的運行軌跡。在本設計中，委托線程與代理線程的交互如圖4所示，每當委托線程提交任務后它就被阻塞，直到代理線程處理完該任務才解除阻塞；另外代理線程負荷最重，它占用大部分的CPU資源。

圖4 線程交互時序圖

委托線程與代理線程之間的通信接口該怎樣設計呢？從需求出發，代理線程完成委托線程的任務需要以下資源：網絡連接句柄、接收數據包指針、同步信號量和委托線程私有數據存儲區。發送回應數據包必須提供網絡連接句柄；要解析協議必須依賴接收數據包；當代理線程完成任務后需要同步委托線程，這里將使用信號；客戶端往往需要設置委托線程，數據將保存在它的私有數據存儲區。數據結構的設計如圖5所示。

圖5 線程通信接口

在上述通信接口設計中有SemProtect用于保護線程的私有數據單元，這個信號量有存在的必要嗎？以圖6中沒有設置信號保護的情況為例，這將直接導致一個錯誤：當Proxy需要通過連接句柄主動發送數據時，委托線程搶奪了CPU，并將該連接句柄置為無效，等Proxy再次獲得CPU時，它并不知道該句柄已經無效了，發送數據將會導致LWIP協議棧紊亂。

圖6 沒有信號量保護導致錯誤

解決這個問題的辦法就是原子操作，即檢測線程有效與使用連接句柄發送數據不能被打斷，信號量能夠勝任這種場合。圖7和圖8表明，無論Proxy先還是后，獲取信號量都能避免上述狀況下錯誤的發生。

圖7 Proxy先獲取信號量

圖8 Proxy后獲取信號量

結 語

本文重點研究了基于μC／OS－II和LWIP的嵌入式系統下并發服務器和代理線程的實現模式，它具備網絡多連接（數目僅依賴內存大小）和極大節省內存的優勢，深入探究線程同步和網絡開發陷阱，對于嵌入式系統網絡開發具備實用價值。

論文中涉及的技術方法已在嵌入式產品上驗證成功，該產品軟件基于μC／OS－II V2.86和 LWIP V1.3.2，硬件基于LPC1768處理器和以太網口，實踐證明論文中的方法穩定、可行。

［1］Jean J Labrosse.嵌入式實時操作系統μC／OS－II［M］.邵貝貝，等譯.北京：北京航空航天大學出版社，2007.

［2］David E.Simon嵌入式系統軟件教程［M］.陳向群，等譯.北京：機械工業出版社，2005.

［3］Adam Dunkels.Design and Implementation of the LWIP TCP／IP Stack.Swedish Institute of Computer Science，2001.