柚子快報邀請碼778899分享：QNX為什么是安全的操作系統(tǒng)？

http://yzkb.51969.com/

來自微信公眾號：車端軟件開發(fā)，大佬講的很好，在此整理補充做個筆記

目錄

QNX介紹

QNX特點

QNX是嵌入式硬實時的微內核操作系統(tǒng)

QNX是類UNIX操作系統(tǒng)

QNX是功能安全和信息安全的操作系統(tǒng)

QNX其他特性

1. QNX調度算法及策略

2. QNX IPC通訊機制

3. QNX 的IDE集成開發(fā)環(huán)境

中國自動輔助駕駛領域基礎平臺軟件所遇到的問題

QNX算法移植以及性能優(yōu)化舉例

算法移植

分享常見的QNX性能優(yōu)化項

IPC優(yōu)化

編譯選項優(yōu)化

驅動級別優(yōu)化

網絡協議棧優(yōu)化

系統(tǒng)API優(yōu)化

用戶接口優(yōu)化

QNX提供Momentics?IDE環(huán)境對算法進行性能分析

QNX提供了onboard debug也支持應用程序調用棧的實時保存及相應的GDB，在調查一些忙等的現場會有很大的幫助。

QNX調度算法

基本調度算法

調度策略

先進先出（FIFO）

輪詢（Round Robin）

零星調度（Sporadic）

什么時候會發(fā)生調度？

中斷與優(yōu)先級

多CPU上的線程調度

自適應分區(qū)調度算法

分區(qū)調度

自適應分區(qū)調度

自適應分區(qū)調度與線程優(yōu)先級

自適應分區(qū)調度富裕算力分配

“關鍵線程”與“關鍵分區(qū)”

關鍵線程的破產

自適應分區(qū)繼承

自適應分區(qū)的小結

QNX介紹

????????QNX成立于1980年，是全世界第一個類UNIX的符合POSIX標準的微內核的硬實時操作系統(tǒng)，在過去的幾十年中廣泛的應用在汽車、工業(yè)自動化、國防、航空航天、醫(yī)療、核電和通信等領域，提供以嵌入式操作系統(tǒng)為核心的中間件和基礎軟件解決方案。

????????到目前為止，世界上幾乎所有的主機廠都采用了基于QNX操作系統(tǒng)的軟件技術。全球top?25家電動汽車廠家，其中24家在使用QNX的軟件操作系統(tǒng)，例如，中國的小鵬汽車自動輔助駕駛系統(tǒng)Xpilot3.0和Xpilot3.5基于QNX通過TUV萊茵ISO26262 ASIL D功能安全的硬實操作系統(tǒng)，合眾新能源汽車的哪吒S采用QNX Hypervisor打造其全新科技感智能座艙，并在其全棧自研的TA PILOT 3.0智能駕駛系統(tǒng)中搭載QNX OS for Safety操作系統(tǒng)，實現多種場景下的智能輔助駕駛，又如零跑汽車在其量產的第三代高端純電SUV—零跑C11和智能純電橋車C01中均采用了QNX Neutrino實時操作系統(tǒng)和QNX Hypervisor，旨在為中國消費者帶來更個性化與舒適的駕駛體驗。除此之外，高合即將發(fā)布的豪華純電超跑HiPhi Z的自動輔助駕駛平臺使用的是英偉達Orin-X芯片和 QNX 嵌入式硬實時操作系統(tǒng)。

QNX特點

QNX是嵌入式硬實時的微內核操作系統(tǒng)

有硬實時、微內核、模塊化、弱耦合、分布式的特點，從1980年誕生之初就是基于SOA架構設計，基于Client-Server的模型，具體表現為:

硬實時：任何切換時間和中斷時延速度快，所有的任務響應均為確定性deterministic行為。微內核：除調度、進程管理、中斷及操作系統(tǒng)核心的功能外，其余部分都處于用戶態(tài)，包括驅動、協議棧、文件系統(tǒng)及功能模塊等。模塊化：操作系統(tǒng)的各個功能單元都模塊化設計，內存保護，并且相互隔離，可按照需要動態(tài)加載或卸載，基于消息機制通信，按照Client-Server的架構設計。弱耦合：模塊與模塊之間互不影響，都在獨立的虛擬地址空間運行。分布式：局域網內的QNX系統(tǒng)對于用戶角度可以認為是一臺QNX系統(tǒng)，資源可以復用。

微內核則和宏內核結構相反，它提倡內核中的功能模塊盡可能的少。內核只提供最核心的功能，比如任務調度，中斷處理等等。其他實際的模塊功能如進程管理、存儲器管理、文件管理……這些則被移出內核，變成一個個服務進程，和用戶進程同等級，只是它們是一種特殊的用戶進程。

QNX是類UNIX操作系統(tǒng)

????????遵循POSIX的最高級別PSE54標準（注：POSIX標準有四個等級PSE51, PSE52, PSE53和 PSE54, 在RTOS實時操作系統(tǒng)的世界里，只有QNX操作系統(tǒng)是PSE54標準的，因為QNX誕生之初就是類UNIX系統(tǒng)按照POSIX標準編寫），因此基于開源的應用程序以及一些開源的中間件都可以無縫的移植到QNX系統(tǒng)之上。QNX Microkernel和Process Manager組成QNX最小系統(tǒng)Procnto，其他如驅動程序、協議棧、文件系統(tǒng)、應用程序都作為一個獨立的模塊運行在QNX系統(tǒng)之上。

????????POSIX（Portable Operating System Interface，可移植操作系統(tǒng)接口）是一個IEEE標準，旨在提高各種UNIX操作系統(tǒng)上運行的軟件的可移植性和兼容性。它定義了操作系統(tǒng)應該為應用程序提供的接口標準，使得遵循POSIX標準的軟件能夠在不同的操作系統(tǒng)上運行，而無需進行大量的修改。

????????POSIX標準有四個等級：PSE51、PSE52、PSE53和PSE54。這些等級代表了不同的兼容性和功能級別，其中PSE54是最高級別。在RTOS（實時操作系統(tǒng)）的世界中，QNX操作系統(tǒng)是唯一一個符合PSE54標準的系統(tǒng)。這是因為QNX從誕生之初就是基于類UNIX系統(tǒng)并按照POSIX標準編寫的，因此它具有高度的兼容性和可移植性。

遵循POSIX最高標準（PSE54）意味著QNX操作系統(tǒng)完全遵循了POSIX定義的所有接口和功能要求。這使得基于開源的應用程序以及一些開源的中間件，只要它們也遵循POSIX標準，就可以無縫地移植到QNX系統(tǒng)之上。換句話說，這些應用程序和中間件無需進行大量的修改或重新編寫，就可以直接在QNX系統(tǒng)上運行，從而大大簡化了移植過程并提高了效率。

