RTOS的調度原理是什么

RTOS的調度原理是什么，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

        我們這一系列的微信推送，僅僅是為了可以幫助大家快速地對操作系統有一個感性層面上的認識。當然，讓人更好地記住一樣復雜的東西，就是尋找另一樣簡單的東西來解釋它。但是，這種方式的解釋，是完全不符合教育應該有的嚴謹邏輯的。因此，讓我們來收回這種非科學的論證，轉而用科學的方法論來表述我們需要闡述的東西。

（一） 自己寫一個調度算法

        在很久很久以前，我大抵記得那是我大二學生時期，我就開始自己動手寫過一個調度算法。其實現的功能非常簡單，就是使兩個“任務”分時地去交替執行，并且，利用定時器去決定這兩個任務運行的時間。當時滿心歡喜地想告訴全世界，自己完成了一個“內核”的框架。

        現在想來，上述的這個行為真的是非常可笑的無知滿足。因為這個算法的實現非常簡單。簡單闡述一下其原理，就是建立兩個指向函數的指針變量，然后建立兩個函數，并且用上述兩個變量指向它們。定時器開始定時，假設周期為10ms，那么每隔10ms只要去切換著兩個變量就可以了。這樣子，如果宏觀性上面，你就能看到兩個任務是在同時運行了。

        再來分析一下上述的東西，聽著特別簡單，但是經不住仔細推敲，它們肯定是不符合操作系統的任何特征的。首先，如果你的每個任務執行的時間小于10ms還好，萬一超過了其分時分配的運行時間（10ms）而強行使用定時器去切換，那當前沒運行完的數據完全就丟失了，沒有任何拯救的余地。其次，它的任務沒法被動態地建立，回收。還有很多很多的缺點。這是我大三恍然大悟的東西。因此，到現在我也不喜歡使用在主函數里面利用定時器產生計數值，根據計數值去切換運行函數的方式。為什么？因為你裸機編程的時候，特別是在某個函數里面有大量的通訊等待操作時，你無法保證每個函數的運行時間正好小于等于你設定的時間。因此總會出現，有些任務根本執行不到這一現象。

       但是不幸的是，后來工作之后，發現很多電子工程師都是這樣去處理他的程序流向的。

（二） 操作系統調度算法的原理

        我開始研究操作系統，也是那時候在自信滿滿地用了我自己的“內核”做了幾個項目之后，直到有一次做一個長距離Modbus高速通信，由于這個函數里面有一個做CRC檢驗失敗等待重傳的函數。而由于選用了高速的數據流，加上距離比較長，因此高頻信號的畸變比較嚴重，導致了誤碼率很高。因此這個函數頻繁被調用，但是后來發現，這個函數幾乎不能被完整運行下來。分析了好久的原因，最后發現，原來這個函數執行的時間遠遠超過了我分配給它的運行時間了，因此，沒等它執行完成，我的調度算法強制將其中斷了。并且由于沒有數據的保存機制，導致了整個函數只能執行一半就被銷毀了。后來工作之后，也遇到過別的工程師這么做，勸其修改，還是不聽，最后導致了嚴重的錯誤。從那以后，我寧愿while(1)到底，也不愿使用這樣的方式了。

       而一個成熟的操作系統內核，它的調度算法是會在中斷當前任務之后，將數據保存下來的。

       我們稱當前運行的任務為“運行態”，而沒有被運行的任務，我們稱為“非運行狀態”。但是關于“非運行狀態”，這只是一個籠統的名稱而已，這里面包含了眾多的子狀態。我們以后來詳細說明一下“非運行狀態”的具體細分。在這里注明一下，我們課程的邏輯當中，為了簡化操作系統模型，因此把所有具體的非運行狀態進行集合化，在一些高級的操作系統當中，這個問題有待討論。

       以最基本的分時操作系統來說，這里假設所有任務的優先級都是統一的，時間一到就會自動輪詢。當時間到來時，運行態任務沒有被執行完的數據，操作系統都會有一個機制，將這些數據進行保存，可以是壓入堆棧。具體操作的過程，就是將寄存器里面的數據進行保存，有點類似于中斷函數的調用。接著把可以回收的內存進行回收。然后，為下一個需要執行的任務分配內存，最后再去執行下一個需要執行的任務。而當時間又輪到了第一次沒有執行完的任務之后，又會重新為其分配內存，然后把之前的數據取出來，繼續執行。整個籠統的過程就是這樣。

關于RTOS的調度原理是什么問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。