Exclusive locks (exclusive locks, write locks, X locks) and shared locks (read locks, s locks) spin locks

Shared lock (s lock ):If transaction t adds a shared lock to data a, other transactions can only add a shared lock to data a, but cannot apply an exclusive lock until all shared locks are released. Transactions authorized to share locks can only read data and cannot modify data.
Exclusive lock (x lock ):If transaction t adds an exclusive lock to data a, other transactions cannot add any type of lock to auntil the lock on the resource is released at the end of the transaction. Transactions authorized to exclusive locks can read and modify data.

Linux spin lock:

When a process enters the CPU and runs, it willCodeLocks to prevent other CPU processes from modifying the code (do not rule out the situation where the CPU is locked to another CPU, which will be discussed later .). The so-called sub-spin lock is such a lock: process a enters the CPU, locks the door to run, process B comes to the CPU, and finds that the door is locked, so wait for process a to come out and hand over the unlock key.

Every time we talk about the concept of "Lock", we always talk about "deadlocks" -- yes, we must prevent deadlocks when using locks. the deadlock is generated like this: process a enters the CPU, lock, process B comes to the front of the CPU and waits for process a to come out, but the bad situation arises: process a must get the help of process B if it wants to come out, so process a started to wait for the help of process B, but process B has been waiting for process a to come out! Such a wait cannot be terminated and eventually becomes a deadlock.

For example, process a wants to lock the code segment A, and then wants to lock the code segment B. process B wants to lock the code segment B, and then wants to lock the code segment. There is no problem in the first step, but when both processes are going to proceed to the next step, we find that the task cannot be completed: process a has locked the code segment A, and process B cannot operate on it again, similarly, process B has locked the code segment of process B, and process a cannot operate on it, so the two processes wait for the other to release the lock. Of course, such a wait is also endless. It seems that two cars are driving opposite each other on a very pressed bridge. No one will let the two cars meet each other and they are waiting for the other to give way.

To avoid deadlocks, each lock operation must be ordered and atomic. There are sequential locks, that is, each lock is performed in the ascending order of the executable queue address. We will discuss this very well in the future.

Atomic, that is, each lock must be executed to the end, otherwise it will not be executed.