QNX Microkernel和Process Manager組成QNX的最小系統(tǒng)Procnto，為系統(tǒng)提供了基本的內核和進程管理功能。其他如驅動程序、協議棧、文件系統(tǒng)、應用程序等都作為獨立的模塊運行在QNX系統(tǒng)之上。這種模塊化設計使得QNX系統(tǒng)非常靈活和可擴展，可以根據不同的需求添加或刪除模塊。

總的來說，POSIX最高標準（PSE54）為QNX操作系統(tǒng)提供了高度的兼容性和可移植性，使得基于POSIX標準的應用程序和中間件可以無縫地移植到QNX系統(tǒng)上。這種特性使得QNX在RTOS領域具有獨特的優(yōu)勢，能夠滿足各種復雜的實時應用需求。

QNX是功能安全和信息安全的操作系統(tǒng)

QNX通過功能安全TUV萊茵ISO 26262 ASIL D最高等級道路車輛最高功能等級安全認證，包括QNX 操作系統(tǒng)、QNX Hypervisor虛擬化和Graphic Monitor圖形監(jiān)控子系統(tǒng)以及QNX IPC通訊機制black channel，同時黑莓是網絡信息安全標準ISO/SAE 21434 委員會基礎軟件組唯一成員。

QNX其他特性

1. QNX調度算法及策略

QNX調度算法有很多種，本質上基于優(yōu)先級搶占式。QNX的線程優(yōu)先級是一個0-255的數字，數字越大優(yōu)先級越高。在QNX上有三種基本調度策略，可以單獨使用也可以組合使用，包括基于時間片輪詢Round Robin、優(yōu)先級搶占式FIFO和基于時間Budget的Sporadic算法。同時QNX還提供APS自適應分區(qū)調度算法，在CPU滿負荷的場景下保證低優(yōu)先級的任務有調度的機會，不被“餓死”。

2. QNX IPC通訊機制

QNX除了支持Native的IPC機制如Massage passing、Signal等，同時還提供POSIX標準的IPC例如MessageQ、Piple、Shared Memory等IPC通訊方式，多種IPC方式供用戶在不同的應用場景下進行選擇。

3. QNX 的IDE集成開發(fā)環(huán)境

QNX提供基于Eclipse的Momentics IDE集成開發(fā)環(huán)境，供用戶進行基于以太網Software GDB的代碼級的編譯調試或系統(tǒng)性能分析，可實時以圖形化的方式，查看進程資源、系統(tǒng)日志、CPU占用情況，內存使用情況，進程間通信以及Coredump等。

中國自動輔助駕駛領域基礎平臺軟件所遇到的問題

????????近年來自動輔助駕駛領域非?；鸨?，許多國內外的主機廠都逐步在量產項目中開發(fā)以及發(fā)布L2+的功能，當我們回顧這幾年來快速發(fā)展會發(fā)現，大多數的自動輔助駕駛的人才都來自于Robotaxi，自動駕駛算法初創(chuàng)公司或大學研究機構，特別是算法人才。這就有個顯著的特點，在這些公司里面的大多數項目，最初都是基于工控機+英偉達顯卡（大多數用英偉達的GPU，少數用AMD的）+開源的操作系統(tǒng)+來自于開源的算法，其實和汽車電子的安全性本身毫無關系，唯一的好處就是快，容易盡早演示，盡快融資。

????????這些算法人才加入主機廠之后，更傾向于用以前最熟悉的開發(fā)方式，這樣好盡快的出演示成果，也就是英偉達的SOC+開源的操作系統(tǒng)+來自于開源的算法。另一方面，在自動輔助駕駛項目中，一般主機廠會把控制器平臺即硬件和平臺軟件外包給外部的Tier1來做，類似于一臺PC電腦，而自己開發(fā)應用和算法。

????????一般主機廠也有平臺組，負責部分的驅動及驅動以上的中間件的整合，系統(tǒng)組負責系統(tǒng)設計統(tǒng)籌，功能安全團隊負責整體的功能安全，而算法團隊負責算法應用的開發(fā)和實現，那么問題就來了，除純算法團隊外，一般國外的主機廠都會有一個成建制的叫算法嵌入式工程實現的團隊，負責算法在非工控機的嵌入式環(huán)境和實時操作系統(tǒng)的優(yōu)化實現落地，這樣的團隊即要懂一點算法架構，又要懂嵌入式軟件的開發(fā)和硬件特性，又要對操作系統(tǒng)有足夠的理解。

????????而在中國的許多主機廠，沒有看到有這樣一個團隊，甚至這樣的人才存在。因此不少項目由于開發(fā)周期緊，人員不具備嵌入式系統(tǒng)開發(fā)的經驗，會采用更接近于robotaxi的方式開發(fā)，即英偉達SOC中的處理器（類似工控機），SOC中的GPU（類似顯卡）和開源操作系統(tǒng)+未經優(yōu)化的各種開源算法，在滿足基本功能和有限性能的前提下，功能安全團隊的建議通常會被直接忽略，因為要滿足極短的量產時間，在國內主機廠軍備競賽中領先才是最重要的，這在歐美的主機廠是不可想象的。在這一點上，中國也有許多人才儲備充足并且付責任的主機廠做的非常好，特別是有專門的經驗豐富的算法工程實現的團隊負責優(yōu)化落地。期待在不久的將來，能夠有更多的主機廠重視起這個問題，在中國有更多的行業(yè)人才能夠填補這一空白。

QNX算法移植以及性能優(yōu)化舉例

QNX提供ADAS reference平臺產品，里面涵蓋了Sensor Framework，networking，open source modules，第三方的SDK以及一些參考設計，其中sensor Framework提供了ADAS的一些基本庫。

算法移植

自動輔助駕駛以開源的算法居多，由于QNX符合POSIX PSE54標準，API兼容基本一致，因此各類開源算法可以很方便的移植到QNX的平臺上，使用QNX的工具鏈進行編譯并運行，但是雖然API是一致的，但由于實時操作系統(tǒng)的特性，表現的行為會有所差異，需要對系統(tǒng)進行優(yōu)化調整。

QNX有專門的team來根據roadmap以及客戶需求移植一些開源軟件，比如ROS/ROS2，比如OpenCV和vSomeIP，我們也會負責后期的維護。

分享常見的QNX性能優(yōu)化項

IPC優(yōu)化

