嵌入式軟件實(shí)時(shí)性分析及增強(qiáng)概述

一、前言

實(shí)時(shí)性(RealTime/Real-Time)是嵌入式軟件領(lǐng)域一個(gè)關(guān)鍵性能指標(biāo)，也是計(jì)算機(jī)系統(tǒng)領(lǐng)域一個(gè)老生常談的話題。本文將從工程實(shí)踐的角度系統(tǒng)性描述軟件實(shí)時(shí)性的概念、影響軟件實(shí)時(shí)性的因素，以及如何提高軟件實(shí)時(shí)性。雖部分內(nèi)容是基于Linux描述，但相關(guān)思想和方法也適用于其它通用操作系統(tǒng)(General Purpose Operating System,后文簡(jiǎn)稱OS)。Linux的應(yīng)用非常廣泛，相關(guān)問(wèn)題比較有代表性，且是開(kāi)源軟件，資源比較豐富，相應(yīng)的性能提升也能帶來(lái)更大的價(jià)值。掌握OS的基本概念如中斷、異常、線程、調(diào)度等有助于更好的理解本文。

二、實(shí)時(shí)性概述

2.1 實(shí)時(shí)性概念

很多人容易對(duì)實(shí)時(shí)性產(chǎn)生誤解，認(rèn)為實(shí)時(shí)性是衡量完成一個(gè)任務(wù)的最快時(shí)間。相反實(shí)時(shí)性關(guān)注的不是完成一個(gè)任務(wù)的最快時(shí)間，而是完成這個(gè)任務(wù)的最差時(shí)間。在對(duì)實(shí)時(shí)性進(jìn)行更深入探討前，先簡(jiǎn)單回顧下軟件實(shí)時(shí)性問(wèn)題的由來(lái)。實(shí)時(shí)性的概念是伴隨著OS產(chǎn)生的，在沒(méi)有OS之前，基于圖靈機(jī)模型的計(jì)算機(jī)按照邏輯串行執(zhí)行指令，在系統(tǒng)層面不存在影響任務(wù)實(shí)時(shí)性和確定性的因素。隨著軟硬件技術(shù)的發(fā)展，有了OS、中斷處理、調(diào)度、搶占、臨界區(qū)、SMP等概念，影響實(shí)時(shí)性的一些關(guān)鍵要素就出現(xiàn)了(雖然裸機(jī)也有中斷，但不是本文關(guān)注點(diǎn))。

在某些應(yīng)用場(chǎng)景，如果任務(wù)實(shí)時(shí)性不達(dá)標(biāo)，會(huì)導(dǎo)致非常嚴(yán)重的后果如交通、航天、醫(yī)療等安全關(guān)鍵領(lǐng)域，因此實(shí)時(shí)性在這些領(lǐng)域是一個(gè)非常重要的技術(shù)指標(biāo)。維基百科對(duì)計(jì)算機(jī)領(lǐng)域?qū)崟r(shí)的定義已非常準(zhǔn)確，直接引用如下：

Atask in a software-controlled system is called real-time (or "executable in real-time, in real-time") if the combined response and execution time of the task is less than the maximum time allowed, taking into account outside influences.

簡(jiǎn)單總結(jié)即“響應(yīng)時(shí)間+執(zhí)行時(shí)間小于允許的最大時(shí)間，則稱為實(shí)時(shí)”。使用圖1的模型表示實(shí)時(shí)的概念會(huì)更形象一些：

圖1 實(shí)時(shí)性概念

CPU按序執(zhí)行指令流，在T0時(shí)刻發(fā)生外部中斷(也適用于如信號(hào)量、文件描述符事件等內(nèi)部事件)，CPU因?yàn)槟承┮蛩卦诮?jīng)過(guò)一段時(shí)間的延遲后進(jìn)入事件響應(yīng)函數(shù)，此時(shí)定義為T1，從進(jìn)入事件響應(yīng)函數(shù)到事件完全處理完成，到達(dá)T2結(jié)束完成整個(gè)事件處理流程。為了統(tǒng)一語(yǔ)言，把T0～T1描述為響應(yīng)時(shí)間也稱為延遲Latency，T1～T2描述為任務(wù)處理時(shí)間，把M稱為Deadline，按照這種方式劃分，可適用于任何對(duì)實(shí)時(shí)性有要求的場(chǎng)景。如外部事件是中斷，則T0～T1為中斷響應(yīng)時(shí)間或中斷延遲，T1～T2為中斷處理時(shí)間；如外部事件是一個(gè)資源就緒的調(diào)度事件，則T0～T1為調(diào)度響應(yīng)時(shí)間或調(diào)度延遲，T1～T2為調(diào)度處理時(shí)間。響應(yīng)時(shí)間/處理時(shí)間的最大值與最小值之間的差值，稱為抖動(dòng)Jitter，對(duì)于需要周期性完成的任務(wù)來(lái)說(shuō)抖動(dòng)是很重要的一個(gè)指標(biāo)。任務(wù)在執(zhí)行過(guò)程中發(fā)生切換，稱之為搶占，實(shí)時(shí)任務(wù)對(duì)非實(shí)時(shí)任務(wù)的搶占是確保實(shí)時(shí)性非常重要的機(jī)制。

關(guān)于實(shí)時(shí)性還有硬實(shí)時(shí)和軟實(shí)時(shí)的概念，圖1中若”T2 - T0 < M”恒為真則為硬實(shí)時(shí)，而如果是基于一定條件使”T2 - T0 < M”為真則為軟實(shí)時(shí)，如T2 - T0在一段時(shí)間內(nèi)的平均值小于Deadline，則可以稱為軟實(shí)時(shí)。

