RTOS任務(wù)間通信能用全局變量嗎？

作者 |?strongerHuang，微信公眾號?| strongerHuang

RTOS任務(wù)間通信能用全局變量嗎？其實(shí)，不定期會有小伙伴問類似問題。

有深入理解RTOS原理，或閱讀過RTOS源碼的同學(xué)應(yīng)該知道：RTOS實(shí)現(xiàn)任務(wù)間通信通常是由一系列指針進(jìn)行操作實(shí)現(xiàn)的。

任務(wù)間通信的“有效數(shù)據(jù)”，其實(shí)也是由指針指向一個(gè)“變量”或“數(shù)組”實(shí)現(xiàn)的。

1.信號量

信號量，本質(zhì)是傳遞一個(gè)“事件”。比如：任務(wù)A完成發(fā)送數(shù)據(jù)，通過信號量通知任務(wù)B。

OSSemPost(EventSem_SendOK);

我們主要想傳遞“完成發(fā)送數(shù)據(jù)”這個(gè)“事件”，進(jìn)一步分析，其實(shí)就是一個(gè)“標(biāo)志”或“變量”。

2.隊(duì)列

隊(duì)列和信號量原理類似有點(diǎn)類似，只是這里是“變量”。比如：串口接收完成一幀數(shù)據(jù)，通過隊(duì)列發(fā)送給任務(wù)B.

OSQPost(UARTRcvQueue, RcvBuf);

相比信號量，隊(duì)列傳遞的數(shù)據(jù)量更大，隊(duì)列傳遞的有效數(shù)據(jù)一般是“數(shù)組”。

還有郵箱，與隊(duì)列類似，可以理解為“二維數(shù)組”。

寫到這里，你會發(fā)現(xiàn)，不管信號量，還是隊(duì)列，底層本質(zhì)也是傳遞“變量”“數(shù)組”。

那么問題來了，很多小伙伴學(xué)了基礎(chǔ)的原理之后，就存在這樣的疑惑：RTOS任務(wù)間通信能用全局變量嗎？

答案是：能用，但強(qiáng)烈不建議用。

全局變量有什么問題？

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

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

2.代碼規(guī)范問題：整個(gè)項(xiàng)目只有少數(shù)幾個(gè)全局變量沒什么問題，如果是整個(gè)項(xiàng)目有幾十個(gè)，甚至幾百個(gè)全局變量，你覺得這樣的代碼，后面好維護(hù)嗎？

經(jīng)過多次迭代，代碼只會越來越難理解，越來越難閱讀。

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

4.安全性問題：有一句話怎么說的呢，全局變量是項(xiàng)目的“罪魁禍?zhǔn)住?，?xiàng)目做大之后，一旦有小修改，可能就會引發(fā)大Bug.

全局變量還有很多弊端，這里就不一一描述了，總之一點(diǎn)：慎用全局變量。

當(dāng)然，以上描述的問題（弊端）都是基于項(xiàng)目中存在多個(gè)變量的情況，如果項(xiàng)目只有1、2個(gè)全局變量，這種不在本文討論范圍之內(nèi)。

信號量、隊(duì)列通信原理

大部分RTOS的信號量、隊(duì)列都是使用指針、結(jié)構(gòu)體、數(shù)組等，結(jié)合系統(tǒng)進(jìn)行“封裝”，使任務(wù)間通信更加有效、安全，同時(shí)也遵循“高內(nèi)聚低耦合”的原則。
比如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);}

我們需要傳遞的有效信息雖然只有一個(gè)變量，但它會做“臨界區(qū)”管理，以及預(yù)判一些錯(cuò)誤的情況等。

最后，RTOS源碼也可以算是一個(gè)優(yōu)秀的項(xiàng)目，特別是目前普及率比較高、裝機(jī)量比較多的RTOS，比如μC/OS、FreeRTOS、RT-Thread、ThreadX等。

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