????????QNX支持絕大部分主流POSIX系統(tǒng)常見的IPC方式，同時也有其獨特的原生IPC方式，Message-passing。在自動輔助駕駛方案設計中，常有公司會將UDS、DDS做為軟件通信總線的架構方案原封不動地從Linux照搬到QNX上。從功能上看，這樣的跨平臺方案可以使得代碼重用并且功能沒有區(qū)別。但從性能角度考慮，由于QNX獨特內核架構，這并不是高效的解決方案。不同于Linux的宏內核架構，QNX為了安全性和實時性采用了微內核架構，絕大部分的系統(tǒng)服務，比如網絡協議棧，它是完全運行在內核之外以服務（Resource Manager)的方式運行。如果采用UDS（Unix Domain Socket)這用基于網絡服務（嚴格意義上講，UDS并不需要經過網絡協議棧，但也是需要經過QNX的網絡服務io-pkt支持）的通訊方式，那么所有的數據報都需要經過網絡服務中轉，相比直接通訊多了一次IPC，這就帶來了系統(tǒng)資源的浪費。建議的優(yōu)化方案是采用更高效的IPC方式，一般情況下，中小量的數據量傳輸建議使用message-passing，特別大的數量使用shared memory方式。另外，一些開源軟件也會大量使用FIFO，PIPE等IPC，盡管QNX支持這類使用，但是我們也建議改成更高效的message passing方式，以減少單次IPC的開銷。

????????IPC（Inter-Process Communication，進程間通信）是操作系統(tǒng)中不同進程之間共享信息和通信的機制。在自動輔助駕駛方案設計中，IPC的性能優(yōu)化對于確保系統(tǒng)的實時性和效率至關重要。

????????QNX操作系統(tǒng)支持多種主流的POSIX系統(tǒng)常見的IPC方式，如Unix Domain Socket（UDS）、DDS等。同時，它還有自己獨特的原生IPC方式，即消息傳遞（Message-passing）。在跨平臺方案設計中，盡管將UDS、DDS等從Linux照搬到QNX上可以實現代碼重用和功能無差異，但從性能角度來看，這并不是最優(yōu)的選擇。

????????針對IPC的優(yōu)化，建議在QNX中采用更高效的通信方式。對于中小量的數據量傳輸，建議使用message-passing方式。Message-passing是QNX原生支持的IPC方式，具有高效、靈活的特點，能夠減少單次IPC的開銷。對于特別大的數據量傳輸，則建議使用共享內存（Shared Memory）方式。共享內存允許不同進程直接訪問同一塊內存區(qū)域，從而實現高效的數據共享和通信。

????????此外，盡管QNX支持FIFO、PIPE等IPC方式，但在實際應用中，也建議將這些方式替換為更高效的message passing方式。這樣可以進一步減少單次IPC的開銷，提高系統(tǒng)的整體性能。

編譯選項優(yōu)化

????????QNX采用GCC的框架，出于安全性的考慮，QNX的編譯器版本更新相比沒有開源社區(qū)激進，相比會慢一些。比如SDP 7.0采用的是GCC 5.4.0，SPD 7.1采用的GCC 8.3.0，即將推出的SDP Moun會采用GCC 11.X。有時候會發(fā)現，運行同樣一個算法庫，QNX性能會比開源低，那很有可能是由于編譯版本或編譯優(yōu)化選項差異的原因。因為在Linux系統(tǒng)上默認的ARMv8的編譯優(yōu)化選項是滿級的，而QNX默認不打開ARMv8的優(yōu)化選項，因此程序編譯時候需要打開相關編譯選項才能獲得最佳性能，因為QNX基于安全性考慮某些編譯選項在默認編譯的時候并沒有打開會導致性能問題。

QNX采用GCC的編譯框架，意味著其源代碼通過GCC（GNU Compiler Collection）進行編譯，生成可執(zhí)行文件。GCC是一個廣泛使用的開源編譯器，支持多種編程語言和平臺。

驅動級別優(yōu)化

????????如網絡/存儲設備驅動，根據以往的經驗，大部分的性能問題的瓶頸在設備驅動這層。特別是新的硬件、新的驅動，要注意根據QNX系統(tǒng)服務層做好適配，驅動的好壞，往往是除硬件本身之外最主要的性能影響因素。我們遇到非常多的來自驅動層面的空等，忙等，最終導致系統(tǒng)機能的冗余浪費。

網絡協議棧優(yōu)化

?????????除了網絡驅動的優(yōu)化，QNX的網絡協議棧io-pkt本身也提供了豐富的參數，可以根據具體使用的應用場景來達到性能的最優(yōu)化。另外，使用QNX SDP 7.1及后續(xù)版本的用戶，可以使用最新的版本網絡協議棧io-sock，它對多核CPU的利用和大并發(fā)小包數據的處理能力有顯著地提升。兩個協議棧各有千秋，實際上大量的案例證明，用戶并沒有達到io-pkt的性能瓶頸，socket buffer 不足導致丟包，typed memory pool分配的不夠導致收發(fā)阻塞等等，這些都可以通過配置以及API層面的優(yōu)化達到性能提升。

系統(tǒng)API優(yōu)化

????????如memory allocation，memory copy等，QNX提供jemalloc根據實際應用場景提供額外內存泄漏手段，提供更多的功能，jemalloc比default的malloc效率更高，特別是對于大量線程高并發(fā)調用的場景。

用戶接口優(yōu)化

????????QNX 提供的底層接口，尤其是一些自有API，是有不少細微差別的，比如sendmsg()和sendmmsg(), 用戶往往會比較熟悉前者，用于socket的發(fā)包，但是后者提供了message 隊列來實現不增加IPC的基礎上提高了整體的吞吐率。又比如mmap()，我們提供了一些QNX獨有的flag來應對不同的memory mapping 場景，如MAP_ANON與MAP_PHYS的配合，才代表申請物理連續(xù)memory region而MAP_LAZY 更會延遲內存的申請分配。了解并熟悉每個接口的參數配置以及相近命名接口的應用場景會對開發(fā)幫助很大。

QNX提供Momentics?IDE環(huán)境對算法進行性能分析

????????如memory leak，application profile等，同時提供kernel trace進行分析，在抓取的時間段中可以獲得每個時間點的事件、中斷響應，給出優(yōu)化建議。我們也支持自定義的kernel 事件，來讓用戶可以精確的了解代碼片段的運行情況。

QNX提供了onboard debug也支持應用程序調用棧的實時保存及相應的GDB，在調查一些忙等的現場會有很大的幫助。

