python學習筆記-（十四）I/O多路複用 阻塞、非阻塞、同步、異步

1. 概念說明

1.1 用戶空間與內核空間

如今操做系統都是採用虛擬存儲器，那麼對32位操做系統而言，它的尋址空間（虛擬存儲空間）爲4G（2的32次方）。操做系統的核心是內核，獨立於普通的應用程序，能夠訪問受保護的內存空間，也有訪問底層硬件設備的全部權限。爲了保證用戶進程不能直接操做內核（kernel），保證內核的安全，操心繫統將虛擬空間劃分爲兩部分，一部分爲內核空間，一部分爲用戶空間。針對linux操做系統而言，將最高的1G字節（從虛擬地址0xC0000000到0xFFFFFFFF），供內核使用，稱爲內核空間，而將較低的3G字節（從虛擬地址0x00000000到0xBFFFFFFF），供各個進程使用，稱爲用戶空間。

1.2 進程切換

爲了控制進程的執行，內核必須有能力掛起正在CPU上運行的進程，並恢復之前掛起的某個進程的執行。這種行爲被稱爲進程切換。所以能夠說，任何進程都是在操做系統內核的支持下運行的，是與內核緊密相關的。

從一個進程的運行轉到另外一個進程上運行，這個過程當中通過下面這些變化：
1. 保存處理機上下文，包括程序計數器和其餘寄存器。
2. 更新PCB信息。
3. 把進程的PCB移入相應的隊列，如就緒、在某事件阻塞等隊列。
4. 選擇另外一個進程執行，並更新其PCB。
5. 更新內存管理的數據結構。
6. 恢復處理機上下文。 

注：總而言之就是很耗資源，具體的能夠參考這篇文章：進程切換

1.3 進程阻塞

正在執行的進程，因爲期待的某些事件未發生，如請求系統資源失敗、等待某種操做的完成、新數據還沒有到達或無新工做作等，則由系統自動執行阻塞原語(Block)，使本身由運行狀態變爲阻塞狀態。可見，進程的阻塞是進程自身的一種主動行爲，也所以只有處於運行態的進程（得到CPU），纔可能將其轉爲阻塞狀態。當進程進入阻塞狀態，是不佔用CPU資源的。

1.4 文件描述符

文件描述符（File descriptor）是計算機科學中的一個術語，

文件描述符在形式上是一個非負整數。實際上，它是一個索引值，指向內核爲每個進程所維護的該進程打開文件的記錄表。當程序打開一個現有文件或者建立一個新文件時，內核向進程返回一個文件描述符。在程序設計中，一些涉及底層的程序編寫每每會圍繞着文件描述符展開。可是文件描述符這一律念每每只適用於UNIX、Linux

1.5 緩存I/O

緩存 I/O 又被稱做標準 I/O，大多數文件系統的默認 I/O 操做都是緩存 I/O。在 Linux 的緩存 I/O 機制中，操做系統會將 I/O 的數據緩存在文件系統的頁緩存（ page cache ）中，也就是說，數據會先被拷貝到操做系統內核的緩衝區中，而後纔會從操做系統內核的緩衝區拷貝到應用程序的地址空間。

緩存 I/O 的缺點：
數據在傳輸過程當中須要在應用程序地址空間和內核進行屢次數據拷貝操做，這些數據拷貝操做所帶來的 CPU 以及內存開銷是很是大的。 

2. 同步與異步

首先來解釋同步和異步的概念，這兩個概念與消息的通知機制有關。也就是同步與異步主要是從消息通知機制角度來講的。

2.1 概念描述

同步就是一個任務的完成須要依賴另一個任務時，只有等待被依賴的任務完成後，依賴的任務才能算完成，這是一種可靠的任務序列。要麼成功都成功，失敗都失敗，兩個任務的狀態能夠保持一致。

異步是不須要等待被依賴的任務完成，只是通知被依賴的任務要完成什麼工做，依賴的任務也當即執行，只要本身完成了整個任務就算完成了。至於被依賴的任務最終是否真正完成，依賴它的任務沒法肯定，因此它是不可靠的任務序列。

2.2 消息通知

異步的概念和同步相對。當一個同步調用發出後，調用者要一直等待返回消息（結果）通知後，才能進行後續的執行；當一個異步過程調用發出後，調用者不能馬上獲得返回消息（結果）。實際處理這個調用的部件在完成後，經過狀態、通知和回調來通知調用者。 

 

這裏提到執行部件和調用者經過三種途徑返回結果：狀態、通知和回調。使用哪種通知機制，依賴於執行部件的實現，除非執行部件提供多種選擇，不然不受調用者控制。

1. 若是執行部件用狀態來通知，那麼調用者就須要每隔必定時間檢查一次，效率就很低（有些初學多線程編程的人，總喜歡用一個循環去檢查某個變量的值，這實際上是一種很嚴重的錯誤）； 

2. 若是是使用通知的方式，效率則很高，由於執行部件幾乎不須要作額外的操做。至於回調函數，其實和通知沒太多區別。

2.3 場景比喻

