摘要
臨界區是一種防止多個線程同時執行一個特定代碼節的機制，這一主題并沒有引起太多關注，因而人們未能對其深刻理解。在需要跟蹤代碼中的多線程處理的性能時，對
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
次。如果該臨界區在旋轉操作期間變為可用，該調用線程就避免了等待操作?！毙D計數可以在多處理器計算機上提供更佳性能，其原因在于在一個循環中旋轉通常要快于進入內核模式等待狀態。此字段默認值為零，但可以用
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)，并占用應用了備用字段的臨界區。這樣就使事情簡單了許多?，F在我們的實用工具可以簡單地遍歷進程中的所有臨界區，并且只顯示具有正確填充的備用字段的臨界區信息。那么需要為這一實用工具付出什么代價呢？請稍等，還有更多的內容！
因為您的所有臨界區現在都包含對其進行初始化時的地址，實用工具可以通過提供其初始化地址來識別各個臨界區。原始代碼地址本身沒有那么有用。幸運的是，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（十進制形式）?？梢杂枚喾N方法獲得 PID，但最簡單的方法可能就是通過 Task
Manager。在沒有其他選項時，MyCriticalSections 列出了來自代碼模塊的所有臨界區狀態，您已經將
CriticalSectionHelper.DLL
鏈接至這些代碼模塊。如果有可用于這一（些）模塊的符號，代碼將嘗試提供該臨界區的名稱，以及對其進行初始化的位置。
要查看 MyCriticalSections 是如何起作用的，請運行 Demo.EXE 程序，該程序包含在下載文件中。Demo.EXE
只是初始化兩個臨界區，并由一對線程進入這兩個臨界區。圖 3 顯示運行“MyCriticalSections 2040”的結果（其中 2040 為 Demo.EXE 的
PID）。
在該圖中，列出了兩個臨界區。在本例中，它們被命名為 csMain 和 yetAnotherCriticalSection。每個“Address:”行顯示了
CRITICAL_SECTION 的地址及其名稱?！癐nitialized in”行包含了在其中初始化 CRITICAL_SECTION
的函數名。代碼的“Initialized at”行顯示了源文件和初始化函數中的行號。
對于 csMain 臨界區，您將看到鎖定數為 0、遞歸數為
1，表示一個已經被一線程獲得的臨界區，并且沒有其他線程在等待該臨界區。因為從來沒有線程被阻止于該臨界區，所以 Entry Count 字段為 0。
現在來看 yetAnotherCriticalSection，會發現其遞歸數為 3?？焖贋g覽 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
小組的軟件工程師。他、他的妻子和他們的貓是新罕布什爾州的新居民。他的聯系方式為 RussOsterlund@adelphia.net 或 Web 站點 http://www.smidgeonsoft.com。