????????最后總結一下，即便作為ISO26262 ASIL-D安全認證的硬實時性操作系統(tǒng)，QNX在系統(tǒng)性能上也并沒有落后宏內核系統(tǒng)。只要合理地使用和優(yōu)化，它的性能表現同樣非常優(yōu)秀，同時占用更低系統(tǒng)資源。QNX有著豐富的算法移植和優(yōu)化經驗能給到用戶，同時QNX提供一系列的手段和工具去定位算法性能的瓶頸。??

QNX調度算法

作為一個硬實時操作系統(tǒng)，QNX是一個基于優(yōu)先級搶占的系統(tǒng)。這也導致其基本調度算法相對比較簡單。因為不需要像別的通用操作系統(tǒng)考慮一些復雜的“公平性”，只需要保證“優(yōu)先級最高的線程最優(yōu)先得到 CPU”就可以了。

基本調度算法

調度算法，是基于優(yōu)先級的。QNX的線程優(yōu)先級，是一個0-255的數字，數字越大優(yōu)先級越高。所以，優(yōu)先級0是內核中的idle線程。同時，優(yōu)先級64是一個分界嶺。就是說，優(yōu)先級1 – 63 是非特權優(yōu)先級，一般用戶都可以用，而64 – 255必須是有root權限的線程才以設。這個“優(yōu)先級64”分界線，如果有必要，還可以通過啟動Procnto時傳 –P 來改變。

內核中的idle線程是Linux系統(tǒng)在初始化時為每個CPU創(chuàng)建的一個線程。idle線程的目的是在不影響性能的前提下，盡可能減少功耗。一般來說，idle線程的優(yōu)先級被設置為很低，這是因為它只在沒有其他進程需要運行時才運行，用以降低功耗

調度算法的對像是線程，而線程在QNX上，有大約20個狀態(tài)。（參考 /usr/include/sys/states.h）在這許多狀態(tài)中，跟調度有關的，其實只有 STATE_RUNNING和STATE_READY兩個狀態(tài)。STATE_RUNNING是線程當前正在使用CPU，而STATE_READY是等著被執(zhí)行（被調度）的線程。其他狀態(tài)的線程，處于某種“阻塞”狀態(tài)中，調度算法不需要關注。

所以在調度算法看來，整個系統(tǒng)里的線程像這樣：

圖 1 有兩個CPU的系統(tǒng)里的線程

這是一個有兩個CPU的系統(tǒng)，所以可以看到有兩個RUNNING線程；對于 BLOCK THREAD，它們不參于調度，所以不需要考慮它們的優(yōu)先級。

調度策略

在QNX上實質上只有三種基本調度策略，“輪詢”（Round Robin），“先進先出”（First in first out）和＂零星調度”(Sporadic) 算法。雖然形式上還有一個“其他”，但“其他”跟“輪詢”是一樣的。這些調度策略，在 /usr/include/sched.h 里有定義。(SCHED_FIFO, SCHED_RR, SCHED_SPORADIC, SCHED_OTHER)

先進先出（FIFO）

在FIFO策略中，一個線程可以一直占用CPU，直到它執(zhí)行完。這意味著如果一個線程正在做一個非常長的數學計算而且沒有其他更高優(yōu)先級的線程就緒，這個線程就會一直執(zhí)行下去。擁有相同優(yōu)先級的線程會怎么樣呢？它們會一直等待，當然更低優(yōu)先級的線程也得不到執(zhí)行。如果運行中的線程退出或者自愿放棄CPU的使用權，此時內核會尋找其他擁有相同優(yōu)先級的就緒線程。如果沒有這樣的線程，內核會繼續(xù)尋找更低優(yōu)先級的就緒線程。自愿放棄CPU有以下兩種情況。如果線程進入sleep，或被信號量阻塞，此時更低優(yōu)先級的線程可以運行。另外一個是一個系統(tǒng)調用sched_yield()，僅僅讓渡CPU給相同優(yōu)先級的線程。如果一個線程調用了sched_yield()，而且沒有相同優(yōu)先級的線程就緒，此時會繼續(xù)執(zhí)行調用sched_yield()的線程。

輪詢（Round Robin）

????????Round Robin的調度策略和FIFO類似，但是如果有相同優(yōu)先級的線程就緒的話，當前線程不會永遠執(zhí)行下去。當前線程只執(zhí)行一個系統(tǒng)定義好的時間片的時長，時間片的長度可以使用函數sched_rr_get_interval()獲取。時間片的長度通常是4ms，不過實際上是ticksize的4倍，ticksize的值可以通過ClockPeriod()查詢。

????????內核啟動一個RR線程的時候會開始計時，RR線程運行一段時間后分配給它的時間片將會用完。此時內核會檢查是否有相同優(yōu)先級的線程處于就緒狀態(tài)，如果有，內核會讓該線程開始執(zhí)行，否則內核會繼續(xù)讓之前的線程執(zhí)行并會再分配一個時間片給該線程。

????????強調一下，調度策略只限于在READY隊列里的線程，優(yōu)線級最高的線程有不止一個時，才會用到。如果線程不再 READY，或是有別的更高優(yōu)先級的線程 READY了，那就高優(yōu)先級線程獲取CPU，沒有什么策略可言。

????????“輪詢調度”（Round Robin）跟平時生活里排隊的情形差不多，晚到的人排在隊尾，早到的人排在隊首，等到叫號（調度）的時候，隊首的人會被先叫到 。如下圖所示：

圖 2 論詢調度示意

首先在CPU 1上運行的線程4，被挪入優(yōu)先級15的隊列末尾然后重新搜索可執(zhí)行的最高優(yōu)先級線程，這里有優(yōu)先級15隊列上的線程3和4線程3因為在隊列最前端，它被選擇得到CPU，線程3的狀態(tài)變?yōu)镽UNNING，在CPU1上執(zhí)行

可以預期，當下一次調度發(fā)生時，線程3會被挪入優(yōu)先級15隊列末尾，而線程4會被調度執(zhí)行，這樣線程3和4會分別得到CPU1.

“先進先出”（First in first out）調度則剛好相反，后來的人插在隊首，然后在叫號的時候被先叫到?？聪聢D：

圖 3 先進先出調度示意

首先在CPU 1上運行的線程4，被挪入優(yōu)先級15的隊列隊首 然后重新搜索可執(zhí)行的最高優(yōu)先級線程，這里有優(yōu)先級15隊列上的線程4和3 線程4因為在隊列最前端，它被選擇得到CPU，線程4的狀態(tài)變?yōu)镽UNNING，在CPU1上執(zhí)行

可以看到，在這個調度算法下，如果沒有別的狀態(tài)發(fā)生，事實上線程4就會一直占據CPU1。

