CODEWITHSUNDEEP
c#.netlockingdeadlock
Eric
Eric

Reputation: 6016

Why doesn't Lock'ing on same object cause a deadlock?

If I write some code like this:

class Program {
    static void Main(string[] args) {
        Foo();
        Console.ReadLine();
    }

    static void Foo() {
        lock(_lock) {
            Console.WriteLine("Foo");
            Bar();
        }
    }

    static void Bar() {
        lock(_lock) {
            Console.WriteLine("Bar");
        }
    }
    
    private static readonly object _lock = new object();
}

I get as output:

Foo
Bar

I expected this to deadlock, because Foo acquires a lock, and then waits for Bar to acquire the lock. But this doesn't happen.

Does the locking mechanism simply allow this because the code is executed on the same thread?

Upvotes: 63

Views: 16300

Answers (4)

pathfinder666
pathfinder666

Reputation: 189

Two words: Reentrant lock.

If a thread has already acquired a lock, then it does not wait if it wants to acquire the lock again. This is very much needed otherwise it could have turned simple recursive functions into a nightmare!

Upvotes: 12

thumbmunkeys
thumbmunkeys

Reputation: 20764

For the same thread a lock is always reentrant, so the thread can lock an object as often as it wants.

Upvotes: 96

Sergey Berezovskiy
Sergey Berezovskiy

Reputation: 236298

Because you have only one thread here.

lock is shortcut for 

bool lockWasTaken = false;
var temp = obj;
try { 
       Monitor.Enter(temp, ref lockWasTaken); 
       // your thread safe code
}
finally { if (lockWasTaken) Monitor.Exit(temp); }

Monitor.Enter acquire the Monitor on the object passed as the parameter. If another thread has executed an Enter on the object but has not yet executed the corresponding Exit, the current thread will block until the other thread releases the object. It is legal for the same thread to invoke Enter more than once without it blocking; however, an equal number of Exit calls must be invoked before other threads waiting on the object will unblock.

Upvotes: 24

Servy
Servy

Reputation: 203829

The lock statement is smarter than that, and it is designed to prevent just this. The lock is "owned" by the thread once it gets inside of it, so anytime it reaches another lock statement that locks on the same object it will realize that it already has access to that lock.

Upvotes: 7

Related Questions