Click here to Skip to main content
15,881,424 members
Please Sign up or sign in to vote.
5.00/5 (2 votes)
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

According to the docs:
http://msdn.microsoft.com/en-us/library/ms682608.aspx[^]

"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.

Iain.
 
Share this answer
 
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.
 
Share this answer
 
Comments
Niklas L 24-Jun-10 7:24am    
The question is from 9 Sep '08, and had an answer. Better late than never?
Emilio Garavaglia 24-Jun-10 7:32am    
why not! It's one of the issues I struggled a lot years ago...
nothing second time also try to lock critical section.
 
Share this answer
 
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.
 
Share this answer
 
Comments
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 Garavaglia 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 Garavaglia 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 http://www.softwareverify.com/software-verify-blog/?p=160


CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900