同步/異步 與 阻塞/非阻塞的區別

轉貼地址：http://www.cppblog.com/converse/archive/2009/05/13/82879.html

#######################

//聲明： 1  本帖做者是：那誰的技術博客，至此感謝！

#######################

同步/異步 與 阻塞/非阻塞的區別

我喜歡用本身的語言經過聯繫現實生活中的一些現象解釋一些概念,當我能作到這一點時,說明我已經理解了這個概念.今天要解釋的概念是:同步/異步與阻塞/非阻塞的區別.

這兩組概念經常讓人迷惑,由於它們都是涉及到IO處理,同時又有着一些相相似的地方.

首先來解釋同步和異步的概念,這兩個概念與消息的通知機制有關.

舉個例子,好比我去銀行辦理業務,可能選擇排隊等候,也可能取一個小紙條上面有個人號碼,等到排到我這一號時由櫃檯的人通知我輪到我去辦理業務了.
前者(排隊等候)就是同步等待消息,然後者(等待別人通知)就是異步等待消息.在異步消息處理中,等待消息者(在這個例子中就是等待辦理業務的人)每每註冊一個回調機制,在所等待的事件被觸發時由觸發機制(在這裏是櫃檯的人)經過某種機制(在這裏是寫在小紙條上的號碼)找到等待該事件的人.
而在實際的程序中,同步消息處理就比如簡單的read/write操做,它們須要等待這兩個操做成功才能返回;而異步處理機制就是相似於select/poll之類的多路複用IO操做,當所關注的消息被觸發時,由消息觸發機制通知觸發對消息的處理.

其次再來解釋一下阻塞和非阻塞,這兩個概念與程序等待消息(無所謂同步或者異步)時的狀態有關.
繼續上面的那個例子,不管是排隊仍是使用號碼等待通知,若是在這個等待的過程當中,等待者除了等待消息以外不能作其它的事情,那麼該機制就是阻塞的,表如今程序中,也就是該程序一直阻塞在該函數調用處不能繼續往下執行.相反,有的人喜歡在銀行辦理這些業務的時候一邊打打電話發發短信一邊等待,這樣的狀態就是非阻塞的,由於他(等待者)沒有阻塞在這個消息通知上,而是一邊作本身的事情一邊等待.可是須要注意了,第一種同步非阻塞形式其實是效率低下的,想象一下你一邊打着電話一邊還須要擡頭看到底隊伍排到你了沒有,若是把打電話和觀察排隊的位置當作是程序的兩個操做的話,這個程序須要在這兩種不一樣的行爲之間來回的切換,效率可想而知是低下的;然後者,異步非阻塞形式卻沒有這樣的問題,由於打電話是你(等待者)的事情,而通知你則是櫃檯(消息觸發機制)的事情,程序沒有在兩種不一樣的操做中來回切換.

不少人會把同步和阻塞混淆,我想是由於不少時候同步操做會以阻塞的形式表現出來,好比不少人會寫阻塞的read/write操做,可是別忘了能夠對fd設置O_NONBLOCK標誌位,這樣就能夠將同步操做變成非阻塞的了;一樣的,不少人也會把異步和非阻塞混淆,由於異步操做通常都不會在真正的IO操做處被阻塞,好比若是用select函數,當select返回可讀時再去read通常都不會被阻塞,就比如當你的號碼排到時通常都是在你以前已經沒有人了,因此你再去櫃檯辦理業務就不會被阻塞.

可見,同步/異步與阻塞/非阻塞是兩組不一樣的概念,它們能夠共存組合,也能夠參見這裏:
http://www.ibm.com/developerworks/cn/linux/l-async/（強烈推薦去看看）

----------------------------------------- 分割線 ------------------------------------------------------
昨晚寫完這篇文章以後,今早來看了看反饋,同時再本身閱讀了幾遍,發現仍是有一些地方解釋的不夠清楚,在這裏繼續補充完善一下個人說法,希望沒有越說越糊塗.

同步和異步:上面提到過,同步和異步僅僅是關於所關注的消息如何通知的機制,而不是處理消息的機制.也就是說,同步的狀況下,是由處理消息者本身去等待消息是否被觸發,而異步的狀況下是由觸發機制來通知處理消息者,因此在異步機制中,處理消息者和觸發機制之間就須要一個鏈接的橋樑,在咱們舉的例子中這個橋樑就是小紙條上面的號碼,而在select/poll等IO多路複用機制中就是fd,當消息被觸發時,觸發機制經過fd找處處理該fd的處理函數.

請注意理解消息通知和處理消息這兩個概念,這是理解這個問題的關鍵所在.仍是回到上面的例子,輪到你辦理業務這個就是你關注的消息,而去辦理業務就是對這個消息的處理,二者是有區別的.而在真實的IO操做時,所關注的消息就是該fd是否可讀寫,而對消息的處理就是對這個fd進行讀寫.同步/異步僅僅關注的是如何通知消息,它們對如何處理消息並不關心,比如說,銀行的人僅僅通知你輪到你辦理業務了,而如何辦理業務他們是不知道的.