Deadline是一個(gè)期望值，根據(jù)需求確定，但是T2-T0卻是一個(gè)動(dòng)態(tài)值，在不同的應(yīng)用場(chǎng)景或者系統(tǒng)內(nèi)外部狀態(tài)下值是不同的，也就是上文說(shuō)的抖動(dòng)，如何找到Max(T2-T0)就是對(duì)實(shí)時(shí)性進(jìn)行驗(yàn)證的關(guān)鍵。業(yè)界通常使用可調(diào)度性分析對(duì)軟件實(shí)時(shí)性、確定性進(jìn)行驗(yàn)證，ISO26262對(duì)高功能安全等級(jí)軟件的可調(diào)度性分析是強(qiáng)制要求?？烧{(diào)度性分析可通過(guò)對(duì)系統(tǒng)軟件架構(gòu)(必要時(shí)分析可深入至代碼級(jí))的數(shù)據(jù)流、控制流、執(zhí)行路徑的分析，構(gòu)造對(duì)應(yīng)的測(cè)試用例，通過(guò)測(cè)試驗(yàn)證系統(tǒng)的可調(diào)度性，如Linux常用的cycletest就是通過(guò)測(cè)試對(duì)系統(tǒng)的實(shí)時(shí)性進(jìn)行驗(yàn)證。對(duì)實(shí)時(shí)應(yīng)用(后簡(jiǎn)稱RT App)執(zhí)行的實(shí)時(shí)性驗(yàn)證，需要計(jì)算應(yīng)用處理的最大時(shí)間和最長(zhǎng)執(zhí)行路徑，在計(jì)算機(jī)系統(tǒng)領(lǐng)域通常使用最差執(zhí)行時(shí)間(Worst-case execution time，簡(jiǎn)稱WCET)表示，WCET的計(jì)算和驗(yàn)證也有多種方法，包括抽象解釋、靜態(tài)分析、測(cè)試驗(yàn)證等。關(guān)于實(shí)時(shí)性的驗(yàn)證，內(nèi)容非常的多，為了確保本文不發(fā)散，這里僅做概念介紹，不再深入分析。

為了確保”T2 - T0 < M”，在M是常量的情況下，需要減少T0～T2的時(shí)間跨度，并在這個(gè)時(shí)間跨度內(nèi)合理的分配響應(yīng)和處理時(shí)間。對(duì)于開(kāi)放式OS，其部署多個(gè)具備不同業(yè)務(wù)特征且Deadline不同的實(shí)時(shí)任務(wù)，單純的依靠OS提供的調(diào)度策略或?qū)崟r(shí)性機(jī)制很難保證系統(tǒng)內(nèi)所有實(shí)時(shí)任務(wù)滿足其Deadline，需要配合任務(wù)的到達(dá)時(shí)間arrive time、松弛時(shí)間slack time等進(jìn)行定量分析計(jì)算并制定相應(yīng)的調(diào)度策略。

2.2影響實(shí)時(shí)性的關(guān)鍵因素

在討論影響軟件實(shí)時(shí)性因素之前，需要界定一個(gè)范圍，因?yàn)橛绊憣?shí)時(shí)性的因素太多，芯片、內(nèi)存(cache)、外設(shè)、軟件等等。通常來(lái)說(shuō)硬件特性會(huì)顯著影響軟件的執(zhí)行速度，如CPU是否多核，主頻高低，是否有MMU，是否有特權(quán)級(jí)切換，是否有cache，幾級(jí)cache，CPU是否動(dòng)態(tài)調(diào)頻，內(nèi)存是什么介質(zhì)，訪問(wèn)方式是UMA還是NUMA等？進(jìn)而影響系統(tǒng)實(shí)時(shí)性，但這部分內(nèi)容與特定平臺(tái)相關(guān)，為避免發(fā)散本文僅討論軟件因素。

為了統(tǒng)一共識(shí)，這里限定一個(gè)具體的場(chǎng)景，該場(chǎng)景能將影響實(shí)時(shí)性的相關(guān)因素都串起來(lái)，后續(xù)的分析也基于此：“實(shí)時(shí)應(yīng)用RT App阻塞等待某OS資源，而該資源又依賴外部中斷”，場(chǎng)景可實(shí)例化為RT App通過(guò)read接口阻塞在網(wǎng)絡(luò)socket上，系統(tǒng)在socket數(shù)據(jù)就緒后喚醒RT App任務(wù)讀取網(wǎng)卡報(bào)文，并完成數(shù)據(jù)處理。

按照?qǐng)D1的模型，外部事件為網(wǎng)卡中斷，T0～T1為網(wǎng)卡驅(qū)動(dòng)與協(xié)議棧處理并喚醒阻塞在read調(diào)用的任務(wù)，即網(wǎng)絡(luò)報(bào)文的響應(yīng)時(shí)間；而T1～T2是RT App對(duì)網(wǎng)絡(luò)報(bào)文的處理時(shí)間。先從OS負(fù)責(zé)的響應(yīng)時(shí)間部分開(kāi)始如圖2，這里將響應(yīng)時(shí)間T0～T1繼續(xù)分解，得出如下幾個(gè)點(diǎn)：

T0：外部發(fā)生網(wǎng)卡物理中斷

T01：CPU進(jìn)入中斷處理程序(Interrupt Service Routine)ISR

T02：完成網(wǎng)卡驅(qū)動(dòng)與協(xié)議棧處理喚醒目標(biāo)線程，也稱就緒時(shí)間或Arrival Time

T03：目標(biāo)線程被選為CPU的當(dāng)前任務(wù)

圖2 響應(yīng)時(shí)間分解

實(shí)際環(huán)境中，在上述幾個(gè)時(shí)間點(diǎn)之間仍然可能會(huì)出現(xiàn)新的中斷、異常、非預(yù)期調(diào)度、負(fù)載均衡等(實(shí)際系統(tǒng)在做實(shí)時(shí)性優(yōu)化時(shí)需要盡量避免這些情況發(fā)生)，但是這些行為最終回歸到上述四個(gè)步驟，不影響本文分析。

從上圖可以看出，在操作系統(tǒng)層面，影響任務(wù)實(shí)時(shí)性的關(guān)鍵因素有這四個(gè)：

1. T0～T01中斷延遲(外部中斷發(fā)生到CPU執(zhí)行中斷處理程序間的延遲)
2. T01～T02中斷處理開(kāi)銷(為了簡(jiǎn)化模型，把一些內(nèi)核功能如協(xié)議棧的開(kāi)銷也算在中斷處理里了)
3. T02～T03調(diào)度延遲(任務(wù)等待的資源就緒，到CPU選定目標(biāo)任務(wù)之間的延遲)
4. T03～T1調(diào)度開(kāi)銷(上下文切換，返回到用戶態(tài)RT App阻塞點(diǎn))

T0～T01中斷延遲主要由受系統(tǒng)關(guān)中斷影響，因?yàn)橹袛喟l(fā)生時(shí)系統(tǒng)可能處于關(guān)中斷狀態(tài)，在關(guān)中斷狀態(tài)下CPU會(huì)暫時(shí)屏蔽外部信號(hào)，在打開(kāi)中斷后才響應(yīng)該外部中斷。如系統(tǒng)當(dāng)前正在執(zhí)行的代碼不能被中斷打斷時(shí)，調(diào)用接口屏蔽外部中斷，處理完成后再打開(kāi)外部中斷。顯然關(guān)中斷的代碼范圍越大執(zhí)行時(shí)間越長(zhǎng)，可能的中斷延遲也會(huì)越大。對(duì)于支持中斷優(yōu)先級(jí)的芯片，還受中斷優(yōu)先級(jí)影響，高優(yōu)先級(jí)中斷會(huì)優(yōu)先于低優(yōu)先級(jí)中斷被處理。

