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.WriteLi ne("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.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Zytan" <zy**********@g mail.comwrote in message
news:11******** *************@n 35g2000prd.goog legroups.com...

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.WriteLi ne("Hello"); }
}

Zytan

[Christof Nordiek]

"Zytan" <zy**********@g mail.comschrieb im Newsbeitrag
news:11******** *************@n 35g2000prd.goog legroups.com...

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
"Zytan" <zy**********@g mail.comwrote in message
news:11******** *************@n 35g2000prd.goog legroups.com...
| 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.WriteLi ne("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

On Wed, 25 Apr 2007 12:11:12 -0400, "William Stacey [C# MVP]" <wi************ @gmail.com>
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: ne******@flound er.com
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]
"Joseph M. Newcomer" <ne******@floun der.comwrote in message
news:rn******** *************** *********@4ax.c om...
| 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]"
<wi************ @gmail.com>
| 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: ne******@flound er.com
| Web: http://www.flounder.com
| MVP Tips: http://www.flounder.com/mvp_tips.htm

[Chris Mullins [MVP]]

"William Stacey [C# MVP]" <wi************ @gmail.comwrote

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.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise , Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

[Willy Denoyette [MVP]]

"Chris Mullins [MVP]" <cm******@yahoo .comwrote in message
news:e9******** ******@TK2MSFTN GP05.phx.gbl...

"William Stacey [C# MVP]" <wi************ @gmail.comwrote

>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_SECTIO N construct in the OS.
Both mutexes and CRITICAL_SECTIO Ns allow recursive acquisition, and indeed, the
CRITICAL_SECTIO N 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
On Wed, 25 Apr 2007 13:20:34 -0700, "Chris Mullins [MVP]" <cm******@yahoo .comwrote:

>"William Stacey [C# MVP]" <wi************ @gmail.comwrote

>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: ne******@flound er.com
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