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

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

這兩組概念常常讓人迷惑,因為它們都是涉及到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操作時,函數會馬上返回不會被阻塞,當所關注的事件被觸發時會調用之前註冊的回呼函數進行處理,具體可以參見我上面的串連給出的那篇文章.回到上面的例子中,如果在銀行等待辦理業務的人採用的是非同步方式去等待訊息被觸發,也就是領了一張小紙條,假如在這段時間裡他不能離開銀行做其它的事情,那麼很顯然,這個人被阻塞在了這個等待的操作上面;但是呢,這個人突然發覺自己煙癮犯了,需要出去抽根煙,於是他告訴大堂經理說,排到我這個號碼的時候麻煩到外面通知我一下(註冊一個回呼函數),那麼他就沒有被阻塞在這個等待的操作上面,自然這個就是非同步+非阻塞的方式了.