T01～T02中斷處理開(kāi)銷主要受中斷處理邏輯復(fù)雜度影響，操作系統(tǒng)為提高中斷處理速度，通常會(huì)分段處理中斷，把一些關(guān)鍵性操作放在ISR中處理，這部分代碼必須處于關(guān)中斷狀態(tài)運(yùn)行。把更耗時(shí)的操作在開(kāi)中斷狀態(tài)下執(zhí)行，如Linux的軟中斷機(jī)制，再比如微內(nèi)核架構(gòu)的OS會(huì)將復(fù)雜的中段處理放在用戶態(tài)線程處理。在OS內(nèi)核處理中斷或者其它必要流程中可能會(huì)訪問(wèn)臨界區(qū)，這時(shí)會(huì)使用自旋鎖或者互斥鎖，這些操作也會(huì)影響中斷處理時(shí)長(zhǎng)，進(jìn)而影響整個(gè)系統(tǒng)實(shí)時(shí)性。在工程實(shí)踐上影響內(nèi)核實(shí)時(shí)性、確定性很多時(shí)候都是這些臨界區(qū)訪問(wèn)導(dǎo)致的。所有中斷相關(guān)的處理工作完成后，OS通過(guò)調(diào)度接口喚醒目標(biāo)任務(wù)進(jìn)入下一階段。

圖3 Linux應(yīng)用運(yùn)行模型

T02～T03調(diào)度延遲主要受系統(tǒng)關(guān)調(diào)度(也稱關(guān)搶占)、調(diào)度點(diǎn)(也稱搶占點(diǎn))的影響。當(dāng)目標(biāo)任務(wù)所需資源就緒時(shí)，目標(biāo)任務(wù)所在的CPU上下文可能處于關(guān)調(diào)度的狀態(tài)，禁止搶占，必須等待打開(kāi)調(diào)度后才能發(fā)生調(diào)度行為，同關(guān)中斷一樣，關(guān)調(diào)度的范圍越大，可能的調(diào)度延遲也會(huì)越大，遇到這種情況OS一般會(huì)設(shè)置一個(gè)標(biāo)志，等待調(diào)度發(fā)生。同時(shí)由于調(diào)度是軟件行為，必須有調(diào)度點(diǎn)才能發(fā)生調(diào)度，即目標(biāo)任務(wù)就緒，目標(biāo)任務(wù)所在CPU也處于可調(diào)度狀態(tài)，此時(shí)需要有合適的調(diào)度點(diǎn)讓CPU發(fā)生調(diào)度行為。調(diào)度點(diǎn)又有主動(dòng)調(diào)度點(diǎn)和系統(tǒng)調(diào)度點(diǎn)。主動(dòng)調(diào)度點(diǎn)是指調(diào)用了可能引起阻塞的函數(shù)引起系統(tǒng)調(diào)度，而系統(tǒng)調(diào)度點(diǎn)是指系統(tǒng)在運(yùn)行過(guò)程中的調(diào)度，非應(yīng)用主動(dòng)發(fā)起，也稱搶占點(diǎn)，即當(dāng)前任務(wù)在未主動(dòng)讓出CPU的情況下被動(dòng)發(fā)生的調(diào)度，如Linux內(nèi)核中斷處理完成或者從內(nèi)核態(tài)返回用戶態(tài)時(shí)。

T03～T1調(diào)度開(kāi)銷是系統(tǒng)的基礎(chǔ)開(kāi)銷，受場(chǎng)景和OS具體實(shí)現(xiàn)影響如是同一地址空間內(nèi)線程切換還是進(jìn)程間切換、是否有特權(quán)級(jí)切換、是否實(shí)時(shí)線程、采用哪種調(diào)度策略、是否有資源配額限制等，這些因素會(huì)顯著的影響調(diào)度的開(kāi)銷。當(dāng)調(diào)度發(fā)生，已就緒的目標(biāo)線程是否被選為當(dāng)前任務(wù)取決于系統(tǒng)的調(diào)度策略。如Linux默認(rèn)采用的公平調(diào)度算法，任務(wù)根據(jù)動(dòng)態(tài)優(yōu)先級(jí)共享CPU。這在很大程度上保證了系統(tǒng)的公平，卻導(dǎo)致實(shí)時(shí)性的降低。此時(shí)基于優(yōu)先級(jí)的調(diào)度策略就派上了用場(chǎng)，當(dāng)高優(yōu)先級(jí)任務(wù)就緒時(shí)，搶占低優(yōu)先級(jí)任務(wù)，不管低優(yōu)先級(jí)任務(wù)是否完成，一般的實(shí)時(shí)OS均支持基于優(yōu)先級(jí)的調(diào)度策略。使用優(yōu)先級(jí)的調(diào)度策略，在使用加鎖的共享資源時(shí)，可能會(huì)遇到優(yōu)先級(jí)反轉(zhuǎn)問(wèn)題，導(dǎo)致高優(yōu)先級(jí)任務(wù)的實(shí)時(shí)性降低。另外系統(tǒng)中可能存在多個(gè)實(shí)時(shí)任務(wù)，影響多個(gè)實(shí)時(shí)任務(wù)的實(shí)時(shí)性的因素還包括這些實(shí)時(shí)任務(wù)的DeadLine的先后以及任務(wù)執(zhí)行時(shí)機(jī)，僅按優(yōu)先級(jí)處理也可能會(huì)導(dǎo)致任務(wù)DeadLine的失守。

表1:

至此完成影響系統(tǒng)響應(yīng)時(shí)間的分析，總結(jié)內(nèi)容如表1。下面對(duì)RT App負(fù)責(zé)的T1～T2處理時(shí)間進(jìn)行分析，從應(yīng)用編程的角度出發(fā)，RT App被喚醒后有一般三種運(yùn)行模式：

1.執(zhí)行計(jì)算邏輯

2.執(zhí)行系統(tǒng)調(diào)用，訪問(wèn)系統(tǒng)資源

3.線程間、進(jìn)程間通信

工程真實(shí)場(chǎng)景是上述三種情況的各種可能組合，但是影響實(shí)時(shí)性的因素主要與上述三種情況有關(guān)。

