網絡編程學習和實踐的過程中,同步(synchronous)/異步(asynchronous)與阻塞(blocking)/非阻塞(non-blocking)總是會迷惑很多人。依然記得我半年之前在記述IOCP時,一句不經意的“非阻塞I/O則是致力于提供高效的異步I/O”便引來一番口水論爭。
今天在查一些資料的時候,看到關于這幾個詞的論辯竟不是一般的多,細細想來,這個問題似乎也確實有解釋的必要,不在于爭論對錯,而在于辨明是非。
討論之前,先限定討論的范圍:此處之同步/異步僅限于I/O操作,與OS所討論的進程/線程中的其他同步/異步沒有直接關系;討論的內容是:兩對相似的術語之間的區別到底有多大。
- 非常大:
Douglas C. Schmidt在《C++網絡編程》中這樣說到:
They are very different, as follows:
AIO is "asynchronous I/O", i.e., the operation is invoked asynchronously and control returns to the client while the OS kernel processes the I/O request. When the operation completes there is some mechanism for the client to retrieve the results.
Non-blocking I/O tries an operation (such as a read() or write()) and if it the operation would block (e.g., due to flow control on a TCP connection or due to lack of data in a socket), the call returns -1 and sets errno to EWOULDBLOCK.
翻譯如下:
異步I/O:例如,操作被異步調用時,控制權交給客戶端,I/O操作請求則交由操作系統內核處理,當操作完成后,通過某種機制將結果通知客戶端。
非阻塞I/O:嘗試調用某操作,如果操作被阻塞,則調用返回-1并置錯誤值為EWOULDBLOCK。
從這兩段“very different”的解釋來看,我的感覺是并沒有指出二者的區別,因為我們無法確定所謂AIO是如何處理的,如果AIO直接“調用返回-1并置錯誤值為EWOULDBLOCK”,實現“控制權交給客戶端”,似乎并無任何不妥。況且,對于非阻塞I/O,我們也需要“當操作完成后,通過某種機制將結果通知客戶端”這樣的處理。
- 無差別:
而在Wikipedia上則直接等同二者:Asynchronous I/O, or non-blocking I/O, is a form of input/output processing that permits other processing to continue before the transmission has finished.
當然,對于recv和send,我們一般會說他們是阻塞起的,而不會說他們是同步起的,但這顯然不是二者的區別,因為我們都知道,阻塞的原因正是等待同步結果的返回。
因此,二者的區別在于,阻塞/非阻塞是表現,同步/異步是原因,我們說某某操作是阻塞起的,或者某某線程是阻塞起的,是因為在等待操作結果的同步返回;我們說某某操作是非阻塞的,是因為操作結果會通過異步方式返回。
討論到這兒,再咬文嚼字的爭辯下去似乎已經沒有任何實際意義。
------------------------------------------------------------
PS:糾結一些必要的概念是為了加深理解,太過糾結了反倒會滯塞理解。我之前對于其概念也并非特別清楚,所以才會再續一篇特意言明,也算彌補一下自己的過失。