操做系統知識回顧---進程線程模型

1、進程模型

(一)多道程序設計

從系統容許多個程序同時進入CPU那一天開始，咱們纔有了進程，這個對CPU資源的抽象。咱們把這種多個程序同時運行在CPU的狀況叫作多道程序。其優勢沒必要贅述，舉個例子，單一程序設計時，比如公交車上每次只能坐一我的，多道之後，就能坐多我的，有上有下。也是基於這樣的設計思路，纔有如今的各類貌似高端的技術。多道，跟中斷，DMA，SPOOLer一併，被稱爲計算機操做系統發展史上里程碑同樣的創造。

(二)進程定義

在某個數據集合上，具備獨立功能的程序運行過程，叫作進程。英文裏有許多叫法(process task job)固然換湯不換藥，不一樣時代的產物罷了。進程的出現，解決了程序併發執行時對系統資源共享的描述問題，同時順路解決了程序執行時動態特徵的描述問題。雖然是抽象出來的概念，但做爲程序員，那東西是存在的。

(三)進程控制操做

進程控制的目的是爲進程完成生命週期指明方向，保駕護航。系統建立了進程，必定要負責到底。從進程建立，撤銷，到狀態轉換中的阻塞，喚醒，掛起，激活，同時還有進程間優先級的控制。這些控制指令都是經過「原語」實現的，這個詞不出意外最早是在數據庫基礎知識中學到的，對滴，不能被打斷，打斷就拋棄結果。對於系統，沒有被打斷的可能性。

此處加一個小插曲：進程的建立fork()的執行過程

1.爲子進程分配一個空閒進程描述符；

2.賦予子進程惟一標示符pid；

3.以一次一頁的方式複製父進程的地址空間(這是Unix的實現方式，linux引入COW技術)；

4.子進程得到父進程共享資源的指針；

5.子進程進入就緒態，加入調度隊列；

6.子進程返回0，向父進程返回pid。

(四)進程分類及進程層次結構

系統進程vs用戶進程，系統進程優先於用戶進程

前臺進程vs後臺進程，先後臺進程有優先級的區別，前臺每每高於後臺

計算密集vsI/O密集，決定了調度策略，是系統設計時討論的話題

進程的層級結構有樹形（unix）和平行結構（windows）

(五)進程狀態切換

基本狀態爲三態及轉換，如圖1

發展一下成爲五態模型，加入了建立和撤銷兩個case，如圖2

再複雜一點，加入掛起原語，使得就緒和阻塞有掛起狀態，增長了系統調度複雜性，但提升了靈活度，下降調度難度。如圖3

linux中包含五種狀態，使用宏進行了定義：

TASK_RUNNING對應運行態，TASK_INTERRUPTIBLE可中斷態，TASK_UNINTERRUPUTIBLE不可中斷態，兩種是就緒態中的不一樣方向

TASK_ZOMBIE僵死狀態，對應於阻塞態，TASK_STOPPED中止態，對應於進程的撤銷狀態。五個狀態之間的轉換，如圖4

(六)進程控制塊

就像開車得有方向盤，管理得有管理的可控對象，對於進程來說，PCB就是進程的方向盤，他是一個專門的數據結構，記錄了進程的外部特徵，描述了進程的運動過程，標記了進程在整個生命週期中的活動，成爲了系統感知進程存在的惟一標識。這個數據結構中包含了三個方面的內容：

進程管理，內存管理，文件管理

看上去就很容易理解了，OS的大部分功能經過進程來實現，因此進程中必須包含實現操做系統功能的「方向盤」。這些內容中，多數是記錄了管理相應對象的主指針，以及指向不一樣管理對象描述塊的指針，好比文件管理，指向文件描述塊，就是咱們常說的FCB等。

在linux系統中，TCB被具體實現爲task_struct其中包含了進程調度 pid，信號處理，狀態管理，進程隊列指針，定時控制，信號量管理，上下文切換，文件系統管理，內存管理等等。這個數據結構能看懂，看完，你的Linux內核分析工做就能夠開始了。

(七)進程虛擬地址空間

內存管理模塊會在進程建立的時候分配地址空間，這些空間被進程劃分爲四大部分：

PCB佔用，用戶棧空間，私有用戶空間（代碼），共享空間。其中，PCB佔用的部分又劃分爲PCB號，進程狀態，進程控制信息

(八)進程上下文環境

首先應該明白什麼叫作上下文，小學語文的時候，老師就會讓咱們結合上下文來猜不認識的詞的意思，中學英語老師也有這個習慣。如今，這個方式仍然適用，只不過是系統用，他需呀這個上下文信息來猜咱們運行到哪裏了，進程是什麼狀況了。咱們讀完上文，就會記住，而後去讀下文，最後綜合上下文進行猜詞。系統也得這麼作。也就是保存上下文信息，分析當前進程運行狀態。

