Click here to Skip to main content
13,147,689 members (29,453 online)
Rate this:
Please Sign up or sign in to vote.
See more:
Sample code is as follows:

<br />class TestClass<br />{<br />CCriticalSection m_csTest;<br />void Fun1() <br />{		<br />	m_csTest.Lock();<br />	Fun2();<br />	MessageBox("In Fun1 critical section.");<br />	m_csTest.Unlock();<br />}<br /><br />void Fun2()<br />{<br />	m_csTest.Lock();	<br />	MessageBox("In Fun2 critical section.");<br />	m_csTest.Unlock();<br />}<br />};<br />

I am pretty aware we should not do this. But what will be the situation? Do I need to unlock the critical section twice as shown in the code or only one time unlock is sufficient?[confused]
Posted 9-Sep-08 0:24am
Rate this: bad
Please Sign up or sign in to vote.

Solution 1

According to the docs:[^]

"A thread must call LeaveCriticalSection once for each time that it entered the critical section."

Which seems pretty clear. Even without reading them, it would be good to do a Leave for every Enter. At worst you are wasting your time. At best, it is needed.

Rate this: bad
Please Sign up or sign in to vote.

Solution 2

What you did is correct: for every lock there is an unlock.
Multiple locks simply result in multiple increments of the thread lock count. That are compensate by multiple decrements in unlock.

Your code is simply avoiding Fun1 and Fun2 to be used simultaneously by different threads.
Even in the case one of them calls Fun2 directly.
Niklas Lindquist 24-Jun-10 7:24am
The question is from 9 Sep '08, and had an answer. Better late than never?
emilio_grv 24-Jun-10 7:32am
why not! It's one of the issues I struggled a lot years ago...
Rate this: bad
Please Sign up or sign in to vote.

Solution 4

nothing second time also try to lock critical section.
Rate this: bad
Please Sign up or sign in to vote.

Solution 3

Clearly, this is a deadlock.
Lock is a blocking call.

So you called Lock once successfully in Fun1 and then you're calling Lock again on the same object in Fun2 before calling Unlock.
Cedric Moonen 24-Jun-10 6:51am
I don't agree: calling lock on a CCriticalSection which has already been locked by the SAME thread is not a blocking call. This is safe and in certain conditions perfectly acceptable. See the link that Iain provided (well, it is for CRITICAL_SECTION and not for CCriticalSection but the principle is the same).
«_Superman_» 24-Jun-10 7:16am
The documentation of EnterCriticalSection states that the owner thread can make additional calls without blocking.
But the documentation of CCriticalSection::Lock states that it is blocking.
I have not tried this myself.
Lock will not probably block on the same thread since CCriticalSection is a thin wrapper for CRITICAL_SECTION.
emilio_grv 24-Jun-10 7:36am
CCriticalSection is just a RAII wrapper the doesn't revamp functionality.
lock calls EnterCriticalSection and unlock call LeaveCriticalSection.
A same tread can set multiple locks.
emilio_grv 24-Jun-10 7:37am
Reason for my vote of 1
Wrong concept.
Stephen Kellett 15-Jul-10 13:45pm
This is NOT a deadlock.
A deadlock occurs when two or more threads enter the sequence of locks in a conflicting order.
This example is one thread enter two locks, twice each. That is logically correct and acceptable.
The code could be improved by controlling the locks using CSingleLock to manage the lock lifetime.

Mote information on how to use CSingleLocks here
  Print Answers RSS
Top Experts
Last 24hrsThis month

Advertise | Privacy |
Web03 | 2.8.170915.1 | Last Updated 24 Jun 2010
Copyright © CodeProject, 1999-2017
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100