MFC: CCriticalSection problem
-
I create a new project (MFC Dialog) and place a button on the dialog. The code that the button performs is the following:
CCriticalSection c; c.Lock(); c.Lock(); c.Unlock(); c.Unlock();When I start the Program in DEBUG-Mode I expect the following behaviour: 1. The CritSec is created. 2. The first Lock is applied. 3. The second call to Lock should result in a deadlock. :omg: But that is not the case. The code will run without any problems. WHY:confused:!!!! Is there some different behaviour in DEBUG-Mode, or what? Greets Snow -
I create a new project (MFC Dialog) and place a button on the dialog. The code that the button performs is the following:
CCriticalSection c; c.Lock(); c.Lock(); c.Unlock(); c.Unlock();When I start the Program in DEBUG-Mode I expect the following behaviour: 1. The CritSec is created. 2. The first Lock is applied. 3. The second call to Lock should result in a deadlock. :omg: But that is not the case. The code will run without any problems. WHY:confused:!!!! Is there some different behaviour in DEBUG-Mode, or what? Greets Snow -
what is the return value when second lock is applied -- modified at 6:51 Monday 28th November, 2005
both are true
-
both are true
Hi, the CCriticalSection object encapsulates the CRITICAL_SECTION type. The lock function calls the EnterCriticalSection API. So from the MSDN libs I found this:
After a thread has ownership of a critical section, it can make additional calls to
EnterCriticalSection or TryEnterCriticalSection without blocking its execution. This prevents a
thread from deadlocking itself while waiting for a critical section that it already owns. The
thread enters the critical section each time EnterCriticalSection and TryEnterCriticalSection
succeed. A thread must call LeaveCriticalSection once for each time that it entered the critical
section.So it is normal behaviour codito ergo sum -- modified at 11:29 Monday 28th November, 2005
-
Hi, the CCriticalSection object encapsulates the CRITICAL_SECTION type. The lock function calls the EnterCriticalSection API. So from the MSDN libs I found this:
After a thread has ownership of a critical section, it can make additional calls to
EnterCriticalSection or TryEnterCriticalSection without blocking its execution. This prevents a
thread from deadlocking itself while waiting for a critical section that it already owns. The
thread enters the critical section each time EnterCriticalSection and TryEnterCriticalSection
succeed. A thread must call LeaveCriticalSection once for each time that it entered the critical
section.So it is normal behaviour codito ergo sum -- modified at 11:29 Monday 28th November, 2005
Thanks a lot!