計算機系統008 - 操做系統概況

本篇開始，將介紹操做系統相關知識，這一部分的知識涵蓋操做系統通識到具體的平臺。和本系列前面全部文章同樣，力求精簡但有所突破。

1. 硬件使用回顧

若是已經閱讀過前面的文章，那麼應該對計算機硬件執行計算的概念有所瞭解，這裏作一下簡單回顧，也是做爲操做系統必要性的基礎。
計算機硬件主要能夠分爲以下四大部分：

• CPU，包括控制單元CU和執行單元EU，執行單元其實仍是經過算術邏輯單元ALU來實現功能
• 存儲器，包括內存、Cache，以及最貼近CPU的寄存器等
• 輸入輸出設備，包括鍵盤、鼠標、顯示器、磁盤等等
• 總線，鏈接上述三種元器件的電氣線纜，起到連通的做用

那麼典型的計算過程是：

• 基於CPU支持的指令集ISA編寫任務描述
• 經過輸入設備輸入到存儲器中，注意這期間使用到了總線
• CPU執行計算任務，期間一樣使用到了總線
• 經過輸出設備輸出結果，期間使用到了總線

看起來也沒什麼問題，程序員應該有能力獨立完成上述步驟，順利調用CPU進行計算。但有一個問題要先引發重視，那就是總線的使用時機。

1.1 總線使用

圖中能夠看出，總線分爲地址總線、數據總線、控制總線三種，這裏不去討論分類的細節，畢竟從名稱上所能觀察到的含義足夠使用。思考的問題是，爲何總線要分類？

總線之因此要分類，首先是由於總線總數有限，就是說從硬件層面，不能將每兩個可能發生通訊的組件之間所有用總線相連。既然不能造成點對點專線，而組件之間又確實有通訊的需求，那就只能採起一個辦法，共用總線。

共用總線是好事，畢竟遠離CPU的線纜大部分時候都是處於空閒狀態的，假如可以共享硬件總線，不管是從經濟仍是電路設計的角度來說，都是一件節約成本的事。簡單的共用無非就是你們約定俗成，分時段使用，不過這樣一點也不高效，畢竟使不使用總線要看任務描述中的指令順序，要看指令的操做對象是數據、地址仍是須要控制。爲了更加高效地利用線纜，那麼必定須要一個相似總線控制的單元。該單元管理並維護着全部總線的使用，擁有調度的能力，這樣纔可以及時填補空檔，並有效響應其餘組件使用總線的需求。

到了這裏，就天然明白總線爲何要分類了。分類是爲了更好地管理總線，不只要分，最好是能進一步細分，分類越細，越能在調度時提供更多信息支持，越能物盡其用。

說了這麼些關於總線使用的問題，主要是引出一個概念：硬件資源獨佔時，能夠隨意使用，但帶來問題是使用率低，不經濟。若是要共享，就必須有所謂的控制單元，創建規則，進行管理。不然各個用戶不只沒法正常完成本身的計算任務，並且還頗有可能干擾其餘人的計算需求。

1.2 資源管理

如上所述，當須要共享某一硬件資源來達到提升利用率並同時保持良好響應的目標時，就須要有控制單元進行管理。對於計算機硬件總體而言，如獨佔使用，每次只運行一個計算任務，那麼只要在總線這一層實現控制便可。然而若是要運行多個計算任務，或是多個用戶共享使用，那就須要一個控制單元來完成管理、調度的功能。而在計算機系統中，這個單元就叫作操做系統。

2. 操做系統

那麼不言而喻，操做系統最根本的工做是進行資源管理，確保計算任務能夠正確執行。固然任何管理老是有管理理念的差別存在，對應的也就是操做系統調度算法各有側重。對比操做系統發展史，主要有以下兩個方向：

• 追求高CPU利用率，即儘量填滿CPU指令週期。典型的有批處理操做系統、多道操做系統
• 追求低響應時長，即有更好的交互體驗。典型的有分時操做系統

這兩個方向有各自相違背的點，由於所謂的低響應時長，就表明着必須可以中斷執行中的任務，而每次中斷，實質上，對於單個任務來說，都是延長了總執行時長的因素。不過若是能所以服務於更多用戶、更多計算任務，甚至更好地將使用到不一樣組件的任務同時執行，一點點中斷開銷仍是值得的。

2.1 操做系統的定義

道理講到這裏，也不能免俗，須要爲操做系統下一個定義。操做系統是一種系統軟件，它管理計算機硬件和軟件資源，並向計算機應用程序提供通用服務。

換成圖示的話，它在整個計算任務中的位置以下所示：

貌似前文中咱們只講到操做系統是管理計算機硬件的，但這裏的定義中還出現了軟件資源，那麼這些軟件資源指的又是什麼？

咱們知道，所謂軟件、應用程序這些名詞表明的無非是計算任務描述，它從根本上是由CPU ISA中指令加上操做對象有序組合而成。既然核心元素是CPU ISA，而各廠家CPU又有所不一樣，那麼編寫程序時，必定須要根據具體ISA去編寫。這就帶來一個問題，每一個軟件想要運行在某一CPU上，先要找到手冊，逐字逐句進行翻譯（指令映射），才能運行。但這些工做其實都是機械重複且低效的，也就意味着要重複地投入大量人力物力來完成這個步驟，然而有一個設備很擅長幹這種髒活累活，那就是計算機。若是咱們能夠將指令映射的步驟自動化，讀取CPU ISA手冊，自動映射，就無需再手動處理。而這個過程，就是編譯器的雛形。

