Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: C++ C++/CLI C MFC ATL WTL STL
Sample code is as follows:

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

void Fun2()
{
	m_csTest.Lock();	
	MessageBox("In Fun2 critical section.");
	m_csTest.Unlock();
}
};


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 1:24am
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

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.
  Permalink  
Rate this: bad
good
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.
  Permalink  
Comments
Niklas Lindquist at 24-Jun-10 7:24am
   
The question is from 9 Sep '08, and had an answer. Better late than never?
emilio_grv at 24-Jun-10 7:32am
   
why not! It's one of the issues I struggled a lot years ago...
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 4

nothing second time also try to lock critical section.
  Permalink  
Rate this: bad
good
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.
  Permalink  
Comments
Cedric Moonen at 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_» at 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 at 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 at 24-Jun-10 7:37am
   
Reason for my vote of 1
Wrong concept.
Stephen Kellett at 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
  Print Answers RSS
0 OriginalGriff 325
1 DamithSL 265
2 CPallini 235
3 Sergey Alexandrovich Kryukov 229
4 Maciej Los 190
0 OriginalGriff 5,455
1 DamithSL 4,422
2 Maciej Los 3,860
3 Kornfeld Eliyahu Peter 3,480
4 Sergey Alexandrovich Kryukov 3,010


Advertise | Privacy | Mobile
Web01 | 2.8.141216.1 | Last Updated 24 Jun 2010
Copyright © CodeProject, 1999-2014
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