IO模型淺析-阻塞、非阻塞、IO複用、訊號驅動、非同步IO、同步IO

最近看到OVS使用者態的代碼，在接收核心態資訊的時候，使用了Epoll多工機制，對其十分不解，於是從網上找了一些資料，學習了一下《UNIX網路變成卷1：通訊端連網API》這本書對應的章節，網上雖然關於該主題的博文很多，並且講解的很詳細，但是在這裡還是做一個學習筆記，記錄一下自己的想法。

IO模型

在《UNIX網路變成卷1：通訊端連網API》這本書中，提到了五種I/O模型，分別為：阻塞式I/O、非阻塞式I/O、I/O複用（Epoll、select都是一種I/O複用機制），資訊驅動式I/O、非同步I/O，下面具體的一一介紹。

阻塞式I/O模型

阻塞，顧名思義，當進程在等待資料時，若該資料一直沒有產生，則該進程將一直等待，直到等待的資料產生為止，這個過程中進程的狀態是阻塞的。

如所示，在linux中，使用者態進程調用recvfrom系統調用接收資料，當前核心中並沒有準備好資料，該使用者態進程將一直在此等待，不會進行其他的操作，待核心態準備好資料，將資料從核心態拷貝到使用者空間記憶體，然後recvfrom返回成功的指示，此時使用者態進行才解除阻塞的狀態，處理收到的資料。

從上述過程可以看出，使用者態接收核心態資料的時候，主要有兩個過程：核心態獲得資料-->將資料從核心態的記憶體空間中複製到使用者態進程的緩衝區中

非阻塞式I/O模型

在非阻塞式I/O模型中，當進程等待核心的資料，而當該資料未到達的時候，進程會不斷詢問核心，直到核心準備好資料。

如，使用者態進程調用recvfrom接收資料，當前並沒有資料報文產生，此時recvfrom返回EWOULDBLOCK，使用者態進程會一直調用recvfrom詢問核心，待核心準備好資料的時候，之後使用者態進程不再詢問核心，待資料從核心複製到使用者空間，recvfrom成功返回，使用者態進程開始處理資料。

需要注意的是，當資料從核心複製到使用者空間中的這一段時間中，使用者態進程是處於阻塞的狀態的。

非阻塞式I/O模型，個人覺得這個名字可能有點混淆，並不是和阻塞式模型是完全對立的，不是說進程等不到資料，就去做別的事情，恰恰進程這個時候一直在原地等待資料的到來，與阻塞式模型不同的是，非阻塞相當於進程一直在敲門問“資料好了麼，快給我”，然後房門後的人說“沒有準備好，請稍後！”，這個過程是一種輪詢的狀態，而阻塞式是佛系的態度，敲了一次門，房門後的人沒有給任何回應，於是就去睡覺，啥都不做，直到房門後的人做出響應叫醒他，進程才去做下一步動作。

I/O複用模型

在ovs的使用者態源碼裡，就用到了I/O複用模型，在電腦網路裡面，有很多關於“複用”的用法，比如多工，意思就是本來一條鏈路上一次只能傳輸一個資料流，如果要實現兩個源之間多條資料流同時傳輸，那就得需要多條鏈路了，但是複用技術可以通過將一條鏈路劃分頻率，或者劃分傳輸的時間，使得一條鏈路上可以同時傳輸多條資料流。

套用到I/O複用模型上，可以對應到如下應用情境：如果一個進程需要等到多種不同的訊息，那麼一般的做法就是開啟多條線程，每個線程接收一類訊息，如果每個線程都是採用阻塞式I/O模型，那麼每個線程在訊息未產生的時候就會阻塞，也就是說在多線程中使用阻塞式I/O。I/O複用就是基於上述的情境中，無需採用多線程監聽訊息的方式，進程直接監聽所有的訊息類型，這其中就涉及到select、poll、epoll等不同的方法。

如所示，使用者態進程採用select的方法，通過select可以等待多個不同類型的訊息，如果其中有一個類型的訊息準備好，則select會返回資訊，然後使用者態進程調用recvfrom接收資料。

可以將select複用機制看作是一個描述符集合的管理，進程通過向這個集合中放入不同的描述符，用來等待不同的訊息產生，然後通過select統一的進行管理，讓其可以同時等待這個集合中任意一個事件的產生。

I/O複用和阻塞式I/O很相似，不同的是，I/O複用等待多類事件，阻塞式I/O只等待一類事件，另外，在I/O複用中，會產生兩個系統調用（如，select和recvfrom），而阻塞式I/O只產生一個系統調用。那麼這就涉及到具體的效能問題，當只存在一類事件的時候，使用阻塞式I/O模型的效能會更好，當存在多種不同類型的事件時，I/O複用的效能要好的多，因為阻塞式I/O模型只能監聽一類事件，所以這個時候需要使用多線程進行處理。

訊號驅動式I/O模型

在訊號驅動式I/O模型中，與阻塞式和非阻塞式有了一個本質的區別，那就是使用者態進程不再等待核心態的資料準備好，直接可以去做別的事情。