刨除RT App業(yè)務(wù)自身算法邏輯、調(diào)試、BUG等對(duì)計(jì)算時(shí)間的影響，在計(jì)算資源充足的情況下，影響計(jì)算邏輯時(shí)長(zhǎng)的可能因素主要是內(nèi)外部事件的打斷和搶占。關(guān)于內(nèi)外部事件打斷，是指RT App在執(zhí)行過(guò)程中頻繁被外設(shè)中斷、異常、信號(hào)等打斷，這些打斷會(huì)顯著的影響應(yīng)用執(zhí)行的確定性。中斷一般屬于不可屏蔽事件，如系統(tǒng)定時(shí)器、各種外設(shè)的IO訪問(wèn)；異常最常見(jiàn)的是缺頁(yè)異常，OS為提高應(yīng)用內(nèi)存使用效率，對(duì)物理內(nèi)存的映射是延遲執(zhí)行的，如在缺頁(yè)異常中完成，當(dāng)任務(wù)首次訪問(wèn)某內(nèi)存頁(yè)面或首次執(zhí)行某代碼段時(shí)，會(huì)造成缺頁(yè)異常，觸發(fā)相應(yīng)的內(nèi)存分配、映射機(jī)制，這部分操作的不確定性會(huì)影響任務(wù)的計(jì)算時(shí)間。內(nèi)存回收是指OS可用內(nèi)存低于某個(gè)水線時(shí)，系統(tǒng)對(duì)可回收內(nèi)存如cache進(jìn)行回收，之后再重新分配給應(yīng)用，這個(gè)過(guò)程可能比較耗時(shí)，進(jìn)而影響內(nèi)存分配的實(shí)時(shí)性，在某些極端情況下觸發(fā)OOM(Out Of Memory)和LMK(Low Memory Killer)，會(huì)導(dǎo)致更多非預(yù)期行為。關(guān)于信號(hào)是指POSIX信號(hào)，OS一般會(huì)在特權(quán)級(jí)切換時(shí)處理信號(hào)事件，這也會(huì)導(dǎo)致任務(wù)的計(jì)算被延遲。關(guān)于搶占，與任務(wù)本身的計(jì)算無(wú)關(guān)了，是當(dāng)前任務(wù)被更高優(yōu)先級(jí)的任務(wù)搶占或者由于配置了cgroup等配額管理導(dǎo)致沒(méi)有計(jì)算資源可用。除此之外，在某些架構(gòu)的處理器上可能還有一些調(diào)試異常、字節(jié)非對(duì)齊異常等打斷任務(wù)的執(zhí)行。

RT App執(zhí)行系統(tǒng)調(diào)用，又有幾種情況，一種是阻塞式系統(tǒng)調(diào)用，阻塞時(shí)長(zhǎng)的不確定性會(huì)導(dǎo)致Deadline的失守，如waitpid；第二種情況是該系統(tǒng)調(diào)用本身比較慢，如操作串口IO的printf，串口打印會(huì)顯著拖慢應(yīng)用的執(zhí)行速度就是這個(gè)原因。還有一種情況是該系統(tǒng)調(diào)用本身不會(huì)阻塞，但是在該系統(tǒng)調(diào)用的實(shí)現(xiàn)中訪問(wèn)了全局資源導(dǎo)致阻塞。

在多核多任務(wù)系統(tǒng)上線程間同步互斥或者進(jìn)程間通信可能會(huì)導(dǎo)致當(dāng)前任務(wù)的阻塞，也會(huì)顯著的影響計(jì)算確定性，進(jìn)而導(dǎo)致Deadline的失守，如mutex lock。

站在OS的角度看影響T1～T2處理時(shí)間的因素，就兩個(gè)：

1.線程執(zhí)行的非預(yù)期打斷

2.可能導(dǎo)致線程阻塞的調(diào)度行為

圖4 APP視角的運(yùn)行模型

站在目標(biāo)任務(wù)Rt App的角度上，影響T1～T2處理時(shí)間的因素就一個(gè)即RT App讓出CPU去執(zhí)行其它代碼。畢竟CPU永遠(yuǎn)都是在按照設(shè)計(jì)流程執(zhí)行計(jì)算，并無(wú)刻意偷懶。

除此之外系統(tǒng)對(duì)計(jì)算資源的分配也會(huì)顯著影響任務(wù)的實(shí)時(shí)性。如圖5：a、b、c三個(gè)同優(yōu)先級(jí)的任務(wù)同時(shí)到達(dá)，如果按圖示的執(zhí)行順序執(zhí)行則只有Da(a任務(wù)的Deadline)能滿足，其它兩個(gè)任務(wù)的Deadline都會(huì)失守，但如果把a(bǔ)任務(wù)的執(zhí)行適當(dāng)延遲到b、c任務(wù)之后，則可以保證三個(gè)任務(wù)的目標(biāo)Deadline都滿足。

圖5 實(shí)時(shí)任務(wù)調(diào)度

通過(guò)上述分析，可以看出影響任務(wù)實(shí)時(shí)性的主要因素基本與中斷(包含內(nèi)部中斷和外部中斷)、調(diào)度時(shí)機(jī)、調(diào)度策略、資源分配有關(guān)，掌握這些原理能幫助研發(fā)人員更好的理解實(shí)時(shí)性問(wèn)題的分析和解決方法。

三、如何解決實(shí)時(shí)性問(wèn)題

3.1 實(shí)時(shí)性問(wèn)題分析

書接上文，在動(dòng)手解決系統(tǒng)實(shí)時(shí)性問(wèn)題前，需要先明確系統(tǒng)的實(shí)時(shí)性瓶頸在哪里，根因是什么，以及制定優(yōu)化后的目標(biāo)。不同的系統(tǒng)、不同的場(chǎng)景，其面臨的實(shí)時(shí)性需求差異很大，沒(méi)有統(tǒng)一的答案，甚至沒(méi)有統(tǒng)一的方法。留下本章節(jié)的目的主要是想說(shuō)明這部分內(nèi)容的重要性，后續(xù)的優(yōu)化措施都是從這里出發(fā)，可根據(jù)第二章節(jié)的描述，大膽假設(shè)、小心求證，一步步接近真相。有道無(wú)術(shù)，尚可求也，若需求或者方向錯(cuò)了，一切皆是惘然。

3.2 RT App的實(shí)時(shí)優(yōu)化

據(jù)2.2章節(jié)分析所述影響RtApp實(shí)時(shí)性的因素主要是內(nèi)外部事件打斷和調(diào)度引起的阻塞。這兩種因素都可以視為外部干擾，針對(duì)干擾，最好的優(yōu)化措施是防止干擾，次之是降低干擾，安全OS一般都提供了豐富的免打擾機(jī)制。免于干擾是一個(gè)非常重要的安全功能，它能提高系統(tǒng)的實(shí)時(shí)性、確定性、安全性，在進(jìn)行安全相關(guān)業(yè)務(wù)的開(kāi)發(fā)和部署時(shí)一定要充分利用免于干擾的特性。