如果在優(yōu)先級15上的線程3和線程4都是FIFO會怎樣？按上面的描述，線程3還是始終無法獲得CPU1，因為線程4每次都會插在3的前面，再調度就又是4獲得CPU1。除非線層4進入了阻塞狀態(tài)（從而不在READY隊列里了），那么線程3才能獲得CPU。

零星調度（Sporadic）

“零星調度”（Sporadic）算法比較特殊，它比較適合長時間占用CPU的線程。它的基本設計思想是給一個線程準備兩個優(yōu)先級，“前臺”優(yōu)先級比較高，“后臺”優(yōu)先級稍微底一點。如果線程在高優(yōu)先級連續(xù)占用CPU超過一定時間后，線程會被強行降到“后臺”低優(yōu)先級上（這時線程能不能占用CPU取決于系統(tǒng)中有沒有比“后臺”優(yōu)先級高的別的線程了）；然后線程在低優(yōu)先級上經過了一段時間后，會重新被調回高優(yōu)先級。

圖 4 零星調度示意

上圖是一個零星調度線程的示意。

開始的時候，線程在比較高的（正常）優(yōu)先級 H 上運行，一直到把預先分配給零星調度的時間用完（sched_ss_init_budget） 這時，線程會被自動調整為低優(yōu)先級L（sched_ss_low_priority）；一旦被調低，線程也可能運行（如果優(yōu)先級L依然是系統(tǒng)里最高優(yōu)先級的線程），也可能無法運行呆在READY隊列里（系統(tǒng)里有比L更高的優(yōu)先級） 不管線程有沒有執(zhí)行，從最開始運行時間點算起，當線程“執(zhí)行補充時間"（sched_ss_repl_period）過了以后，線程的優(yōu)先級被重新提到優(yōu)先級H，并試圖取得CPU來。

“零星調度”看上去比較“公平”，但是實際在用QNX的項目中，這個調度算法很少被用戶用到。主要是因為一般來說在QNX上很少有線程能夠“連續(xù)占用CPU”的。而且當系統(tǒng)變得復雜，線程數成百上千后，這種上下調優(yōu)先級的做法，很容易出現別的后遺癥。

什么時候會發(fā)生調度？

????????上面介紹了QNX支持的幾個調度算法。那么，什么時候才會發(fā)生調度呢？

????????QNX的設計目標是一個硬實時操作系統(tǒng)，所以，保證最高優(yōu)先級的線程在第一時間占據CPU是很重要的?？紤]到線程的狀態(tài)都是在內核中進行變化的（都是因為線程進行了某個內核調用后變化的），所以QNX在每次從內核調用退出時，都會進行一次線程調度，以保證最高優(yōu)先級的線程可以占據CPU。

????????得益于微內核結構，QNX的內核調用通常都非常短，或者說，每一個內核調用，都能夠比較確定地知道要花多少時間。而且，因為微內核系統(tǒng)的基本就是進程間通信，所以在QNX上，一段程序非常容易進入內核并進行線程狀態(tài)切換，很少能有長時間占滿CPU的，在實際系統(tǒng)上測，現實上很少能有線程執(zhí)行完整個時間片的。

????????舉個例子，哪怕程序里只寫一個 printf("Hello World!\n"); 可是在libc庫里，最后這個會變成一個IO_WRITE消息，MsgSend() 給控制臺驅動；這時，在MsgSend()這個內核調用里，會把printf() 的線程置為阻塞狀態(tài)（REPLY BLOCK），同時會把控制臺驅動的信息接收線程（從RECEIVE BLOCK）改到 READY狀態(tài)，并放入 READY 隊列。當退出MsgSend() 內核調用時，線程調度發(fā)生，通常情況下（如果沒有別的線程READY 的話）控制臺驅動的信息接收線程被激活，并占據CPU.

????????如果用戶寫了一個既不內核調用，也不放棄CPU的線程會怎么樣？那時候，時鐘中斷會發(fā)生，當內核記時到線程占據了一整個時間片（QNX上是4ms）后，內核會強制當前線程進入 READY，并重新調度。如果同一優(yōu)先級只有這一個線程（這是優(yōu)先級最高線程），那么調度后，還是這個線程獲取CPU。如果同一優(yōu)先級有別的線程存在，那么根據調度算法來決定哪個線程獲得CPU。

????????另一種常見情況是，由于某些別的原因導致高優(yōu)先級線程被激活，比如網卡驅動中斷導致高優(yōu)先級驅動線程READY，所設時鐘到達導致高優(yōu)先級線程從阻塞狀態(tài)返回READY狀態(tài)了，當前線程開放互斥鎖之類的線程同步對象，導致別的線程返回READY狀態(tài)了。這些，都會在從內核調用退出時，進行調度。

中斷與優(yōu)先級

????????上面提到如果用戶線程長期占有CPU，時鐘中斷會打斷用戶線程。細心的讀者或許會有疑問，那中斷的優(yōu)先級是多少呢？

????????答案是在QNX這樣的實時操作系統(tǒng)里，“硬件中斷”永遠高于任何線程優(yōu)先級，哪怕你的線程優(yōu)先級到了255，只要有中斷發(fā)生，都要讓路，CPU會跳轉去執(zhí)行中斷處理程序，執(zhí)行完了再回歸用戶線程。事實上，能夠快速穩(wěn)定地響應中斷處理，是一個實時操作系統(tǒng)的硬指標。

????????我們這里說的是“硬件中斷”，就是說，當外部設備，通過中斷控制器，向CPU發(fā)出中斷請求時，無論當時CPU上執(zhí)行的線程優(yōu)先級是什么，都會先跳轉到內核的中斷處理程序；中斷處理程序會去中斷控制器找到具體是哪一個源發(fā)生了中斷（中斷號），并據此，跳轉到該中斷號的中斷處理程序（通常是硬件驅動程序 通過 InterruptAttach() 掛接的函數）。在這個過程中，如果當前CPU正在處理另一個中斷，那么這時，會根據中斷的優(yōu)先級來決定是讓CPU繼續(xù)處理下去（當前中斷進入等待）；或者發(fā)生中斷搶占，新中斷的優(yōu)先級比舊中斷高，所以跳轉新中斷處理。

