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

Question

Possible Duplicate:
Re-entrant locks in C#

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?

By the way - it's a bit out of topic but - I think that it's good to know that *"Locks are not magic dust that you sprinkle on code and suddenly it gets safe."*: http://blogs.msdn.com/b/ericlippert/archive/2009/03/06/locks-and-exceptions-do-not-mix.aspx — jwaliszko, Oct 22 '12 at 19:08

thumbmunkeys · Accepted Answer · 2016-04-22T12:27:06.467

94

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

edited Apr 22 '16 at 12:27

answered Oct 22 '12 at 18:18

thumbmunkeys

20,606
8
62
110

8

+1 The keyword is "reentrant"; a non-reentrant lock (e.g. a file lock) would deadlock. – Oct 22 '12 at 18:25
3

Thanks, reentrant was the terminology I lacked, and why I couldn't find an answer to this quickly on Google. – Eric Oct 22 '12 at 18:31
2

If a lock can be acquired by a thread more than once, and has to be released that many times, it is called *recursive*. Perhaps not in C# though, but just so you know. – Kaz Oct 22 '12 at 20:42

Sergey Berezovskiy · Answer 2 · 2012-10-22T18:24:58.790

23

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.

edited Oct 22 '12 at 18:24

answered Oct 22 '12 at 18:18

Sergey Berezovskiy

232,247
41
429
459

2

+1 for notice about equal number of exit calls before separate thread access permission – jwaliszko Oct 22 '12 at 18:33
@JaroslawWaliszko re-exiting after re-entering :) – Sergey Berezovskiy Oct 22 '12 at 18:34

score 11 · Answer 3 · edited Jul 11 '23 at 14:20

11

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!

edited Jul 11 '23 at 14:20

General Grievance

4,555
31
31
45

answered Oct 22 '12 at 18:37

pathfinder666

179
3

+1 for recursive common sense – jwaliszko Oct 22 '12 at 18:43

score 6 · Answer 4 · answered Oct 22 '12 at 18:19

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.

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

4 Answers4

Linked