Resources | Resources |



Critical sections

A critical section is code that must not be accessed by more than one thread at a time. Critical sections serve two main purposes:

  • To serialize access to an external device or resource that supports only one operation at a time.
  • To prevent any thread from reading or writing a data structure in an intermediate (unstable) state between two normal (stable) states.

A critical section terminates within a fixed time (bounded waiting). Semaphores or other synchronization mechanisms are required at the entry and exit of a critical section. When multiple threads are waiting, the thread with highest priority gains access when available.

Thread safety

A critical section is required for thread safety in the following cases:

  • The manipulation of a data structure takes more than one computer instruction.
  • The manipulation involves examining the state of the data structure and then using that state to decide how to modify the structure.

For example:

  • Adding an element to a doubly linked list (takes more than one computer instruction).
  • Checking whether a structure variable is equal to zero and initializing the structure if this is true (examines structure to determine how to modify the structure).

Critical sections are not required for protection if an object is accessed by only a single thread.

Critical section rules

Threads should minimize the time spent inside a critical section. Because other threads cannot enter the critical section while any thread is inside, overhead increases if a thread does not exit the critical section without undue delay. In general, critical sections protecting a data structure should terminate quickly and should not execute blocking calls inside the critical section. Critical sections protecting an external device or resource may block inside the critical section, but only to the extent required by the protected device or resource.

Developers should try to avoid critical sections, or use as few as possible. The necessity of getting and releasing critical sections increases overhead and the likelihood of deadlock. For example, if a developer uses ten different critical sections that must be in a particular order, a deadlock may occur if two or more threads try to enter the critical sections in a different order.

The following are some general rules when using critical sections:

  • Minimize the time spent in the critical section to minimize contention.
  • Rearrange the code if the outcome inside the critical section is unclear. For example, callbacks inside a critical section increase the chances of contention.

Example - Critical section within a process

The following figure shows the enter and leave operations for critical sections.

Critical Section within Process

Example - Inter-process critical section or mutex

The following figure shows the enter and leave operations for a critical section shared by two processes.

Inter-process Critical Section OR Mutex