消息通信過程可以采取輪詢或者中斷兩種方式，本文嘗試對輪詢法的一個缺陷做出分析。

一般輪詢法的框架：

bool have_msg = false; msg_struct msg; while(1) { have_msg = poll_msg(&msg); if(have_msg) { switch(msg.type) { case MSG_TYPE1: // deal_with_msg_type_1(); case MSG_TYPE2: // deal_with_msg_type_2(); case MSG_TYPE3: // deal_with_msg_type_3(); default: // unknown_msg_type_error(); } }

在一般小程序中采取該方法并沒有任何問題，但是，在一個復雜系統中擔負底層通信任務的通訊庫如果設計成這種方式，則會為編程帶來很多困難。

在一個復雜系統中，多線程技術會被廣泛采用。顯然，上面的循環遇到某個消息就處理某個消息，屬于單線程的工作模式。如何使得上面的程序適合多線程處理呢？可以考慮使用信號燈。我們將上面接收數據的線程成為接收線程，使用數據的線程為工作線程。首先工作線程在信號燈上睡眠等待數據，接收線程收到數據后將數據掛入工作線程消息隊列，然后喚醒工作線程。到目前為止，我們已經可以發現 第一個問題 了：系統中需要維護若干信號燈和若干消息隊列。這些工作必須由通信庫使用者來維護。隨著通信庫的用戶量越來越大，用戶的維護開銷也會越來越大。

關于第一個問題，也許還可以茍且忍受。但是，接下來的 第二個問題 會讓問題更加復雜。考慮這樣一種場景：type1和type2兩種消息具有依賴關系，而某個功能的實現需要先接收到type1消息，然后接收到type2消息。我們可以讓實現次功能的工作線程依次等待兩個信號燈即可。但是，如果系統中還存在第三個線程，它也需要使用type1消息呢？此時單一的信號燈已經不能解決問題了！當type1消息到達時，type1消息隊列上的信號燈是喚醒原來的工作線程呢還是喚醒第三個線程？這個問題不解決，要么會丟包，要么會讓代碼內部邏輯混亂。那么，有補救辦法嗎？有！在上面的消息接收線程中進一步細分消息類型，比如，將type1細分成type1_for_thread_work, type1_for_thread_third。此時，接收線程趨向于混雜。一旦系統中類似情況很多的時候，無論是效率還是代碼可維護性，都會受到極大挑戰。

解決上面問題的方法有2種：

1、互斥、阻塞地收發數據包

2、采用多端口，不同的while(1){}針對不同的端口。上層應用通過使用不同的端口來避免消息混雜。

下圖描述了單一端口發存在的問題，以及多端口的優勢。

輪詢法在混合消息通信中的缺陷