同步
　　所謂同步，就是在發(fā)出一個功能調用時，在沒有得到結果之前，該調用就不返回。按照這個定義，其實絕大多數(shù)函數(shù)都是同步調用（例如sin, isdigit等）。但是一般而言，我們在說同步、異步的時候，特指那些需要其他部件協(xié)作或者需要一定時間完成的任務。最常見的例子就是 SendMessage。該函數(shù)發(fā)送一個消息給某個窗口，在對方處理完消息之前，這個函數(shù)不返回。當對方處理完畢以后，該函數(shù)才把消息處理函數(shù)所返回的 LRESULT值返回給調用者。

異步
　　異步的概念和同步相對。當一個異步過程調用發(fā)出后，調用者不能立刻得到結果。實際處理這個調用的部件在完成后，通過狀態(tài)、通知和回調來通知調用者。以 CAsycSocket類為例（注意，CSocket從CAsyncSocket派生，但是起功能已經由異步轉化為同步），當一個客戶端通過調用 Connect函數(shù)發(fā)出一個連接請求后，調用者線程立刻可以朝下運行。當連接真正建立起來以后，socket底層會發(fā)送一個消息通知該對象。這里提到執(zhí)行 部件和調用者通過三種途徑返回結果：狀態(tài)、通知和回調。可以使用哪一種依賴于執(zhí)行部件的實現(xiàn)，除非執(zhí)行部件提供多種選擇，否則不受調用者控制。如果執(zhí)行部 件用狀態(tài)來通知，那么調用者就需要每隔一定時間檢查一次，效率就很低（有些初學多線程編程的人，總喜歡用一個循環(huán)去檢查某個變量的值，這其實是一種很嚴重 的錯誤）。如果是使用通知的方式，效率則很高，因為執(zhí)行部件幾乎不需要做額外的操作。至于回調函數(shù)，其實和通知沒太多區(qū)別。

阻塞
　　阻塞調用是指調用結果返回之前，當前線程會被掛起。函數(shù)只有在得到結果之后才會返回。有人也許會把阻塞調用和同步調用等同起來，實際上他是不同的。對于同 步調用來說，很多時候當前線程還是激活的，只是從邏輯上當前函數(shù)沒有返回而已。例如，我們在CSocket中調用Receive函數(shù)，如果緩沖區(qū)中沒有數(shù) 據(jù)，這個函數(shù)就會一直等待，直到有數(shù)據(jù)才返回。而此時，當前線程還會繼續(xù)處理各種各樣的消息。如果主窗口和調用函數(shù)在同一個線程中，除非你在特殊的界面操 作函數(shù)中調用，其實主界面還是應該可以刷新。socket接收數(shù)據(jù)的另外一個函數(shù)recv則是一個阻塞調用的例子。當socket工作在阻塞模式的時候， 如果沒有數(shù)據(jù)的情況下調用該函數(shù)，則當前線程就會被掛起，直到有數(shù)據(jù)為止。

非阻塞
　　非阻塞和阻塞的概念相對應，指在不能立刻得到結果之前，該函數(shù)不會阻塞當前線程，而會立刻返回。

　　對象的阻塞模式和阻塞函數(shù)調用
　　對象是否處于阻塞模式和函數(shù)是不是阻塞調用有很強的相關性，但是并不是一一對應的。阻塞對象上可以有非阻塞的調用方式，我們可以通過一定的API去輪詢狀 態(tài)，在適當?shù)臅r候調用阻塞函數(shù)，就可以避免阻塞。而對于非阻塞對象，調用特殊的函數(shù)也可以進入阻塞調用。函數(shù)select就是這樣的一個例子。

在Winsock中實現(xiàn)異步的方法有很多，Winsock的IO模型有下面六種
??? 一：select模型
??? 二：WSAAsyncSelect模型
??? 三：WSAEventSelect模型
??? 四：Overlapped I/O 事件通知模型
??? 五：Overlapped I/O 完成例程模型
??? 六：IOCP模型
從一到六越來越高級，越來越高效，實現(xiàn)越來越復雜。


曾在網上看到一些比喻用來很好的說明這些模型，在這里引用一下。
老陳有一個在外地工作的女兒，不能經常回來，老陳和她通過信件聯(lián)系。他們的信會被郵遞員投遞到他們的信箱里。
一：select模型

老陳非常想看到女兒的信。以至于他每隔10分鐘就下樓檢查信箱，看是否有女兒的信~~~~~
在這種情況下，“下樓檢查信箱”然后回到樓上耽誤了老陳太多的時間，以至于老陳無法做其他工作。

二：WSAAsyncSelect模型

后來，老陳使用了微軟公司的新式信箱。這種信箱非常先進，一旦信箱里有新的信件，蓋茨就會給老陳打電話：喂，大爺，你有新的信件了！從此，老陳再也不必頻繁上下樓檢查信箱了，牙也不疼了，你瞅準了，藍天......不是，微軟~~~~~~~~

三：WSAEventSelect模型

后來，微軟的信箱非常暢銷，購買微軟信箱的人以百萬計數(shù)......以至于蓋茨每天24小時給客戶打電話，累得腰酸背痛，喝蟻力神都不好使~~~~~~
微軟改進了他們的信箱：在客戶的家中添加一個附加裝置，這個裝置會監(jiān)視客戶的信箱，每當新的信件來臨，此裝置會發(fā)出“新信件到達”聲，提醒老陳去收信。蓋茨終于可以睡覺了。

四：Overlapped I/O 事件通知模型

后來，微軟通過調查發(fā)現(xiàn)，老陳不喜歡上下樓收發(fā)信件，因為上下樓其實很浪費時間。于是微軟再次改進他們的信箱。新式的信箱采用了更為先進的技術，只要用戶告訴微軟自己的家在幾樓幾號，新式信箱會把信件直接傳送到用戶的家中，然后告訴用戶，你的信件已經放到你的家中了！老陳很高興，因為他不必再親自收發(fā)信件了！

五：Overlapped I/O 完成例程模型

老陳接收到新的信件后，一般的程序是：打開信封----掏出信紙----閱讀信件----回復信件......為了進一步減輕用戶負擔，微軟又開發(fā)了一種新的技術：用戶只要告訴微軟對信件的操作步驟，微軟信箱將按照這些步驟去處理信件，不再需要用戶親自拆信/閱讀/回復了！老陳終于過上了小資生活！

六：IOCP模型

微軟信箱似乎很完美，老陳也很滿意。但是在一些大公司情況卻完全不同！這些大公司有數(shù)以萬計的信箱，每秒鐘都有數(shù)以百計的信件需要處理，以至于微軟信箱經常因超負荷運轉而崩潰！需要重新啟動！微軟不得不使出殺手锏......
微軟給每個大公司派了一名名叫“Completion Port”的超級機器人，讓這個機器人去處理那些信件！

其實，上面每種模型都有優(yōu)點，要根據(jù)程序需求而適當選擇合適的模型，前面三種模型效率已經比較高，實現(xiàn)起來難道不大，很多一般的網絡程序都采用前三種模型，只有對網絡要求特別高的一些服務器才會考慮用后面的那些模型。MFC中的CAsyncSocket類就是用的WSAAsyncSelect模型，電驢中也是用的這種，不過在尋找對應socket的時候進行了優(yōu)化，查找更快，在GridCast中采用的是WSAEventSelect模型，等待。

轉載：點擊打開鏈接

總結

以上是生活随笔為你收集整理的Windows I/O模型、同步/异步、阻塞/非阻塞的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。