困難在於事件信號用索引 標識在對象句柄數組中。當在該數組中間添加或刪除事件時,此類索引將變換。數組
一般,此類問題經過使用存儲句柄的容器、包裝數組並表明客戶端應用程序執行插入、刪除和查找來解決。安全
本文將討論此類容器類的設計和實現。容器存儲 WaitForMultipleObjects 方法使用的事件句柄。容器類的用戶經過數字 ID 引用各個句柄,在容器的生存期內,甚至在添加或刪除事件時,該數字 ID 都不會更改。服務器
WaitForMultipleObjects/MsgWaitForMultipleObjects 的接口最適合較爲簡單的狀況,這些狀況包括:網絡
當向句柄發送信號時,將得到句柄索引做爲返回值。此索引(做爲輸入傳遞的事件數組中的位置)沒有直接的用途。使用這些函數的實際目的是獲取已發送信號的句柄或致使該句柄的某些非臨時信息。多線程
圖 1 顯示了說明這一問題的示例。它的代碼(理論媒體流應用程序的一部分)等待音頻設備或網絡發送信號(在本文的代碼下載中能夠找到此代碼或其餘代碼示例)。app
圖 1 等待信號的媒體流應用程序socket
- #define MY_AUDIO_EVENT (WAIT_OBJECT_0)
- #define MY_SOCKET_EVENT (WAIT_OBJECT_0 + 1)
- HANDLE handles[2];
- handles[] = audioInHandle;
- handles[1] = socketHandle;
- ...
- switch( WaitForMultipleObjects(handles) )
- {
- case MY_AUDIO_EVENT:
- // Handle audio event
- break;
- case MY_SOCKET_EVENT:
- // Handle socket event
- // What happens if we need to stop audio here?
- break;
- }
獲得的結果爲 WAIT_OBJECT_0(索引 0)意味着已向音頻設備發送信號。獲得索引 1 意味着已向網絡發送信號。如今,若是須要關閉 audioInHandle 以響應從 socketHandle 觸發的事件,會出現什麼狀況?您將須要刪除句柄數組中的索引 0,這將變換大於 0 的索引,意味着 MY_SOCKET_EVENT 值須要是動態的,而不是常量。ide
雖然有多種解決這種問題的方法(例如,在數組末尾保留可選句柄或變換數組的開頭),但隨着事件增多以及錯誤路徑的處理(索引偏離 WAIT_ABANDONED_0),這些方法將很快變得混亂。函數
乍一看,問題是您不能使用常量標識事件句柄。但經過仔細觀察,咱們發現此接口的根本問題在於它使用數組索引來標識事件句柄。這樣,索引在此處承擔着雙重任務:既表示句柄在內存中的位置又表示已向事件發送信號的事實,這形成了不便。工具
理想的狀況是,被髮送信號的事件可從數組中的索引獨立標識。這正是 DynWaitList 類的用武之處。
DynWaitList 類是要爲 WaitForMultipleObjects 方法傳遞的句柄數組的容器列表。句柄的內部集合具備靜態最大大小。類做爲模板實現,而集合的最大大小是惟一的模板參數。
容器接口包含所需的方法:用於插入事件並指定其 ID 的 Add 方法,用於刪除事件以及一些 Wait 變體的 Remove 方法。圖 2 顯示瞭如何使用 DynWaitList 解決前文列舉的問題。
圖 2 使用 DynWaitList
- WORD idAudioEvent, idSocketEvent;
- DynWaitList<10> handles(100); // Max 10 events, first ID is 100
- handles.Add( socketHandle, &idSocketEvent );
- handles.Add( audioInHandle, &idAudioEvent );
- ...
- switch( handles.Wait(2000) )
- {
- case (HANDLE_SIGNALED| idAudioEvent ):
- // Handle audio event
- break;
- case (HANDLE_SIGNALED| idSocketEvent):
- // Handle socket event
- if( decided_to_drop_audio )
- {
- // Array will shift within; the same ID
- // can be reused later with a different
- // handle if, say, we reopen audio
- handles.Remove(idAudioEvent);
- // Any value outside the
- // 100...109 range is fine
- idAudioEvent = ;
- }
- break;
- case (HANDLE_ABANDONED| idSocketEvent):
- case (HANDLE_ABANDONED| idAudioEvent):
- // Critical error paths
- break;
- case WAIT_TIMEOUT:
- break;
- }
此處列舉的示例顯示了一些衆所周知的事件 ID。不過,也存在 ID 不少、事先不熟悉的情形。下面是一些常見的情形:
至此,這些示例有一個共同的主題:動態句柄列表表明應用程序所處的不斷變化的外部環境。
實現容器須要平衡選取性能、簡單性以及存儲空間這些衝突的目標。這些須要根據最多見的容器使用狀況(如前文所述)進行評估。這有助於枚舉要在容器上執行的操做以及這些操做的出現頻率:
鑑於這些操做,我決定將內部存儲設置爲一個事件句柄數組(Windows 須要的那種)以及一個並行的 ID(16 位值)數組。經過這種並行數組安排能夠在索引和事件 ID 之間進行有效的轉換。具體來講:
另外一個重要的注意事項是線程安全。在給定此容器用途的狀況下,應當要求將操做序列化,所以,我選擇不保護內部數組。
圖 3 顯示了對代表主接口和容器內部項的類的聲明。
圖 3 顯示主接口和容器內部項的類聲明
- class DynWaitlistImpl
- {
- protected:
- DynWaitlistImpl( WORD nMaxHandles, HANDLE *pHandles,
- WORD *pIds, WORD wFirstId );
- // Adds a handle to the list; returns TRUE if successful
- BOOL Add( HANDLE hNewHandle, WORD *pwNewId );
- // Removes a handle from the list; returns TRUE if successful
- BOOL Remove( WORD wId );
- DWORD Wait(DWORD dwTimeoutMs, BOOL bWaitAll = FALSE);
- // ...
- Some snipped code shown later ...
- private:
- HANDLE *m_pHandles;
- WORD *m_pIds;
- WORD m_nHandles;
- WORD m_nMaxHandles;
- };
- template <int _nMaxHandles> class DynWaitlist: public DynWaitlistImpl
- {
- public:
- DynWaitlist(WORD wFirstId):
- DynWaitlistImpl( _nMaxHandles, handles, ids, wFirstId ) { }
- virtual ~DynWaitlist() { }
- private:
- HANDLE handles[ _nMaxHandles ];
- WORD ids[ _nMaxHandles ];
- };
請注意該類是如何拆分爲兩個類的,其中一個基類存放數組指針,一個模板派生類存放實際存儲。這樣,經過派生不一樣的模板類,能夠靈活進行動態數組分配(若是須要)。這種實現徹底使用靜態存儲。
將句柄添加到數組十分簡單,但查找空閒 ID 來表示新建事件的操做除外。根據所選設計,容器中將存在一個 ID 數組。此數組是預先分配的,用於支持容器能夠存放的最大 ID 數。所以,數組能夠方便地存放兩組 ID:
這要求在構造時使用全部可能的 ID 值填充 ID 數組。在這種狀況下,使用緊跟 上一個已使用 ID 的 ID 來查找空閒 ID 十分簡單。不須要搜索。圖 4 中顯示了類構造函數和 Add 方法的代碼。這兩種方法共同構建並使用空閒 ID 池。
圖 4 類構造函數和 Add 方法
- DynWaitlistImpl::DynWaitlistImpl(
- WORD nMaxHandles, // Number of handles
- HANDLE *pHandles, // Pointer to array of handle slots
- WORD *pIds, // Pointer to array of IDs
- WORD wFirstID) // Value of first ID to use
- // Class Constructor.
- Initializes object state
- : m_nMaxHandles(nMaxHandles)
- , m_pHandles(pHandles)
- , m_pIds(pIds)
- , m_nHandles()
- {
- // Fill the pool of available IDs
- WORD wId = wFirstID;
- for( WORD i = ; i < nMaxHandles; ++i )
- {
- m_pIds[i] = wId;
- wId++;
- }
- }
- BOOL DynWaitlistImpl::Add(
- HANDLE hNewHandle, // Handle to be added
- WORD *pwNewId ) // OUT parameter - value of new ID picked
- // Adds one element to the array of handles
- {
- if( m_nHandles >= m_nMaxHandles )
- {
- // No more room, no can do
- return FALSE;
- }
- m_pHandles[ m_nHandles ] = hNewHandle;
- // Pick the first available ID
- (*pwNewId) = m_pIds[ m_nHandles ];
- ++m_nHandles;
- return TRUE;
- }
要將句柄從賦予其 ID 的容器中刪除,須要查找該句柄的索引。經過此實現,能夠將索引到 ID 的轉換優化爲 1 階,但這會下降轉換的性能。在給定 ID 的狀況下,須要執行線性搜索(N 階)在數組中查找其索引。對於服務器,相對於斷開鏈接的狀況,用戶不太介意響應時間,所以,我決定接受性能下降的情形。找到要刪除的索引後,刪除操做就變得輕鬆快捷了,只須要交換找到的句柄與上一個「正在使用的」句柄就好了(參見圖 5)。
圖 5 刪除操做
- BOOL DynWaitlistImpl::Remove(
- WORD wId ) // ID of handle being removed
- // Removes one element from the array of handles
- {
- WORD i;
- BOOL bFoundIt = FALSE;
- for( i = ; i < m_nHandles; ++i )
- {
- // If we found the one we want to remove
- if( m_pIds[i] == wId )
- {
- // Found it!
- bFoundIt = TRUE;
- break;
- }
- }
- // Found the ID we were looking for?
- if( bFoundIt )
- {
- WORD wMaxIdx = (m_nHandles - 1);
- if( i < wMaxIdx ) // if it isn't the last item being removed
- {
- // Take what used to be the last item and move it down,
- // so it takes the place of the item that was deleted
- m_pIds [i] = m_pIds [ wMaxIdx ];
- m_pHandles[i] = m_pHandles[ wMaxIdx ];
- // Save the ID being removed, so it can be reused in a future Add
- m_pIds [ wMaxIdx ] = wId;
- }
- --m_nHandles;
- m_pHandles[m_nHandles] = ;
- return TRUE;
- }
- else
- {
- return FALSE;
- }
- }
檢測信號是 DynWaitList 執行的主要任務。調用 WaitForMultipleObjects 十分簡單,由於全部數據已預先歸檔供調用時使用。因爲並行的 ID 數組,將檢測到的信號轉換爲上層能夠引用的 ID 也十分簡單。Wait 方法的主要內容是代碼,如圖 6 所示。Wait 有一些變體,全部變體都使用內部 TranslateWaitResult 方法執行索引到 ID 的轉換。
圖 6 檢測信號
- // Snippet from the header file – Wait is a quick, inline method
- DWORD Wait(DWORD dwTimeoutMs, BOOL bWaitAll = FALSE)
- {
- return TranslateWaitResult(
- WaitForMultipleObjects( m_nHandles,
- m_pHandles,
- bWaitAll,
- dwTimeoutMs )
- );
- }
- // Snippet from the CPP file – method called by all flavors of Wait
- DWORD DynWaitlistImpl::TranslateWaitResult(
- DWORD dwWaitResult ) // Value returned by WaitForMultipleObjectsXXX
- // translates the index-based value returned by Windows into
- // an ID-based value for comparison
- {
- if( (dwWaitResult >= WAIT_OBJECT_0) &&
- (dwWaitResult < (DWORD)(WAIT_OBJECT_0 + m_nHandles) ) )
- {
- return HANDLE_SIGNALED | m_pIds[dwWaitResult - WAIT_OBJECT_0];
- }
- if( (dwWaitResult >= WAIT_ABANDONED_0) &&
- (dwWaitResult < (DWORD)(WAIT_ABANDONED_0 + m_nHandles) ) )
- {
- return HANDLE_ABANDONED | m_pIds[dwWaitResult - WAIT_ABANDONED_0];
- }
- return dwWaitResult; // No translation needed for other values
- }
咱們正在跨入「多核」計算世界,咱們經過多線程執行工做,從而提升效率。在這個世界中,事件多路複用是否會更重要呢?大多數應用程序會最終以每一個線程一個事件的方式運行,從而抵消 DynWaitList 的優勢嗎?
我想是不會的。我相信,即便對於使用多核的計算機,事件多路複用也是重要的,其緣由至少有以下兩點:
總之,將非臨時 ID 與傳遞到 Windows WaitForMultipleObjects 函數的每一個事件關聯能夠簡化代碼並下降錯誤的可能性,緣由是它減輕了應用程序將無心義的事件索引轉換爲有用對象句柄或指針的負擔。DynWaitList 類將此關聯進程有效地封裝在這些 Windows API 等待函數的包裝內。涉及的全部操做都屬於 1 階,但構造和句柄刪除除外,它們屬於 N 階。經過對數組排序能夠進行進一步優化,這在提升句柄刪除速度的同時,會輕微下降句柄添加操做的性能。