是不是所有操作系統在CPU層面上都是通過時間片輪轉的形式來運行程序的，如果是的話那麼無論什麼實時操作系統、什麼多用戶操作系統、什麼網路操作系統什麼的其實並無本質上的區別？

順便問一下實時操作系統究竟是什麼意思，說什麼實時操作系統能夠在規定的時間內完成任務，可現在的CPU計算能力不都很強嗎，不也能很快的完成任務嗎，為什麼要加一個規定時間呢？

是不是所有操作系統在CPU層面上都是通過時間片輪轉的形式來運行程序的

不是，還有批處理系統、優先順序搶佔式調度系統。分時復用的辦法很多，時間片輪轉只是其中一種。

至於「實時操作系統」、「多用戶操作系統」、「網路操作系統」，並不是按照調度方式分類的，不要搞混。

實時操作系統究竟是什麼意思

首先需要明確實時操作系統（RTOS）和實時應用程序（real-time application）的區別。RTOS的作用是運行RT-App，因此RTOS的定義就是能夠運行RT-App的操作系統。RT-App就是滿足實時性約束（real-time constraint）的應用程序。

所以問題的關鍵就變成了「實時性約束」的定義。教科書上的定義往往是這樣的：能夠保證在任何情況下，總能在時間T之內，對外部事件（event）給出響應（response），這個時間T也稱為截止時間（deadline）。

（軟體+硬體=系統，這裡並沒有涉及到操作系統。系統滿足實時性約束，它就是實時系統。實時系統不使用OS也是可以的，同樣，使用了RTOS，照樣可以開發出不滿足實時性約束的系統）

實時系統不需要運行得很快，我們關注的不是響應event的平均時間，而是響應event的最壞情況時間，也就是上限（deadline）。

現在考慮一個使用RTOS的實時系統，為了讓系統滿足實時性，要求系統接收到event時，RTOS要在時間T1之內切換到task，task要在時間T2之內完成對event的響應，這樣整個系統就可以在時間T1+T2內完成事件響應。

RTOS需要關注的，就是這個T1，也就是能不能在一個固定的時間上限以內完成任務調度和切換。為了保證最壞情況，RTOS甚至會犧牲平均性能。

通用OS一般會追求較低的平均調度耗時，偶爾出現調度超時是可以接受的，因此會出現用戶操作長時間無響應。對於RTOS，調度超時不可以接受。

題主真正的問題不在系統層面，而是一個抽象層次的問題；如果我們說CPU都是用硅做的，那它們是不是本質上並無區別呢？宇宙萬物都是由粒子構成的，那是不是本質上就並無區別呢？

顯然，把抽象層次提高到一定程度之後，你總會發現共性，非要說這些共性就是本質相同，那也並不能說錯，只不過沒什麼意義而已。

那麼操作系統是不是分時復用呢，不擡槓的說，是的；那它們都一樣嗎？如果你看調度演算法（也就是分時復用的策略），那肯定還是不同的。

實時操作系統就是分時策略上，保證任務一定能夠在實時間隔內得到時間片，和我們平時用的非實時系統當然是很不一樣的。

比如你有個音頻處理任務必須要在30MS內完成，OK，現在有個Excel處理要跑1個小時，它已經佔住CPU時間片了，非實時系統不調度你就慢慢等吧，CPU再快，也有撐破實時的計算任務。

並不是全部時間片輪轉的。

比如有的是FIFO，線程主動掛起才會切換出去。

cpu計算能力強，不代表響應時間快。簡單的可以看看安卓跟ios的界面操作對比。安卓喫虧的地方不是cpu性能不夠，而是調度演算法，對界面響應這塊不是實時調度的。

比如汽車，就是實時系統，踩剎車，油門，要馬上給出反饋，如果反饋比較慢，操控性就差，還容易出安全事故。

