程序依葫蘆畫瓢原作者的程序，代碼雷同度達90%（后面有下載地址），想自己添加些新的功能（添加可以查看I/O處理進度的功能），但迫于時間，沒有完成�，F(xiàn)在我上網(wǎng)是非常困難的，但對我來說也好，這樣就有更多的時間看看書，少上上網(wǎng)了。
純概念性程序，也沒有截圖 下載：http://down.cr173.com/soft1/CopyFileSources.rar
要想編寫一個高性能的服務(wù)器應(yīng)用程序，必須實現(xiàn)一個高效的線程模型。讓太少或者太多的服務(wù)器線程來處理客戶的請求，都可能導(dǎo)致性能問題。例如，如果一個服務(wù)器創(chuàng)建單個線程來處理所有的請求，那么客戶端可能長期等待而得不到響應(yīng)，因為服務(wù)器同一時刻只能忙于處理一個請求。當然單個線程也能并發(fā)處理多個請求，當I/O操作被啟動時，它可以從一個請求切換到另一個請求，但是這種結(jié)構(gòu)相當復(fù)雜，并且不能充分利用多處理器的優(yōu)勢。在另一個極端，服務(wù)器可以創(chuàng)建一個大規(guī)模的線程池，這樣幾乎每一個客戶請求都可以由一個專門的線程來處理。這種情形通常會導(dǎo)致線程頻繁切換：大量線程被喚醒，執(zhí)行CPU處理，阻塞等待I/O，然后在請求完成之后又一次阻塞以等待新的請求。如果沒有別的情況，太多的線程將導(dǎo)致過多的上下文切換，因為調(diào)度程序不得不將處理器時間在多個活動線程之間分割。
服務(wù)器的目標是使線程避免不必要的阻塞，盡量減少上下文切換。同時，還要使用多線程來發(fā)揮最大限度的并行。理想的情況是在每一個處理器上運行一個線程來處理一個客戶請求，當處理器上的活動線程完成一個請求時，如果還有其他的請求正在等待，則不阻塞。為了使這一優(yōu)化處理可以有效的進行，應(yīng)用程序必須有一種可行的方法，使得一個正在處理客戶請求的線程在I/O上阻塞時（例如它在處理過程中需要讀取一個文件時）另外一個等待線程被激活。
Windows NT 3.5引進了一系列API使得這個目標的實現(xiàn)變得相對容易。這些API主要聚焦在一個叫完成端口的對象上。在本文中，首先我將講解完成端口的使用，然后再深入其內(nèi)部，向你展示W(wǎng)indows NT中完成端口的實現(xiàn)機制。
喜歡 
頂
難過
囧
圍觀
無聊