????????當然，實際應用中，特別是微內核環(huán)境下，考慮中斷其實只是中斷設備給出的一個通知，對這中斷的響應并不需要真的在中斷處理中進行，驅動程序可以選擇在普通線程中處理，QNX上有InterruptAttachEvent() 就是為了這個設計的。通常這里的“事件”會是一個“脈沖”，也就是說，當硬件中斷發(fā)生，內核檢查到相應中斷綁定了事件。這時，不會跳轉到用戶中斷處理程序，而是直接發(fā)出那個脈沖，以激活一個外部（驅動器中）線程，在這線程中，做設備中斷所需要的處理。這樣做，雖然稍微增加了一些中斷延遲，但也帶來了不少好處。首先，這個外部線程同普通的用戶線程一樣，所以可以調用任何庫函數，而中斷服務程序因為執(zhí)行環(huán)境的不同，有好多限制。其次，因為是普通用戶線程，就可以用線程調度的方法規(guī)定其優(yōu)先級（脈沖事件是帶優(yōu)先級的），使不同的設備中斷處理，跟正常業(yè)務邏輯更好地一起使用。

????????在QNX這樣的微內核環(huán)境下，中斷處理的方式確實有其獨特之處。首先，我們要明確中斷本質上只是設備向系統(tǒng)發(fā)出的一種通知，告知系統(tǒng)某個特定事件已經發(fā)生，需要相應的處理。但并不意味著中斷處理必須在中斷發(fā)生的即時上下文中完成。

????????QNX提供的InterruptAttachEvent()機制允許驅動程序選擇在一個普通的用戶線程中處理中斷，而不是傳統(tǒng)的在中斷服務程序中直接處理。這種設計思路有幾個關鍵的優(yōu)勢。

首先，當硬件中斷發(fā)生時，內核會檢測到相應的中斷，并檢查是否有與該中斷綁定的事件（通常是一個“脈沖”）。此時，內核不會直接跳轉到用戶的中斷處理程序，而是發(fā)出這個脈沖。這個脈沖的作用類似于一個信號，用于激活一個在驅動程序中定義的外部線程。這個外部線程隨后會執(zhí)行設備中斷所需要的處理邏輯。

????????這樣做雖然可能稍微增加了一些中斷的延遲，但帶來的好處是顯著的。由于這個外部線程是一個普通的用戶線程，它擁有與普通用戶線程相同的執(zhí)行環(huán)境和能力。這意味著它可以調用任何庫函數，使用任何可用的系統(tǒng)資源，而不會受到中斷服務程序通常存在的諸多限制。

????????此外，由于它是一個普通的用戶線程，我們可以使用線程調度的方法來規(guī)定其優(yōu)先級。這意味著不同的設備中斷處理可以根據需要設置不同的優(yōu)先級，從而更好地與正常的業(yè)務邏輯協同工作。例如，對于實時性要求較高的設備中斷，我們可以將其處理線程的優(yōu)先級設置得較高，以確保其得到及時響應。

多CPU上的線程調度

現在同步多處理器（SMP）已經相當普及了。在SMP上，也就是說當有多個CPU時，我們的調度算法有什么變化呢？比如一個有2個CPU的系統(tǒng)，首先肯定，系統(tǒng)上可執(zhí)行線程中的最高優(yōu)先級線程，一定在2個CPU上的某一個上執(zhí)行；那，是不是第二高優(yōu)先級的線程就在另一個CPU上執(zhí)行呢？

雖然直覺上我們覺得應該是這樣的（系統(tǒng)里的第一，第二高優(yōu)先級的線程占據CPU1和CPU2），但事實上，第二高優(yōu)先級的線程占據CPU2這件事，并不是必要的。實時搶占系統(tǒng)的要求是最高優(yōu)先級”必須“能夠搶占CPU，但對第二高優(yōu)先級并沒有規(guī)定。拿我們最開始的雙CPU圖再看一眼。

圖 5 有兩個CPU的系統(tǒng)里的線程

線程4以優(yōu)先級15占據CPU1這是毫無疑問的，但線程5只有優(yōu)先級12，為什么它可以占據CPU2，而線程3明明也有優(yōu)先級15，但只能排隊等候，這是不是優(yōu)先級倒置了？其實并沒有，如上所述，系統(tǒng)確實保證了“最高優(yōu)先級占據CPU”的要求，但在CPU2上執(zhí)行什么線程，除了線程本身的優(yōu)先級以外，還有一些別的因素可以權衡，其中一個在SMP上比較重要的，就是“線程躍遷”。

“線程躍遷”指的是一個線程，一會兒在CPU1上執(zhí)行，一會兒在CPU2上執(zhí)行。在SMP系統(tǒng)上，線程躍遷而導致的緩存清除與重置，會給系統(tǒng)性能帶來很大的影響。所以在線程調度時，盡量把線程調度到上次執(zhí)行時用的CPU，是SMP調度算法里比較重要的一環(huán)。上述例子中，很有可能就是線程3上一次是在CPU1上執(zhí)行的，而線程5雖然優(yōu)先級比較低，很有可能上一次就是在CPU2上執(zhí)行的。

實際應用中，因為QNX的易于阻塞的特性，其實大多數情況下，還是符合“第一，第二高優(yōu)先級線程在CPU上執(zhí)行”的。只是，如果你觀察到了上述情形，也不需要擔心，設計上確實有可能不是第二高優(yōu)先級的線程在運行。

另一個多處理器上常見的應用，是線程綁定。在正常情況下，把可執(zhí)行線程調度到哪一個CPU上，是由操作系統(tǒng)完成的。當然操作系統(tǒng)會考慮“線程躍遷”等情形來做決定。但是，QNX的用戶也可以把線程綁定到某一個（或者某幾個）CPU上，這樣操作系統(tǒng)在調度時，會考慮用戶的要求來進行。綁定是通過ThreadCtl() 修改線程的 “RUNMASK” 來進行的，如果你有0,1,2,3 總共4個CPU，那么 0x00000003意味著線程可以在CPU0和CPU1上執(zhí)行，具體例子可以參考ThreadCtl()函數說明。更簡單的辦法，是通過QNX特有的 on 命令的 –C 參數來指定，這個指定的 runmask，還會自動繼承。所以你可以簡單的如下執(zhí)行：

# on –C 0x00000003 Navigation &# on –C 0x00000004 Media &# on –C 0x00000008 System &

這樣來把不同的系統(tǒng)部署到不同的CPU上。

這樣做的好處當然是可以減少比如因為系統(tǒng)繁忙而對導航帶來的影響，但不要忘了，另一面，如果所有 Media 線程都處于阻塞狀態(tài)，上述綁定也限制了導航線程使用CPU2的可能，CPU2這時候就會空轉（執(zhí)行內核 idle 線程）。

自適應分區(qū)調度算法

前面我們提到過，在討論優(yōu)先級調度時，只是討論當有多個優(yōu)先級相同的線程時，系統(tǒng)怎樣取舍。優(yōu)先級不一樣時，肯定是優(yōu)先級高的贏。但是“高出多少”并不是一個考量因素。兩個線程，一個優(yōu)先級10，另一個優(yōu)先級11的情況，和一個10，另一個40的情況是一樣的。并不會因為10和40差距比較大而有什么不同。

