本文假定您熟悉 Win32、C++ 和多線程處理。
下載本文的代碼：CriticalSections.exe (415KB)
摘要
臨 界區是一種防止多個線程同時執行一個特定代碼節的機制，這一主題並沒有引起太多關注，因而人們未能對其深刻理解。在需要跟蹤代碼中的多線程處理的性能時， 對 Windows 中臨界區的深刻理解非常有用。 本文深入研究臨界區的原理，以揭示在查找死鎖和確認性能問題過程中的有用信息。它還包含一個便利的實用工具程序，可以顯示所有臨界區及其當前狀態。
在 我們許多年的編程實踐中，對於 Win32® 臨界區沒有受到非常多的“under the hood”關注而感到非常奇怪。當然，您可能瞭解有關臨界區初始化與使用的基礎知識，但您是否曾經花費時間來深入研究 WINNT.H 中所定義的 CRITICAL_SECTION 結構呢？在這一結構中有一些非常有意義的好東西被長期忽略。我們將對此進行補充，並向您介紹一些很有意義的技巧，這些技巧對於跟蹤那些難以察覺的多線程處 理錯誤非常有用。更重要的是，使用我們的 MyCriticalSections 實用工具，可以明白如何對 CRITICAL_SECTION 進行微小地擴展，以提供非常有用的特性，這些特性可用於調試和性能調整（要下載完整代碼，參見本文頂部的鏈接）。
老實說，作者們經常忽略 CRITICAL_SECTION 結構的部分原因在於它在以下兩個主要 Win32 代碼庫中的實現有很大不同：Microsoft® Windows® 95 和 Windows NT®。人們知道這兩種代碼庫都已經發展出大量後續版本（其最新版本分別爲 Windows Me 和 Windows XP），但沒有必要在此處將其一一列出。關鍵在於 Windows XP 現在已經發展得非常完善，開發商可能很快就會停止對 Windows 95 系列操作系統的支持。我們在本文中就是這麼做的。
誠然，當今最受關注的是 Microsoft .NET Framework，但是良好的舊式 Win32 編程不會很快消失。如果您擁有采用了臨界區的現有 Win32 代碼，您會發現我們的工具以及對臨界區的說明都非常有用。但是請注意，我們只討論 Windows NT 及其後續版本，而沒有涉及與 .NET 相關的任何內容，這一點非常重要。
臨界區：簡述
如果您非常熟悉臨界區，並可以不假思索地進行應用，那就可以略過本節。否則，請向下閱讀，以對這些內容進行快速回顧。如果您不熟悉這些基礎內容，則本節之後的內容就沒有太大意義。
臨 界區是一種輕量級機制，在某一時間內只允許一個線程執行某個給定代碼段。通常在修改全局數據（如集合類）時會使用臨界區。事件、多用戶終端執行程序和信號 量也用於多線程同步，但臨界區與它們不同，它並不總是執行向內核模式的控制轉換，這一轉換成本昂貴。稍後將會看到，要獲得一個未佔用臨界區，事實上只需要 對內存做出很少的修改，其速度非常快。只有在嘗試獲得已佔用臨界區時，它纔會跳至內核模式。這一輕量級特性的缺點在於臨界區只能用於對同一進程內的線程進 行同步。
臨界區由 WINNT.H 中所定義的 RTL_CRITICAL_SECTION 結構表示。因爲您的 C++ 代碼通常聲明一個 CRITICAL_SECTION 類型的變量，所以您可能對此並不瞭解。研究 WINBASE.H 後您會發現：
typedef RTL_CRITICAL_SECTION CRITICAL_SECTION;
我們將在短時間內揭示 RTL_CRITICAL_SECTION 結構的實質。此時，重要問題在於 CRITICAL_SECTION（也稱作 RTL_CRITICAL_SECTION）只是一個擁有易訪問字段的結構，這些字段可以由 KERNEL32 API 操作。
在將臨界區傳遞給 InitializeCriticalSection 時（或者更準確地說，是在傳遞其地址時），臨界區即開始存在。初始化之後，代碼即將臨界區傳遞給 EnterCriticalSection 和 LeaveCriticalSection API。一個線程自 EnterCriticalSection 中返回後，所有其他調用 EnterCriticalSection 的線程都將被阻止，直到第一個線程調用 LeaveCriticalSection 爲止。最後，當不再需要該臨界區時，一種良好的編碼習慣是將其傳遞給 DeleteCriticalSection。
在臨界區未被使用的理 想情況中，對 EnterCriticalSection 的調用非常快速，因爲它只是讀取和修改用戶模式內存中的內存位置。否則（在後文將會遇到一種例外情況），阻止於臨界區的線程有效地完成這一工作，而不需要 消耗額外的 CPU 週期。所阻止的線程以內核模式等待，在該臨界區的所有者將其釋放之前，不能對這些線程進行調度。如果有多個線程被阻止於一個臨界區中，當另一線程釋放該臨 界區時，只有一個線程獲得該臨界區。
深入研究：RTL_CRITICAL_SECTION 結構
即使您已經在日常工作中使用 過臨界區，您也非常可能並沒有真正瞭解超出文檔之外的內容。事實上存在着很多非常容易掌握的內容。例如，人們很少知道一個進程的臨界區是保存於一個鏈表 中，並且可以對其進行枚舉。實際上，WINDBG 支持 !locks 命令，這一命令可以列出目標進程中的所有臨界區。我們稍後將要談到的實用工具也應用了臨界區這一鮮爲人知的特徵。爲了真正理解這一實用工具如何工作，有必 要真正掌握臨界區的內部結構。記着這一點，現在開始研究 RTL_CRITICAL_SECTION 結構。爲方便起見，將此結構列出如下：
struct RTL_CRITICAL_SECTION
{
PRTL_CRITICAL_SECTION_DEBUG DebugInfo;
LONG LockCount;
LONG RecursionCount;
HANDLE OwningThread;
HANDLE LockSemaphore;
ULONG_PTR SpinCount;
};
以下各段對每個字段進行說明。
DebugInfo 此字段包含一個指針，指向系統分配的伴隨結構，該結構的類型爲 RTL_CRITICAL_SECTION_DEBUG。這一結構中包含更多極有價值的信息，也定義於 WINNT.H 中。我們稍後將對其進行更深入地研究。
LockCount 這是臨界區中最重要的一個字段。它被初始化爲數值 -1；此數值等於或大於 0 時，表示此臨界區被佔用。當其不等於 -1 時，OwningThread 字段（此字段被錯誤地定義於 WINNT.H 中 — 應當是 DWORD 而不是 HANDLE）包含了擁有此臨界區的線程 ID。此字段與 (RecursionCount -1) 數值之間的差值表示有多少個其他線程在等待獲得該臨界區。
RecursionCount 此字段包含所有者線程已經獲得該臨界區的次數。如果該數值爲零，下一個嘗試獲取該臨界區的線程將會成功。
OwningThread 此字段包含當前佔用此臨界區的線程的線程標識符。此線程 ID 與 GetCurrentThreadId 之類的 API 所返回的 ID 相同。
LockSemaphore 此字段的命名不恰當，它實際上是一個自復位事件，而不是一個信號。它是一個內核對象句柄，用於通知操作系統：該臨界區現在空閒。操作系統在一個線程第一次 嘗試獲得該臨界區，但被另一個已經擁有該臨界區的線程所阻止時，自動創建這樣一個句柄。應當調用 DeleteCriticalSection（它將發出一個調用該事件的 CloseHandle 調用，並在必要時釋放該調試結構），否則將會發生資源泄漏。
SpinCount 僅用於多處理器系統。MSDN® 文檔對此字段進行如下說明：“在多處理器系統中，如果該臨界區不可用，調用線程將在對與該臨界區相關的信號執行等待操作之前，旋轉 dwSpinCount 次。如果該臨界區在旋轉操作期間變爲可用，該調用線程就避免了等待操作。”旋轉計數可以在多處理器計算機上提供更佳性能，其原因在於在一個循環中旋轉通常 要快於進入內核模式等待狀態。此字段默認值爲零，但可以用 InitializeCriticalSectionAndSpinCount API 將其設置爲一個不同值。
RTL_CRITICAL_SECTION_DEBUG 結構
前面我們注意到，在 RTL_CRITICAL_SECTION 結構內，DebugInfo 字段指向一個 RTL_CRITICAL_SECTION_DEBUG 結構，該結構給出如下：
struct _RTL_CRITICAL_SECTION_DEBUG
{
WORD Type;
WORD CreatorBackTraceIndex;
RTL_CRITICAL_SECTION *CriticalSection;
LIST_ENTRY ProcessLocksList;
DWORD EntryCount;
DWORD ContentionCount;
DWORD Spare[ 2 ];
}
這一結構由 InitializeCriticalSection 分配和初始化。它既可以由 NTDLL 內的預分配數組分配，也可以由進程堆分配。RTL_CRITICAL_SECTION 的這一伴隨結構包含一組匹配字段，具有迥然不同的角色：有兩個難以理解，隨後兩個提供了理解這一臨界區鏈結構的關鍵，兩個是重複設置的，最後兩個未使用。
下面是對 RTL_CRITICAL_SECTION 字段的說明。
Type 此字段未使用，被初始化爲數值 0。
CreatorBackTraceIndex 此字段僅用於診斷情形中。在註冊表項 HKLM/Software/Microsoft/Windows NT/CurrentVersion/Image File Execution Options/YourProgram 之下是 keyfield、GlobalFlag 和 StackTraceDatabaseSizeInMb 值。注意，只有在運行稍後說明的 Gflags 命令時纔會顯示這些值。這些註冊表值的設置正確時，CreatorBackTraceIndex 字段將由堆棧跟蹤中所用的一個索引值填充。在 MSDN 中搜索 GFlags 文檔中的短語“create user mode stack trace database”和“enlarging the user-mode stack trace database”，可以找到有關這一內容的更多信息。
CriticalSection 指向與此結構相關的 RTL_CRITICAL_SECTION。圖 1 說明該基礎結構以及 RTL_CRITICAL_SECTION、RTL_CRITICAL_SECTION_DEBUG 和事件鏈中其他參與者之間的關係。
圖 1 臨界區處理流程
ProcessLocksList LIST_ENTRY 是用於表示雙向鏈表中節點的標準 Windows 數據結構。RTL_CRITICAL_SECTION_DEBUG 包含了鏈表的一部分，允許向前和向後遍歷該臨界區。本文後面給出的實用工具說明如何使用 Flink（前向鏈接）和 Blink（後向鏈接）字段在鏈表中的成員之間移動。任何從事過設備驅動程序或者研究過 Windows 內核的人都會非常熟悉這一數據結構。
EntryCount/ContentionCount 這些字段在相同的時間、出於相同的原因被遞增。這是那些因爲不能馬上獲得臨界區而進入等待狀態的線程的數目。與 LockCount 和 RecursionCount 字段不同，這些字段永遠都不會遞減。
Spares 這兩個字段未使用，甚至未被初始化（儘管在刪除臨界區結構時將這些字段進行了清零）。後面將會說明，可以用這些未被使用的字段來保存有用的診斷值。
即 使 RTL_CRITICAL_SECTION_DEBUG 中包含多個字段，它也是常規臨界區結構的必要成分。事實上，如果系統恰巧不能由進程堆中獲得這一結構的存儲區， InitializeCriticalSection 將返回爲 STATUS_NO_MEMORY 的 LastError 結果，然後返回處於不完整狀態的臨界區結構。
臨界區狀態
當程序執行、進入與離開臨界區時， RTL_CRITICAL_SECTION 和 RTL_CRITICAL_SECTION_DEBUG 結構中的字段會根據臨界區所處的狀態變化。這些字段由臨界區 API 中的簿記代碼更新，在後面將會看到這一點。如果程序爲多線程，並且其線程訪問是由臨界區保護的公用資源，則這些狀態就更有意義。
但是，不管 代碼的線程使用情況如何，有兩種狀態都會出現。第一種情況，如果 LockCount 字段有一個不等於 -1 的數值，此臨界區被佔用，OwningThread 字段包含擁有該臨界區的線程的線程標識符。在多線程程序中，LockCount 與 RecursionCount 聯合表明當前有多少線程被阻止於該臨界區。第二種情況，如果 RecursionCount 是一個大於 1 的數值，其告知您所有者線程已經重新獲得該臨界區多少次（也許不必要），該臨界區既可以通過調用 EnterCriticalSection、也可以通過調用 TryEnterCriticalSection 獲得。大於 1 的任何數值都表示代碼的效率可能較低或者可能在以後發生錯誤。例如，訪問公共資源的任何 C++ 類方法可能會不必要地重新進入該臨界區。
注 意，在大多數時間裏，LockCount 與 RecursionCount 字段中分別包含其初始值 -1 和 0，這一點非常重要。事實上，對於單線程程序，不能僅通過檢查這些字段來判斷是否曾獲得過臨界區。但是，多線程程序留下了一些標記，可以用來判斷是否有兩 個或多個線程試圖同時擁有同一臨界區。
您可以找到的標記之一是即使在該臨界區未被佔用時 LockSemaphore 字段中仍包含一個非零值。這表示：在某一時間，此臨界區阻止了一個或多個線程 — 事件句柄用於通知該臨界區已被釋放，等待該臨界區的線程之一現在可以獲得該臨界區並繼續執行。因爲 OS 在臨界區阻止另一個線程時自動分配事件句柄，所以如果您在不再需要臨界區時忘記將其刪除，LockSemaphore 字段可能會導致程序中發生資源泄漏。
在多線程程序中可能遇到的另一狀態是 EntryCount 和 ContentionCount 字段包含一個大於零的數值。這兩個字段保存有臨界區對一個線程進行阻止的次數。在每次發生這一事件時，這兩個字段被遞增，但在臨界區存在期間不會被遞減。 這些字段可用於間接確定程序的執行路徑和特性。例如，EntryCount 非常高時則意味着該臨界區經歷着大量爭用，可能會成爲代碼執行過程中的一個潛在瓶頸。
在研究一個死鎖程序時，還會發現一種似乎無法進行邏輯 解釋的狀態。一個使用非常頻繁的臨界區的 LockCount 字段中包含一個大於 -1 的數值，也就是說它被線程所擁有，但是 OwningThread 字段爲零（這樣就無法找出是哪個線程導致問題）。測試程序是多線程的，在單處理器計算機和多處理器計算機中都會出現這種情況。儘管 LockCount 和其他值在每次運行中都不同，但此程序總是死鎖於同一臨界區。我們非常希望知道是否有任何其他開發人員也遇到了導致這一狀態的 API 調用序列。
構建一個更好的捕鼠器
在 我們學習臨界區的工作方式時，非常偶然地得到一些重要發現，利用這些發現可以得到一個非常好的實用工具。第一個發現是 ProcessLocksList LIST_ENTRY 字段的出現，這使我們想到進程的臨界區可能是可枚舉的。另一個重大發現是我們知道了如何找出臨界區列表的頭。還有一個重要發現是可以在沒有任何損失的情況 下寫 RTL_CRITICAL_SECTION 的 Spare 字段（至少在我們的所有測試中如此）。我們還發現可以很容易地重寫系統的一些臨界區例程，而不需要對源文件進行任何修改。
最初，我們由一個 簡單的程序開始，其檢查一個進程中的所有臨界區，並列出其當前狀態，以查看是否擁有這些臨界區。如果擁有，則找出由哪個線程擁有，以及該臨界區阻止了多少 個線程？這種做法對於 OS 的狂熱者們比較適合，但對於只是希望有助於理解其程序的典型的程序員就不是非常有用了。
即使是在最簡單的控制 臺模式“Hello World”程序中也存在許多臨界區。其中大部分是由 USER32 或 GDI32 之類的系統 DLL 創建，而這些 DLL 很少會導致死鎖或性能問題。我們希望有一種方法能濾除這些臨界區，而只留下代碼中所關心的那些臨界區。 RTL_CRITICAL_SECTION_DEBUG 結構中的 Spare 字段可以很好地完成這一工作。可以使用其中的一個或兩個來指示：這些臨界區是來自用戶編寫的代碼，而不是來自 OS。
於是，下一個邏輯問題就變爲如何確定哪些臨界區是來自您編寫的代碼。有些讀者可能還記得 Matt Pietrek 2001 年 1 月的 Under The Hood 專欄中的 LIBCTINY.LIB。LIBCTINY 所採用的一個技巧是一個 LIB 文件，它重寫了關鍵 Visual C++ 運行時例程的標準實現。將 LIBCTINY.LIB 文件置於鏈接器行的其他 LIB 之前，鏈接器將使用這一實現，而不是使用 Microsoft 所提供的導入庫中的同名後續版本。
爲對臨界區應用類似技巧，我們創建 InitializeCriticalSection 的一個替代版本及其相關導入庫。將此 LIB 文件置於 KERNEL32.LIB 之前，鏈接器將鏈接我們的版本，而不是 KERNEL32 中的版本。對 InitializeCriticalSection 的實現顯示在圖 2 中。此代碼在概念上非常簡單。它首先調用 KERNEL32.DLL 中的實際 InitializeCriticalSection。接下來，它獲得調用 InitializeCriticalSection 的代碼地址，並將其貼至 RTL_CRITICAL_SECTION_DEBUG 結構的備用字段之一。我們的代碼如何確定調用代碼的地址呢？x86 CALL 指令將返回地址置於堆棧中。CriticalSectionHelper 代碼知道該返回地址位於堆棧幀中一個已知的固定位置。
實 際結果是：與 CriticalSectionHelper.lib 正確鏈接的任何 EXE 或 DLL 都將導入我們的 DLL (CriticalSectionHelper.DLL)，並佔用應用了備用字段的臨界區。這樣就使事情簡單了許多。現在我們的實用工具可以簡單地遍歷進 程中的所有臨界區，並且只顯示具有正確填充的備用字段的臨界區信息。那麼需要爲這一實用工具付出什麼代價呢？請稍等，還有更多的內容！
因爲 您的所有臨界區現在都包含對其進行初始化時的地址，實用工具可以通過提供其初始化地址來識別各個臨界區。原始代碼地址本身沒有那麼有用。幸運的是， DBGHELP.DLL 使代碼地址向源文件、行號和函數名稱的轉換變得非常容易。即使一個臨界區中沒有您在其中的簽名，也可以將其地址提交給 DBGHELP.DLL。如果將其聲明爲一個全局變量，並且如果符號可用，則您就可以在原始源代碼中確定臨界區的名稱。順便說明一下，如果通過設置 _NT_SYMBOL_PATH 環境變量，並設置 DbgHelp 以使用其 Symbol Server 下載功能，從而使 DbgHelp 發揮其效用，則會得到非常好的結果。
MyCriticalSections 實用工具
我們將所有這些思想結合起來，提出了 MyCriticalSections 程序。MyCriticalSections 是一個命令行程序，在不使用參數運行該程序時可以看到一些選項：
Syntax: MyCriticalSections <PID> [options]
Options:
/a = all critical sections
/e = show only entered critical sections
/v = verbose
唯一需要的參數是 Program ID 或 PID（十進制形式）。可以用多種方法獲得 PID，但最簡單的方法可能就是通過 Task Manager。在沒有其他選項時，MyCriticalSections 列出了來自代碼模塊的所有臨界區狀態，您已經將 CriticalSectionHelper.DLL 鏈接至這些代碼模塊。如果有可用於這一（些）模塊的符號，代碼將嘗試提供該臨界區的名稱，以及對其進行初始化的位置。
要查看 MyCriticalSections 是如何起作用的，請運行 Demo.EXE 程序，該程序包含在下載文件中。Demo.EXE 只是初始化兩個臨界區，並由一對線程進入這兩個臨界區。圖 3 顯示運行“MyCriticalSections 2040”的結果（其中 2040 爲 Demo.EXE 的 PID）。
在 該圖中，列出了兩個臨界區。在本例中，它們被命名爲 csMain 和 yetAnotherCriticalSection。每個“Address:”行顯示了 CRITICAL_SECTION 的地址及其名稱。“Initialized in”行包含了在其中初始化 CRITICAL_SECTION 的函數名。代碼的“Initialized at”行顯示了源文件和初始化函數中的行號。
對於 csMain 臨界區，您將看到鎖定數爲 0、遞歸數爲 1，表示一個已經被一線程獲得的臨界區，並且沒有其他線程在等待該臨界區。因爲從來沒有線程被阻止於該臨界區，所以 Entry Count 字段爲 0。
現 在來看 yetAnotherCriticalSection，會發現其遞歸數爲 3。快速瀏覽 Demo 代碼可以看出：主線程調用 EnterCriticalSection 三次，所以事情的發生與預期一致。但是，還有一個第二線程試圖獲得該臨界區，並且已經被阻止。同樣，LockCount 字段也爲 3。此輸出顯示有一個等待線程。
MyCriticalSections 擁有一些選項，使其對於更爲勇敢的探索者非常有用。/v 開關顯示每個臨界區的更多信息。旋轉數與鎖定信號字段尤爲重要。您經常會看到 NTDLL 和其他 DLL 擁有一些旋轉數非零的臨界區。如果一個線程在獲得臨界區的過程中曾被鎖定，則鎖定信號字段爲非零值。/v 開關還顯示了 RTL_CRITICAL_SECTION_DEBUG 結構中備用字段的內容。
/a 開關顯示進程中的所有臨界區，即使其中沒有 CriticalSectionHelper.DLL 簽名也會顯示。如果使用 /a，則請做好有大量輸出的準備。真正的黑客希望同時使用 /a 和 /v，以顯示進程中全部內容的最多細節。使用 /a 的一個小小的好處是會看到 NTDLL 中的LdrpLoaderLock 臨界區。此臨界區在 DllMain 調用和其他一些重要時間內被佔用。LdrpLoaderLock 是許多不太明顯、表面上難以解釋的死鎖的形成原因之一。（爲使 MyCriticalSection 能夠正確標記 LdrpLoaderLock 實例，需要用於 NTDLL 的 PDB 文件可供使用。）
/e 開關使程序僅顯示當前被佔用的臨界區。未使用 /a 開關時，只顯示代碼中被佔用的臨界區（如備用字段中的簽名所指示）。採用 /a 開關時，將顯示進程中的全部被佔用臨界區，而不考慮其來源。
那麼，希望什麼時候運行 MyCriticalSections 呢？一個很明確的時間是在程序被死鎖時。檢查被佔用的臨界區，以查看是否有什麼使您驚訝的事情。即使被死鎖的程序正運行於調試器的控制之下，也可以使用 MyCriticalSections。
另 一種使用 MyCriticalSections 的時機是在對有大量多線程的程序進行性能調整時。在阻塞於調試器中的一個使用頻繁、非重入函數時，運行 MyCriticalSections，查看在該時刻佔用了哪些臨界區。如果有很多線程都執行相同任務，就非常容易導致一種情形：一個線程的大部分時間被 消耗在等待獲得一個使用頻繁的臨界區上。如果有多個使用頻繁的臨界區，這造成的後果就像花園的澆水軟管打了結一樣。解決一個爭用問題只是將問題轉移到下一 個容易造成阻塞的臨界區。
一個查看哪些臨界區最容易導致爭用的好方法是在接近程序結尾處設置一個斷點。在遇到斷點時，運行 MyCriticalSections 並查找具有最大 Entry Count 值的臨界區。正是這些臨界區導致了大多數阻塞和線程轉換。
盡 管 MyCriticalSections 運行於 Windows 2000 及更新版本，但您仍需要一個比較新的 DbgHelp.DLL 版本 － 5.1 版或更新版本。Windows XP 中提供這一版本。也可以由其他使用 DbgHelp 的工具中獲得該版本。例如，Debugging Tools For Windows 下載中通常擁有最新的 DbgHelp.DLL。
深入研究重要的臨界區例程
此最後一節是爲那些希望理解臨界區實現內幕的勇敢讀者提供的。對 NTDLL 進行仔細研究後可以爲這些例程及其支持子例程創建僞碼（見下載中的 NTDLL(CriticalSections).cpp）。以下 KERNEL32 API 組成臨界區的公共接口：
InitializeCriticalSection
InitializeCriticalSectionAndSpinCount
DeleteCriticalSection
TryEnterCriticalSection
EnterCriticalSection
LeaveCriticalSection
前兩個 API 只是分別圍繞 NTDLL API RtlInitializeCriticalSection 和 RtlInitializeCriticalSectionAndSpinCount 的瘦包裝。所有剩餘例程都被提交給 NTDLL 中的函數。另外，對 RtlInitializeCriticalSection 的調用是另一個圍繞 RtlInitializeCriticalSectionAndSpinCount 調用的瘦包裝，其旋轉數的值爲 0。使用臨界區的時候實際上是在幕後使用以下 NTDLL API：
RtlInitializeCriticalSectionAndSpinCount
RtlEnterCriticalSection
RtlTryEnterCriticalSection
RtlLeaveCriticalSection
RtlDeleteCriticalSection
在這一討論中，我們採用 Kernel32 名稱，因爲大多數 Win32 程序員對它們更爲熟悉。
InitializeCriticalSectionAndSpinCount 對臨界區的初始化非常簡單。RTL_CRITICAL_SECTION 結構中的字段被賦予其起始值。與此類似，分配 RTL_CRITICAL_SECTION_DEBUG 結構並對其進行初始化，將 RtlLogStackBackTraces 調用中的返回值賦予 CreatorBackTraceIndex，並建立到前面臨界區的鏈接。
順便說一聲，CreatorBackTraceIndex 一般接收到的值爲 0。但是，如果有 Gflags 和 Umdh 實用工具，可以輸入以下命令：
Gflags /i MyProgram.exe +ust
Gflags /i MyProgram.exe /tracedb 24
這些命令使得 MyProgram 的“Image File Execution Options”下添加了註冊表項。在下一次執行 MyProgram 時會看到此字段接收到一個非 0 數值。有關更多信息，參閱知識庫文章 Q268343“Umdhtools.exe:How to Use Umdh.exe to Find Memory Leaks”。臨界區初始化中另一個需要注意的問題是：前 64 個 RTL_CRITICAL_SECTION_DEBUG 結構不是由進程堆中分配，而是來自位於 NTDLL 內的 .data 節的一個數組。
在 完成臨界區的使用之後，對 DeleteCriticalSection（其命名不當，因爲它只刪除 RTL_CRITICAL_SECTION_ DEBUG）的調用遍歷一個同樣可理解的路徑。如果由於線程在嘗試獲得臨界區時被阻止而創建了一個事件，將通過調用 ZwClose 來銷燬該事件。接下來，在通過 RtlCriticalSectionLock 獲得保護之後（NTDLL 以一個臨界區保護它自己的內部臨界區列表 — 您猜對了），將調試信息從鏈中清除，對該臨界區鏈表進行更新，以反映對該信息的清除操作。該內存由空值填充，並且如果其存儲區是由進程堆中獲得，則調用 RtlFreeHeap 將使得其內存被釋放。最後，以零填充 RTL_CRITICAL_SECTION。
有兩個 API 要獲得受臨界區保護的資源 — TryEnterCriticalSection 和 EnterCriticalSection。如果一個線程需要進入一個臨界區，但在等待被阻止資源變爲可用的同時，可執行有用的工作，那麼 TryEnterCriticalSection 正是您需要的 API。此例程測試此臨界區是否可用；如果該臨界區被佔用，該代碼將返回值 FALSE，爲該線程提供繼續執行另一任務的機會。否則，其作用只是相當於 EnterCriticalSection。
如果該線程在繼續 進行之前確實需要擁有該資源，則使用 EnterCriticalSection。此時，取消用於多處理器計算機的 SpinCount 測試。這一例程與 TryEnterCriticalSection 類似，無論該臨界區是空閒的或已經被該線程所擁有，都調整對該臨界區的簿記。注意，最重要的 LockCount 遞增是由 x86“lock”前綴完成的，這一點非常重要。這確保了在某一時間內只有一個 CPU 可以修改該 LockCount 字段。（事實上，Win32 InterlockedIncrement API 只是一個具有相同鎖定前綴的 ADD 指令。）
如果調用線程無法立即獲得該臨界區，則 調用 RtlpWaitForCriticalSection 將該線程置於等待狀態。在多處理器系統中，EnterCriticalSection 旋轉 SpinCount 所指定的次數，並在每次循環訪問中測試該臨界區的可用性。如果此臨界區在循環期間變爲空閒，該線程獲得該臨界區，並繼續執行。
RtlpWaitForCriticalSection 可能是這裏所給的所有過程中最爲複雜、最爲重要的一個。這並不值得大驚小怪，因爲如果存在一個死鎖並涉及臨界區，則利用調試器進入該進程就可能顯示出 RtlpWaitForCriticalSection 內 ZwWaitForSingleObject 調用中的至少一個線程。
如僞碼 中所顯示，在 RtlpWaitForCriticalSection 中有一點簿記工作，如遞增 EntryCount 和 ContentionCount 字段。但更重要的是：發出對 LockSemaphore 的等待，以及對等待結果的處理。默認情況是將一個空指針作爲第三個參數傳遞給 ZwWaitForSingleObject 調用，請求該等待永遠不要超時。如果允許超時，將生成調試消息字符串，並再次開始等待。如果不能從等待中成功返回，就會產生中止該進程的錯誤。最後，在從 ZwWaitForSingleObject 調用中成功返回時，則執行從 RtlpWaitForCriticalSection 返回，該線程現在擁有該臨界區。
RtlpWaitForCriticalSection 必須認識到的一個臨界條件是該進程正在被關閉，並且正在等待加載程序鎖定 (LdrpLoaderLock) 臨界區。RtlpWaitForCriticalSection 一定不能 允許該線程被阻止，但是必須跳過該等待，並允許繼續進行關閉操作。
LeaveCriticalSection 不像 EnterCriticalSection 那樣複雜。如果在遞減 RecursionCount 之後，結果不爲 0（意味着該線程仍然擁有該臨界區），則該例程將以 ERROR_SUCCESS 狀態返回。這就是爲什麼需要用適當數目的 Leave 調用來平衡 Enter 調用。如果該計數爲 0，則 OwningThread 字段被清零，LockCount 被遞減。如果還有其他線程在等待，例如 LockCount 大於或等於 0，則調用 RtlpUnWaitCriticalSection。此幫助器例程創建 LockSemaphore（如果其尚未存在），併發出該信號提醒操作系統：該線程已經釋放該臨界區。作爲通知的一部分，等待線程之一退出等待狀態，爲運 行做好準備。
最後要說明的一點是，MyCriticalSections 程序如何確定臨界區鏈的起始呢？如果有權訪問 NTDLL 的正確調試符號，則對該列表的查找和遍歷非常簡單。首先，定位符號 RtlCriticalSectionList，清空其內容（它指向第一個 RTL_CRITICAL_SECTION_DEBUG 結構），並開始遍歷。但是，並不是所有的系統都有調試符號，RtlCriticalSectionList 變量的地址會隨 Windows 的各個版本而發生變化。爲了提供一種對所有版本都能正常工作的解決方案，我們設計了以下試探性方案。觀察啓動一個進程時所採取的步驟，會看到是以以下順序 對 NTDLL 中的臨界區進行初始化的（這些名稱取自 NTDLL 的調試符號）：
RtlCriticalSectionLock
DeferedCriticalSection (this is the actual spelling!)
LoaderLock
FastPebLock
RtlpCalloutEntryLock
PMCritSect
UMLogCritSect
RtlpProcessHeapsListLock
因爲檢查進程環境塊 (PEB) 中偏移量 0xA0 處的地址就可以找到加載程序鎖，所以對該鏈起始位置的定位就變得比較簡單。我們讀取有關加載程序鎖的調試信息，然後沿着鏈向後遍歷兩個鏈接，使我們定位於 RtlCriticalSectionLock 項，在該點得到該鏈的第一個臨界區。有關其方法的說明，請參見圖 4。
圖 4 初始化順序
小結
幾 乎所有的多線程程序均使用臨界區。您遲早都會遇到一個使代碼死鎖的臨界區，並且會難以確定是如何進入當前狀態的。如果能夠更深入地瞭解臨界區的工作原理， 則這一情形的出現就不會像首次出現時那樣的令人沮喪。您可以研究一個看來非常含糊的臨界區，並確定是誰擁有它，以及其他有用細節。如果您願意將我們的庫加 入您的鏈接器行，則可以容易地獲得有關您程序臨界區使用的大量信息。通過利用臨界區結構中的一些未用字段，我們的代碼可以僅隔離並命名您的模塊所用的臨界 區，並告知其準確狀態。
有魄力的讀者可以很容易地對我們的代碼進行擴展，以完成更爲異乎尋常的工作。例如，採用與 InitializeCriticalSection 掛鉤相類似的方式截獲 EnterCriticalSection 和 LeaveCriticalSection，可以存儲最後一次成功獲得和釋放該臨界區的位置。與此類似，CritSect DLL 擁有一個易於調用的 API，用於枚舉您自己的代碼中的臨界區。利用 .NET Framework 中的 Windows 窗體，可以相對容易地創建一個 GUI 版本的 MyCriticalSections。對我們代碼進行擴展的可能性非常大，我們非常樂意看到其他人員所發現和創造的創新性辦法。
有關文章，請參閱：
Global Flag Reference:Create kernel mode stack trace database
GFlags Examples:Enlarging the User-Mode Stack Trace Database
Under the Hood:Reduce EXE and DLL Size with LIBCTINY.LIB
Matt Pietrek 是一位軟件架構師和作者。他就職於 Compuware/NuMega 實驗室，身份爲 BoundsChecker 和“分佈式分析器”產品的首席架構師。他已經創作了三本有關 Windows 系統編程的書籍，並是 MSDN Magazine 的特約編輯。他的 Web 站點 (http://www.wheaty.net) 有關於以前文章和專欄的 FAQ 和信息。
Jay Hilyard 是 Compuware/NuMega 實驗室的 BoundsChecker 小組的軟件工程師。他、他的妻子和他們的貓是新罕布什爾州的新居民。他的聯繫方式爲 [email protected] 或 Web 站點 http://www.smidgeonsoft.com。