Linux、Unix、QNX等POSIX OS的很多免于干擾機(jī)制都是在進(jìn)程上生效的，因此實(shí)時(shí)任務(wù)要和其它通用任務(wù)做隔離，即使是實(shí)時(shí)任務(wù)間仍然可以使用線程隔離運(yùn)行。在資源允許的情況下，可以使用核隔離加親和性綁定的機(jī)制保證實(shí)時(shí)任務(wù)的運(yùn)行隔離，使用isolcpus參數(shù)隔離出獨(dú)立的CPU核用作實(shí)時(shí)任務(wù)的運(yùn)行，加上親和性綁定，可以保證除內(nèi)核必要的系統(tǒng)線程外，沒(méi)有其它線程能干擾到綁定到隔離核上實(shí)時(shí)任務(wù)的運(yùn)行。對(duì)于內(nèi)存使用導(dǎo)致的缺頁(yè)異常或者可能的分配不及時(shí)，可以使用預(yù)先分配內(nèi)存資源加mlockall資源鎖定的方法解決。RtApp在啟動(dòng)后可以預(yù)先將所需的內(nèi)存資源全部申請(qǐng)好，然后使用mlockall將所有資源鎖定，在后續(xù)的執(zhí)行過(guò)程中就不會(huì)存在向系統(tǒng)申請(qǐng)資源的情況。資源的預(yù)先申請(qǐng)可以使用動(dòng)態(tài)申請(qǐng)的方式，也可以使用靜態(tài)分配的方式。靜態(tài)分配的方式確定性更好也是功能安全相關(guān)標(biāo)準(zhǔn)強(qiáng)烈推薦的內(nèi)存使用方式，但是需要RtApp在設(shè)計(jì)實(shí)現(xiàn)時(shí)就確定相關(guān)資源；動(dòng)態(tài)申請(qǐng)的方式需要RtApp先從內(nèi)核將資源申請(qǐng)好，然后在用戶態(tài)由應(yīng)用自己維護(hù)內(nèi)存池，提供定制化的動(dòng)態(tài)申請(qǐng)釋放接口，gibc庫(kù)也有一定緩存管理機(jī)制，但是不一定滿足應(yīng)用的定制化訴求。不管是哪種方式，核心思想都是在使用資源時(shí)保證其確定性，而不是和系統(tǒng)中的其它任務(wù)競(jìng)爭(zhēng)。

圖6免于干擾的模型

除了對(duì)實(shí)時(shí)任務(wù)進(jìn)行設(shè)置外，還可以通過(guò)對(duì)其它非實(shí)時(shí)任務(wù)進(jìn)行限制排除或降低運(yùn)行干擾。在運(yùn)行上可以通過(guò)調(diào)整非實(shí)時(shí)任務(wù)的優(yōu)先級(jí)降低其CPU使用率，也可以通過(guò)一些工具如cpulimit、nice等命令控制任務(wù)的CPU占用率，控制組cgroup機(jī)制功能強(qiáng)大，可控制包含CPU、內(nèi)存等資源的使用，也可使用POSIX接口setrlimit控制內(nèi)存等資源使用上限。

對(duì)于因RtApp主動(dòng)調(diào)度降低實(shí)時(shí)性的問(wèn)題，需要靠RtApp在設(shè)計(jì)實(shí)現(xiàn)時(shí)避免使用此類接口，避免使用臨界區(qū)，通常規(guī)則是在做實(shí)時(shí)操作時(shí)可以釋放資源如鎖、信號(hào)量等，但是不要獲取資源。對(duì)于阻塞式操作如IO操作，可以使用POSIX規(guī)范設(shè)置IO_NONBLOCK非阻塞工作模式，在該模式下IO操作以非阻塞模式運(yùn)行，任務(wù)根據(jù)資源的就緒情況進(jìn)行處理。對(duì)于被搶占，需要根據(jù)系統(tǒng)可調(diào)度性分析結(jié)果，根據(jù)需求合理的設(shè)計(jì)各任務(wù)之間的調(diào)度策略、優(yōu)先級(jí)、任務(wù)執(zhí)行時(shí)機(jī)等，同時(shí)在實(shí)時(shí)任務(wù)間進(jìn)行互斥時(shí)，使用帶有優(yōu)先級(jí)繼承的mutex鎖，防止出現(xiàn)反轉(zhuǎn)。

關(guān)于調(diào)度策略和計(jì)算資源在多實(shí)時(shí)任務(wù)間的分配，這里以Linux為例介紹一下常見(jiàn)的調(diào)度策略，其中非實(shí)時(shí)調(diào)度策略為：SCHED_OTHER、SCHED_BATCH、SCHED_IDLE，這三個(gè)調(diào)度策略大同小異，都是基于動(dòng)態(tài)nice值的公平調(diào)度。實(shí)時(shí)調(diào)度策略為：SCHED_FIFO、SCHED_RR、SCHED_DEADLINE。SCHED_RR和SCHED_FIFO都是基于固定優(yōu)先級(jí)的調(diào)度策略，其中RR相較于FIFO的區(qū)別在與優(yōu)先級(jí)相同情況下是否會(huì)主動(dòng)讓出CPU，而SCHED_DEADLINE是根據(jù)Deadline的先后來(lái)調(diào)度的也就是EDF調(diào)度算法，EDF可搶占FIFO、RR的任務(wù)。在進(jìn)行計(jì)算資源分配時(shí)需要結(jié)合業(yè)務(wù)特征選擇合適的調(diào)度算法，防止出現(xiàn)圖5情況的發(fā)生。

針對(duì)一些其它打斷如軟硬中斷太多，可通過(guò)親和性設(shè)置把中斷和軟中斷線程綁定到其他核上；對(duì)定時(shí)信號(hào)打斷可更換定時(shí)器的使用方式為timerfd，在資源允許的情況下對(duì)于一些場(chǎng)景，還可能使用輪詢模式代替中斷模式來(lái)提高實(shí)時(shí)性，但是此類情況需要具體問(wèn)題具體分析了。