假如我們有紅藍兩個線程，它們的優(yōu)先級一樣，調度策略是RR，兩個線程都不阻塞，那么在10時間片的區(qū)間里，我們看到的就是這樣一個執(zhí)行結果：

也就是說，各占了50%的CPU。但只要把藍色線程提高哪怕1，執(zhí)行結果就成了下面這樣。

這種“非黑即白”的情形，是實時系統(tǒng)的基本要求（高優(yōu)先級搶占CPU）。但是當然，現實情況有時候比較復雜。比如 “HMI渲染” 是需要經常占據CPU的一個任務（這樣畫面才會順暢），但“用戶輸入”也是需要響應比較快的（不然用戶的點擊就會沒有反應）。如果“用戶輸入”的優(yōu)先級太高的話，那用戶拖拽時，畫面就會卡頓甚至沒有反應？反之，如果”HMI 渲染“的優(yōu)先級太高，那么有用戶輸入時，因為處理程序優(yōu)先級低而造成用戶輸入反應慢。通常情況下，需要有經驗的系統(tǒng)工程師不斷調整這兩個任務的優(yōu)先級（因為優(yōu)先級繼承與傳統(tǒng)，一個任務可能涉及到多個線程），來達到系統(tǒng)的最優(yōu)。那么，有沒有別的辦法呢?

分區(qū)調度

傳統(tǒng)上，有一種“分區(qū)調度”的方法，今天還有一些Hypervisor采取這個辦法。這個想法很簡單，就是把CPU算力隔成幾個分區(qū)，比如70%，30%這樣，然后把不同線程分到這些分區(qū)里，當分區(qū)里的CPU預算被用完以后，那個分區(qū)里所有可執(zhí)行線程都會被”停住“，直到預算恢復。

假設我們把紅線程放入70%紅色分區(qū)，藍線程放入30%藍色分區(qū)，然后以10個時間片為預算滑動窗口大小，各線程具體就會如下圖占據CPU：

圖 6 分區(qū)調度算力全滿示意

在前6個時間片中，藍紅分區(qū)分別占據CPU，注意在第7個時間片時，雖然藍分區(qū)中線程跟紅分區(qū)中線程有相同的優(yōu)先級，雖然調度策略是輪回，應該輪到藍線程上了，但是因為藍線程已經用完了10個時間片里的3個，所以系統(tǒng)沒有執(zhí)行藍線程，而是繼續(xù)讓紅線程占據CPU，一直到第8第9和第10個時間片結束。

10個時間片結束后，窗口向右滑動，這時我們等于又多了一個時間片的預算，在新的10個時間片中，藍線程只占了兩個(20%)，這樣，新的第11個時間片，就分給了藍分區(qū)。

同理再滑動后，第12個時間片，分給紅線程；一直到17個時間片時，同樣的事情再度發(fā)生，藍分區(qū)線程又用完了10個時間片里的3個，而被迫等待它的預算重新補充進來。

綜上，在任意一個滑動窗口中，藍色分區(qū)總是只占30%，而紅色分區(qū)卻占了70%。QNX的自適應分區(qū)調度，跟上面這個是類似的。只是傳統(tǒng)的分區(qū)調度，有一個明顯的弱點。

想一下這個情況，如果紅線程因為某些情況被阻塞了，會發(fā)生什么呢？

圖 7 分區(qū)調度算力有富余示意

對，藍線程是唯一可執(zhí)行線程，所以它一直占據CPU。但是，當3個時間片輪轉之后，因為藍分區(qū)只有30%的時間預算，它將不再占據CPU，而因為紅線程無法執(zhí)行，接下來的7個時間片CPU處于空轉狀態(tài)（執(zhí)行Idle線程）。

一直到時間窗口移動，那時，因為藍分區(qū)只占用了20%的算力，所以它再次占據CPU……

所以你也看到了，在傳統(tǒng)的分區(qū)調度里，當一個分區(qū)的算力有富裕的時候，CPU就被浪費了。

自適應分區(qū)調度

QNX在傳統(tǒng)的分區(qū)調度上，增加了“自適應”的部份。其基本思想是一樣的，給算力加分區(qū)，然后把不同的線程分到分區(qū)里。這樣，當所有的線程都忙起來時，你會發(fā)現情況跟圖7是一樣的。但是當分區(qū)算力有富裕時，“自適應“允許把多出來的算力”借“給需要更多算力的分區(qū)。

圖 8 自適就分區(qū)算力有富裕示意

如上，當藍色分區(qū)里的線程消耗完了他自己的分區(qū)預算后，自適應分區(qū)會把有富裕算力的紅色分區(qū)的預算，借給藍色分區(qū)，藍分區(qū)內線程得以繼續(xù)在CPU上運行。注意，在第8個時間片時，紅色分區(qū)需要使用CPU，藍色分區(qū)立即讓路，把CPU讓給紅色分區(qū)。而當紅色分區(qū)里的線程被阻塞住以后，藍色分區(qū)線程繼續(xù)使用CPU。

自適應分區(qū)似乎確實帶來了好處，但是也帶來了一些潛在的問題，需要在系統(tǒng)設計的時候做好決定。

自適應分區(qū)調度與線程優(yōu)先級

你可能會好奇，在分區(qū)調度的系統(tǒng)里，線程的優(yōu)先級代表了什么？

答案取決于各個分區(qū)對各自算力的消耗情況。我們假設藍色分區(qū)里的線程優(yōu)先級比較高，紅色的優(yōu)先級比較低，當兩個分區(qū)都有預算時，內核會調度（所有分區(qū)里的）最高優(yōu)先級線程執(zhí)行。如果系統(tǒng)一直不是很忙，那么不論分區(qū)，永遠是有最高優(yōu)先級的線程得到CPU，這個，跟一個標準的實時操作系統(tǒng)是一致的。

當兩個分區(qū)中某一個有預算時（意味著那個分區(qū)中所有的線程都不在執(zhí)行狀態(tài)），那么多出來的CPU算力會被分給另一個分區(qū)，另一個分區(qū)中的最高優(yōu)先級線程（雖然用完了自己分區(qū)的預算，但得到了別的分區(qū)的算力），繼續(xù)占據CPU。這個，也是跟實時操作系統(tǒng)是一致的。

