Simple understanding of spin locks and semaphores

To prevent multiple processes from accessing the same resource or competing with multiple processors, the kernel uses a locking mechanism to protect shared data. First, a brief analysis of the classification of the operating system:

1. Operating System classification

Real-Time OS and time-sharing OS. They all share a common feature of multi-tasking, but the main difference lies in application scenarios. For example, an inappropriate real-time operating system is used in scenarios with high real-time requirements such as missile launch and satellite launch, however, time-sharing operations have relatively low real-time requirements. Multi-task operating systems can be divided into two types: Non-preemptible multi-task and preemptible multi-task. Non-preemptible multi-task means that each process continuously occupies the CPU until the CPU is completed or is automatically transferred out, and other processes can use the CPU. Preemptible multitasking means that each process consumes a limited amount of CPU time. at a certain time, it must be introduced, similar to the time-sharing multiplexing technology in computer networks. Preemptible multi-task scheduling is the most basic scheduling method in many operating systems. 2. Process Scheduling In reality, we found that processes can be divided into two types: I/O consumable type: processes frequently interact with the outside world. For example, to open or browse files, you must wait for user commands to read data on the CD. CPU consumption type: processes are always running on the CPU for most of the time and seldom need to wait. Therefore, we should treat these two types of processes differently. We use the processor to follow the principle of high throughput and fast response time. For the I/O consumption type, because it needs to wait frequently for I/O, it needs a higher priority to seize the current running process, to ensure that the CPU response is immediately obtained when the I/O conditions are met, and its time slice is longer than other CPU-consuming processes. On the contrary, the CPU-consuming process has a relatively low priority and the time slice does not need to be too long. Let's look at an example to better understand: assume that the user runs two programs, one is the typing program and the other is the video program. Obviously, the typing program is I/O consumable, while the video program is processor consumable. A person's typing speed is no longer faster than the computer's video encoding speed and the display speed on the screen, but he wants to input a computer and display it on the screen every time he clicks a word. Therefore, for a typing program, we give it a higher priority so that people can enter it immediately and have more time slices. In contrast, the video program has a lower priority, in order to give way to the typing program, the time slice is certainly less. In fact, the higher the priority, the longer the time slice, and vice versa. Three spin locks The lock mechanism is used to lock the code of a process when it enters CPU running, so as not to modify the code in other CPU processes. The lock itself is a mutex lock, that is, "Lock" and "unlock! An execution unit wants to access the protected by the spin lockShared resourcesThe lock must be obtained first. After accessing the shared resource, the lock must be released. If no execution unit keeps the lock when obtaining the spin lock, the lock will be obtained immediately. If the lock already has the lock when obtaining the spin lock, the get lock operation will spin there, until the lock is released by the holder of the spin lock. Simply put, the so-called 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 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 kept waiting. Process A is coming 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. Disadvantage: a competing spin lock makes the thread requesting it spin while waiting for the lock to re-available (especially wasting processor time ). Therefore, the spin lock should not be held for a long time. Four semaphores   Semaphores in Linux are sleep locks. If a task tries to obtain an held semaphore, the semaphore will push it into the waiting queue and then sleep it. In this case, the processor is free to execute other code. When the process holding the semaphore releases the semaphore, a task in the waiting queue will be awakened to obtain the semaphore. The sleep feature of semaphores makes the semaphores suitable for cases where the lock is held for a long time. They can only be used in the process context because the interrupt context cannot be scheduled; in addition, when the Code holds a semaphore, it cannot hold a spin lock.   Differences between the two Although the conditions for use between the two are complex, in fact, in actual use, semaphores and spin locks are not easy to confuse. Note the following principles: If the code needs to sleep-this often happens when it is synchronized with the user space-using semaphores is the only option. Because it is not restricted by sleep, it is generally easier to use semaphores. If you need to choose between the spin lock and semaphore, it depends on the length of time the lock was held. Ideally, all locks should be held as short as possible, but it is better to use semaphores if they are held for a long time. In addition, unlike the spin lock, semaphores do not disable kernel preemption, so the code holding semaphores can be preemptible. This means that the semaphore will not have a negative impact on the scheduling response time.