Is it valid to nest a critical section?

Question

For example, would this be valid?

CRITICAL_SECTION cs;

::InitializeCriticalSection( &cs );

::EnterCriticalSection( &cs );      // First level
::EnterCriticalSection( &cs );        // Second level

/* do some stuff */

::LeaveCriticalSection( &cs );        // Second level
::LeaveCriticalSection( &cs );      // First level

::DeleteCriticalSection( &cs );

Obviously, I would never intentionally do this, but what if this were to come about as a result of function calls such that the "first level" gets called to lock an object for a complex (e.g. search) algorithm and the "second level" gets called in that object's accessor functions?

Pecker

Answer 1

Yes it is valid to enter the same critical section while already inside it. From the docs:

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.

Beliabelial

The same applies to all other types of synchronization objects - mutexs, semaphores, etc. Once a thread has obtained a lock, it can reenter the lock as many times as it wants without blocking. Just be sure to release the lock the same number of times that you enter it so it releases correctly for other threads to obtain. – Aaronson

@Remy: no, it doesn't apply to all other types of synchronization objects. You can certainly have non-reentrant mutexes. – Beliabelial

Standard mutexes are reentrant, though. Quote from MSDN: "The thread that owns a mutex can specify the same mutex in repeated wait function calls without blocking its execution. Typically, you would not wait repeatedly for the same mutex, but this mechanism prevents a thread from deadlocking itself while waiting for a mutex that it already owns. However, to release its ownership, the thread must call ReleaseMutex once for each time that the mutex satisfied a wait." – Aaronson

@Remy: it specifically does not apply to semaphores, which you cannot acquire as many times as you want. Quote from MSDN: "A thread that waits repeatedly for the same semaphore object, however, decrements the semaphore's count each time a wait operation is completed; the thread is blocked when the count gets to zero." – Mcneese

Answer 2

From the documentation:

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.

Vara

yeah, but ... well I'm calling it a tie. – Vara

Thank you ! - upvotes are cheap these days. I upvoted Martinho, by the way, for winning the race. ps: I was going to just write "Yes" as my answer, but thought it would be sporting to cite the source. – Vara

Answer 3

To validate the other two posts. Quick look at Critical section in WinDbg shows that cricital section maintains an integer variable to hold Recursion counts.

0:001> dt RTL_CRITICAL_SECTION
+0x000 DebugInfo : Ptr32 _RTL_CRITICAL_SECTION_DEBUG
+0x004 LockCount : Int4B
+0x008 RecursionCount : Int4B
+0x00c OwningThread : Ptr32 Void
+0x010 LockSemaphore : Ptr32 Void
+0x014 SpinCount : Uint4B 

RecursionCount - It is possible for a thread to acquire a critical section more than once. This field indicates how many times the same thread has acquired the critical section. By default, the value of this field is 0, indicating that there is no thread owning the critical section.

Slug