看到一個有意思的問題：裸機代碼用全局變量實現模塊間通信，那么，RTOS任務間通信為什么不用全局變量？ ? 有深入理解RTOS原理，或閱讀過RTOS源碼的同學應該知道：RTOS實現任務間通信通常是由一系列指針進行操作實現的。 ? ? 任務間通信的“有效數據”，其實也是由指針指向一個“變量”或“數組”實現的。 ? 1.信號量

信號量，本質是傳遞一個“事件”。比如：任務A完成發送數據，通過信號量通知任務B。

OSSemPost(EventSem_SendOK);

我們主要想傳遞“完成發送數據”這個“事件”，進一步分析，其實就是一個“標志”或“變量”。

2.隊列

隊列和信號量原理類似有點類似，只是這里是“變量”。比如：串口接收完成一幀數據，通過隊列發送給任務B.

OSQPost(UARTRcvQueue, RcvBuf);

相比信號量，隊列傳遞的數據量更大，隊列傳遞的有效數據一般是“數組”。

還有郵箱，與隊列類似，可以理解為“二維數組”。

寫到這里，你會發現，不管信號量，還是隊列，底層本質也是傳遞“變量”“數組”。

那么問題來了：RTOS任務間通信為什么不用全局變量？

這個問題比較常見，也看到在我的技術交流群有討論，所以就簡單來分享一下看法。

全局變量有什么問題？

RTOS任務間通信為什么不用全局變量？原因在于使用全局變量存在諸多弊端。 ?

1.搶占問題 兩個或多個任務，都要去“使用”同一個全局變量，如果不添加任何“互斥”措施，必定會存在搶占的問題。 ?

2.代碼規范問題 整個項目只有少數幾個全局變量沒什么問題，如果是整個項目有幾十個，甚至幾百個全局變量，你覺得這樣的代碼，后面好維護嗎？ ? 經過多次迭代，代碼只會越來越難理解，越來越難閱讀。 ?

3.耦合性問題 全局變量會導致分層不合理與模塊化編程相違背，你的全局變量沒有歸屬，既不是任務A，也不是模塊A，最終可能“任人宰割”導致“夭折”。 ?

4.安全性問題 有一句話怎么說的呢，全局變量是項目的“罪魁禍首”，項目做大之后，一旦有小修改，可能就會引發大Bug. ? ? ? 全局變量還有很多弊端，這里就不一一描述了，總之一點：慎用全局變量。 ? 當然，以上描述的問題（弊端）都是基于項目中存在多個變量的情況，如果項目只有1、2個全局變量，這種不在本文討論范圍之內。 ?

信號量、隊列通信原理

大部分RTOS的信號量、隊列都是使用指針、結構體、數組等，結合系統進行“封裝”，使任務間通信更加有效、安全，同時也遵循“高內聚低耦合”的原則。 ? 比如ucos的信號量post：

INT8U  OSSemPost (OS_EVENT *pevent)
{
#if OS_CRITICAL_METHOD == 3u                          /* Allocate storage for CPU status register      */
    OS_CPU_SR  cpu_sr = 0u;
#endif


#if OS_ARG_CHK_EN > 0u
    if (pevent == (OS_EVENT *)0) {                    /* Validate 'pevent'                             */
        return (OS_ERR_PEVENT_NULL);
    }
#endif
    if (pevent->OSEventType != OS_EVENT_TYPE_SEM) {   /* Validate event block type                     */
        return (OS_ERR_EVENT_TYPE);
    }
    OS_ENTER_CRITICAL();
    if (pevent->OSEventGrp != 0u) {                   /* See if any task waiting for semaphore         */
                                                      /* Ready HPT waiting on event                    */
        (void)OS_EventTaskRdy(pevent, (void *)0, OS_STAT_SEM, OS_STAT_PEND_OK);
        OS_EXIT_CRITICAL();
        OS_Sched();                                   /* Find HPT ready to run                         */
        return (OS_ERR_NONE);
    }
    if (pevent->OSEventCnt < 65535u) {                /* Make sure semaphore will not overflow         */
        pevent->OSEventCnt++;                         /* Increment semaphore count to register event   */
        OS_EXIT_CRITICAL();
        return (OS_ERR_NONE);
    }
    OS_EXIT_CRITICAL();                               /* Semaphore value has reached its maximum       */
    return (OS_ERR_SEM_OVF);
}
    我們需要傳遞的有效信息雖然只有一個變量，但它會做“臨界區”管理，以及預判一些錯誤的情況等。

最后，RTOS源碼也可以算是一個優秀的項目，特別是目前普及率比較高、裝機量比較多的RTOS，比如μC/OS、FreeRTOS、RT-Thread、ThreadX等。

最最后，有時間的小伙伴可以閱讀一下RTOS源碼，RTOS內核我推薦μC/OS，閱讀源碼能讓你掌握一些軟件架構的知識，也能讓你明白一些開發過程種常見的問題。

編輯：黃飛

?