因此軟件資源指的是一些基礎功能資源，提供一些基礎功能，以供編寫計算任務描述時使用，簡化任務描述的編寫時間。而也是由於這些基礎軟件資源，對底層硬件（如CPU）進行了封裝（wrap），才使得操做系統能夠提供通用服務。

2.2 操做系統提供了哪些服務

因爲我的沒法給出準肯定義，而又不能誤人誤己，只能選擇翻譯大牛書籍，書籍名稱爲《Operating Systems Internals and Design Principles》 2.1.1小節內容。

一般，一個完整的操做系統須要提供如下幾個方面的服務：

• 程序開發
  操做系統提供各式各樣的工具和服務，如編輯器、調試器，用於幫助程序員開發程序。這些工具按照封裝程度能夠進一步劃分爲如下兩種：

  • Instruction Set Architecture
    指令系統體系結構ISA，定義了操做系統使用的機器語言指令系統。事實上，應用程序和操做系統都可以直接訪問ISA。

  • Applicaiton Binary Interface
    應用程序二進制接口ABI，定義了操做系統的系統調用接口，以及在系統中經過ISA可以使用的硬件資源和服務。每一個操做系統或平臺會選擇使用一種二進制格式做爲可執行格式，同一程序如需在不一樣操做系統上實現可移植，就必須在ABI層進行適配。

  • Application Programming Interface
    應用程序編程接口API，API封裝了操做系統所提供的硬件資源和服務，使用API能夠下降應用程序複雜度，移植時，也能夠直接在API層進行映射。

• 程序運行
  程序運行須要不少步驟，包括加載指令和數據、初始化I/O設備和文件，以及其餘相關資源。有了操做系統，程序員只要在編寫程序是遵循所提供接口便可，而無需關心執行所需的具體細節。

• I/O設備訪問
  一樣的，操做系統中可能會同時運行多個程序，程序之間對I/O設備的訪問須要管理以便順利協做。操做系統封裝I/O設備的硬件細節，爲程序提供統一接口，同時也管理、維護I/O設備使用狀況以便調度。

• 文件訪問控制
  文件從操做系統的角度來看，是I/O設備磁盤上的一種對象。經過對象的抽象，將一組二進制值約束爲文件內容，同時經過額外的二進制值來表明各類訪問屬性。因此文件實際上能夠成爲磁盤類I/O設備的訪問單元，所以，對於I/O設備自己的管理天然包括了內部全部文件狀況的維護。

• 系統訪問
  操做系統管理資源，也維護這大量有關資源的信息。這些信息的訪問必須有所保護，不然一旦被惡意修改，輕則系統信息錯誤，重則直接崩潰。同時，對於同一資源的訪問，系統層也應當進行調度，以保證相互間互不衝突。

• 錯誤檢測和響應
  計算機硬件終歸是電氣電路組成的，電氣電路在使用環境、壽命等因素的影響下，會出現潛在錯誤。同時，軟件編寫中也可能引入錯誤，如除零。操做系統會對這些潛在錯誤進行檢測，並嘗試修復。如沒法修復，則提示用戶或最終關機。

• 統計信息
  對於全部資源的管理調度，須要基於對應的維護信息，只有在各相關組件間共享這些內容，才能更加精確地達成提升CPU利用率或更低響應時長的目標。

3. 操做系統組織架構

上一節中給出了操做系統的定義，列出了須要提供的服務，這一節就從操做系統自己內部如何實現的角度，來談談操做系統組織架構。所謂組織架構，實際上就是操做系統中是如何提供各服務的，是每一個服務做爲一個程序，彙集而造成操做系統，仍是走大而全的策略一個程序包含全部操做系統內容。這兩種方式，分別對應 單內核和微內核兩種架構。

3.1 單內核

單內核中全部服務如文件系統、存儲管理等都由多個運行在內核態（Kernel Mode）的模塊來完成。雖然每一個模塊單獨服務，但因爲高度集成，一旦某一模塊產生bug，則會使整個內核崩潰。不過一樣由於集成度高，全部操做位於同一地址空間內，控制代碼的運行效率會更高。

傳統UNIX、DOS以及早期的Mac OS系統均採用單內核形式。

3.2 微內核

微內核的原則是將服務的實現和基礎操做分離，如某些功能能夠經過運行在微內核以外的服務組件來提供。對比單內核，一個模塊的錯誤並不會引發整個內核的崩潰，並且服務的擴展也更加便捷。固然微內核在效率上就略有劣勢。

3.3 混合內核

既然單內核和微內核均有各自優缺點，那麼天然而然就能想象獲得會有人將二者混合使用。經過讓一些微內核結構代碼運行在內核空間上，提升內核總體運行效率。典型混合內核例子有Windows NT及以後系列、Mac OS X等。

下圖是Windows和Linux操做系統結構圖，感興趣的話能夠先有個概念，具體討論將放在後續文章中。

Windows

Linux

4. 總結

本篇定位於介紹操做系統的由來、必要性、所提供的服務，以及服務組織形式。掌握了這些概念，就應該要朝着提升CPU使用率、下降響應時長的目標去，進一步瞭解內部具體實現原理，而這些，均會在接下來幾篇中慢慢道來。