Windows伺服器端編程－第二章 裝置IO與線程通訊－5－I/O完成連接埠

l       I/O完成連接埠

Windows2000被設計成為一個安全的，健壯的，能夠服務於數千個使用者的作業系統。根據以往來看，通常使用以下兩種模型之一編寫服務應用程式：

 

l       串列模型

線程等待用戶端的請求(通常通過網路)。當請求到達，線程醒來並處理用戶端的請求。

 

l       並行模型

線程等待用戶端的請求併產生一個新線程來處理請求。在新線程在處理用戶端的請求時，老的線程迴圈處理另一個用戶端的請求。新線程在完全處理完用戶端的請求後退出。

 

串列模型的問題在於不能很好的處理多重的、並發的請求。如果兩個用戶端同時發出請求，一次僅能夠處理一個；第二個請求必須等待第一個請求完成。設計成串列模型的服務應用程式在多處理器的機器上沒有優勢。很明顯，串列模型用於簡單的伺服器應用程式比較好，較少的用戶端串連使得請求能較快的被處理。Ping服務就是串列模型伺服器應用程式的好例子。

 

       由於串列模型的局限性，並行模型極其流行。在並行模型下，建立一個線程用來處理所有用戶端的請求。其優勢在於等待請求到來的線程僅有很少一點工作要做。大多數時候，線程在休眠。當用戶端請求到來，線程醒來，建立新的線程來處理請求，然後等待另一個串連。這意味著進入的用戶端請求可以被很方便的處理。並且，由於每個用戶端請求有自己的處理線程，伺服器應用程式能夠進行很好的伸縮，在多處理器的機器上更有優勢。因此在使用並行模型的情況下，升級硬體(添加CPU)，伺服器應用程式的效能也跟著提升。

 

       並行模型的服務應用程式是在Windows下實現的。Windows小組注意到意味其效能並不像期望那樣高。特別地，Windows小組注意到對大量並發用戶端請求的處理意味著在系統中有大量的線程在同時運行。由於所有的線程都是可啟動並執行(沒有掛起和等待某些東西發生)，微軟意識到Windows的核心花費了太多時間在運行線程的環境切換上，以至於線程沒有足夠的時間來幹活。為了使Windows有一個令人信服的伺服器運行環境，微軟需要解決這個問題。結果就是I/O完成連接埠核心對象。