Critical section and race conditions
The code segment that accesses and manipulates shared data is called a critical section (critical section).
Multiple execution threads (such as processes, interrupt handlers, kernel threads, etc.) execute critical section code at the same time, which may lead to resource sharing. Therefore, it is necessary to avoid concurrent access in the critical section.
Therefore, the critical section code cannot be interrupted before the execution ends, and the entire critical section needs to be as an indivisible instruction.
Two threads of execution execute simultaneously in the same critical section. If this happens, it is called a race condition .
Even if multiple threads of a single process share files or process signals within a program, race conditions may occur, leading to concurrency. Although this kind of concurrency does not really happen at the same time, but crosses, it is pseudo-concurrency.
Avoiding concurrency and preventing race conditions are called synchronization .
Atomic operations can ensure that interleaving is impossible, because the processor will physically ensure that this is impossible.
The use of the lock is voluntary and non-mandatory, and it is a programming method chosen by the programmer.
Linux implements several different locking mechanisms.
The main difference between the various lock mechanisms is the behavior when the lock is already held by another thread of execution and therefore unavailable, such as waiting and sleeping until the lock is available.
The lock is implemented using atomic operations.
The deadlock is caused by the execution threads (one internal or multiple mutuals) waiting for each other to lock.
Lock contention (referring to other execution threads trying to acquire the lock while the lock is being occupied) leads to a decrease in system performance.
The lock granularity is used to describe the data size of the lock protection.
The lock protects not the critical section, but the data used in the critical section.