如何以CLR“友好”方式获得_real_线程ID？

Question

作为一个练习，我正在编写一些代码来显示进程内的O/S进程和O/S线程（如Sysinternals进程管理器）。

我发现.net的ManagedThreadId（s）不是O/S线程标识符。读了一下之后，我发现AppDomain.GetCurrentThreadId（）。不幸的是，该功能被标记为“过时”（这可能意味着未来“不可用”）。我找到的一个解决方案是使用InteropServices直接调用Win32 GetCurrentThreadId。我对此感觉很好，但它与.net哲学相反。

我的问题是：是否有CLR“友好”的方式获得当前线程的真实ID？

仅供参考，以下是代码片段，展示了迄今为止我所尝试的内容。 // 1和// 2显示正确的线程ID，// 3和// 4尝试以CLR友好的方式获取相同的信息（但它们不起作用）。

谢谢你的帮助，

John。

[DllImport("kernel32.dll")] 
static extern int GetCurrentThreadId(); 

static void Main(string[] args) 
{ 
    // AppDomain.GetCurrentThreadId() is "obsolete" 

    int ThreadId1 = AppDomain.GetCurrentThreadId(); // 1 

    // not the ".net" way of doing things 

    int ThreadId2 = GetCurrentThreadId();    // 2 

    // "no joy" attempts to get the same results I got above 

    int ThreadId3 = Process.GetCurrentProcess().Threads[0].Id; // 3 
    int ThreadId4 = Thread.CurrentThread.ManagedThreadId;  // 4 


    Console.WriteLine("ThreadId1: {0}, ThreadId2: {1}, ThreadId3: {2}, " + 
        "ThreadId4: {3}", 
        ThreadId1, ThreadId2, ThreadId3, ThreadId4); 
} 

Answer 1

PInvoking到GetCurrentThreadId是你最好的选择，并会给你正确的信息。

但是我必须警告你，为什么CLR不提供这些信息有很好的理由：对于托管代码来说，这几乎是一个完全无用的值。从CLR的角度来看，单个托管线程在其生命周期中由多个不同的本地线程支持是完全合法的。这意味着GetCurrentThreadId的结果可以（且将会）在线程的整个生命周期中发生变化。

在许多应用中，这不是一个可观察的现象。在一个UI应用程序中，这不会实际发生，因为它通常由一个STA线程支持，由于COM互操作问题，它更难以更换（通常甚至是非法的）。许多开发人员都对此非常无知。然而，在通常是后台线程的执行上下文的情况下，很容易换掉MTA线程。

Answer 2

这是过时的原因;这个想法在未来“实际”的线程ID可能不是恒定的，或者可能在.NET线程之间共享。