舉個例子，好比我去銀行辦理業務，可能會有兩種方式： 

1. 選擇排隊等候； 

2. 另種選擇取一個小紙條上面有個人號碼，等到排到我這一號時由櫃檯的人通知我輪到我去辦理業務了；

第一種：前者(排隊等候)就是同步等待消息通知，也就是我要一直在等待銀行辦理業務狀況；

第二種：後者(等待別人通知)就是異步等待消息通知。在異步消息處理中，等待消息通知者(在這個例子中就是等待辦理業務的人)每每註冊一個回調機制，在所等待的事件被觸發時由觸發機制(在這裏是櫃檯的人)經過某種機制(在這裏是寫在小紙條上的號碼，喊號)找到等待該事件的人。

3. 阻塞與非阻塞

阻塞和非阻塞這兩個概念與程序（線程）等待消息通知(無所謂同步或者異步)時的狀態有關。也就是說阻塞與非阻塞主要是程序（線程）等待消息通知時的狀態角度來講的。

3.1 概念描述

阻塞調用是指調用結果返回以前，當前線程會被掛起，一直處於等待消息通知，不可以執行其餘業務。函數只有在獲得結果以後纔會返回。

阻塞調用和同步調用不一樣點：

1. 對於同步調用來講，不少時候當前線程可能仍是激活的，只是從邏輯上當前函數沒有返回而已，此時，這個線程可能也會處理其餘的消息。還有一點，在這裏先擴展下：

　　　　a.若是這個線程在等待當前函數返回時，仍在執行其餘消息處理，那這種狀況就叫作同步非阻塞；

　　　　b.若是這個線程在等待當前函數返回時，沒有執行其餘消息處理，而是處於掛起等待狀態，那這種狀況就叫作同步阻塞；

　　　　因此同步的實現方式會有兩種：同步阻塞、同步非阻塞；同理，異步也會有兩種實現：異步阻塞、異步非阻塞；

　　2.對於阻塞調用來講，則當前線程就會被掛起等待當前函數返回；

非阻塞和阻塞的概念相對應，指在不能馬上獲得結果以前，該函數不會阻塞當前線程，而會馬上返回。雖然表面上看非阻塞的方式能夠明顯的提升CPU的利用率，可是也帶了另一種後果就是系統的線程切換增長。增長的CPU執行時間能不能補償系統的切換成本須要好好評估。 

3.2 場景比喻

繼續上面的那個例子，不管是排隊仍是使用號碼等待通知，若是在這個等待的過程當中，等待者除了等待消息通知以外不能作其它的事情，那麼該機制就是阻塞的，表如今程序中,也就是該程序一直阻塞在該函數調用處不能繼續往下執行。

相反，有的人喜歡在銀行辦理這些業務的時候一邊打打電話發發短信一邊等待，這樣的狀態就是非阻塞的，由於他(等待者)沒有阻塞在這個消息通知上，而是一邊作本身的事情一邊等待。

可是須要注意了，同步非阻塞形式其實是效率低下的，想象一下你一邊打着電話一邊還須要擡頭看到底隊伍排到你了沒有。若是把打電話和觀察排隊的位置當作是程序的兩個操做的話，這個程序須要在這兩種不一樣的行爲之間來回的切換，效率可想而知是低下的；而異步非阻塞形式卻沒有這樣的問題，由於打電話是你(等待者)的事情，而通知你則是櫃檯(消息觸發機制)的事情，程序沒有在兩種不一樣的操做中來回切換。

4. IO多路複用

剛纔說了，對於一次IO訪問（以read舉例），數據會先被拷貝到操做系統內核的緩衝區中，而後纔會從操做系統內核的緩衝區拷貝到應用程序的地址空間。因此說，當一個read操做發生時，它會經歷兩個階段：
1. 等待數據準備 (Waiting for the data to be ready)
2. 將數據從內核拷貝到進程中 (Copying the data from the kernel to the process)

正式由於這兩個階段，linux系統產生了下面五種網絡模式的方案。
- 阻塞 I/O（blocking IO）
- 非阻塞 I/O（nonblocking IO）
- I/O 多路複用（ IO multiplexing）
- 信號驅動 I/O（ signal driven IO）
- 異步 I/O（asynchronous IO）

注：因爲signal driven IO在實際中並不經常使用，因此我這隻說起剩下的四種IO Model。

4.1 阻塞 I/O（blocking IO）

在linux中，默認狀況下全部的socket都是blocking，一個典型的讀操做流程大概是這樣：

 

 

當用戶進程調用了recvfrom這個系統調用，kernel就開始了IO的第一個階段：準備數據（對於網絡IO來講，不少時候數據在一開始尚未到達。好比，尚未收到一個完整的UDP包。這個時候kernel就要等待足夠的數據到來）。這個過程須要等待，也就是說數據被拷貝到操做系統內核的緩衝區中是須要一個過程的。而在用戶進程這邊，整個進程會被阻塞（固然，是進程本身選擇的阻塞）。當kernel一直等到數據準備好了，它就會將數據從kernel中拷貝到用戶內存，而後kernel返回結果，用戶進程才解除block的狀態，從新運行起來。

