解開 Windows 下的臨界區中的代碼死結【轉自MSDN】

解開 Windows 下的臨界區中的代碼死結發布日期： 1/13/2005 | 更新日期： 1/13/2005

Matt Pietrek和 Russ Osterlund

本文假定您熟悉 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 組成臨界區的公用介面：

InitializeCriticalSectionInitializeCriticalSectionAndSpinCountDeleteCriticalSectionTryEnterCriticalSectionEnterCriticalSectionLeaveCriticalSection

前兩個 API 只是分別圍繞 NTDLL API RtlInitializeCriticalSection 和 RtlInitializeCriticalSectionAndSpinCount 的瘦封裝。所有剩餘常式都被提交給 NTDLL 中的函數。另外，對 RtlInitializeCriticalSection 的調用是另一個圍繞 RtlInitializeCriticalSectionAndSpinCount 調用的瘦封裝，其旋轉數的值為 0。使用臨界區的時候實際上是在幕後使用以下 NTDLL API：

RtlInitializeCriticalSectionAndSpinCountRtlEnterCriticalSectionRtlTryEnterCriticalSectionRtlLeaveCriticalSectionRtlDeleteCriticalSection

在這一討論中，我們採用 Kernel32 名稱，因為大多數 Win32 程式員對它們更為熟悉。

InitializeCriticalSectionAndSpinCount 對臨界區的初始化非常簡單。RTL_CRITICAL_SECTION 結構中的欄位被賦予其起始值。與此類似，分配 RTL_CRITICAL_SECTION_DEBUG 結構並對其進行初始化，將 RtlLogStackBackTraces 調用中的傳回值賦予 CreatorBackTraceIndex，並建立到前面臨界區的連結。

順便說一聲，CreatorBackTraceIndex 一般接收到的值為 0。但是，如果有 Gflags 和 Umdh 工具 + 生產力，可以輸入以下命令：

Gflags /i MyProgram.exe +ustGflags /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 的等待，以及對等待結果的處理。預設情況是將一個null 指標作為第三個參數傳遞給 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 的偵錯符號）：

RtlCriticalSectionLockDeferedCriticalSection (this is the actual spelling!)LoaderLockFastPebLockRtlpCalloutEntryLockPMCritSectUMLogCritSectRtlpProcessHeapsListLock

因為檢查進程環境塊 (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。