比較特殊的情況是，當兩個分區(qū)都沒有預算，都需要占據CPU時，這時，藍色線程雖然有較高的優(yōu)先級，但因為分區(qū)算力(30%)被用完，面且沒有別的算力可以“借”，所以它被留在READY隊列中，而比它優(yōu)先級低的紅色線程得以占據CPU。

自適應分區(qū)調度富裕算力分配

我們上面的例子只有兩個分區(qū)，考慮這樣一個例子。假設我們現在有A (70%)，B (20%)，C (10%) 三個分區(qū)，A分區(qū)沒有可執(zhí)行線程，B分區(qū)有個優(yōu)先級為10的線程，C分區(qū)有個優(yōu)先級為20的線程。我們知道A分區(qū)的70%會分配給B和C，但具體是怎么分配的呢？

如上所述，當預算有富裕時，系統(tǒng)挑選所有分區(qū)中，優(yōu)先級最高的線程執(zhí)行，也就是說C分區(qū)中的線程得到運行。在一個窗口以后，你會發(fā)現A的CPU使用率是0%，B是20%，C則達到了80%。也就是說A所有的富裕算力，都給了C分區(qū)（因為C中的線程優(yōu)先級高）。

也許，在某些時候，這個不是你所期望的。也許C中有一些第三方程序你無法控制，你也不希望他們偷偷提高優(yōu)先級而占用全部富裕算力。QNX提供了SchedCtl()函數，可以設SCHED_APS_FREETIME_BY_RATIO 標志。設了這個標志后，富裕算力會按照各分區(qū)的預算比例分配給各分區(qū)。上面的例子下，最后的CPU使用率會變成 A 是0%， B是65%，而C是35%。A分區(qū)富裕的70%算力，按照大約 2: 1的比例，分給了分區(qū)B和C。

“關鍵線程”與“關鍵分區(qū)”

在實際使用中，有一些重要任務，可能需要響應，不論其所在的分區(qū)還有沒有算力。比如一個緊急中斷服務線程，不管分區(qū)是不是還有預算，都需要響應。為了解決這種情況，在QNX的自適應分區(qū)調度里，除了給分區(qū)分配算力預算以外，還允許有權限的用戶為分區(qū)分配“關鍵響應時間”，并把特定線程定義為“關鍵線程”。

當一個“關鍵線程”需要執(zhí)行時，如果線程所在分區(qū)有預算，它就直接使用所在分區(qū)預算就好，如同普通線程；如果所在分區(qū)沒有預算了，但是別的分區(qū)還有預算，那么“自適應”部份會把別分區(qū)的預算拿過來，并用于關鍵線程，這個跟普通的自適應分區(qū)調度一樣。

只有當系統(tǒng)里所有分區(qū)都沒有預算了，而有一個關鍵線程需要運行，而且線程所在的分區(qū)已經預先分配了關鍵響應預算，那么線程允許“突破”分區(qū)的預算，使用“關鍵響應預算”來執(zhí)行。在QNX里，一個關鍵線程消耗的時間，從退出RECEIVE_BLOCK開始，到下一次進入RECEIVE_BLOCK。而且，關鍵線程的屬性是可傳遞的，如果關鍵線程在執(zhí)行中，給別的線程發(fā)送了消息，那個線程也會變成關鍵線程。

總的來說，關鍵線程是用來保證關鍵任務不會因為系統(tǒng)太忙而無法取得CPU時間。即使所有的分區(qū)都被占滿了，至少還有“關鍵響應時間”可供關鍵線程來使用。當然，一個系統(tǒng)里不應該有太多的關鍵線程和關鍵響應時間。理論上，假設所有的線程都是關鍵線程，那么整個系統(tǒng)其實就變成了一個普通的按優(yōu)先級調度的實時系統(tǒng)，所有的分區(qū)和預算都不起作用了。

在最緊急的情況下，關鍵線程可以使用“關鍵響應時間”來完成它的任務。如果“關鍵響應時間”還是不夠，會怎么樣？這個是系統(tǒng)設計問題，在設計系統(tǒng)的時候，你就應該為關鍵線程分配它能夠完成任務所需要的最大時間。如果依然發(fā)生“關鍵響應時間”不夠的狀況（被稱為“破產”狀態(tài)），這個就是一個設計錯誤了。

關鍵線程的破產

如上所述，關鍵線程的破產是一個設計問題?；蛘呔€程完成的任務并不那么“關鍵”，或者設計時給出的預算不夠。這種情況下需要重新審視整個系統(tǒng)設計（因為系統(tǒng)在某些情況下無法保證關鍵任務在預定時間內完成）。QNX在自適應分區(qū)里提供了偵測到關鍵線程破產時的多種響應辦法，可以是強行忽視，或者重啟系統(tǒng)，或者由自適應分區(qū)系統(tǒng)自動調整分區(qū)的預算。

自適應分區(qū)繼承

想像這個場景，文件系統(tǒng)在System分區(qū)里，但另一個Others分區(qū)里的第三方應用拼命調用文件系統(tǒng)，很有可能造成System分區(qū)的預算耗盡；這樣，首先可能導致別的應用無法使用文件系統(tǒng)；更嚴重的，可能是System分區(qū)里別的系統(tǒng)，比如Audio也無法正常工作。這個，顯然是自適應分區(qū)系統(tǒng)帶來的安全隱患。

解決辦法，就是跟優(yōu)先級在消息傳遞上可以繼承一樣，分區(qū)也是可以繼承的。文件系統(tǒng)雖然分配在System系統(tǒng)里，但根據它響應的是誰的請求，時間被記到請求服務的線程分區(qū)里。這樣，如果一個第三方應用拼命調用文件系統(tǒng)，最多能做的，也只是消耗它自己的分區(qū)，當他自己分區(qū)的預算被耗盡時，影響它自己的CPU占用率。

自適應分區(qū)的小結

自適應分區(qū)有一些有趣的用法，比如我們常常被要求“系統(tǒng)需要保留30%的算力”。有了自適應分區(qū)，就可以建一個有30%預算的分區(qū)，在里面跑一個 for (;;); 這樣的死循環(huán)。這樣，剩下的系統(tǒng)就只有70%的算力了，可以在這個環(huán)境下檢驗一下系統(tǒng)的性能和穩(wěn)定性。

自適應分區(qū)的具體操作方法，可以參考QNX的文檔。不同版本的QNX有稍微不同的命令行，但基本設計是一樣的。這篇文章只是介紹了自適應分區(qū)的基本概念，實際使用上，還是有許多細節(jié)需要考慮的，真的要使用，還是需要詳細參考QNX對應文檔。

柚子快報邀請碼778899分享：QNX為什么是安全的操作系統(tǒng)？

http://yzkb.51969.com/

好文閱讀