Reprinted from https://blog.csdn.net/susidian/article/details/51068858
Spin lock
Spin locks are similar to mutex locks, except that spin locks do not cause the caller to sleep. If the spin lock is already held by another execution unit, the caller keeps looping there to see if the spin lock holder has The lock is released, hence the name "spin". Its role is to solve the mutually exclusive use of a resource. Because spinlocks do not cause the caller to sleep, spinlocks are much more efficient than mutex locks. Although its efficiency is higher than that of mutex locks, it also has some shortcomings:
1. The spin lock always occupies the CPU. It runs all the time without acquiring the lock--spin, so it occupies the CPU. Acquiring the lock in a short amount of time will undoubtedly make the CPU less efficient.
2. Deadlock may be caused when spinlock is used, deadlock may be caused by recursive call, and deadlock may also be caused by calling some other functions, such as copy_to_user(), copy_from_user(), kmalloc(), etc.
Therefore, we must use spin locks carefully. Spin locks are only really needed when the kernel is preemptible or SMP. In a single-CPU and non-preemptible kernel, the operation of spin locks is no-op. The spin lock is suitable for the case where the lock user keeps the lock for a short time.
The locking principle of two locks
Mutual exclusion lock: The thread will go from sleep (locking) to running (unlocking), and there are overheads such as context switching, cpu preemption, and signal transmission in the process .
Spin lock: The thread is always running (locking -> unlocking), and the flag bit of the lock is detected in an infinite loop. The mechanism is not complicated.
Mutexes are sleep-waiting locks. For example, on a dual-core machine there are two threads (thread A and thread B) running on Core0 and Core1 respectively. Suppose thread A wants to obtain a lock in a critical section through the pthread_mutex_lock operation, and the lock is currently held by thread B, then thread A will be blocked, and Core0 will perform a context switch at this time. Switch) puts thread A in the waiting queue, at which time Core0 can run other tasks (such as another thread C) without busy waiting. This is not the case with spin locks, which are busy-waiting locks. If thread A uses the pthread_spin_lock operation to request a lock, then thread A will always be busy waiting on Core0 and keep requesting locks until it gets this until locked.
The difference between the two locks
The initial cost of the mutex lock is higher than that of the spin lock, but it is basically done once and for all. The size of the lock holding time in the critical section will not affect the cost of the mutex lock, and the spin lock is an infinite loop detection, locking The CPU is consumed in the whole process. Although the initial cost is lower than that of the mutex, the cost of locking increases linearly with the lock holding time.
Application of two locks
Mutual exclusion locks are used for operations that hold the lock for a long time in the critical section. For example, the following situations can be considered
1 The critical section has IO operations
2 The critical section code is complex or the amount of loops is large
3 Critical sections are very competitive
4 single core processors
As for the spin lock, it is mainly used in the case where the lock holding time of the critical section is very short and the CPU resources are not tight. The spin lock is generally used in multi-core servers.