針對(duì)自動(dòng)駕駛應(yīng)用場(chǎng)景，普遍使用CPU、GPU、BPU、DSP、NPU等異構(gòu)核混合計(jì)算，存在大量任務(wù)覆蓋感知、規(guī)劃、決策全流程，基于事件驅(qū)動(dòng)并完全交由OS編排調(diào)度，存在任務(wù)執(zhí)行抖動(dòng)大的問(wèn)題。而基于有向無(wú)環(huán)圖的方式組織計(jì)算任務(wù)，并根據(jù)圖的特性對(duì)任務(wù)進(jìn)行編排能大大提高任務(wù)的實(shí)時(shí)性，這種方法降低了任務(wù)運(yùn)行確定性對(duì)于OS的依賴，且保持較高的靈活性，百度Apollo的Cyber以及英偉達(dá)DriveWorks的CGF均使用了該方法。

總結(jié)下來(lái)對(duì)于提高任務(wù)實(shí)時(shí)性的核心思想就是通過(guò)使用確定性資源，隔離或減少外部干擾，避免執(zhí)行被非預(yù)期打斷達(dá)到時(shí)間、空間的確定性，對(duì)于多任務(wù)場(chǎng)景還需要結(jié)合其它任務(wù)的特征選擇合適的調(diào)度策略。

3.3 OS實(shí)時(shí)優(yōu)化方案

在給出具體的優(yōu)化措施分析前，回到表1分析出的影響實(shí)時(shí)性的關(guān)鍵因素，從源頭出發(fā)，給出解決OS實(shí)時(shí)性問(wèn)題的思路，如表2。

表2

后文將根據(jù)這個(gè)優(yōu)化思路基于Linux這個(gè)應(yīng)用廣泛的OS，描述在工程實(shí)踐中針對(duì)OS的實(shí)時(shí)性增強(qiáng)，通常的措施有如下一些：

1.根據(jù)業(yè)務(wù)場(chǎng)景需求調(diào)整實(shí)時(shí)中斷的優(yōu)先級(jí)或親和性，確保實(shí)時(shí)任務(wù)關(guān)注的中斷能夠被及時(shí)的響應(yīng)，合理設(shè)置中斷的觸發(fā)時(shí)機(jī)，規(guī)避中斷風(fēng)暴。

2.提高內(nèi)核時(shí)鐘頻率，也就是CONFIG_HZ，增加內(nèi)核時(shí)鐘HZ可以顯著的提高任務(wù)響應(yīng)的實(shí)時(shí)性，本質(zhì)上是通過(guò)增加定時(shí)中斷，變相增加調(diào)度點(diǎn)，因?yàn)長(zhǎng)inux內(nèi)核在中斷處理完成時(shí)會(huì)發(fā)起調(diào)度。同理，取消CONFIG_NO_HZ的配置，也是相同的道理，該配置會(huì)減少內(nèi)核無(wú)用定時(shí)器中斷，降低開(kāi)銷，進(jìn)而變相減少調(diào)度點(diǎn)。

3.不論是哪種OS內(nèi)核，在開(kāi)發(fā)實(shí)現(xiàn)時(shí)都需要減少鎖的使用，尤其是多個(gè)場(chǎng)景或者關(guān)鍵路徑上同時(shí)持有一個(gè)鎖是需要盡量避免的，可通過(guò)大鎖換小鎖或者無(wú)鎖設(shè)計(jì)來(lái)解決。即使必須使用鎖，也需根據(jù)場(chǎng)景選擇開(kāi)銷最小的方式，如讀寫鎖、互斥鎖、自旋鎖。

4.打開(kāi)內(nèi)核搶占，大部分OS包括Linux都是支持搶占模式的，用戶可根據(jù)自己的應(yīng)用場(chǎng)景選擇配置不同的搶占模式，在下圖menuconfig中已很明確的說(shuō)明了每種配置所支持的應(yīng)用場(chǎng)景：強(qiáng)調(diào)吞吐性和可用性的服務(wù)器模式(無(wú)搶占點(diǎn)，此模式下內(nèi)核態(tài)代碼完全無(wú)法搶占)；強(qiáng)調(diào)均衡性能以及用戶響應(yīng)的桌面模式（此模式下通過(guò)硬編碼增加了一些自愿搶占點(diǎn)）；基于桌面的低延遲增強(qiáng)模式（此模式相對(duì)于之前的模式搶占點(diǎn)增加更多）。這三種模式本質(zhì)上都是做一件事，就是在內(nèi)核的各種關(guān)鍵路徑上逐級(jí)遞增調(diào)度點(diǎn)。

圖7 Linux內(nèi)核搶占模式

5.Linux RT補(bǔ)丁，打上該補(bǔ)丁后，Linux的搶占模式還會(huì)增加兩種，每種模式都包含一些優(yōu)化措施，這些措施本質(zhì)上依然是兩點(diǎn)：減少關(guān)中斷、關(guān)搶占的代碼路徑與增加更多的調(diào)度點(diǎn)。如中斷線程化，該措施會(huì)更進(jìn)一步減少關(guān)中斷執(zhí)行的代碼范圍，把更多的處理邏輯放到中斷線程中去做，線程上下文是可打斷可搶占的；再如通過(guò)rt_mutex 重新實(shí)現(xiàn)spinlock_t，Linux內(nèi)核的spinlock機(jī)制是一種CPU鎖機(jī)制，在沒(méi)打RT補(bǔ)丁時(shí)，一旦調(diào)用該鎖，則禁止中斷或禁止搶占，并持續(xù)占有CPU直到鎖資源就緒，非常影響實(shí)時(shí)性。重寫spinlock后內(nèi)核中大量使用自旋鎖spinlock的地方變成了可以調(diào)度的點(diǎn)，且不會(huì)無(wú)意義的空耗CPU。

6.如果不局限實(shí)時(shí)任務(wù)的處理必須在用戶態(tài)，可以在內(nèi)核開(kāi)發(fā)實(shí)時(shí)任務(wù)，這種方法配合上述其它措施，可大大提高任務(wù)的實(shí)時(shí)性，因?yàn)槿蝿?wù)處于內(nèi)核態(tài)，不會(huì)有特權(quán)級(jí)切換，不會(huì)有缺頁(yè)異常，上下文切換導(dǎo)致的cachemiss開(kāi)銷也會(huì)小很多，經(jīng)典RTOS所有任務(wù)都運(yùn)行在一個(gè)地址空間，在這一點(diǎn)上有很大優(yōu)勢(shì)，即使對(duì)于微內(nèi)核OS，在工程實(shí)踐中也可以通過(guò)將部分關(guān)鍵任務(wù)放在內(nèi)核態(tài)來(lái)提高其實(shí)時(shí)性能如定時(shí)器管理任務(wù)。

