Spin_lock & Mutex_lock The difference?

Why do I need a kernel lock?

Multi-core processor, there will be multiple processes in the kernel state, and in the kernel state, the process can access all the kernel data, so to protect the shared data, that is, mutex processing

What are the kernel lock mechanisms?

(1) Atomic operation

atomic_t data type, Atomic_inc (atomic_t *v) adds v plus 1

Atomic operations are less efficient than normal operations and are therefore used only when necessary and cannot be mixed with normal operations

If it is a single-core processor, atomic operations are the same as normal operations

(2) Spin lock

spinlock_t data types, Spin_lock (&lock) and Spin_unlock (&lock) are lock and unlock

A process waiting to be unlocked will repeatedly check that the lock is released without going to sleep (busy waiting), so it is often used for short-term protection of a piece of code

Also, a process that holds a spin lock does not allow sleep, or it can cause a deadlock-because sleep can cause the lock-holding process to be re-dispatched and again apply for the lock that you have held

In the case of a single-core processor, the spin lock is defined as an empty operation, because a simple shutdown interrupt enables mutual exclusion

(3) Signal volume and mutex amount

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

Process sleep and wake-up when competing for semaphores and mutexes are expensive, so it is not suitable for short-term code protection and is suitable for protecting longer critical areas

What is the difference between the mutex and the semaphore? (reproduced but could not find the original source)

(1) Mutex is used for mutual exclusion of threads, signal lines are used for thread synchronization

This is the fundamental difference between the mutex and the semaphore, which is the difference between the mutex and the synchronization

Mutex: Refers to a resource that allows only one visitor to access it, with uniqueness and exclusion. But mutual exclusion cannot limit the order in which visitors access resources, that is, access is unordered

Synchronization: Refers to the mutual exclusion of the basis (in most cases), through other mechanisms to achieve the visitor's orderly access to resources. In most cases, synchronization has been mutually exclusive, especially if all writes to the resource must be mutually exclusive. In rare cases, multiple visitors can be allowed to access resources at the same time

(2) The mutex value can only be 0/1, and the semaphore value may be a nonnegative integer

In other words, a mutex can only be used for mutually exclusive access to a resource, and it cannot implement multi-threaded mutex issues for multiple resources. The semaphore can realize multi-thread mutual exclusion and synchronization of multiple homogeneous resources. When the semaphore is a single-valued semaphore, it is also possible to complete a mutually exclusive access to a resource

(3) The lock and unlock of the mutex must be used by the same thread, the semaphore can be released by one of the threads, and the other thread gets

[The difference between]mutex and spin lock

Distinction and application of mutexes and Spin lock (difference between sleep-waiting and busy-waiting) 2011-10-19 11:43

The semaphore mutex is sleep-waiting. This means that when a mutex is not acquired, there is a context switch, adding itself to the busy wait queue until another thread releases the mutex and wakes it up, while the CPU is idle and can dispatch other task processing. 

and the spin lock spin lock is busy-waiting. This means that when there is no lock available, it is always busy waiting and locking requests continue until the lock is obtained. The CPU is always busy in this process and cannot do other tasks. 

For example, on a dual-core machine, there are two threads (thread A and thread B), which run on Core0 and Core1 respectively. Using a thread on a SPIN-LOCK,COER0 will always consume the CPU. 
Another notable detail is that spin lock consumes more user time. This is because two threads are running on two cores, and most of the time only one thread can get the lock, so the other thread is always busy waiting on the core it runs on, CPU occupancy is 100%, and the mutex is different, and the context switch occurs when a request to lock fails. This will make it possible to empty a nucleus for other computing tasks. (In fact, this context switch has an impact on the performance of the thread that already has the lock, because when the thread releases the lock it needs to notify the operating system to wake up the blocked threads, which is an additional overhead)

Summary
(1) The mutex is suitable for the scene with very frequent lock operation and has better adaptability. Although it costs more than spin lock (mostly context switching), it is suitable for complex scenarios in real-world development, providing greater flexibility in terms of performance. 

(2) Spin Lock's lock/unlock performance is better (less CPU instruction), but it only adapts to scenarios where critical areas run for a short time. In the actual software development, unless the programmer is aware of the lock operation behavior of their own program, it is not a good idea to use spin lock (usually a multi-threaded program has thousands of operations on the lock, if the lock operation fails (contended lock requests) Too much will waste a lot of time waiting for the empty. 

(3) a more insured approach may be to use the Mutex first (conservatively), and then, if there is further demand for performance, you can try tuning with spin lock. After all, our program is not as high-performance as Linux kernel (the most common lock operation for Linux kernel is spin lock and RW lock). 

Spin_lock & Mutex_lock The difference?