如所示，當需要等待資料的時候，首先使用者態會向核心發送一個訊號，告訴核心我要什麼資料，然後使用者態就不管了，做別的事情去了，而當核心態中的資料準備好之後，核心立馬發給使用者態一個訊號，說”資料準備好了，快來查收“，使用者態進程收到之後，立馬調用recvfrom，等待資料從核心空間複製到使用者空間，待完成之後recvfrom返回成功指示，使用者態進程才處理別的事情。

通過上面的圖，可以看出訊號驅動式I/O模型有種非同步作業的趕腳，但是在將資料從核心複製到使用者空間這段時間內使用者態進程是阻塞的

非同步I/O模型

非同步I/O模型相對於訊號驅動式I/O模型就更徹底了。

如，首先使用者態進程告訴核心態需要什麼資料（中通過aio_read），然後使用者態進程就不管了，做別的事情，核心等待使用者態需要的資料準備好，然後將資料複製到使用者空間，此時才告訴使用者態進程，”資料都已經準備好，請查收“，然後使用者態進程直接處理使用者空間的資料。

在複製資料到使用者空間這個時間段內，使用者態進程也是不阻塞的

同步I/O

《UNIX網路變成卷1：通訊端連網API》這本書中，並沒有把同步I/O作為一種單獨的I/O模型來說明，在沒有閱讀這些資料之前，我一直認為阻塞式I/O等同於同步I/O，非阻塞式I/O等同於非同步I/O，可見不能單純的通過字面意思就進行判斷。

通過對上述幾種I/O模型的描述中，可以得到一個結論：阻塞式I/O、非阻塞式I/O、I/O複用模型是同步I/O模型，因為在等待資料的過程中，這三種模型中的進程都沒有去做別的事情，即便是非阻塞式的輪詢，也可以看作是一種同步。

同時書中也認為訊號驅動式I/O模型是同步I/O，書中說到：POSIX將同步IO操作定義為“導致請求進程阻塞，直到I/O操作完成”，而書中認為在訊號驅動式I/O模型中等待資料的那段時間不算是真正的I/O操作（因為沒有調用I/O相關的系統調用），而資料從核心複製到使用者空間才是真正的I/O操作（這個時候調用了recvfrom系統調用）。

I/O模型比較

書中的這張圖表述的非常清楚，從等待資料和資料複製這兩個時間段，指出了不同I/O模型的區別，這裡不再贅述。

總結

從網上看了很多資料，不同的博主對這五個模型總結的情況不同，無一例外，基本都採用一個生活情境來描述他們的不同，但是我個人覺得有些情境描述太過簡單，沒有將不同模型的區別描述完全，在這裡我也舉一個生活中的情境作為總結，當然這隻是我自己的想法，不妥之處評論區可以指出。

我們去餐廳吃飯，會經過以下幾個步驟：首先根據菜單點菜，然後等待廚房準備好，接著服務員上菜。在這個情境中，等待廚房準備菜肴等同於等待資料，服務員上菜等同於將資料從核心複製到使用者空間，你就是使用者態進程了，服務員和飯店看作是核心態的進程。

阻塞式I/O模型：只點一個菜，然後在餐桌上開始等待，在這個過程中什麼事都不幹，等服務員把菜上到桌子上之後才開始大快朵頤。

非阻塞式I/O模型：只點一個菜，然後開始等待，啥事都不做，等了一會兒然後就去問服務員，“我的菜好了嗎？”，沒好接著等待，過了一會兒然後又跑去問....重複這個過程，直到服務員說“親，你的菜好了，我現在給您送桌上去”，然後你坐在桌子上，等待服務員把飯菜送到你的餐桌上，才開始吃飯。

I/O複用模型：你點了很多菜，然後開始等待，某個時刻其中一個菜或者多個菜廚房裡同時好了，服務員跑過來說，“親，您的有些菜好了，要現在上桌嗎？”， 你回答，現在就上，於是服務員上一個菜（服務員一次只能上一個菜），你就吃完一個，上一個你就吃完一個。。。

訊號驅動式I/O模型：只點一個菜，然後給服務員留下手機，告訴他菜準備好了打個電話給你，先不要上菜，然後你就出去玩耍了，等到菜好了，服務員手機通知你，你立馬回到了餐廳，對服務員說“你現在可以上菜了”，於是你在餐桌上等待服務員把菜送上來，然後吃飯。

非同步I/O模型：只點一個菜，然後給服務員留下手機，告訴他菜準備好了先上菜，菜上桌了打電話給你，然後你就出去玩耍了，等到菜上桌了，服務員手機通知你，你立馬回到了餐桌，開始吃飯。

參考資料

UNIX網路變成卷1：通訊端連網API
網路IO之阻塞、非阻塞、同步、非同步總結
IO - 同步，非同步，阻塞，非阻塞 （亡羊補牢篇）

segmentfault對應該博文頁面 1190000016359495