7.除了上述專門針對(duì)實(shí)時(shí)性的優(yōu)化措施外，還有部分內(nèi)核調(diào)試、安全檢查功能對(duì)于實(shí)時(shí)性影響較大，如lockup檢測(cè)機(jī)制以及一些調(diào)試功能如ftrace，這些功能單點(diǎn)耗時(shí)并不多，但是加在一起也是一個(gè)很可觀的開(kāi)銷。

對(duì)于Linux，完成上述優(yōu)化措施后，在不修改內(nèi)核接口以及框架的情況下，通過(guò)打補(bǔ)丁的方式能做的優(yōu)化措施也已經(jīng)基本做完了。通常來(lái)講，此時(shí)Linux任務(wù)的實(shí)時(shí)性會(huì)有一個(gè)很明顯的提升，但是是否可以做到硬實(shí)時(shí)？實(shí)踐中對(duì)于多數(shù)場(chǎng)景已經(jīng)夠了，但是Linux內(nèi)核功能的豐富性和復(fù)雜性決定了其依然有大量的不確定性，為此就引出了后續(xù)的一些優(yōu)化方案。

8.基于Xenomai或EVL的雙域方案(還有更早的RTLinux)，該方案采用雙域，將內(nèi)核分為兩個(gè)域，一個(gè)功能簡(jiǎn)單結(jié)構(gòu)精簡(jiǎn)的EVL Core實(shí)時(shí)域，一個(gè)非實(shí)時(shí)的Linux域，兩個(gè)域共同使用一個(gè)硬件抽象層，實(shí)時(shí)域提供一套獨(dú)立的接口供上層RT App使用。該方案比較重要的幾個(gè)點(diǎn)是：

• Linux域的所有代碼均可被中斷打斷，Linux域的關(guān)中斷代碼被重寫了，實(shí)際上不會(huì)關(guān)硬件中斷，而僅是置一個(gè)標(biāo)志位
• 所有外設(shè)中斷，均會(huì)先交由EVL Core實(shí)時(shí)域先處理，之后才交給Linux域處理，且不再受Linux域關(guān)中斷影響，因此大大提高中斷處理的及時(shí)性
• 運(yùn)行在實(shí)時(shí)域的實(shí)時(shí)任務(wù)的調(diào)度不再依賴Linux域，因?yàn)镋VL Core實(shí)時(shí)域的功能簡(jiǎn)單，調(diào)度延遲相較于Linux的調(diào)度延遲低很多，可大大提高調(diào)度及時(shí)性
• 為保證實(shí)時(shí)性，RtApp的變成需要使用實(shí)時(shí)域?qū)Ｓ媒涌?，否則可能導(dǎo)致運(yùn)行域切換影響實(shí)時(shí)性

圖8 EVL架構(gòu)示意圖

該方案也支持CPU核和內(nèi)存資源的預(yù)先分配，可確保EVL Core實(shí)時(shí)域獲得確定的CPU核和內(nèi)存資源，該方案在X86平臺(tái)上可做到10微秒級(jí)的延遲與抖動(dòng)。把兩個(gè)域作為一個(gè)整體來(lái)看，其核心依然是通過(guò)dovetail和evl Core大大降低了中斷延遲與處理的時(shí)間以及EVL側(cè)的調(diào)度延遲。

9.如果上述方案依然無(wú)法滿足實(shí)時(shí)性需求，而又確實(shí)想使用Linux的生態(tài)和資源，業(yè)界仍然有解決方案，即基于內(nèi)存分區(qū)、CPU核隔離的Linux+RTOS雙系統(tǒng)方案，該方案的相較于EVL的雙域方案更進(jìn)一步，直接在物理層做了設(shè)備隔離，OS做了軟件隔離，可確保Linux不會(huì)影響RTOS側(cè)的實(shí)時(shí)業(yè)務(wù)，如果兩個(gè)OS需要通信，既可通過(guò)外設(shè)通信，也可通過(guò)共享內(nèi)存的機(jī)制實(shí)現(xiàn)。該方案在工業(yè)控制領(lǐng)域有不少成功的案例，且Linux也可切換為其它操作系統(tǒng)如Windows+RTX。

圖9 Windows+RTX示意圖

措施8、9都是通過(guò)不同的方法確保實(shí)時(shí)任務(wù)和非實(shí)時(shí)任務(wù)的隔離，且實(shí)時(shí)任務(wù)由于使用了精簡(jiǎn)的RT運(yùn)行時(shí)確保任務(wù)的實(shí)時(shí)性與確定性。

3.4 實(shí)時(shí)性與應(yīng)用場(chǎng)景探討

實(shí)時(shí)和非實(shí)時(shí)都有其適用的應(yīng)用場(chǎng)景，如對(duì)于任務(wù)執(zhí)行時(shí)間確定，到達(dá)時(shí)間確定的周期性任務(wù)，采用RMA策略的實(shí)時(shí)OS能很好的滿足其需求，但是也有部分場(chǎng)景不適合，比如手機(jī)、PC機(jī)、服務(wù)器等有大量各種類型任務(wù)同時(shí)并發(fā)的開(kāi)放式應(yīng)用場(chǎng)景。在上述這些應(yīng)用場(chǎng)景里，如果系統(tǒng)內(nèi)的任務(wù)全部設(shè)置為基于優(yōu)先級(jí)調(diào)度，會(huì)是什么情況呢？假設(shè)優(yōu)先級(jí)設(shè)置不合理，或者部分應(yīng)用惡意調(diào)高優(yōu)先級(jí)頻繁占用CPU資源，會(huì)導(dǎo)致一些正常業(yè)務(wù)餓死，UI卡頓，用戶會(huì)出現(xiàn)明顯的不適。

在Mixed-critical系統(tǒng)里，既部署有實(shí)時(shí)任務(wù)，也部署有非實(shí)時(shí)任務(wù)，此時(shí)需要在保障實(shí)時(shí)任務(wù)的前提下也確保系統(tǒng)的可用性、吞吐性等，這種場(chǎng)景和需求下并不是所有的實(shí)時(shí)措施都適合。如在對(duì)RtApp進(jìn)行優(yōu)化時(shí)使用的免于干擾機(jī)制，不論是核隔離綁定、還是內(nèi)存資源的預(yù)先確定對(duì)資源消耗都非常大，會(huì)對(duì)系統(tǒng)的可用性有影響，在系統(tǒng)資源受限時(shí)需要慎重使用；對(duì)于雙域方案，則需要對(duì)業(yè)務(wù)的部署進(jìn)行域的劃分，且控制應(yīng)用的編程接口和運(yùn)行模式，適用于新開(kāi)發(fā)的應(yīng)用或者是容易移植的場(chǎng)景。在進(jìn)行實(shí)時(shí)性優(yōu)化時(shí)需要根據(jù)自己的應(yīng)用場(chǎng)景對(duì)實(shí)時(shí)路徑進(jìn)行分解，明確實(shí)施指標(biāo)并結(jié)合其它系統(tǒng)需求選擇合適的方案。

