Concurrent control in device drivers (spin lock and semaphore)

In a driver, when multiple threads access the same resource at the same time (a global variable in the driver is a typical shared resource), "race" may be thrown, so we must have concurrent control over the shared resource. The most common way to solve concurrency control in the Linux kernel is to spin the lock and Semaphore (most of the time as a mutex). Spin lock and semaphore "similar but not class", similar to their functional similarity, "not" refers to them in essence and the realization mechanism is completely different, not belong to a class. The spin lock does not cause the caller to sleep, and if the spin lock has been maintained by another unit of execution, the caller has been looping to see if the lock has been freed by the spin lock, and "spin" is "in situ". The semaphore, which causes the caller to sleep, drags the process out of the running queue, unless the lock is acquired. This is their "no class". However, whether it is a semaphore, or a spin lock, at any time, there can be at most one retention, that is, at any time only one execution unit can acquire the lock. This is their "similar". Given the above characteristics of spin locks and semaphores, in general, spin locks are suitable for a very short period of time, which can be used in any context; The semaphore is suitable for a longer period of time and can only be used in the process context. If a protected shared resource is accessed only in the process context, the shared resource can be protected with semaphores, and a spin lock is a good choice if the access time for the shared resource is very short. However, if a protected shared resource needs to be accessed in an interrupt context (including the bottom half, the interrupt handle and the top half, which is a soft interrupt), the spin lock must be used.