Thoughts on spin locks

Chapter 5 of the book "Understanding the Linux kernel in depth" describes kernel synchronization. When the kernel control path must access the shared data structure or enter the critical section, you need to obtain a "Lock" for yourself ". The resources protected by the lock mechanism are very similar to those restricted in the room. When someone enters the room, the door is locked. If the kernel control path wants to access resources, it tries to get the key "Open the door ". It can be successful only when the resource is idle. Then, as long as it still wants to use this resource, the door is still locked. When the kernel control path is released, the door is opened and another kernel path can enter the room. This is the description of the spin lock in the book. Here we will talk about the spin lock in kernel synchronization, but I personally feel that I can talk about the spin lock function separately.

To protect shared resources and protect shared resources, the spin lock function mainly includes the following types in Linux: spin lock and semaphore), atomic operation, interrupt shielding, BKL (big kernel lock), rwlock, brlock (only included in the 2.4 kernel), RCU, and seqlock (only in the 2.6 kernel ).

(1) spin lock)

Spin lock is a kind of lock designed to prevent multi-processor concurrency. It is applied to interrupt processing and other parts. For a single processor, to prevent the concurrency in the interrupt processing, you can simply disable the interrupt without the need for spin locks. The spin lock can only be held by one kernel task at most. The kernel control path discovery lock is "locked" by the kernel control path running on another CPU, and "rotated" around it ", execute a compact loop command repeatedly until the lock is released. The spin lock can prevent more than one kernel task from entering the critical section at any time. Therefore, this lock can effectively avoid competition for shared resources for Kernel Tasks running concurrently on the multi-processor.

In fact, the intention of the spin lock is to implement lightweight locking in a short period of time. A competing spin lock allows the thread requesting it to spin while waiting for the lock to be available again (especially wasting processing time), so the spin lock should not be held for too long. If you need to lock for a long time, it is best to use a semaphore (this will be introduced later ). However, the spin lock reduces the overhead of context switching. The spin locks are expressed in the spinlock_t structure and contain two fields:

Slock

This field indicates the status of the spin lock. If the value is 1, it indicates the "Unlocked" status, and any negative number or 0 indicates the "locked" status.

Break_lock

Indicates that the process is busy waiting for the spin lock

Because the spin lock can only be held by up to one kernel task at a time point, only one thread is allowed to exist in the critical section at a time point. This satisfies the locking service required by Symmetric Multi-processing machines. On a single processor, the spin lock is only used as a switch to set kernel preemption. If the kernel preemptible does not exist, the spin lock will be completely removed from the kernel during compilation. To put it simply, spin locks are mainly used in the kernel to prevent concurrent access to the critical zone in the multi-processor and to prevent competition caused by kernel preemption. In addition, the spin lock does not allow the task to sleep (sleep of a task holding the spin lock will cause an automatic deadlock-Because sleep may cause the kernel task holding the lock to be rescheduled, apply for a lock that you already hold), which can be used in the interrupt context.

Deadlock: assume that one or more kernel tasks, one or more resources, each kernel is waiting for one of these resources, but all resources are occupied. In this case, all kernel tasks are waiting for each other, but they will never release the occupied resources. Therefore, no kernel task can obtain the required resources and continue running, this means that the deadlock has occurred. Self-occupation means that you possess a certain resource, and then apply for the resource that you already possess. Obviously, it is impossible to obtain the resource again. This is the case if a spin lock is used recursively.

(2) semaphores (semaphore)

I mentioned semaphores in chapter 1 of "a deep understanding of Linux kernel". In essence, semaphores (semaphore) are used to keep waiting for sleep, if the kernel control path tries to obtain the busy resources protected by the kernel semaphore, the semaphore will push it into the waiting queue, and the corresponding process will be suspended to sleep. In this case, the processor is free to execute other code. When the process holding the semaphore releases the semaphore, a task pending in the queue will be awakened, so that the semaphore can be obtained. Only functions that can sleep can obtain the kernel semaphore.

Semaphores have sleep characteristics, so that semaphores can be used when locks are 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. If the code needs to sleep-this often happens when it is synchronized with the user space-using semaphores is the only option. If you need to choose between a spin lock and a semaphore, it is generally easier to use a semaphore when it is not subject to sleep restrictions and requires a lock for a long time. However, the time lock spin lock is ideal. However, it is ideal that all locks should be held as short as possible. 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.