• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆-4  評論-40  文章-117  trackbacks-0
            同步(synchronous) IO和異步(asynchronous) IO,阻塞(blocking) IO和非阻塞(non-blocking)IO分別是什么,到底有什么區別?這個問題其實不同的人給出的答案都可能不同,比如wiki,就認為asynchronous IO和non-blocking IO是一個東西。這其實是因為不同的人的知識背景不同,并且在討論這個問題的時候上下文(context)也不相同。所以,為了更好的回答這個問題,我先限定一下本文的上下文。
            本文討論的背景是Linux環境下的network IO。
            本文最重要的參考文獻是Richard Stevens的“UNIX® Network Programming Volume 1, Third Edition: The Sockets Networking ”,6.2節“I/O Models ”,Stevens在這節中詳細說明了各種IO的特點和區別,如果英文夠好的話,推薦直接閱讀。Stevens的文風是有名的深入淺出,所以不用擔心看不懂。本文中的流程圖也是截取自參考文獻。

            Stevens在文章中一共比較了五種IO Model:
                blocking IO
                nonblocking IO
                IO multiplexing
                signal driven IO
                asynchronous IO
            由于signal driven IO在實際中并不常用,所以我這只提及剩下的四種IO Model。

            再說一下IO發生時涉及的對象和步驟。
            對于一個network IO (這里我們以read舉例),它會涉及到兩個系統對象,一個是調用這個IO的process (or thread),另一個就是系統內核(kernel)。當一個read操作發生時,它會經歷兩個階段:
            1 等待數據準備 (Waiting for the data to be ready)
            2 將數據從內核拷貝到進程中 (Copying the data from the kernel to the process)
            記住這兩點很重要,因為這些IO Model的區別就是在兩個階段上各有不同的情況。

            blocking IO
            在linux中,默認情況下所有的socket都是blocking,一個典型的讀操作流程大概是這樣:


            當用戶進程調用了recvfrom這個系統調用,kernel就開始了IO的第一個階段:準備數據。對于network io來說,很多時候數據在一開始還沒有到達(比如,還沒有收到一個完整的UDP包),這個時候kernel就要等待足夠的數據到來。而在用戶進程這邊,整個進程會被阻塞。當kernel一直等到數據準備好了,它就會將數據從kernel中拷貝到用戶內存,然后kernel返回結果,用戶進程才解除block的狀態,重新運行起來。
            所以,blocking IO的特點就是在IO執行的兩個階段都被block了。

            non-blocking IO

            linux下,可以通過設置socket使其變為non-blocking。當對一個non-blocking socket執行讀操作時,流程是這個樣子:


            從圖中可以看出,當用戶進程發出read操作時,如果kernel中的數據還沒有準備好,那么它并不會block用戶進程,而是立刻返回一個error。從用戶進程角度講 ,它發起一個read操作后,并不需要等待,而是馬上就得到了一個結果。用戶進程判斷結果是一個error時,它就知道數據還沒有準備好,于是它可以再次發送read操作。一旦kernel中的數據準備好了,并且又再次收到了用戶進程的system call,那么它馬上就將數據拷貝到了用戶內存,然后返回。
            所以,用戶進程其實是需要不斷的主動詢問kernel數據好了沒有。

            IO multiplexing

            IO multiplexing這個詞可能有點陌生,但是如果我說select,epoll,大概就都能明白了。有些地方也稱這種IO方式為event driven IO。我們都知道,select/epoll的好處就在于單個process就可以同時處理多個網絡連接的IO。它的基本原理就是select/epoll這個function會不斷的輪詢所負責的所有socket,當某個socket有數據到達了,就通知用戶進程。它的流程如圖:


            當用戶進程調用了select,那么整個進程會被block,而同時,kernel會“監視”所有select負責的socket,當任何一個socket中的數據準備好了,select就會返回。這個時候用戶進程再調用read操作,將數據從kernel拷貝到用戶進程。
            這個圖和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。

            Asynchronous I/O

            linux下的asynchronous IO其實用得很少。先看一下它的流程:


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

            到目前為止,已經將四個IO Model都介紹完了。現在回過頭來回答最初的那幾個問題:blocking和non-blocking的區別在哪,synchronous IO和asynchronous IO的區別在哪。
            先回答最簡單的這個:blocking vs non-blocking。前面的介紹中其實已經很明確的說明了這兩者的區別。調用blocking IO會一直block住對應的進程直到操作完成,而non-blocking IO在kernel還準備數據的情況下會立刻返回。

            在說明synchronous IO和asynchronous IO的區別之前,需要先給出兩者的定義。Stevens給出的定義(其實是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操作的狀態,也不需要主動的去拷貝數據。

            最后,再舉幾個不是很恰當的例子來說明這四個IO Model:
            有A,B,C,D四個人在釣魚:
            A用的是最老式的魚竿,所以呢,得一直守著,等到魚上鉤了再拉桿;
            B的魚竿有個功能,能夠顯示是否有魚上鉤,所以呢,B就和旁邊的MM聊天,隔會再看看有沒有魚上鉤,有的話就迅速拉桿;
            C用的魚竿和B差不多,但他想了一個好辦法,就是同時放好幾根魚竿,然后守在旁邊,一旦有顯示說魚上鉤了,它就將對應的魚竿拉起來;
            D是個有錢人,干脆雇了一個人幫他釣魚,一旦那個人把魚釣上來了,就給D發個短信。

            原帖地址:http://blog.csdn.net/historyasamirror/archive/2010/07/31/5778378.aspx

            posted on 2012-02-09 13:52 李陽 閱讀(416) 評論(0)  編輯 收藏 引用 所屬分類: Linux
            久久精品国产色蜜蜜麻豆| 久久偷看各类wc女厕嘘嘘| 色综合久久久久| 国产精品日韩欧美久久综合| 久久乐国产精品亚洲综合| 久久午夜福利无码1000合集| 久久久久亚洲av无码专区导航| 欧美久久综合性欧美| 久久无码高潮喷水| 美女写真久久影院| 久久午夜夜伦鲁鲁片免费无码影视| 国内精品久久久人妻中文字幕| 欧洲国产伦久久久久久久| 日韩精品久久久肉伦网站| 欧美激情精品久久久久久久九九九| 伊人久久精品无码av一区| 国产成人精品久久免费动漫| 香蕉久久夜色精品国产2020| 久久99久久99精品免视看动漫| 区亚洲欧美一级久久精品亚洲精品成人网久久久久 | 久久久噜噜噜久久中文字幕色伊伊 | 亚洲日本va午夜中文字幕久久| 亚洲国产精品无码久久久蜜芽| 久久激情亚洲精品无码?V| 久久九九精品99国产精品| 精品久久久久久久久免费影院| 亚洲乱亚洲乱淫久久| 久久精品aⅴ无码中文字字幕不卡| 久久精品国产精品亚洲人人| 久久国产精品久久| 久久精品夜夜夜夜夜久久| 99久久精品免费看国产一区二区三区 | 亚洲Av无码国产情品久久| 久久精品国产福利国产秒| 色婷婷综合久久久久中文| 国产69精品久久久久9999APGF | 久久久久久亚洲精品不卡 | 99久久精品九九亚洲精品| 国产精品一久久香蕉产线看| 国产精品9999久久久久| 粉嫩小泬无遮挡久久久久久|