資料介紹
1 操作系統對實時性能的影響
操作系統從誕生發展到現代經歷了批處理系統、分時系統和實時系統等演進過程,具有多樣化特征,派生出不同分支。其中,實時性是操作系統的重要特性,它要求在規定的時間窗口內邏輯正確地完成規定的任務,具有及時性、交互性、多路性、獨立性等特點[1]。操作系統的實時性主要取決于I/O管理中的異步方式、內存管理中的頁中斷機制、線程管理中的內核代碼是否可搶占、資源管理中的信號量策略以及中斷延遲和時鐘精度等硬件支撐結構[2]。由于多線程系統中線程對公共資源的爭奪,資源的有效管理成為提升系統實時性能的重要因素,而信號量是管理公共資源的經典方式,所以,信號量設計是影響系統實時性的基礎設計。本文重點論述信號量策略對實時性能的影響,并以NT內核為研究對象和實現平臺,分析現有幾種信號量策略的優、缺點,提出了一種新策略,在保證系統通用性前提下提升了系統實時性。
2 信號量策略對實時性能的影響
荷蘭科學家設計的信號量算法為線程使用共享資源提供了有效的同步和互斥機制,NT內核中,信號量(KSEMAPHORE)通過封裝DISPATCHER_HEADER結構實現計數器和等待隊列,其數據結構struct _KSEMA-PHORE{DISPATCHER_HEADER Header LONG Limit}在參考文獻[3]中有詳細描述,上述結構可簡略為:
struct _KSEMAPHORE{LONG SignalState //信號量
計數器變量
LIST_ENTRY WaitList} //線程等待隊列鏈表
它的操作有創建(CreateSemaphore)、刪除(CloseHandle)、請求(WaitForSingleObject)和釋放(ReleaseSemaphore)信號量等。
線程使用資源前需要請求保護該資源的信號量,若信號量計數器減1后小于0,內核阻塞線程并將其排在信號量的線程等待隊列中,同時啟動線程調度程序將計算資源交給等待運行的線程,執行請求操作的線程沒有陷入“忙等”,而是“讓權等待”。若擁有信號量的線程釋放資源使得計數器加1后還小于等于0,則喚醒線程等待隊列中的等待線程并送線程調度隊列。因此,在資源緊張情況下,請求和釋放信號量會涉及資源等待隊列和線程調度隊列兩個隊列。本文討論資源等待隊列,對于資源請求,采用什么策略將線程放入隊列;對于資源釋放,采用什么策略把線程從隊列中取出并放入調度隊列??紤]放入與取出線程時同時采用策略的復雜性,固定取出策略從隊列頭部取出線程,請求時采取策略將線程放入隊列,目前有以下三種策略[1]:
(1)后進先出LIFO(Last In First Out),線程請求資源后,若信號量計數器小于0,將線程排在線程等待隊列的隊頭。該策略易于實現,線程等待隊列只需一個單鏈表即可,這種“后來先服務”的方式還可以利用CPU緩存TLB(Tanslation Lookaside Buffer)中存在的剛被掛起線程的頁表數據,不必更新緩存,提高了運行速度。但是,后進先出方式讓最先被掛起的線程鮮有被服務,若獲得資源的線程高頻率請求資源,會導致最先請求資源的線程由于長時間處在隊尾得不到服務導致“餓死”(Starva-tion),使得一些線程頻繁調度,而一些線程很少被調度。
?。?)先進先出FIFO(First In First Out),線程請求資源后,若信號量計數器小于0,將線程排在線程等待隊列的隊尾。該策略克服了線程的“餓死”現象,對資源有請求的線程都能公平地占有資源,請求隊列調度均衡化,從策略角度來看,所有線程都整齊劃一無差別。這種先來先服務的方式沒有考慮線程的其他因素,例如,對時間緊要程度的要求不同,有實時線程和一般線程之分,如果對實時線程和一般線程都采用先進先出方式,那么實時線程的實時性將大幅降低,特別在等待隊列中已有很多線程的情況下,實時線程只有等待前面所有線程釋放信號量后才能得到調度,造成不必要的延時。信號量的數據結構和操作也要復雜一些,需要一個隊尾指針。
?。?)基于優先級隊列Priority,線程請求資源后,若信號量計數器小于0,則將線程根據其優先級排在線程等待隊列的相應位置。該策略克服了先進先出的均衡化調度缺點,使優先級高的線程始終處在隊列的隊首,搶占優先級低的線程;線程可根據時間特性來確定它的優先級并排隊,提高了線程的實時性。然而這種方式也有其不足,優先級低的線程始終得不到調度,同樣會導致“餓死”。如果系統中有大量線程爭搶稀有資源,排隊過程還會引入隊列的搜索時間。
這就需要一種策略,對于具有很強時效性的實時線程使用優先級排隊,對于一般線程按照先進先出排隊。由于實時線程很少,配合哈希(Hash)表分類實時線程(如圖1虛直線上部分所示)基本不會引入搜索時間。
3 基于Priority和FIFO結合的信號量策略
針對優先級隊列過分強調高優先級線程的缺點和先進先出隊列過分強調平均的缺點,本文提出基于優先級和先進先出隊列結合的排隊策略,同時兼顧實時線程的強實時要求和一般線程的公平要求。
NT內核將用戶線程以一對一方式映射到內核中,并基于優先級調度內核線程,內核將優先級從低到高分為32級,0~15級為一般線程,16~31級為實時線程。本文將這種線程調度隊列的分級方式見之于信號量的等待隊列,如圖1虛直線上部分所示,把線程等待隊列構造成一個長度為17、類型為LIST_ENTRY的哈希(Hash)指針數組,數組1~16根據優先級排列同一級別的實時線程,數組0根據先進先出排列一般線程。線程請求資源后,若信號量計數器小于0,且線程優先級小于16,則將該線程按照先進先出策略排在線程等待隊列的隊尾;若線程優先級大于等于16,則按照優先級排列該線程。當線程釋放資源時,若信號量計數器小于0,內核應先從優先級隊列中搜索掛起線程,再從先進先出隊列中搜索掛起線程。
4 新信號量策略在NT內核中的實現及結果分析
為了兼容操作系統上層軟件,本文僅修改“請求”函數的代碼而不改變現有信號量的數據結構,將圖1虛直線上部分描述的新信號量策略映射到虛直線下,把優先級隊列和先進先出隊列融合到一個隊列中,隊列的前半部分是優先級隊列,由指針FLINK指定,后半部分為先進先出隊列,由指針BLINK指定,這種復合型隊列同時具備優先級和先進先出隊列的優點,體現了“一個隊列兩種策略”。線程請求資源后,若信號量計數器小于0,且線程的優先級小于16,按照先進先出策略將線程排在BLINK指向的先進先出隊列隊尾;若線程的優先級大于等于16,則將線程按照優先級策略在FLINK指向的優先級隊列中搜索相應的位置,找到小于優先級隊列中的線程并放在該線程之后。當線程釋放資源時,若信號量計數器小于0,由于線程已經根據策略放入恰當的位置,內核只需要從KSEMAPHORE→WaitList→FLINK取出第一個線程送往線程調度隊列即可
操作系統從誕生發展到現代經歷了批處理系統、分時系統和實時系統等演進過程,具有多樣化特征,派生出不同分支。其中,實時性是操作系統的重要特性,它要求在規定的時間窗口內邏輯正確地完成規定的任務,具有及時性、交互性、多路性、獨立性等特點[1]。操作系統的實時性主要取決于I/O管理中的異步方式、內存管理中的頁中斷機制、線程管理中的內核代碼是否可搶占、資源管理中的信號量策略以及中斷延遲和時鐘精度等硬件支撐結構[2]。由于多線程系統中線程對公共資源的爭奪,資源的有效管理成為提升系統實時性能的重要因素,而信號量是管理公共資源的經典方式,所以,信號量設計是影響系統實時性的基礎設計。本文重點論述信號量策略對實時性能的影響,并以NT內核為研究對象和實現平臺,分析現有幾種信號量策略的優、缺點,提出了一種新策略,在保證系統通用性前提下提升了系統實時性。
2 信號量策略對實時性能的影響
荷蘭科學家設計的信號量算法為線程使用共享資源提供了有效的同步和互斥機制,NT內核中,信號量(KSEMAPHORE)通過封裝DISPATCHER_HEADER結構實現計數器和等待隊列,其數據結構struct _KSEMA-PHORE{DISPATCHER_HEADER Header LONG Limit}在參考文獻[3]中有詳細描述,上述結構可簡略為:
struct _KSEMAPHORE{LONG SignalState //信號量
計數器變量
LIST_ENTRY WaitList} //線程等待隊列鏈表
它的操作有創建(CreateSemaphore)、刪除(CloseHandle)、請求(WaitForSingleObject)和釋放(ReleaseSemaphore)信號量等。
線程使用資源前需要請求保護該資源的信號量,若信號量計數器減1后小于0,內核阻塞線程并將其排在信號量的線程等待隊列中,同時啟動線程調度程序將計算資源交給等待運行的線程,執行請求操作的線程沒有陷入“忙等”,而是“讓權等待”。若擁有信號量的線程釋放資源使得計數器加1后還小于等于0,則喚醒線程等待隊列中的等待線程并送線程調度隊列。因此,在資源緊張情況下,請求和釋放信號量會涉及資源等待隊列和線程調度隊列兩個隊列。本文討論資源等待隊列,對于資源請求,采用什么策略將線程放入隊列;對于資源釋放,采用什么策略把線程從隊列中取出并放入調度隊列??紤]放入與取出線程時同時采用策略的復雜性,固定取出策略從隊列頭部取出線程,請求時采取策略將線程放入隊列,目前有以下三種策略[1]:
(1)后進先出LIFO(Last In First Out),線程請求資源后,若信號量計數器小于0,將線程排在線程等待隊列的隊頭。該策略易于實現,線程等待隊列只需一個單鏈表即可,這種“后來先服務”的方式還可以利用CPU緩存TLB(Tanslation Lookaside Buffer)中存在的剛被掛起線程的頁表數據,不必更新緩存,提高了運行速度。但是,后進先出方式讓最先被掛起的線程鮮有被服務,若獲得資源的線程高頻率請求資源,會導致最先請求資源的線程由于長時間處在隊尾得不到服務導致“餓死”(Starva-tion),使得一些線程頻繁調度,而一些線程很少被調度。
?。?)先進先出FIFO(First In First Out),線程請求資源后,若信號量計數器小于0,將線程排在線程等待隊列的隊尾。該策略克服了線程的“餓死”現象,對資源有請求的線程都能公平地占有資源,請求隊列調度均衡化,從策略角度來看,所有線程都整齊劃一無差別。這種先來先服務的方式沒有考慮線程的其他因素,例如,對時間緊要程度的要求不同,有實時線程和一般線程之分,如果對實時線程和一般線程都采用先進先出方式,那么實時線程的實時性將大幅降低,特別在等待隊列中已有很多線程的情況下,實時線程只有等待前面所有線程釋放信號量后才能得到調度,造成不必要的延時。信號量的數據結構和操作也要復雜一些,需要一個隊尾指針。
?。?)基于優先級隊列Priority,線程請求資源后,若信號量計數器小于0,則將線程根據其優先級排在線程等待隊列的相應位置。該策略克服了先進先出的均衡化調度缺點,使優先級高的線程始終處在隊列的隊首,搶占優先級低的線程;線程可根據時間特性來確定它的優先級并排隊,提高了線程的實時性。然而這種方式也有其不足,優先級低的線程始終得不到調度,同樣會導致“餓死”。如果系統中有大量線程爭搶稀有資源,排隊過程還會引入隊列的搜索時間。
這就需要一種策略,對于具有很強時效性的實時線程使用優先級排隊,對于一般線程按照先進先出排隊。由于實時線程很少,配合哈希(Hash)表分類實時線程(如圖1虛直線上部分所示)基本不會引入搜索時間。
3 基于Priority和FIFO結合的信號量策略
針對優先級隊列過分強調高優先級線程的缺點和先進先出隊列過分強調平均的缺點,本文提出基于優先級和先進先出隊列結合的排隊策略,同時兼顧實時線程的強實時要求和一般線程的公平要求。
NT內核將用戶線程以一對一方式映射到內核中,并基于優先級調度內核線程,內核將優先級從低到高分為32級,0~15級為一般線程,16~31級為實時線程。本文將這種線程調度隊列的分級方式見之于信號量的等待隊列,如圖1虛直線上部分所示,把線程等待隊列構造成一個長度為17、類型為LIST_ENTRY的哈希(Hash)指針數組,數組1~16根據優先級排列同一級別的實時線程,數組0根據先進先出排列一般線程。線程請求資源后,若信號量計數器小于0,且線程優先級小于16,則將該線程按照先進先出策略排在線程等待隊列的隊尾;若線程優先級大于等于16,則按照優先級排列該線程。當線程釋放資源時,若信號量計數器小于0,內核應先從優先級隊列中搜索掛起線程,再從先進先出隊列中搜索掛起線程。
4 新信號量策略在NT內核中的實現及結果分析
為了兼容操作系統上層軟件,本文僅修改“請求”函數的代碼而不改變現有信號量的數據結構,將圖1虛直線上部分描述的新信號量策略映射到虛直線下,把優先級隊列和先進先出隊列融合到一個隊列中,隊列的前半部分是優先級隊列,由指針FLINK指定,后半部分為先進先出隊列,由指針BLINK指定,這種復合型隊列同時具備優先級和先進先出隊列的優點,體現了“一個隊列兩種策略”。線程請求資源后,若信號量計數器小于0,且線程的優先級小于16,按照先進先出策略將線程排在BLINK指向的先進先出隊列隊尾;若線程的優先級大于等于16,則將線程按照優先級策略在FLINK指向的優先級隊列中搜索相應的位置,找到小于優先級隊列中的線程并放在該線程之后。當線程釋放資源時,若信號量計數器小于0,由于線程已經根據策略放入恰當的位置,內核只需要從KSEMAPHORE→WaitList→FLINK取出第一個線程送往線程調度隊列即可
下載該資料的人也在下載
下載該資料的人還在閱讀
更多 >
- 在Arduino IDE中使用FreeRTOS信號量
- 開源硬件信號量在行動
- FreeRTOS系列第20篇---FreeRTOS信號量API函數
- FreeRTOS高級篇6---FreeRTOS信號量分析
- ThreadX(六)------信號量semaphore
- FreeRTOS 隊列 信號量 互斥量
- FreeRTOS信號量 & ESP32實戰
- LINUX內核的信號量設計與實現 18次下載
- LINUX內核的信號量設計與實現 5次下載
- uCOS信號量源碼的詳細資料分析 7次下載
- UCOS擴展例程-UCOSIII任務內嵌信號量 17次下載
- UCOS擴展例程-UCOSIII互斥信號量 27次下載
- UCOS擴展例程-UCOSIII使用信號量進行任務同步 24次下載
- Linux操作系統信號量機制的實時化改造 18次下載
- 如何用VxWorks的信號量機制實現任務同步
- 實時頻譜分析儀的工作原理和基本結構 1036次閱讀
- 信號量實現原理介紹 811次閱讀
- FreeRTOS信號量的使用與實例 1788次閱讀
- 基于STM32F407的FreeRTOS學習筆記(8) 702次閱讀
- 基于STM32F407的FreeRTOS學習筆記(7) 449次閱讀
- Free RTOS的互斥信號量 993次閱讀
- Free RTOS的計數型信號量 873次閱讀
- FreeRTOS的二值信號量 1225次閱讀
- freeRTOS中最常用到的信號量有哪些 1724次閱讀
- FreeRTOS信號量使用教程 2861次閱讀
- 使用MM32F3270基于Azure RTOS信號量的應用 862次閱讀
- 淺談鴻蒙內核源碼的信號量運作原理 1442次閱讀
- 嵌入式μC/OS-II系統中基于ECB基本存儲單元實現信號量管理的設計 1294次閱讀
- Verdi使用技巧 連續有效信號量測方法 9653次閱讀
- 簡單介紹信號與信號量 9434次閱讀
下載排行
本周
- 1TC358743XBG評估板參考手冊
- 1.36 MB | 330次下載 | 免費
- 2開關電源基礎知識
- 5.73 MB | 6次下載 | 免費
- 3100W短波放大電路圖
- 0.05 MB | 4次下載 | 3 積分
- 4嵌入式linux-聊天程序設計
- 0.60 MB | 3次下載 | 免費
- 5基于FPGA的光纖通信系統的設計與實現
- 0.61 MB | 2次下載 | 免費
- 6基于FPGA的C8051F單片機開發板設計
- 0.70 MB | 2次下載 | 免費
- 751單片機窗簾控制器仿真程序
- 1.93 MB | 2次下載 | 免費
- 8基于51單片機的RGB調色燈程序仿真
- 0.86 MB | 2次下載 | 免費
本月
- 1OrCAD10.5下載OrCAD10.5中文版軟件
- 0.00 MB | 234315次下載 | 免費
- 2555集成電路應用800例(新編版)
- 0.00 MB | 33564次下載 | 免費
- 3接口電路圖大全
- 未知 | 30323次下載 | 免費
- 4開關電源設計實例指南
- 未知 | 21548次下載 | 免費
- 5電氣工程師手冊免費下載(新編第二版pdf電子書)
- 0.00 MB | 15349次下載 | 免費
- 6數字電路基礎pdf(下載)
- 未知 | 13750次下載 | 免費
- 7電子制作實例集錦 下載
- 未知 | 8113次下載 | 免費
- 8《LED驅動電路設計》 溫德爾著
- 0.00 MB | 6653次下載 | 免費
總榜
- 1matlab軟件下載入口
- 未知 | 935054次下載 | 免費
- 2protel99se軟件下載(可英文版轉中文版)
- 78.1 MB | 537796次下載 | 免費
- 3MATLAB 7.1 下載 (含軟件介紹)
- 未知 | 420026次下載 | 免費
- 4OrCAD10.5下載OrCAD10.5中文版軟件
- 0.00 MB | 234315次下載 | 免費
- 5Altium DXP2002下載入口
- 未知 | 233046次下載 | 免費
- 6電路仿真軟件multisim 10.0免費下載
- 340992 | 191185次下載 | 免費
- 7十天學會AVR單片機與C語言視頻教程 下載
- 158M | 183278次下載 | 免費
- 8proe5.0野火版下載(中文版免費下載)
- 未知 | 138040次下載 | 免費
評論
查看更多