Critical section in multi-threaded applications

The critical section is a section of the executable program code in which access is made to a shared resource (data or device) that should not be simultaneously used by more than one execution thread. When two (or more) processes are located in the critical section, a state of “race” (“competition”) arises. To avoid this situation, four conditions must be met:

1. Two processes should not simultaneously be in critical areas.
2. The program should not be assumptions about the speed or number of processors.
3. A process outside the critical area cannot block other processes.
4. The situation in which the process is always waiting for getting into the critical area is impossible.

The critical section is the object of synchronization of threads, which allows you to prevent the simultaneous execution of a certain set of operations (usually related to data access) by several threads. The critical section performs the same tasks as the mutex.

There are terminological differences between a mutex and a critical section, so a procedure similar to capturing a mutex is called entering a critical section (eng. Enter ), unlocking a mutex - exiting a critical section (eng. Leave ).

The procedure for entering and exiting critical sections usually takes less time than similar operations of the mutex, which is due to the lack of need to contact the OS kernel.

In Microsoft Windows operating systems, the difference between a mutex and a critical section is that the mutex is an object of the kernel and can be used by several processes at the same time, the critical section belongs to the process and serves to synchronize only its threads.

Windows critical sections have optimizations consisting in the use of an atomically variable variable along with the kernel “synchronization event” object. Capturing a critical section means an atomic increase of a variable by 1. A transition to a wait at a kernel event occurs only if the value of the variable before the capture was already greater than 0, that is, there is a real “competition” of two or more streams for a resource.

Thus, in the absence of competition, the capture / release of the critical section is done without referring to the core.

In addition, the capture of an already occupied critical section before a call to the kernel lasts for a short time in the cycle (the number of iterations of the cycle (English spin count ) is set by the InitializeCriticalSectionAndSpinCount () or SetCriticalSectionSpinCount () functions of polling the variable number of current users, and if this variable becomes 0, then the capture takes place without referring to the kernel.

A similar object in the Windows kernel is called FAST_MUTEX ( ExAcquire / ReleaseFastMutex ). It differs from the critical section by the lack of support for recursive re-acquisition by the same stream.

A similar Linux object is called futex.

see also

• Decker's algorithm
• Peterson's algorithm
• Lamport Bakery Algorithm