Identify the thread which holds the lock

Question

one of the threads in my application blocked at the following lock statement and resulted in a deadlock

void ExecuteCommand() {     lock(this._lockinstance)     {         // do some operation     } } 

---

Is it possible to easily identify which thread is currently holding the lock?.. My application has more than 50 threads, which makes it difficult to go through each callstack using visual studio to locate the thread that holds the lock

Answer 1

Some sample code to try out:

class Test {     private object locker = new object();     public void Run() {         lock (locker) {  // <== breakpoint here             Console.WriteLine(System.Threading.Thread.CurrentThread.ManagedThreadId);         }     } } 

Set a breakpoint on the indicated line. When it breaks, use Debug + Windows + Memory + Memory 1. Right click the window and choose "4-byte Integer". In the Address box, type &locker. The 2nd word is the thread ID of the thread that owns the lock. Step past the lock statement to see it change.

Beware that the number is the managed thread ID, not the operating system thread ID that you see in the Debug + Windows + Threads window. That kinda sucks, you probably should add some logging to your program that dumps the value of ManagedThreadId so you have a way to match the value to a thread. Update: fixed in later VS versions, the Debug > Windows > Threads debugger window now shows the ManagedThreadId.

Answer 2

Recently I was trying to determine what function was holding a lock and found the following very useful and had not seen in demonstrated anywhere before. I've placed it as an answer here in case others find it useful too.

Many of the other solutions posted earlier require writing a new class and then converting of all lock(blah) to BetterLock(blah) which is a lot of work for debugging and which you may not want in the production/shipped version of your code. Others required having the debugger attached which changes the code's timing and could obscure the issue.

Instead, try the following...

Original code:

object obj = new object(); lock(obj) {     // Do stuff } 

Modified code for debugging:

object _obj = new object(); object obj {     get     {         System.Diagnostics.StackFrame frame = new System.Diagnostics.StackFrame(1);         System.Diagnostics.Trace.WriteLine(String.Format("Lock acquired by: {0} on thread {1}", frame.GetMethod().Name, System.Threading.Thread.CurrentThread.ManagedThreadId));         return _obj;     } } // Note that the code within lock(obj) and the lock itself remain unchanged. lock(obj) {     // Do stuff } 

By exposing obj as a property, at least temporarily, with very minimal code changes you can determine what function acquired the lock last and on what thread - just look at the Trace output for the last entry. Of course you can output any other information you might find useful in the getter as well.

No, this will not let you determine when a lock was released, but if it was getting released in a timely fashion, then you didn't actually have a lock contention issue in the first place.