Managed ThreadId

Managed Stack Explorer allows one to trace stacks for .NET 2.0 applications at run time. This is handy for tracing deadlock problems. But the project I worked on was based on .NET 1.1. What a pity! After a second thought, I realized that I just need to keep track of the resources locked by threads. When deadlock happened, that is, when a thread issued lock request over some resource but failed after a predefined period of time, I dumped the stack frame of the threads locking the resource. Then the problem boiled down to how to identify the resource locking threads. Originally, I used System.AppDomain.GetCurrentThreadId to identify a thread. But according to the documentation, this id is not stable.

Note An operating-system ThreadId has no fixed relationship to a managed thread, because an unmanaged host can control the relationship between managed and unmanaged threads. Specifically, a sophisticated host can use the Fiber API to schedule many managed threads against the same operating system thread, or to move a managed thread among different operating system threads.

Instead, to identify a thread in .NET 1.1, use Thread.GetHashCode. For applications in .NET 2.0 and later, use Thread.ManagedThreadId.