This article is introduced into the kernel lock by this problem, and concludes as follows
Why do I need a kernel lock? Multi-core processors, there will be several processes in the kernel state, and in the kernel state, the process can access all kernel data, so to protect the shared data, that is, mutual exclusion
What are the kernel locking mechanisms? (1) Atomic Operation atomic_t data type, Atomic_inc (atomic_t *v) the V-plus 1 atomic operation is lower than the ordinary operation efficiency, so use if necessary, and can not be mixed with ordinary operation if it is a single core processor, atomic operation is the same as normal operation (2) Spin lock spinlock_t data types, Spin_lock (&lock) and Spin_unlock (&lock) are lock-and-lock-pending processes that repeatedly check the lock for release without going to sleep (busy waiting) and are often used to protect a piece of code in the short term Also, the process of holding a spin lock does not allow sleep, otherwise it can cause deadlocks-because sleep may cause the process that holds the lock to be scheduled, and again to apply for a lock that is already held if it is a single core processor, the spin lock is defined as an empty operation, because a simple shutdown interrupt can achieve mutual exclusion (3) semaphore and mutex struct Semaphore data types, down (struct semaphore * sem) and up (struct semaphore * sem) are occupied and released struct mutex data types, mutex_lock (struct mutex * Lock) and Mutex_unlock (struct mutex *lock) are lock and unlock competitive semaphores and mutexes need to process sleep and wake, the cost is high, so it is not suitable for short-term code protection, applicable to protect the longer critical area of mutual exclusion and semaphore difference? (reproduced but unable to find the original source) (1) The mutex is used for the mutex of the thread, and the signal line is used for the synchronization of the thread. This is the fundamental difference between mutexes and semaphores, that is, the difference between mutual exclusion and synchronization: A resource that allows only one visitor to access it at the same time, is unique and exclusive. However, mutual exclusion cannot limit the order in which visitors access the resource, that is, the access is unordered synchronization: it means that, on the basis of mutual exclusion (most of the cases), the visitor's ordered access to the resource is achieved through other mechanisms. In most cases, synchronization has been mutually exclusive, especially if all writes to the resource must be mutually exclusive. In a few cases, you can allow multiple visitors to access the resource at the same time (2) The mutex value is only 0/1, and the semaphore value can be a non-negative integer that is to say, a mutex can only be used for mutually exclusive access to a resource, and it cannot implement multiple-resource multithreading mutex issues. Semaphores can achieve multiple threads of mutual exclusion and synchronization of similar resources. When the semaphore is a single value signal, you can also complete the mutex access of a resource (3) the lock and unlock of the mutex must be used by the same thread, the semaphore can be released by one, and the other thread gets the &NBsp
[The difference between turning]mutex and spin lockDifferences and applications of mutex and spin lock (difference between sleep-waiting and busy-waiting) 2011-10-19 11:43
Semaphore mutex is sleep-waiting. This means that when a mutex is not acquired, there is a context switch, and it is added to the busy wait queue until another thread releases the mutex and wakes it up, while the CPU is idle and can schedule other tasks to be processed.
The spin lock spin is busy-waiting. This means that when there is no lock available, it is always busy waiting and holding the lock request until the lock is obtained. In this process the CPU is always busy and cannot do other tasks.
For example, there are two threads (thread A and thread B) on a dual-core machine that runs on CORE0 and Core1 respectively. The thread on the SPIN-LOCK,COER0 will always occupy the CPU.
Another notable detail is that spin lock consumes more user time. This is because two threads are running on two cores, respectively. Most of the time only one thread can get the lock, so another thread has been busy waiting on the core on which it is running, the CPU occupancy rate has been 100%, and the mutex is different, and the context switch occurs when the lock request fails. This allows for a core to be vacated for other tasks. (This context switch actually has an effect on the performance of the thread that already has the lock, because it needs to notify the operating system to wake up the blocked threads when the thread releases the lock, which is an extra overhead)
Summarize
(1) The mutex is suitable for the scene with very frequent lock operation, and has better adaptability. Although it will cost more than spin lock (mainly context switching), it can be adapted to the actual development of complex application scenarios and provide greater flexibility to ensure a certain performance.
(2) The Lock/unlock performance of Spin lock is better (less CPU instruction is spent), but it only adapts to scenarios where the critical section runs for a short time. In real software development, it is not a good idea to use spin lock unless the programmer is aware of the lock-operation behavior of its own program (usually a multithreaded program has countless operations on the lock, if the failed lock operation (contended lock requests) Too many words will waste a lot of time to wait for the empty.
(3) A more insurance approach might be to use a Mutex first (conservatively), and then if there is further demand for performance, you can try tuning with spin lock. After all, our programs are not as demanding as the Linux kernel (Linux kernel most commonly used lock operations are spin lock and RW lock).
