Difference between spin locks and semaphores

In the driver, when multiple threads access the same resource at the same time (the global variable in the driver is a typical shared resource), it may lead to a "race State ", therefore, we must control the concurrency of shared resources. The most common method to solve Concurrency Control in Linux kernel is spin lock and semaphore (usually used as mutex lock ).

Spin locks are similar to semaphores, but not similar to semaphores. Similar to semaphores, spin locks are similar to semaphores in terms of functions. They are completely different in nature and implementation mechanism, but not in the same category.

The spin lock will not cause the caller to sleep. If the spin lock has been maintained by another execution unit, the caller will keep repeating and check whether the lock holder has released the lock, "Spin" means "in-situ rotation ". The semaphores cause the caller to sleep. They drag the process out of the running queue unless the lock is obtained. This is their "not class ".

However, either a semaphore or a spin lock can have at most one lock at any time point, that is, at most one execution unit can obtain a lock at any time point. This is their "similar ".

In view of the above features of the spin lock and semaphore, the spin lock is suitable for keeping the time very short, it can be used in any context; the semaphore is suitable for holding for a long time, it can only be used in the process context. If the protected shared resource is accessed only in the process context, the shared resource can be protected by semaphores. If the access time to the shared resource is very short, the spin lock is also a good choice. However, if the protected shared resource needs to interrupt context access (including the bottom half, namely the Interrupt Processing handle and the top half, namely the Soft Interrupt), the spin lock must be used.

The differences are summarized as follows:

1. Because the processes competing for semaphores will sleep while waiting for the lock to become available again, the semaphores are suitable for cases where the lock will be held for a long time.

2. On the contrary, when the lock is held for a short time, it is not appropriate to use the semaphore, because the time consumed by sleep may be longer than the full time occupied by the lock.

3. Because the execution thread will sleep during lock contention, the semaphore lock can only be obtained in the process context, because scheduling cannot be performed in the interrupt context (using the spin lock.

4. You can sleep when holding a semaphore (You may not need to sleep, of course), because it won't be deadlocked when other processes try to get the same semaphore, (because the process is just sleep, and you will continue to execute it ).

5. You cannot use spin locks when using semaphores, because you may sleep while waiting for semaphores, but do not allow sleep when holding spin locks.

6. The critical section of semaphore lock protection can contain code that may cause blocking, while the spin lock must be used to protect the critical section containing such code. Blocking means process switching, if another process tries to obtain the spin lock after the process is switched out, the deadlock will occur.

7. Unlike the spin lock, semaphores do not prohibit kernel preemption (kernel cannot be preemptible when the spin lock is held). Therefore, the Code holding the semaphores can be preemptible, this means that the semaphores do not have a negative impact on the scheduling wait time.
In addition to the synchronization mechanism described above, there are BKL (large kernel lock) and SEQ lock.

BKL is a global spin lock mainly used to facilitate the process from Linux's initial SMP to fine-grained locking mechanism.

The seq lock is used to read and write shared data. To implement this lock, you only need to rely on a Sequence Counter.

PS: the attempt to obtain the spin lock recursively will inevitably lead to deadlocks. The process of applying for this resource keeps "spinning" and cannot obtain the resource.

From above: http://www.cnblogs.com/iceocean/articles/1610192.html