而不少人之因此把同步和阻塞混淆,我想也是由於沒有區分這兩個概念,好比阻塞的read/write操做中,實際上是把消息通知和處理消息結合在了一塊兒,在這裏所關注的消息就是fd是否可讀/寫,而處理消息則是對fd讀/寫.當咱們將這個fd設置爲非阻塞的時候,read/write操做就不會在等待消息通知這裏阻塞,若是fd不可讀/寫則操做當即返回.

不少人又會問了,異步操做不會是阻塞的吧?已經通知了有消息能夠處理了就必定不是阻塞的了吧?
其實異步操做是能夠被阻塞住的,只不過一般不是在處理消息時阻塞,而是在等待消息被觸發時被阻塞.好比select函數,假如傳入的最後一個timeout參數爲NULL,那麼若是所關注的事件沒有一個被觸發,程序就會一直阻塞在這個select調用處.而若是使用異步非阻塞的狀況,好比aio_*組的操做,當我發起一個aio_read操做時,函數會立刻返回不會被阻塞,當所關注的事件被觸發時會調用以前註冊的回調函數進行處理,具體能夠參見我上面的鏈接給出的那篇文章.回到上面的例子中,若是在銀行等待辦理業務的人採用的是異步的方式去等待消息被觸發,也就是領了一張小紙條,假如在這段時間裏他不能離開銀行作其它的事情,那麼很顯然,這我的被阻塞在了這個等待的操做上面;可是呢,這我的忽然發覺本身煙癮犯了,須要出去抽根菸,因而他告訴大堂經理說,排到我這個號碼的時候麻煩到外面通知我一下(註冊一個回調函數),那麼他就沒有被阻塞在這個等待的操做上面,天然這個就是異步+非阻塞的方式了. 

嘯天豬：

個人理解：

同步： '你'親自辦這件事
異步： 交代要作的事情，而後忙其餘的事情；'別人'(內核)會充當你的跑腿，在條件就緒後將這事辦成，而後通知你(callback)；

阻塞： 若是條件未就緒，'你'必須死等它就緒;進程睡眠
非阻塞：若是條件未就緒，'你'能夠轉身道別的事情;進程能夠做任何想作的事情，不過一般是低效的輪詢。

以這種理解方式，阻塞/非阻塞只對同步操做有意義；異步I/O老是意味着進程不會由於I/O陷入睡眠。

將" select"歸類爲異步+blocking不妥，select實際上完成的只是read/write的第一部分：等待條件就緒；惟一的改進是能夠等待多個條件。"select + read/write"的調用形式容易產生"系統通知我條件就緒"的假象，可實際上你不過是在條件就緒的時候醒來，而後仍然親自動手完成了數據複製的操做。

依然使用銀行的隱喻：

櫃檯R：只能取款
櫃檯W：只能存款

read: 親自在櫃檯R排隊(進程睡眠) + 取款
write: 親自在櫃檯W排隊(進程睡眠) + 存款

select + read/write : 親自同時在R、W兩個櫃檯排隊(進程睡眠) + (存款|取款|存款+取款)

AIO : 告訴心腹小弟要取款若干，而後忙別的事情；小弟取款完畢將其如數奉上。

UNP一書中6.2節對I/O模型的分類我以爲很合理：

1).read/write、read + NON_BLOCK、select、signal driven I/O 都屬於同步I/O; 它們的共同特色是：將數據從內核空間複製到到用戶空間的這個操做，是由用戶空間的代碼顯式發起的。

2).只有AIO 屬於 異步I/O；內核不露聲色的將數據從內核空間複製到用戶空間，而後通知進程。

那誰（原創者）：

@嘯天豬

我看了一下你的評論,我想咱們之間觀點最大的分歧點在於:

個人觀點是同步/異步僅是消息通知的機制,至於消息到來時如何處理與這兩個概念無關.

而你的觀點則認爲,同步/異步不只僅包括消息通知,還包括了對消息的處理,因此select之類的通知消息的觸發機制你歸類爲"同步",而AIO這種俘獲了消息也對消息進行了處理(好比你說的將數據從內核copy到用戶態)的機制纔是真正的異步.

也就是說,你上面回覆的這句話:
異步： 交代要作的事情，而後忙其餘的事情；'別人'(內核)會充當你的跑腿，在條件就緒後將這事辦成，而後通知你(callback)；

事實上是咱們之間對這個概念認知的最大分歧,你認爲異步就是不止通知了消息,還要加上將這件事情辦妥.而我認爲,異步僅在於通知這個消息發生了,而具體如何處理該消息不在它關注的範圍以內.

我在寫上上面這段評論的時候也在思考對這個概念的理解,我仍是認爲個人觀點是正確的,今天太晚了,改天找來UNP詳細看看.