除了調度要實時以為，很多演算法都要調整，比如內存分配，要採用穩定開銷的演算法，而不是時快時慢的演算法。比如刪除隊列，如果是普通單鏈表，那麼要刪除頭部的話就很快，要刪除尾部的話就要遍歷一遍整個隊列，如果隊列很長，就比較耗時，這種就是時快時慢的演算法。對普通系統來說，平均耗時不高就行了，對實時系統來說，期望每次都能穩定在一個範圍內，可以不快，但要可期。

本質上都是中斷機制。

時間片中斷只是中斷的一種，所以確實可以認為，實時操作系統在本質上和別的操作系統一樣。

孫悟空、豬八戒、沙僧三個人輪流玩一臺遊戲機，每人輪流玩5分鐘。

如果把遊戲機看作CPU的話，孫悟空、豬八戒、沙僧就是三個任務，時間片是5分鐘。

假如現在正輪到八戒玩

唐僧來了，也想玩

如果唐僧要八戒限時滾出去，要自己上去玩，就是實時操作系統。唐僧下來後，八戒也不一定接著繼續玩，誰的優先順序最高，輪到誰玩。

如果唐僧來了後，乖乖地等八戒把5分鐘用完，乖乖地排隊，是排在悟空前面、還是後面，看人品（優先順序），然後才能輪到自己玩，就是非實時操作系統。

現在的應用程序不是你寫的helloworld，運行一下就結束退出了。大部分應用軟體都是無限死循環，一直在運行，如果你不主動關閉它，會一直在運行。當多個軟體同時運行時，這就要求我們CPU要分配合適的時間片給它們，輪流執行。

我們日常使用的Windows、Linux操作系統一般都是非實時操作系統，時間片為1ms甚至更短，只要CPU的速度足夠快，切換的速度足夠快，讓你感覺就是多個任務同時在運行：你可以一邊聽歌、一邊聊天、一邊寫程序。其實後臺這些程序一直在輪流佔用CPU運行。等你開的程序足夠多了，內存滿了，有部分程序交換到硬碟裏的交換分區去了，再切換回來執行的時候，你纔有可能明顯感到延遲和卡頓。此時你可能感覺很不爽，頂多罵兩句：什麼破電腦，卡得很！接著繼續玩。

實時操作系統一般用於航空航天對時間要求非常高的場合，火箭飛行每秒鐘幾十公里，遇到問題時要在規定的時間限制內搶佔CPU解決。如果像非實時操作系統那樣，遇事不要慌，先發個朋友圈，排排隊等他一段時間，火箭早就飛出去幾十米開外了，誤差很大。

修改了一下：實時並不是立刻馬上，這個很難，但最多等一個時鐘節拍：tick。所謂實時就是說：可以保證在限定的時間內能搶佔到CPU執行。每一個OS的時鐘節拍，操作系統的調度器都要讓最高優先順序的任務去執行。只要時鐘節拍夠快，就可以做到實時。

RTOS 沒有時間片的，優先順序一樣的情況下當前進程不主動釋放就不會切換

實時操作系統在有更精準控制需求的地方用的到

比如控制無人機，慢一點點就可能出大問題，導致無人機翻掉。容不得os隨意調度線程帶來的延遲

反對題主把RTOS理解成時間片調度。以瞭解的人最多的μC/OS-II為例。任務調度函數有兩個，OSSched()和OSIntExit()，前者放在systick裡面，為OSTimeDly()及其擴展函數服務，用戶是看不到的，也不能引用，後者由用戶放在中斷代碼的最後，比如某個任務pend在sem上，中斷中postsem，那麼執行OSIntExit()就會引發一次任務調度，中斷結束後這個任務就會被執行。

那麼基於μC/OS-II的代碼就有兩種極端的寫法，一種是隻有OSTimeDly()沒有OSIntExit()，這種代碼正如題主所述，是基於時間片的，按時間片各個任務輪流執行。另一種極端的寫法就是沒有OSTimeDly()只有OSIntExit()，例如放在串口中斷、GPIO變化中斷裡面，這種寫法的代碼完全不符合題主的描述，但卻是完全可以正常工作的，跟時間片沒有任何關係，是外部輸入（串口，GPIO……）的變化引發任務調度。

推薦閱讀：
相關文章