blocking IO的特色就是在IO執行的兩個階段都被block了。

 

4.2 非阻塞 I/O（nonblocking IO）

linux下，能夠經過設置socket使其變爲non-blocking。當對一個non-blocking socket執行讀操做時，流程是這個樣子：

 

當用戶進程發出read操做時，若是kernel中的數據尚未準備好，那麼它並不會block用戶進程，而是馬上返回一個error。從用戶進程角度講 ，它發起一個read操做後，並不須要等待，而是立刻就獲得了一個結果。用戶進程判斷結果是一個error時，它就知道數據尚未準備好，因而它能夠再次發送read操做。一旦kernel中的數據準備好了，而且又再次收到了用戶進程的system call，那麼它立刻就將數據拷貝到了用戶內存，而後返回。

nonblocking IO的特色是用戶進程須要不斷的主動詢問kernel數據好了沒有。

 

4.3 I/O 多路複用（ IO multiplexing）

IO multiplexing就是咱們說的select，poll，epoll，有些地方也稱這種IO方式爲event driven IO。select/epoll的好處就在於單個process就能夠同時處理多個網絡鏈接的IO。它的基本原理就是select，poll，epoll這個function會不斷的輪詢所負責的全部socket，當某個socket有數據到達了，就通知用戶進程。

 

當用戶進程調用了select，那麼整個進程會被block，而同時，kernel會「監視」全部select負責的socket，當任何一個socket中的數據準備好了，select就會返回。這個時候用戶進程再調用read操做，將數據從kernel拷貝到用戶進程。

因此，I/O 多路複用的特色是經過一種機制一個進程能同時等待多個文件描述符，而這些文件描述符（套接字描述符）其中的任意一個進入讀就緒狀態，select()函數就能夠返回。

 

這個圖和blocking IO的圖其實並無太大的不一樣，事實上，還更差一些。由於這裏須要使用兩個system call (select 和 recvfrom)，而blocking IO只調用了一個system call (recvfrom)。可是，用select的優點在於它能夠同時處理多個connection。

因此，若是處理的鏈接數不是很高的話，使用select/epoll的web server不必定比使用multi-threading + blocking IO的web server性能更好，可能延遲還更大。select/epoll的優點並非對於單個鏈接能處理得更快，而是在於能處理更多的鏈接。）

在IO multiplexing Model中，實際中，對於每個socket，通常都設置成爲non-blocking，可是，如上圖所示，整個用戶的process實際上是一直被block的。只不過process是被select這個函數block，而不是被socket IO給block。 

4.4 異步 I/O（asynchronous IO）

inux下的asynchronous IO其實用得不多。先看一下它的流程：

用戶進程發起read操做以後，馬上就能夠開始去作其它的事。而另外一方面，從kernel的角度，當它受到一個asynchronous read以後，首先它會馬上返回，因此不會對用戶進程產生任何block。而後，kernel會等待數據準備完成，而後將數據拷貝到用戶內存，當這一切都完成以後，kernel會給用戶進程發送一個signal，告訴它read操做完成了。 

4.5 總結

blocking和non-blocking的區別：

調用blocking IO會一直block住對應的進程直到操做完成，而non-blocking IO在kernel還準備數據的狀況下會馬上返回。

synchronous IO和asynchronous IO的區別：

在說明synchronous IO和asynchronous IO的區別以前，須要先給出二者的定義。POSIX的定義是這樣子的：
- A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes;
- An asynchronous I/O operation does not cause the requesting process to be blocked;

二者的區別就在於synchronous IO作」IO operation」的時候會將process阻塞。按照這個定義，以前所述的blocking IO，non-blocking IO，IO multiplexing都屬於synchronous IO。

有人會說，non-blocking IO並無被block啊。這裏有個很是「狡猾」的地方，定義中所指的」IO operation」是指真實的IO操做，就是例子中的recvfrom這個system call。non-blocking IO在執行recvfrom這個system call的時候，若是kernel的數據沒有準備好，這時候不會block進程。可是，當kernel中數據準備好的時候，recvfrom會將數據從kernel拷貝到用戶內存中，這個時候進程是被block了，在這段時間內，進程是被block的。

而asynchronous IO則不同，當進程發起IO 操做以後，就直接返回不再理睬了，直到kernel發送一個信號，告訴進程說IO完成。在這整個過程當中，進程徹底沒有被block。

 

各個IO Model的比較如圖所示：

 

經過上面的圖片，能夠發現non-blocking IO和asynchronous IO的區別仍是很明顯的。在non-blocking IO中，雖然進程大部分時間都不會被block，可是它仍然要求進程去主動的check，而且當數據準備完成之後，也須要進程主動的再次調用recvfrom來將數據拷貝到用戶內存。而asynchronous IO則徹底不一樣。它就像是用戶進程將整個IO操做交給了他人（kernel）完成，而後他人作完後發信號通知。在此期間，用戶進程不須要去檢查IO操做的狀態，也不須要主動的去拷貝數據。