Original Address: https://blog.csdn.net/zixiao217/article/details/77063332
Discussion # kernel locks:
## Why kernel lock?
Multicore processors, will be the presence of multiple processes in kernel mode, while in kernel mode, the process is accessible to all kernel data, so to shared data protection, namely exclusive deal
What kernel lock mechanism ## has a?
### (1) atomic operation
atomic_t data types, atomic_inc (atomic_t * v) v will add 1
atomic operation is lower than the average operating efficiency, so use only when necessary, and not with the ordinary operation mixture
if single-core processor, the same atomic operation and normal operation
### (2) spin lock
spinlock_t data type, spin_lock (& lock) and spin_unlock (& lock) are unlocked and locked
waiting process repeatedly checks unlocked lock is released and do not go to sleep (busy wait), so often used for short-term protection piece of code
while holding a spin lock process is not allowed to sleep, or will cause deadlocks - because sleep may cause holdings lock process is rescheduled, they have to apply for a lock held again
if it is a single-core processor, the spin-lock operation is defined as an empty, closed because of the simple interruption can achieve mutual exclusion
### (3) and mutex semaphore
struct semaphore data type, down (struct semaphore * sem) and up (struct semaphore * sem) is occupied and release
struct mutex data type, mutex_lock (struct mutex * lock) and mutex_unlock (struct mutex * lock) are locking and unlocking
the need for the process to sleep and wake up when the competition semaphore and mutex, the higher the cost, so the code is not suitable for short-term protection for longer protection mutex and critical section signal the difference between the amount of?
- Mutex for the thread mutually exclusive signal line for thread synchronization
This is a fundamental difference between a mutex and a semaphore, mutex, and that is the difference between synchronous
mutually exclusive : is a resource while allowing only a visitor to access it, is unique and exclusive. But visitors can not restrict access to exclusive order of resources, that is disorderly access
synchronization : is on the basis of mutually exclusive (in most cases), the visitor achieve orderly access to resources through other mechanisms. In most cases, mutual exclusion synchronization has been achieved, especially in the case of writing all resources must be mutually exclusive. Rarely is one that can allow visitors to simultaneously access multiple resources - Mutually exclusive values can only 0/1, the magnitude of the signal may be non-negative integer
that is, a mutex can only be used for exclusive access to a resource, it can not achieve more resources multithreading mutex problem . Semaphore can implement multiple similar resources multithreading mutex and synchronization. When the mutual exclusion semaphore is a single semaphore is a resource can be completed - Mutex must correspond to the locking and unlocking by the same thread are used, semaphores can be released by a thread, another thread to give
and the difference between #mutex spin lock and applications (difference between sleep-waiting and a busy-waiting)
semaphore mutex is a sleep-waiting. That is when a mutex is not obtained, there will be a context switch, himself, added to the busy waiting queue until another thread releases the mutex and wake it up, but this time the CPU is idle, processing other tasks can be scheduled.
The spin lock spin lock is busy-waiting. That is when the lock is not available, it has been kept busy waiting and conduct lock requests, until you get up to the lock. This process cpu always busy, can not do other tasks.
For example two threads (thread A and thread B) in a dual-core machine, respectively, and run on Core0 Core1. With spin-lock, the thread on coer0 will always occupy CPU.
Also worth noting that the details of a spin lock spent more user time. This is because the two threads are running on two cores, most of the time only one thread can get a lock, another thread has been so busy-wait on its core operation, CPU occupancy rate has been 100%; and mutex is different, when a request for a context switch lock failure occurs, so that an empty core can be of other computing tasks. (In fact, this context switching overhead and this is already holding the thread that is going to affect the performance of the lock, because when the thread releases the lock it needs to notify the operating system to wake up those threads are blocked,)
##to sum up
- Mutex suitable for very frequent scene lock operation, and has better adaptability. Although compared to the spin lock it takes more overhead (primarily context switch), but it can fit in the actual development of complex scenarios, provide greater flexibility in the premise of guaranteed performance.
- spin lock of the lock / unlock better performance (it takes less cpu command), but it is only adapted for operating a short-time critical scene. In the actual software development, unless the operation of the lock behavior of their program very understanding programmer, otherwise the spin lock is not a good idea (usually a multithreaded program with the operation of the lock several million times, if it fails lock operation (contended lock requests) too much, it would waste a lot of time waiting empty).
- Safer approach might be to (conservative) use Mutex, and then if there is further demand for performance, you can try using a spin lock tune. After all, our program Linux kernel not so high as to performance requirements (Linux Kernel is the most common operation lock spin lock and rw lock).