[2] 線程

在配置好WinDbg之后，我們載入一個CLR程序并執行至CLR被載入，然后開始我們的CLR探索之旅。

首先，使用!threads命令看看當前CLR中有哪些線程正在執行



以下為引用：

0:004> !threads
ThreadCount: 2
UnstartedThread: 0
BackgroundThread: 1
PendingThread: 0
DeadThread: 0
PreEmptive GC Alloc Lock
ID ThreadOBJ State GC Context Domain Count APT Exception
0 6ec 0014e708 6020 Enabled 00000000:00000000 00148a90 0 STA
2 a68 00157618 b220 Enabled 00000000:00000000 00148a90 0 MTA (Finalizer)




前面5個計數器分別表示托管(managed)線程、未啟動線程、后臺線程、阻塞線程和僵死線程的數量。
下面的列表是當前托管線程的詳細信息：第一個域是WinDbg的線程編號；ID是Win32線程ID；ThreadObj是線程的對象；State是一個標志位，以后再詳細介紹；PreEmptive GC表示GC是否與此線程協作；GC Alloc Context是GC的相關信息；Domain是線程所在AppDomain；Lock Count是線程擁有鎖的計數器；APT是線程類型，沿用COM中STA/MTA/NTA(netural)的概念；最后的Exception表示線程類型，除了普通的用戶線程外還有finalizer、GC、Theadpool Worker和Threadpool Completion Port，其功能與名字相符。

我們可以在.NET Framework SDK的Tool Developers Guide\Samples\sos子目錄下找到所有sos.dll支持命令的詳細說明；在rotor的clr\src\tools\sos子目錄下找到針對rotor系統的sos.dll的實現代碼。這份源代碼在功能上實現了與CLR正規發行版本基本上相同的功能，也是我們下面研究的主要目標之一。

其中Strike.cpp是sos功能命令的實現所在。每個sos的命令在strike.cpp中以一個函數實現，通過DECLARE_API宏定義函數參數。


以下為引用：

#define DECLARE_API(s) \
CPPMOD VOID \
s( \
HANDLE hCurrentProcess, \
HANDLE hCurrentThread, \
ULONG dwCurrentPc, \
ULONG dwProcessor, \
PCSTR args \
)




函數參數分別傳入WinDbg正在調試的進程句柄、當前線程句柄、當前指令地址、處理器和命令行參數信息。函數內再對此信息進行處理，輸出調試信息到WinDbg界面中。

讓我們先看看Threads命令(strike.cpp:1237)的實現原理。

Threads函數首先從一個全局線程存儲池中獲取當前線程統計信息，并將之存儲在一個結構并內打印統計值；然后調用GetThreadList函數(sos\util.cpp:2259)獲取線程列表；對每個線程獲取線程信息，并將之存儲在一個結構內并打印線程詳細信息；在打印線程信息時，會判斷此線程的類型，并打印相關信息。

首先來看看全局線程存儲池ThreadStore類(vm\threads.h:1998)的設計和使用思路。

CLR在啟動時，會通過 CoInitializeEE 函數(vm\ceemain.cpp:1100)初始化一個執行引擎(Execute Engine)，這兒的EE類似JVM的概念，實際上就是CLR的運行時環境。關于CLR的詳細啟動過程請參見筆者另外一篇文章《.Net平臺下CLR程序載入原理分析》。
CoInitializeEE函數使用全局變量保障每個進程最多只有一個CLR環境；對沒有構造CLR的進程，調用TryEEStartup函數(vm\ceemain.cpp:500)嘗試初始化CLR。偽代碼如下：


以下為引用：

HRESULT STDMETHODCALLTYPE CoInitializeEE(DWORD fFlags)
{
if(++g_RefCount <= 1 && !g_fEEStarted && !g_fEEInit)
{
g_EEStartupStatus = TryEEStartup(fFlags);
}
return SUCCEEDED(g_EEStartupStatus) ?
(SetupThread() ? S_OK : E_OUTOFMEMORY) : g_EEStartupStatus;
}




TryEEStartup函數則以異常安全策略包裝EEStartup函數(vm\ceemain.cpp:206)完成實際的CLR啟動工作。在EEStartup函數中會真正調用InitThreadManager函數(vm\Threads.cpp:2068)完成線程管理器的初始化工作。而InitThreadManager函數出了初始化TLS外，絕大部分工作是由實現ThreadStore類的Singleton模式的ThreadStore::InitThreadStore函數(vm\Threads.cpp:4345)實現的。其中保存全局唯一ThreadStore類實例的就是前面獲取線程統計信息的全局線程存儲池。


以下為引用：

ThreadStore *g_pThreadStore;

BOOL ThreadStore::InitThreadStore()
{
g_pThreadStore = new ThreadStore;

return (g_pThreadStore != NULL);
}





因此，ThreadStore類實際上是一個全局唯一的線程管理器，新增和終止一個CLR線程都需要在此存儲中更新相關信息。此線程管理器除了維護一個當前線程列表的鏈表外，還維護了一套線程相關信息的統計值。前面Threads命令獲取的幾個統計值就是從此而來。而獲取當前線程列表的GetThreadList函數(sos\util.cpp:2259)，實際上也是直接從線程管理器的線程列表中獲取每個線程對象的入口。

最后來看看線程信息的獲取步驟。

每個線程Thread類(vm\Threads.h:544)的對象表示一個managed線程。此線程是一個邏輯上的線程，如果被啟動則可能直接對應于一個系統的物理線程。而一個物理線程則無需綁定到一個被管理的邏輯線程上，物理線程卻可以在多個AppDomain中共享以運行被調度到的被管理線程。此外每個被管理的線程必須有一個運行時環境(Contex)，但不一定在一個確定的應用程序域(AppDomain)中。呵呵，搞糊涂了吧 :D 這里繞的幾個彎子我以后再寫篇詳細的文章討論好了 :P
被管理的線程除了可以獲取當前線程ID和綁定到的物理線程ID外，還有一個ThreadState狀態(vm\Threads.h:576)定義其當前運行情況。
對線程類型的判斷邏輯，首先將線程與FinalizerThread(Finalizer)和GcThread(GC)兩個全局變量指向的系統功能線程比較，判斷是否是這兩種特殊線程；然后根據線程狀態的Thread::TS_ThreadPoolThread位是否被設置來判斷是否在線程池中；如果在線程池中還要通過狀態的Thread::TS_TPWorkerThread標志位進一步判斷是否為工作者線程(Threadpool Worker)，不是工作者線程則為完成端口線程(Threadpool Completion Port)。這幾種線程緩沖池中線程的概念，我們以后章節討論線程池時再詳細討論。