Windows I/O模型、同步/非同步、阻塞/非阻塞
同步
所謂同步,就是在發出一個功能呼叫時,在沒有得到結果之前,該呼叫就不返回。按照這個定義,其實絕大多數函式都是同步呼叫(例如sin, isdigit等)。但是一般而言,我們在說同步、非同步的時候,特指那些需要其他部件協作或者需要一定時間完成的任務。最常見的例子就是 SendMessage。該函式傳送一個訊息給某個視窗,在對方處理完訊息之前,這個函式不返回。當對方處理完畢以後,該函式才把訊息處理函式所返回的 LRESULT值返回給呼叫者。
非同步
非同步的概念和同步相對。當一個非同步過程呼叫發出後,呼叫者不能立刻得到結果。實際處理這個呼叫的部件在完成後,通過狀態、通知和回撥來通知呼叫者。以 CAsycSocket類為例(注意,CSocket從CAsyncSocket派生,但是起功能已經由非同步轉化為同步),當一個客戶端通過呼叫 Connect函式發出一個連線請求後,呼叫者執行緒立刻可以朝下執行。當連線真正建立起來以後,socket底層會發送一個訊息通知該物件。這裡提到執行 部件和呼叫者通過三種途徑返回結果:狀態、通知和回撥。可以使用哪一種依賴於執行部件的實現,除非執行部件提供多種選擇,否則不受呼叫者控制。如果執行部 件用狀態來通知,那麼呼叫者就需要每隔一定時間檢查一次,效率就很低(有些初學多執行緒程式設計的人,總喜歡用一個迴圈去檢查某個變數的值,這其實是一種很嚴重 的錯誤)。如果是使用通知的方式,效率則很高,因為執行部件幾乎不需要做額外的操作。至於回撥函式,其實和通知沒太多區別。
阻塞
阻塞呼叫是指呼叫結果返回之前,當前執行緒會被掛起。函式只有在得到結果之後才會返回。有人也許會把阻塞呼叫和同步呼叫等同起來,實際上他是不同的。對於同 步呼叫來說,很多時候當前執行緒還是啟用的,只是從邏輯上當前函式沒有返回而已。例如,我們在CSocket中呼叫Receive函式,如果緩衝區中沒有數 據,這個函式就會一直等待,直到有資料才返回。而此時,當前執行緒還會繼續處理各種各樣的訊息。如果主視窗和呼叫函式在同一個執行緒中,除非你在特殊的介面操 作函式中呼叫,其實主介面還是應該可以重新整理。socket接收資料的另外一個函式recv則是一個阻塞呼叫的例子。當socket工作在阻塞模式的時候, 如果沒有資料的情況下呼叫該函式,則當前執行緒就會被掛起,直到有資料為止。
非阻塞
非阻塞和阻塞的概念相對應,指在不能立刻得到結果之前,該函式不會阻塞當前執行緒,而會立刻返回。
物件的阻塞模式和阻塞函式呼叫
物件是否處於阻塞模式和函式是不是阻塞呼叫有很強的相關性,但是並不是一一對應的。阻塞物件上可以有非阻塞的呼叫方式,我們可以通過一定的API去輪詢狀 態,在適當的時候呼叫阻塞函式,就可以避免阻塞。而對於非阻塞物件,呼叫特殊的函式也可以進入阻塞呼叫。函式select就是這樣的一個例子。
在Winsock中實現非同步的方法有很多,Winsock的IO模型有下面六種
一:select模型
二:WSAAsyncSelect模型
三:WSAEventSelect模型
四:Overlapped I/O 事件通知模型
五:Overlapped I/O 完成例程模型
六:IOCP模型
從一到六越來越高階,越來越高效,實現越來越複雜。
曾在網上看到一些比喻用來很好的說明這些模型,在這裡引用一下。
老陳有一個在外地工作的女兒,不能經常回來,老陳和她通過信件聯絡。他們的信會被郵遞員投遞到他們的信箱裡。
一:select模型
老陳非常想看到女兒的信。以至於他每隔10分鐘就下樓檢查信箱,看是否有女兒的信~~~~~
在這種情況下,“下樓檢查信箱”然後回到樓上耽誤了老陳太多的時間,以至於老陳無法做其他工作。
二:WSAAsyncSelect模型
後來,老陳使用了微軟公司的新式信箱。這種信箱非常先進,一旦信箱裡有新的信件,蓋茨就會給老陳打電話:喂,大爺,你有新的信件了!從此,老陳再也不必頻繁上下樓檢查信箱了,牙也不疼了,你瞅準了,藍天......不是,微軟~~~~~~~~
三:WSAEventSelect模型
後來,微軟的信箱非常暢銷,購買微軟信箱的人以百萬計數......以至於蓋茨每天24小時給客戶打電話,累得腰痠背痛,喝蟻力神都不好使~~~~~~
微軟改進了他們的信箱:在客戶的家中新增一個附加裝置,這個裝置會監視客戶的信箱,每當新的信件來臨,此裝置會發出“新信件到達”聲,提醒老陳去收信。蓋茨終於可以睡覺了。
四:Overlapped I/O 事件通知模型
後來,微軟通過調查發現,老陳不喜歡上下樓收發信件,因為上下樓其實很浪費時間。於是微軟再次改進他們的信箱。新式的信箱採用了更為先進的技術,只要使用者告訴微軟自己的家在幾樓幾號,新式信箱會把信件直接傳送到使用者的家中,然後告訴使用者,你的信件已經放到你的家中了!老陳很高興,因為他不必再親自收發信件了!
五:Overlapped I/O 完成例程模型
老陳接收到新的信件後,一般的程式是:開啟信封----掏出信紙----閱讀信件----回覆信件......為了進一步減輕使用者負擔,微軟又開發了一種新的技術:使用者只要告訴微軟對信件的操作步驟,微軟信箱將按照這些步驟去處理信件,不再需要使用者親自拆信/閱讀/回覆了!老陳終於過上了小資生活!
六:IOCP模型
微軟信箱似乎很完美,老陳也很滿意。但是在一些大公司情況卻完全不同!這些大公司有數以萬計的信箱,每秒鐘都有數以百計的信件需要處理,以至於微軟信箱經常因超負荷運轉而崩潰!需要重新啟動!微軟不得不使出殺手鐗......
微軟給每個大公司派了一名名叫“Completion Port”的超級機器人,讓這個機器人去處理那些信件!
其實,上面每種模型都有優點,要根據程式需求而適當選擇合適的模型,前面三種模型效率已經比較高,實現起來難道不大,很多一般的網路程式都採用前三種模型,只有對網路要求特別高的一些伺服器才會考慮用後面的那些模型。MFC中的CAsyncSocket類就是用的WSAAsyncSelect模型,電驢中也是用的這種,不過在尋找對應socket的時候進行了優化,查詢更快,在GridCast中採用的是WSAEventSelect模型,等待。
posted on 2006-04-20 17:25 楊粼波 閱讀(2037) 評論(0) 編輯 收藏 引用 所屬分類: 網路程式設計