本文同時(shí)發(fā)布在http://www.yulefox.com和http://www.shnenglu.com/fox。

近來(lái)在Windows下用WSAEventSelect時(shí)，碰到一個(gè)棘手的問(wèn)題，當(dāng)然現(xiàn)在已經(jīng)解決了。

問(wèn)題描述：

一個(gè)Server，一個(gè)ClientA，一個(gè)ClientB，Server用WSAEventSelect模型監(jiān)聽(tīng)（只有監(jiān)聽(tīng)，沒(méi)有讀寫(xiě)），ClientA在連接Server后，ClientA對(duì)應(yīng)的EventA被觸發(fā)，Server的WSAWaitForMultipleEvents等待到EventA，ClientB連接Server時(shí)，TCP三次握手成功，ClientB與Server的TCP狀態(tài)被置為ESTABLISHED，然而Server的WSAWaitForMultipleEvents沒(méi)有等待到EventB被觸發(fā)。

用netstat看了一下，ClientB與Server的狀態(tài)是ESTABLISHED，此時(shí)如果ClientB退出，由于Server無(wú)法正常Close該連接，因此Server的狀態(tài)不是TIME_WAIT而是CLOSE_WAIT（持續(xù)2小時(shí)），Client的狀態(tài)是FIN_WAIT_2（持續(xù)10分鐘）。

我嘗試將ClientA主動(dòng)關(guān)閉后再次連接Server，Server的WSAWaitForMultipleEvents在wait到EventA之后，EventB此時(shí)也被觸發(fā)。

開(kāi)始一直以為問(wèn)題的根源在于WSAEventSelect的使用上，畢竟，之前沒(méi)有系統(tǒng)寫(xiě)過(guò)類(lèi)似的代碼，難免懷疑到事件模型的使用上。多方查閱資料，最后還是沒(méi)有發(fā)現(xiàn)類(lèi)似問(wèn)題的解決方案。

又跟了一上午之后，Kevin開(kāi)始懷疑是多線(xiàn)程使用的問(wèn)題，我看了一下，的確沒(méi)有對(duì)event的多線(xiàn)程操作進(jìn)行處理，但因?yàn)樵诹硪粋€(gè)應(yīng)用中，使用了同樣的模塊，卻沒(méi)有該問(wèn)題。最后考慮必要性時(shí)還是放棄了加臨界資源，無(wú)視多線(xiàn)程同步問(wèn)題。Kevin本來(lái)勸我換個(gè)模型，但我固執(zhí)的認(rèn)為要做就把這事兒做好。因?yàn)橄挛邕€要回學(xué)校一趟，就想盡快搞定，畢竟因?yàn)檫@一塊已經(jīng)把Kevin的進(jìn)度拖了一周了，心下還是過(guò)意不去，而且隱約感覺(jué)到離問(wèn)題的解決越來(lái)越近了。

問(wèn)題分析：

在對(duì)著WSAWaitForMultipleEvents思考了半天之后，忽然開(kāi)竅了，如果ThreadA在WSAWaitForMultipleEvents時(shí)，只有一個(gè)EventA被WSAEventSelect并set到signaled狀態(tài)，則該EventA會(huì)被wait成功，ThreadA處理EventA之后繼續(xù)阻塞在WSAWaitForMultipleEvents。此時(shí)，ThreadB通過(guò)WSAEventSelect將EventB初始化為nonsignaled狀態(tài)，之后即使EventB被set為signaled狀態(tài)，但ThreadA的WSAWaitForMultipleEvents因?yàn)樘幱谧枞麪顟B(tài)，不可能刷新事件集，也就不可能wait到EventB，最終導(dǎo)致了ClientB的請(qǐng)求無(wú)法被響應(yīng)。如果EventA被觸發(fā)則會(huì)被ThreadA等待到，WSAWaitForMultipleEvents返回后再次進(jìn)入時(shí)事件集已經(jīng)被刷新，EventB被wait到也就不難理解了。

問(wèn)題解決：

說(shuō)到底是因?yàn)楫?dāng)ThreadA阻塞在WSAWaitForMultipleEvents處之時(shí)，事件集的變更無(wú)法立即得到體現(xiàn)。如果允許上層應(yīng)用隨時(shí)create或close一些event，則WSAWaitForMultipleEvents就不應(yīng)該無(wú)限阻塞下去。

因此最后的一個(gè)解決方法就是讓W(xué)SAWaitForMultipleEvents超時(shí)返回并Sleep一段時(shí)間，當(dāng)WSAWaitForMultipleEvents再次進(jìn)入時(shí)事件集得以更新。

想了一下，另一個(gè)應(yīng)用中之所以沒(méi)出現(xiàn)該問(wèn)題也只是個(gè)巧合，因?yàn)樵搼?yīng)用中ThreadB的兩次WSAEventSelect間隔很短，在ThreadA獲得時(shí)間片之前已經(jīng)確定了事件集。

說(shuō)白了這也不是一個(gè)什么大問(wèn)題，甚至談不上任何難度，但是因?yàn)橹皩?duì)WSAEventSelect沒(méi)有一個(gè)清晰的概念，因此在發(fā)現(xiàn)和分析問(wèn)題上花費(fèi)了大量時(shí)間，加上在VS2005調(diào)試過(guò)程中，有個(gè)別文件更新時(shí)沒(méi)有被重新編譯，也耗費(fèi)了很多無(wú)謂的時(shí)間，以至于我們都在考慮是不是要放棄IDE，因?yàn)槲覀兇_實(shí)太依賴(lài)IDE了，有些TX為了穩(wěn)妥，每次都是“重新生成整個(gè)解決方案”，如果一個(gè)解決方案有幾千個(gè)文件、幾十萬(wàn)行的代碼，估計(jì)重編一次也要花個(gè)幾分鐘吧。

總結(jié)：

1. netstat觀(guān)察的網(wǎng)絡(luò)連接處于ESTABLISHED狀態(tài)并不意味著邏輯連接被accept，只是表明客戶(hù)端connect的TCP物理連接（三次握手）被服務(wù)器端ack，如果服務(wù)器沒(méi)有accept到該連接，證明網(wǎng)絡(luò)模塊代碼有問(wèn)題；
2. 多線(xiàn)程怎么都是個(gè)問(wèn)題，線(xiàn)程同步盡量避免，畢竟，用Kevin的話(huà)來(lái)說(shuō)，加鎖是丑陋的。但在涉及到同步問(wèn)題時(shí)，還是權(quán)衡一下，我這兒之所以最后沒(méi)有加臨界區(qū)，是因?yàn)槭录饕窃赥hreadA中處理，ThreadB中只有create操作，而且ThreadA對(duì)事件集的刷新要求不是那么嚴(yán)格，也就不考慮加臨界區(qū)了；
3. 如果能力和條件允許的話(huà)，放棄IDE吧，IDE的確不是個(gè)好東西，我主要是指在編譯鏈接的時(shí)候，如果作為編輯器說(shuō)不定還會(huì)好用:)。

個(gè)人網(wǎng)站http://www.yulefox.com用的主機(jī)最近從據(jù)說(shuō)要黑屏的Windows換成了Debian，還在調(diào)整，估計(jì)明天能弄好，內(nèi)容肯定比Cppblog雜的多，談點(diǎn)技術(shù)的還是會(huì)同步更新到http://www.shnenglu.com/fox。