By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,918 Members | 1,816 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,918 IT Pros & Developers. It's quick & easy.

recursive locks work do not deadlock! why?

P: n/a
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

Apr 25 '07 #1
Share this Question
Share on Google+
9 Replies


P: n/a
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.com

"Zytan" <zy**********@gmail.comwrote in message
news:11*********************@n35g2000prd.googlegro ups.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.WriteLine("Hello"); }
}

Zytan

Apr 25 '07 #2

P: n/a
"Zytan" <zy**********@gmail.comschrieb im Newsbeitrag
news:11*********************@n35g2000prd.googlegro ups.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
Apr 25 '07 #3

P: n/a
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**********@gmail.comwrote in message
news:11*********************@n35g2000prd.googlegro ups.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.WriteLine("Hello"); }
| }
|
| Zytan
|
Apr 25 '07 #4

P: n/a
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******@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Apr 25 '07 #5

P: n/a
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******@flounder.comwrote in message
news:rn********************************@4ax.com...
| 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******@flounder.com
| Web: http://www.flounder.com
| MVP Tips: http://www.flounder.com/mvp_tips.htm
Apr 25 '07 #6

P: n/a
"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
Apr 25 '07 #7

P: n/a
"Chris Mullins [MVP]" <cm******@yahoo.comwrote in message
news:e9**************@TK2MSFTNGP05.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.

Apr 25 '07 #8

P: n/a
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
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******@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Apr 26 '07 #9

P: n/a
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

Apr 26 '07 #10

This discussion thread is closed

Replies have been disabled for this discussion.