除此之外實(shí)時(shí)性不是沒(méi)有代價(jià)的，高實(shí)時(shí)性系統(tǒng)保障的是最差場(chǎng)景下的時(shí)間約束，而不是平均場(chǎng)景或者最常用場(chǎng)景，實(shí)際工程實(shí)踐經(jīng)驗(yàn)是其可能帶來(lái)其它場(chǎng)景的性能下降。以下是一些在工程實(shí)踐時(shí)需要特別注意的點(diǎn)：

1.親和性設(shè)置，不論是中斷的親和性還是任務(wù)的親和性，需要考慮負(fù)載的均衡，避免出現(xiàn)“忙死、餓死”等現(xiàn)象尤其是業(yè)務(wù)負(fù)荷比較復(fù)雜的mix-critical系統(tǒng)，可能會(huì)出現(xiàn)除實(shí)時(shí)性任務(wù)或?qū)崟r(shí)中斷能及時(shí)響應(yīng)外，其它任務(wù)都不能及時(shí)響應(yīng)的問(wèn)題，最終仍然是不能滿足項(xiàng)目目標(biāo)的。

2.對(duì)于大量使用第三方或者開(kāi)源組件的項(xiàng)目，mlockall需慎用，避免出現(xiàn)內(nèi)存資源快速耗盡導(dǎo)致OOM的問(wèn)題，如果系統(tǒng)出現(xiàn)OOM，需要配合調(diào)整相關(guān)實(shí)時(shí)任務(wù)的優(yōu)先級(jí)確保其不會(huì)被LMK殺掉。

3.關(guān)于實(shí)時(shí)任務(wù)的優(yōu)先級(jí)，不能設(shè)置成相同的最高99優(yōu)先級(jí)，這會(huì)導(dǎo)致系統(tǒng)一些實(shí)時(shí)性要求不高，但是對(duì)于可用性非常重要的任務(wù)如Linux里用于各種同步的worker線程餓死，導(dǎo)致系統(tǒng)以其它形式卡死導(dǎo)致不可用，同時(shí)優(yōu)先級(jí)不是萬(wàn)能的，優(yōu)先級(jí)的設(shè)置必須符合業(yè)務(wù)特征且充分考慮了多個(gè)實(shí)時(shí)任務(wù)間的影響。

4.關(guān)于提高時(shí)鐘頻率，關(guān)閉動(dòng)態(tài)調(diào)頻、休眠等措施，會(huì)顯著的提高系統(tǒng)平均功耗，這種情況下需要結(jié)合軟件應(yīng)用場(chǎng)景和硬件平臺(tái)的特性進(jìn)行優(yōu)化，如外掛低功耗MCU做一些低功耗實(shí)時(shí)任務(wù)的方式解決。

5.關(guān)于Linux的RT補(bǔ)丁，其普適性是有爭(zhēng)議的，尤其是對(duì)于大量第三方驅(qū)動(dòng)的適配并未經(jīng)過(guò)充分驗(yàn)證，盲目打RT補(bǔ)丁可能會(huì)導(dǎo)致系統(tǒng)的穩(wěn)定性降低。

6.對(duì)于EVL或AMP這種雙域/雙系統(tǒng)方案，其對(duì)軟件部署的模型、外設(shè)資源的分配都有要求，需要站在整個(gè)系統(tǒng)層面評(píng)估方案，避免出現(xiàn)返工。且EVL方案在提高EVL域的實(shí)時(shí)性的代價(jià)是降低了Linux側(cè)的整體實(shí)時(shí)性與應(yīng)用編程的便捷性。

7.部分優(yōu)化措施是有矛盾點(diǎn)的，如為提高中斷或調(diào)度響應(yīng)的及時(shí)性需要增加搶占點(diǎn)和可中斷區(qū)域，但是實(shí)時(shí)任務(wù)如果想提高實(shí)時(shí)性和確定性就必須減少系統(tǒng)中斷和調(diào)度的干擾，最好是非搶占，這些措施之間的平衡需要結(jié)合場(chǎng)景和需求考量。

8.實(shí)時(shí)不等于端到端的快，尤其是多核多任務(wù)的長(zhǎng)流程業(yè)務(wù)，為提高實(shí)時(shí)性額外增加的調(diào)度點(diǎn)和中斷勢(shì)必會(huì)增加系統(tǒng)本身的開(kāi)銷而降低應(yīng)用可使用CPU的資源，且實(shí)時(shí)性與極限吞吐性的矛盾從原理上來(lái)說(shuō)是不可調(diào)和的。實(shí)時(shí)性是一個(gè)需求，但不是唯一的需求，需要回到源頭的應(yīng)用場(chǎng)景和客戶價(jià)值上來(lái)做判斷。

9.最后關(guān)于系統(tǒng)實(shí)時(shí)性，不僅是OS或者單個(gè)實(shí)時(shí)任務(wù)的事情，而是整個(gè)軟件產(chǎn)品里所有有實(shí)時(shí)訴求的任務(wù)、中間件、OS等各種可能的組合，針對(duì)這些具體場(chǎng)景需要結(jié)合系統(tǒng)的可調(diào)度性分析，配合工具進(jìn)行優(yōu)化和配置，避免頭痛醫(yī)頭、腳痛醫(yī)腳。

四、總結(jié)

本文介紹了實(shí)時(shí)性的概念，基于一個(gè)場(chǎng)景從應(yīng)用和OS的角度分析了影響實(shí)時(shí)性的各種關(guān)鍵因素，并基于這些因素給出了相應(yīng)的解決方案和思路。在最后章節(jié)探討了這些解決方案的適用性及需要注意的問(wèn)題。全文總結(jié)如下：

1.影響任務(wù)響應(yīng)的最大因素為中斷延遲和調(diào)度延遲，基于Linux，調(diào)度延遲尤甚

2.提高響應(yīng)速度的關(guān)鍵是降低關(guān)中斷、關(guān)調(diào)度的區(qū)域以及更多的調(diào)度點(diǎn)

3.提高任務(wù)實(shí)時(shí)性和確定性的關(guān)鍵是排除干擾和基于具體場(chǎng)景的計(jì)算資源分配

4.方法可以通用，方案源于需求，細(xì)節(jié)決定成敗，沒(méi)有包打天下的方案