recursive locks work do not deadlock! why?

[Zytan]

This program DOESN'T deadlock due to attempt to reenter the same
lock! Why?

private static object m_lock = new object();

static void Main(string[] args)
{
lock (m_lock) { MyFunc(); }
}

static void MyFunc()
{
lock (m_lock) { Console.WriteLine("Hello"); }
}

Zytan

 

[Nicholas Paldino [.NET/C# MVP]]

Zytan,

Why should it? The lock statement is meant to block out other threads
trying to run the same code, not the same thread.

 

[Christof Nordiek]

This program DOESN'T deadlock due to attempt to reenter the same
lock! Why?

Hi Zytan,

you're code is all in one thread. Each thread can enter the same lock as
often as it want's to. This locks are only for inter thread synchronization,
to prevent that more than one thread access some resource at the same time.

Christof

 

[William Stacey [C# MVP]]

That behavior would be a Mutex, which acts like a binary semephore. A .Net
Monitor allows reentrance for the same thread - this behavior is most handy
(and required) in many situations.

--
William Stacey [C# MVP]
PCR concurrency library: www.codeplex.com/pcr
PSH Scripts Project www.codeplex.com/psobject


| This program DOESN'T deadlock due to attempt to reenter the same
| lock! Why?
|
| private static object m_lock = new object();
|
| static void Main(string[] args)
| {
| lock (m_lock) { MyFunc(); }
| }
|
| static void MyFunc()
| {
| lock (m_lock) { Console.WriteLine("Hello"); }
| }
|
| Zytan
|

 

[Joseph M. Newcomer]

No. A mutex is NOT a binary semaphore; it is a MUTEX. A mutex allows recusive
acquisition by the owner thread. So the lock is following the definition of how a mutex
is supposed to work.
joe

That behavior would be a Mutex, which acts like a binary semephore. A .Net
Monitor allows reentrance for the same thread - this behavior is most handy
(and required) in many situations.

Joseph M. Newcomer [MVP]
email: (e-mail address removed)
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

 

[William Stacey [C# MVP]]

Right, thank Joseph. Have not used Mutex in a while... Primary difference
is a mutex can be used cross-process and a Monitor can not. Also a monitor
is typically faster as the fast path does not require kernel mode switch.
So "Monitor when you can, and Mutex when you have to".

--
William Stacey [C# MVP]


| No. A mutex is NOT a binary semaphore; it is a MUTEX. A mutex allows
recusive
| acquisition by the owner thread. So the lock is following the definition
of how a mutex
| is supposed to work.
| joe
|
| On Wed, 25 Apr 2007 12:11:12 -0400, "William Stacey [C# MVP]"
<[email protected]>
| wrote:
|
| >That behavior would be a Mutex, which acts like a binary semephore. A
..Net
| >Monitor allows reentrance for the same thread - this behavior is most
handy
| >(and required) in many situations.
| Joseph M. Newcomer [MVP]
| email: (e-mail address removed)
| Web: http://www.flounder.com
| MVP Tips: http://www.flounder.com/mvp_tips.htm

 

[Chris Mullins [MVP]]

Also a monitor is typically faster as the fast path does not require
kernel mode switch.

[I can't help myself. I can't. I have to pick nits. Ugh]

If I remember right, from reading the writings of Duffy & Richter, the
monitor does a SpinWait for a little while in the hope it can avoid a kernal
switch. After a bit it gives up, and hands itself off to the kernel.

It's still pretty darn fast though.

 

[Willy Denoyette [MVP]]

Also a monitor is typically faster as the fast path does not require
kernel mode switch.

[I can't help myself. I can't. I have to pick nits. Ugh]

If I remember right, from reading the writings of Duffy & Richter, the
monitor does a SpinWait for a little while in the hope it can avoid a
kernal switch. After a bit it gives up, and hands itself off to the
kernel.

Yep, but only on multi-processor boxes (and multi cores) and (obviously)
when there is contention.

Willy.

 

[Joseph M. Newcomer]

The :"monitor" would be the C# representation of a CRITICAL_SECTION construct in the OS.
Both mutexes and CRITICAL_SECTIONs allow recursive acquisition, and indeed, the
CRITICAL_SECTION does a spin based on the premise that the locking interval is very short
most of the time. If the spin expires, then you get full kernel locking.
joe

Also a monitor is typically faster as the fast path does not require
kernel mode switch.

[I can't help myself. I can't. I have to pick nits. Ugh]

If I remember right, from reading the writings of Duffy & Richter, the
monitor does a SpinWait for a little while in the hope it can avoid a kernal
switch. After a bit it gives up, and hands itself off to the kernel.

It's still pretty darn fast though.

Joseph M. Newcomer [MVP]
email: (e-mail address removed)
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

 

[Zytan]

Everyone, thanks for the replies. After posting, I realized that
Enter does allow the same thread, and it DID make sense to allow this
to happen in my program, as it usually would for most programs.
Coming from using crticial sections in C++, this was a surprise. I
was bug hunting and when I seen my code enter the same lock twice, I
thought I found it until I realized it would have deadlocked on every
run, which it wasn't doing.

thanks for your quick responses!
Zytan