IOCP（转）
在你開發(fā)不同類型的軟件，不久之后或者更晚，你必須得面對客戶端/服務(wù)器端的發(fā)展。對程序員來說，寫一個全面的客戶端/服務(wù)器的代碼是很困難的。這篇文章提供了一個簡單的，但卻強大的客戶端/服務(wù)器源代碼，它能夠被擴展到許多客戶端/服務(wù)器的應(yīng)用程序中。源代碼使用高級的IOCP技術(shù)，這種技術(shù)能高效的為多個客戶端提供服務(wù)。IOCP技術(shù)提供了一種對 一個線程—一個客戶端（one-thread-one client）這種瓶頸問題（很多中問題的一個）的有效解決方案。它使用很少的一直運行的線程和異步輸入/輸出，發(fā)送/接收。IOCP技術(shù)被廣泛應(yīng)用于各自高性能的服務(wù)器，像Apache等。源代碼也提供了一系列的函數(shù)，在處理通信、客戶端/服務(wù)器接收/發(fā)送文件函數(shù)、還有線程池處理等方面都會經(jīng)常用到。文章主要關(guān)注利用IOCP應(yīng)用API函數(shù)的實際解決方案，也提供了一個全面的代碼文檔。此外，也為你呈現(xiàn)了一個能處理多個連接、同時能夠進行文件傳輸?shù)暮唵位貜?fù)客戶端/服務(wù)器。
2.1. 介紹：
這片文章提供了一個類，它是一個應(yīng)用于客戶端和服務(wù)器的源代碼，這個類使用IOCP和異步函數(shù)，我們稍后會進行介紹。這個源代碼是根據(jù)很多代碼和文章得到的。
利用這些簡單的源代碼，你能夠：
l 服務(wù)/連接多個客戶端和服務(wù)器。
l 異步發(fā)送和接收文件。
l 為了處理沉重的客戶端/服務(wù)器請求，創(chuàng)建并管理一個邏輯工作者線程池。（logical worker thread pool）。
我們很難找到充分的，但簡單的能夠應(yīng)對客戶端/服務(wù)器通信的源代碼。在網(wǎng)上發(fā)現(xiàn)的源代碼即復(fù)雜（超過20個類），又不能提供足夠的功能。本問的代碼盡量簡單，也有好的文檔。我們將簡要介紹Winsock API 2.0提供的IOCP技術(shù)，編碼時遇到的疑難問題，以及這些問題的應(yīng)對方案。
2.2. 異步輸入/輸出完成端口（IOCP）簡介
一個服務(wù)器應(yīng)用程序，假如不能夠同時為多個客戶端提供服務(wù)，那它就沒有什么意義。通常的異步I/O調(diào)用，還有多線程都是這個目的。準(zhǔn)確的說，一個異步I/O調(diào)用能夠立即返回，盡管有阻塞的I/O調(diào)用。同時，I/O異步調(diào)用的結(jié)果必須和主線程同步。這可以用很多種方法實現(xiàn)，同步可以通過下面方法實現(xiàn)：
l 利用事件——當(dāng)異步調(diào)用完成時設(shè)定的信號。這種方法的優(yōu)點是線程必須檢查和等待這個信號被設(shè)定。
l 使用GetOverlappedResult函數(shù)——這個方法和上面方法有相同的優(yōu)點。
l 使用異步程序調(diào)用（APC）——這種方法有些缺點。第一，APC總是在正被調(diào)用的線程的上下文中被調(diào)用；第二，調(diào)用線程必須暫停，等待狀態(tài)的改變。
l 使用IOCP——這種方法的缺點是有些疑難問題必須解決。使用IOCP編碼多少有些挑戰(zhàn)。
2.2.1 為什么使用IOCP
使用IOCP，我們能夠克服 一個線程 —— 一個客戶端 問題。我們知道，假如軟件不是運行在一個真實的多處理器機器上，它的性能會嚴(yán)重下降。線程是系統(tǒng)的資源，它們即不是無限的，也不便宜。
IOCP提供了一種利用有限的（I/O工作線程）公平的處理多客戶端的輸入/輸出問題的解決辦法。線程并不被阻塞，在無事可作的情況下也不使CPU循環(huán)。
2.3. 什么是IOCP
我們已經(jīng)知道，IOCP僅僅是一個線程同步對象，有點像信號量（semaphore），因此IOCP并不是一個難懂的概念。一個IOCP對象和很多支持異步I/O調(diào)用的I/O對象相聯(lián)系。線程有權(quán)阻塞IOCP對象，直到異步I/O調(diào)用完成。
3 IOCP如何工作
為了得到更多信息，建議你參考其它的文章（1, 2, 3, see References）。
使用IOCP，你必須處理3件事情。將一個套接字綁定到一個完成端口，使用異步I/O調(diào)用，和使線程同步。為了從異步I/O調(diào)用得到結(jié)果，并知道一些事情，像哪個客戶端進行的調(diào)用，我們必須傳遞兩個參數(shù)：CompletionKey參數(shù)，還有OVERLAPPED結(jié)構(gòu)體。
3.1. CompletionKey參數(shù)
CompletionKey參數(shù)是第一個參數(shù)，是一個DWORD類型的變量。你可以給它傳遞你想要的任何值，這些值總是和這個參數(shù)聯(lián)系。通常，指向結(jié)構(gòu)體的指針，或者包含客戶端指定對象的類的指針被傳遞給這個參數(shù)。在本文的源代碼中，一個ClientContext結(jié)構(gòu)體的指針被傳遞給CompletionKey參數(shù)。
3.2. OVERLAPPED參數(shù)
這個參數(shù)通常被用來傳遞被異步I/O調(diào)用的內(nèi)存。要重點強調(diào)的是，這個數(shù)據(jù)要被加鎖，并且不要超出物理內(nèi)存頁，我們之后進行討論。
3.3. 將套接字和完成端口進行綁定
一旦創(chuàng)建了完成端口，通過調(diào)用CreateIoCompletionPort函數(shù)可以將一個套接字和完成端口進行綁定，像下面的方法：
BOOL IOCPS::AssociateSocketWithCompletionPort(SOCKET socket,
HANDLE hCompletionPort, DWORD dwCompletionKey)
{
HANDLE h = CreateIoCompletionPort((HANDLE) socket,
hCompletionPort, dwCompletionKey, m_nIOWorkers);
return h == hCompletionPort;
}
3.4. 進行異步I/O調(diào)用
通過調(diào)用WSASend, WSARecv函數(shù)，進行實際的異步調(diào)用。這些函數(shù)也需要包含將要被用到的內(nèi)存指針的參數(shù)WSABUF。通常情況下，當(dāng)服務(wù)器/客戶端想要執(zhí)行一個I/O調(diào)用操作，它們并不直接去做，而是發(fā)送到完成端口，這些操作被I/O工作線程執(zhí)行。這是因為，要公平的分配CPU。通過給完成端口傳遞一個狀態(tài)，進行I/O調(diào)用。象下面這樣：
BOOL bSuccess = PostQueuedCompletionStatus(m_hCompletionPort,
pOverlapBuff->GetUsed(),
(DWORD) pContext, &pOverlapBuff->m_ol);
3.5. 線程的同步
通過調(diào)用GetQueuedCompletionStatus函數(shù)進行線程的同步（看下面）。這個函數(shù)也提供了CompletionKey 參數(shù) OVERLAPPED參數(shù)。
BOOL GetQueuedCompletionStatus(
HANDLE CompletionPort, // handle to completion port
LPDWORD lpNumberOfBytes, // bytes transferred
PULONG_PTR lpCompletionKey, // file completion key
LPOVERLAPPED *lpOverlapped, // buffer
DWORD dwMilliseconds // optional timeout value
);
3.6. 四個棘手的IOCP編碼問題和它們的對策
使用IOCP會遇到一些問題，有些問題并不直觀。在使用IOCP的多線程場景中，并不直接控制線程流，這是因為線程和通信之間并沒有聯(lián)系。在這部分，我們將提出四個不同的問題，在使用IOCP開發(fā)客戶端/服務(wù)器程序時會遇到它們。它們是：
l WSAENOBUFS出錯問題。
l 數(shù)據(jù)包的重排序問題。
l 訪問紊亂（access violation）問題
3.6.1 WSAENOBUFS出錯問題。
這個問題并不直觀，并且很難檢查。因為，乍一看，它很像普通的死鎖，或者內(nèi)存泄露。假設(shè)你已經(jīng)弄好了你的服務(wù)器并且能夠很好的運行。當(dāng)你對服務(wù)器進行承受力測試的時候，它突然掛機了。如果你幸運，你會發(fā)現(xiàn)這和WSAENOBUFS出錯有關(guān)。
伴隨著每一次的重疊發(fā)送和接收操作，有數(shù)據(jù)的內(nèi)存提交可能會被加鎖。當(dāng)內(nèi)存被鎖定時，它不能越過物理內(nèi)存頁。操作系統(tǒng)會強行為能夠被鎖定的內(nèi)存的大小設(shè)定一個上限。當(dāng)達到上限時，重疊操作將失敗，并發(fā)送WSAENOBUFS錯誤。
假如一個服務(wù)器在在每個連接上提供了很多重疊接收，隨著連接數(shù)量的增長，很快就會達到這個極限。如果服務(wù)器能夠預(yù)計到要處理相當(dāng)多的并發(fā)客戶端的話，服務(wù)器可以在每個連接上僅僅回復(fù)一個0字節(jié)的接收。這是因為沒有接收操作和內(nèi)存無關(guān)，內(nèi)存不需要被鎖定。利用這個方法，每一個套接字的接收內(nèi)存都應(yīng)該被完整的保留，這是因為，一旦0字節(jié)的接收操作完成，服務(wù)器僅僅為套接字的接收內(nèi)存的所以數(shù)據(jù)內(nèi)存返回一個非阻塞的接收。利用WSAEWOULDBLOCK，當(dāng)非阻塞接收失敗時，也沒有數(shù)據(jù)被阻塞。這種設(shè)計的目的是，在犧牲數(shù)據(jù)吞吐量的情況下，能夠處理最大量的并發(fā)連接。當(dāng)然，對于客戶端如何和服務(wù)器交互，你知道的越多越好。在以前的例子中，每當(dāng)0字節(jié)的接收完成，返回存儲了的數(shù)據(jù)，馬上執(zhí)行非阻塞接收。假如服務(wù)器知道客戶端突然發(fā)送數(shù)據(jù)，當(dāng)0字節(jié)接收一旦完成，為防止客戶端發(fā)送一定數(shù)量的數(shù)據(jù)（大于每個套接字默認(rèn)的8K內(nèi)存大小），它可以投遞一個或多個重疊接收。
源代碼提供了一個簡單的解決WSAENOBUFS錯誤的可行方案。對于0字節(jié)內(nèi)存，我們采用WSARead（）函數(shù)（見OnZeroByteRead（））。當(dāng)調(diào)用完成，我們知道數(shù)據(jù)在TCP/IP棧中，通過采用幾個異步WSARead（）函數(shù)讀取MAXIMUMPACKAGESIZE的內(nèi)存。這個方法在數(shù)據(jù)達到時僅僅鎖定物理內(nèi)存，解決了WSAENOBUFS問題。但是這個方案降低了服務(wù)器的吞吐量（見第9部分的Q6和A6例子）。
3.6.2 數(shù)據(jù)包的重排序問題
在參考文獻3中也討論了這個問題。盡管使用IOCP，可以使數(shù)據(jù)按照它們被發(fā)送的順序被可靠的處理，但是線程表的結(jié)果是實際工作線程的完成順序是不確定的。例如，假如你有兩個I/O工作線程，并且你應(yīng)該接收“字節(jié)數(shù)據(jù)塊1、字節(jié)數(shù)據(jù)塊2 、字節(jié)數(shù)據(jù)塊3”，你可以按照錯誤的順序處理它們，也就是“字節(jié)數(shù)據(jù)塊2、字節(jié)數(shù)據(jù)塊1 、字節(jié)數(shù)據(jù)塊3”。這也意味著，當(dāng)你通過把發(fā)送請求投遞到IO完成端口來發(fā)送數(shù)據(jù)時，數(shù)據(jù)實際上是被重新排序后發(fā)送的。
這個問題的一個實際解決辦法是，為我們的內(nèi)存類增加順序號，并按照順序號處理內(nèi)存。意思是，具有不正確號的內(nèi)存被保存?zhèn)溆?#xff0c;并且因為性能原因，我們將內(nèi)存保存在希哈表中（例如m_SendBufferMap和m_ReadBufferMap）。
要想得到更多這個方案的信息，請查看源代碼，并在IOCPS類中查看下面的函數(shù)：
l GetNextSendBuffer (..) 和GetNextReadBuffer(..), 為了得到排序的發(fā)送或接收內(nèi)存。
l IncreaseReadSequenceNumber(..)和IncreaseSendSequenceNumber(..), 為了增加順序號。
3.6.3 異步阻塞讀和字節(jié)塊包處理問題
大多數(shù)服務(wù)器協(xié)議是一個包，這個包的基礎(chǔ)是第一個X位的描述頭，它包含了完整包的長度等詳細(xì)信息。服務(wù)器可以解讀這個頭，可以算出還需要多少數(shù)據(jù)，并一直解讀，直到得到一個完整的包。在一個時間段內(nèi)，服務(wù)器通過異步讀取調(diào)用是很好的。但是，假若我們想全部利用IOCP服務(wù)器的潛力，我們應(yīng)該有很多的異步讀操作等待數(shù)據(jù)的到達。意思是很多異步讀無順序完成（像在3.6.2討論的），通過異步讀操作無序的返回字節(jié)塊流。還有，一個字節(jié)塊流（byte chunk streams）能包含一個或多個包，或者包的一部分，如圖1所示：
圖1
這個圖表明部分包（綠色）和完整的包（黃色）在字節(jié)塊流中是如何異步到達的。
這意味著我們要想成功解讀一個完整包，必須處理字節(jié)流數(shù)據(jù)塊（byte stream chunks）。還有，我們必須處理部分包，這使得字節(jié)塊包的處理更加困難。完整的方案可以在IOCP類里的ProcessPackage(..)函數(shù)中找到。
3.6.4 訪問紊亂（access violation）問題。
這是一個次要問題，是編碼設(shè)計的結(jié)果，而不是IOCP的特有問題。倘若客戶端連接丟失，并且一個I/O調(diào)用返回了一個錯誤標(biāo)識，這樣我們知道客戶端已經(jīng)不在了。在CompletionKey參數(shù)中，我們?yōu)樗鼈鬟f一個包含了客戶端特定數(shù)據(jù)的結(jié)構(gòu)體的指針。假如我們釋放被ClientContext結(jié)構(gòu)體占用的內(nèi)存，被同一個客戶端執(zhí)行I/O調(diào)用所返回的錯誤碼，我們?yōu)镃lientContext指針傳遞雙字節(jié)的CompletionKey變量，試圖訪問或刪除CompletionKey參數(shù)，這些情況下會發(fā)生什么？一個訪問紊亂發(fā)生了。
這個問題的解決辦法是為ClientContext結(jié)構(gòu)體增加一個阻塞I/O調(diào)用的計數(shù)(m_nNumberOfPendlingIO)，當(dāng)我們知道沒有阻塞I/O調(diào)用時我們刪除這個結(jié)構(gòu)體。EnterIoLoop(..) 函數(shù)和 ReleaseClientContext(..).函數(shù)就是這樣做的。
3.7 源代碼總攬
源代碼的目標(biāo)是提供一些能處理與IOCP有關(guān)的問題的代碼。源代碼也提供了一些函數(shù)，它們在處理通信、客戶端/服務(wù)器接收/發(fā)送文件函數(shù)、還有線程池處理等方面會經(jīng)常用到。
?
圖2 源代碼IOCPS類函數(shù)總攬
我們有很多I/O工作線程，它們通過完成端口（IOCP）處理異步I/O調(diào)用，這些工作線程調(diào)用一些能把需要大量計算的請求放到一個工作隊列著中的虛函數(shù)。邏輯工作線程從隊列中渠道任務(wù)，進行處理，并通過使用一些類提供的函數(shù)將結(jié)果返回。圖形用戶界面（GUI）通常使用Windows消息，通過函數(shù)調(diào)用，或者使用共享的變量，和主要類進行通信。
圖3
圖3顯示了類的總攬。
圖3中的類歸納如下：
l CIOCPBuffer：管理被異步I/O調(diào)用使用的內(nèi)存的類。
l IOCPS：處理所有通信的主要類。
l JobItem：包含被邏輯工作線程所執(zhí)行工作的結(jié)構(gòu)體。
l ClientContext：保存客戶端特定信息的結(jié)構(gòu)體（例如：狀態(tài)、數(shù)據(jù) ）。
3.7.1 內(nèi)存設(shè)計——CIOCPBuffer類
當(dāng)使用異步I/O調(diào)用時，我們必須為I/O操作提供一個私有內(nèi)存空間。當(dāng)我們分配內(nèi)存時要考慮下面一些情況：
l 分配和釋放內(nèi)存是很費時間的，因此我們要反復(fù)利用分配好的內(nèi)存。所以，我們像下面所示將內(nèi)存保存在一個連接表中。
· // Free Buffer List..
·
· CCriticalSection m_FreeBufferListLock;
· CPtrList m_FreeBufferList;
· // OccupiedBuffer List.. (Buffers that is currently used)
· CCriticalSection m_BufferListLock;
· CPtrList m_BufferList;
· // Now we use the function AllocateBuffer(..)
·
// to allocate memory or reuse a buffer.
l 有時，當(dāng)一個異步I/O調(diào)用完成時，我們可能在內(nèi)存中有部分包，因此我們?yōu)榱说玫揭粋€完整的消息，需要分離內(nèi)存。在CIOCPS類中的函數(shù)SplitBuffer（）可以實現(xiàn)這一目標(biāo)。我們有時也需要在兩個內(nèi)存間復(fù)制信息， CIOCPS類中的AddAndFlush（）函數(shù)可以實現(xiàn)。
l 我們知道，我們?yōu)槲覀兊膬?nèi)存增加序列號和狀態(tài)變量（IOZeroReadCompleted（））。
l 我們也需要字節(jié)流和數(shù)據(jù)相互轉(zhuǎn)換的方法，在CIOCPBuffer類中提供了這些函數(shù)。
在我們的CIOCPBuffer類中，有上面所有問題的解決辦法。
3.8 如何使用源代碼
從IOCP中派生你自己的類，使用虛函數(shù)，使用IOCPS類提供的函數(shù)（例如：線程池）。使用線程池，通過使用少數(shù)的線程，為你為各種服務(wù)器或客戶端高效的管理大量的連接提供了可能。
3.8.1 啟動和關(guān)閉服務(wù)器/客戶端
啟動服務(wù)器，調(diào)用下面的函數(shù)：
BOOL Start(int nPort=999,int iMaxNumConnections=1201,
int iMaxIOWorkers=1,int nOfWorkers=1,
int iMaxNumberOfFreeBuffer=0,
int iMaxNumberOfFreeContext=0,
BOOL bOrderedSend=TRUE,
BOOL bOrderedRead=TRUE,
int iNumberOfPendlingReads=4);
l nPortt ：服務(wù)器將監(jiān)聽的端口號（在客戶端模式設(shè)為-1）。
l iMaxNumConnections：最多允許連接數(shù)。
l iMaxIOWorkers ：輸入/輸出工作線程數(shù)。
l nOfWorkers：邏輯工作者數(shù)（在運行時能被改變）。
l iMaxNumberOfFreeBuffer ：保留的重復(fù)利用的內(nèi)存的最大數(shù)量（-1：無 ，0：無窮）。
l iMaxNumberOfFreeContext ：保留的重復(fù)利用的客戶端信息的最大數(shù)量（-1：無 ，0：無窮）。
l bOrderedRead ：用來進行順序讀。
l bOrderedSend ：用來進行順序發(fā)送。
l iNumberOfPendlingReads ：等待數(shù)據(jù)的異步讀循環(huán)的數(shù)量。在連接到一個遠(yuǎn)端的連接時調(diào)用下面的函數(shù)：
Connect(const CString &strIPAddr, int nPort)
l strIPAddr ：遠(yuǎn)端服務(wù)器的IP地址。
l nPort：端口。
關(guān)閉服務(wù)器，調(diào)用函數(shù)：ShutDown（）。
例如：
MyIOCP m_iocp;
if(!m_iocp.Start(-1,1210,2,1,0,0))
AfxMessageBox("Error could not start the Client");
….
m_iocp.ShutDown();
5.1 文件傳輸
使用Winsock 2.0的TransmitFile 函數(shù)傳輸文件。TransmitFile 函數(shù)在連接的套接字句柄上傳輸文件數(shù)據(jù)。此函數(shù)使用操作系統(tǒng)的緩沖管理機制接收文件數(shù)據(jù)，在套接字上提供高性能的文件傳輸。在異步文件傳輸上有以下幾個重要方面：
l 除非TransmitFile 函數(shù)返回，否則不能再對套接字執(zhí)行 發(fā)送 或 寫入 操作，不然會破壞文件的傳輸。在執(zhí)行PrepareSendFile(..) 函數(shù)后，所有對ASend函數(shù)的調(diào)用都是不允許的。
l 由于系統(tǒng)是連續(xù)讀文件數(shù)據(jù)，打開文件句柄的FILE_FLAG_SEQUENTIAL_SCAN特性可以提高緩存性能。
l 在發(fā)送文件（TF_USE_KERNEL_APC）時，我們使用內(nèi)核的異步程序調(diào)用。TF_USE_KERNEL_APC的使用可以帶來明顯的性能提升。很可能（盡管不一定），帶有TransmitFile 的線程的上下文環(huán)境的初始化會有沉重的計算負(fù)擔(dān)；這種情況下可以防止反復(fù)執(zhí)行APC（異步程序調(diào)用）。
文件傳輸?shù)捻樞蛉缦?#xff1a;服務(wù)器通過調(diào)用PrepareSendFile(..)函數(shù)初始化文件傳輸。客戶端接收到文件信息時，通過調(diào)用PrepareReceiveFile(..)函數(shù)準(zhǔn)備接收，并且給服務(wù)器發(fā)送一個包來開始文件傳輸。在服務(wù)器收到包后，它調(diào)用使用高性能的TransmitFile函數(shù)的StartSendFile(..)函數(shù)傳輸指定的文件。
6 源代碼例子
提供的源代碼是一個模擬客戶端/服務(wù)器的例子，它也提供了文件傳輸功能。在源碼中，從類IOCP派生出的類MyIOCP處理客戶端和服務(wù)器端的通信。在4.1.1 部分提到了這個虛函數(shù)的用法。
在客戶端，或者服務(wù)器端的代碼中，虛函數(shù)NotifyReceivedPackage是重點。描述如下：
void MyIOCP::NotifyReceivedPackage(CIOCPBuffer *pOverlapBuff,
int nSize,ClientContext *pContext)
{
BYTE PackageType=pOverlapBuff->GetPackageType();
switch (PackageType)
{
case Job_SendText2Client :
Packagetext(pOverlapBuff,nSize,pContext);
break;
case Job_SendFileInfo :
PackageFileTransfer(pOverlapBuff,nSize,pContext);
break;
case Job_StartFileTransfer:
PackageStartFileTransfer(pOverlapBuff,nSize,pContext);
break;
case Job_AbortFileTransfer:
DisableSendFile(pContext);
break;};
}
這個函數(shù)處理進來的消息和遠(yuǎn)程連接發(fā)送的請求。在這種情形下，它只不過進行一個簡單的回復(fù)或者傳輸文件。源代碼分為兩部分，IOCP和IOCPClient，
它們是連接的雙方。 6.1 編譯器問題
在使用VC++ 6.0 或者 .NT時，在處理類CFile時可能會出現(xiàn)一些奇怪的錯誤。像下面這樣：
“if (pContext->m_File.m_hFile !=
INVALID_HANDLE_VALUE) <-error C2446: '!=' : no conversion "
"from 'void *' to 'unsigned int'”
在你更新頭文件（*.h），或者更新你的VC++ 6.0版本后，或者只是改變類型轉(zhuǎn)換錯誤，都可能會解決這些問題。經(jīng)過一些修改，這個客戶端/服務(wù)器的源代碼在沒有MFC的情況下也能使用。 7 注意點和解決規(guī)則
在你將此代碼用于其它類型的程序時，有一些編程的陷阱和源代碼有關(guān)，使用“多線程編程”可以避免。不確定的錯誤是那些隨時發(fā)生的錯誤，并且通過執(zhí)行相同的出錯的任務(wù)的順序這種方式很難降低這些不確定的錯誤。這類錯誤是存在的最嚴(yán)重的錯誤，一般情況下，它們出錯是因為源代碼設(shè)計執(zhí)行的內(nèi)核的出錯上。當(dāng)服務(wù)器運行多個IO工作線程時，為連接的客戶端服務(wù)，假如編程人員沒有考慮源代碼的多線程環(huán)境，就可能會發(fā)生像違反權(quán)限這種不確定的錯誤。
解決規(guī)則 #1：
像下面例子那樣，絕不在使用上下文 “鎖”之前鎖定客戶端的上下文（例如ClientContext）之前進行讀/寫。通知函數(shù)（像：Notify*(ClientContext *pContext)）已經(jīng)是“線程安全的”，你訪問ClientContext的成員函數(shù)，而不考慮上下文的加鎖和解鎖。
//Do not do it in this way
// …
If(pContext->m_bSomeData)
pContext->m_iSomeData=0;
// …
// Do it in this way.
//….
pContext->m_ContextLock.Lock();
If(pContext->m_bSomeData)
pContext->m_iSomeData=0;
pContext->m_ContextLock.Unlock();
//…
當(dāng)然，你要明白，當(dāng)你鎖定一個上下文時，其他的線程或GUI都將等待它。
解決規(guī)則 #2：
要避免，或者“特別注意”使用那些有復(fù)雜的“上下文鎖”，或在一個“上下文鎖”中有其他類型的鎖的代碼。因為它們很容易導(dǎo)致“死鎖”。（例如：A等待B，B等待C，而C等待A => 死鎖）。
pContext-> m_ContextLock.Lock();
//… code code ..
pContext2-> m_ContextLock.Lock();
// code code..
pContext2-> m_ContextLock.Unlock();
// code code..
pContext-> m_ContextLock.Unlock();
上面的代碼可以導(dǎo)致一個死鎖。
解決規(guī)則 #3：
絕不要在通知函數(shù)（像Notify*(ClientContext *pContext)）的外面訪問一個客戶端的上下文。假如你必須這樣做，務(wù)必使用m_ContextMapLock.Lock(); … m_ContextMapLock.Unlock()對它進行封裝。如下面代碼所示：
ClientContext* pContext=NULL ;
m_ContextMapLock.Lock();
pContext = FindClient(ClientID);
// safe to access pContext, if it is not NULL
// and are Locked (Rule of thumbs#1:)
//code .. code..
m_ContextMapLock.Unlock();
// Here pContext can suddenly disappear because of disconnect.
// do not access pContext members here.
8 下一步的工作
下一步，代碼會被更新，在時間順序上會具有下面的特性：
1. 可以接受新的連接的AcceptEx(..)函數(shù)的應(yīng)用將添加到源代碼中，用來處理短時的連接爆炸（short lived connection bursts）和DOS攻擊。
2. 源代碼可以很容易的用于其它平臺，像Win32, STL, 和 WTL。
說明：最近比較忙，各種事情應(yīng)接不暇。終于弄完了，呵呵。
源代碼可以到網(wǎng)上下載，我分析了，很好，可以應(yīng)用到我的項目中，嘿嘿。
總結(jié)
- 上一篇： 创建线程后为什么马上调用CloseHan
- 下一篇： IOCP配合AcceptEx的例子