上下文信息在系統中指的是用戶地址空間內容，可能是指正在運行的程序，硬件寄存器內容，多指程序運行狀態，該進程相關的核心數據結構最新內容。根據不一樣的操做對象，咱們又把上下文信息分爲三種，

用戶級上下文：用戶地址空間，用戶棧信息，程序段信息（代碼段，數據段）

系統級上下文：靜態信息（PCB，資源使用表）動態信息（核心棧）

寄存器級上下文：PC IP SP ABCD那一些寄存器內部的信息，若是不太懂，能夠看組成原理，也能夠等個人AT&T彙編指令筆記一文，那裏頭會講這些枯燥的符號

再加一個小插曲：中斷處理和進程調度的關係，實際上就是當系統發生中斷，進程做何反應？

來個原汁原味的圖圖來講明，英文很差，仍是轉行吧，別作IT了。如圖5

2、線程模型

(一)線程引入

操做系統課程裏，陳老師喜歡用字處理軟件和web服務器兩個例子引入線程，估計是翻譯外文書的結果，我也喜歡翻譯外文書，估計是找了個翻譯專業的媳婦的結果，哈哈哈，說遠了。此處也給你們簡單介紹一下這兩個模型。

1.字處理軟件，比較常見的就是word，固然，當今的2013，絕非這麼簡單。咱們抽象出來三個線程，接收鍵盤輸入並顯示，自動排版縮進，自動存盤。三個過程都是在word的進程中，他們共享當前所操做的文件，協同處理，固然他們分工不一樣，也有前後順序。

2.web服務器，一個web server進程中會包含這麼幾個進程，網絡鏈接，分派線程，網頁處理，網頁緩存等。這些線程運行在用戶空間，由網絡鏈接請求發起。固然，話又說回來，並不是全部的web服務器都得設計成多線程的模型，系統管理用的多了，實際用於工做的資源就會少，平衡這些因素，才能選出合適的設計方案。

基於這兩個模型，咱們引入線程的概念，對於一個活動的進程，咱們想讓他同時執行多種功能，可是這幾種功能之間經過不一樣進程的解決方案通訊開銷太大，調度開銷也不小，所以咱們應該給出一個比進程更輕量級的實體，他們可以共享的資源更多，通訊更方便高效，低耗，線程這玩意就應運而生了。老話說得好，進程是系統最小資源分配單位，線程是系統最小調度單位，線程是輕量級的進程。一語中的。

(二)線程模型

線程的模型與進程類似，一樣包含線程實現功能所需的數據結構，運行時狀態等信息，同時包含可讀寫的所在進程的資源。那麼進程與線程的實質上的區別在哪兒呢？

一個線程能夠運行在不一樣進程之間，一個進程能夠有多個線程。線程能夠有本身的資源，也能夠共享進程的資源。本質上的區別，能夠從線程的實現機制中說明。

(三)線程實現機制

1.用戶級線程linux

經過用戶程序空間的一組線程庫函數完成全部線程的管理。內核並不知到線程的具體運行狀況，線程之間的切換和狀態轉移不須要核心態系統支持，調度過程是基於應用程序，特有的線程過程。具體的實現過程以下：當系統對進程進行調度的時候，進程對其內部的用戶級線程進行調度和狀態轉換，提升進程內部資源的利用率。當進程內部一個線程處於阻塞狀態時，能夠將其餘就緒態的線程運行。可是當線程提出系統調用或者發生中斷時，進程也被阻塞。

這麼作的優勢是：線程切換沒必要調用系統核心；調度過程是基於用戶程序的，能夠針對用戶程序業務邏輯選擇更好的調度算法；用戶級線程模型能夠運行於任何系統上，只須要有相應的線程庫支持。

固然缺點也很明顯，當進程內部某一個線程進行系統調用時，整個進程都會被阻塞，這樣會影響總體的效率；進程分配到的資源不可以在兩個CPU同時運行，換句話說，用戶級線程不能支持多核多線程的用戶要求。

常見的用戶級線程支持庫是POSIX線程庫，其中包含線程控制的大部分函數接口。

2.核心級線程windows

相對應於用戶級線程，就是系統線程。這種線程模型中，全部的線程管理都由系統完成；沒有線程庫，可是系統提供了調用API函數接口；系統完成線程的上下文切換，系統進行線程調度，並以線程爲基本調度單位進行管理。

優勢：對於多處理器，核心能夠同時調度同一進程的不一樣線程在不一樣CPU中運行。線程的阻塞不會影響其餘線程的運行。核心例程是多線程的。

缺點：在同一進程中調用系統內核，會下降進程運行效率。

固然也有混合上述兩種模型的系統solaris，其中線程的建立在用戶級別，線程調度在系統級別。