One, mutex (mutual exclusion lock):
Mutex locks are mainly used to implement mutually exclusive access functions in the kernel. Access to it must follow some rules: only one task can hold the mutex at a time, and only this task can unlock the mutex. Mutex locks cannot be recursively locked or unlocked.
Two, semaphore (semaphore):
The semaphore needs to be set with an initial value when it is created, which means that several tasks can access the shared resources protected by the semaphore at the same time. The initial value of 1 becomes a mutex, that is, only one task can be at the same time Access to shared resources protected by semaphores. If a task wants to access shared resources, it must first obtain the semaphore. The operation of obtaining the semaphore will subtract 1 from the value of the semaphore. If the value of the current semaphore is negative, it indicates that the semaphore cannot be obtained, and the task must be suspended. The waiting queue of the semaphore is waiting for the semaphore to be available; if the value of the current semaphore is non-negative, it means that the semaphore can be obtained, and thus the shared resources protected by the semaphore can be accessed immediately. After the task accesses the shared resources protected by the semaphore, it must release the semaphore. The release of the semaphore is achieved by adding 1 to the value of the semaphore. If the value of the semaphore is non-positive, it indicates that there is a task waiting for the current semaphore, so It also wakes up all tasks waiting for the semaphore.
Three, rw_semaphore (read and write semaphore):
The read and write semaphore subdivides the visitor, either for the reader or the writer. The reader can only read and access the shared resources protected by the read and write semaphore during the period when the read and write semaphore is maintained. Reading may also require writing, so it must be classified as a writer. It must first obtain the identity of the writer before accessing shared resources. The writer can be demoted to a reader if he finds that he does not need write access. The number of readers that a read and write semaphore has at the same time is not limited, that is, any number of readers can have a read and write semaphore at the same time. If a read-write semaphore is not currently owned by the writer and no writer is waiting for the reader to release the semaphore, then any reader can successfully obtain the read-write semaphore; otherwise, the reader must be suspended until the writer releases the semaphore . If a read-write semaphore is not currently owned by a reader or writer and no writer is waiting for the semaphore, then a writer can successfully obtain the read-write semaphore, otherwise the writer will be suspended until there are no visitors . Therefore, the writer is exclusive and exclusive.
Four, Spanlock (spin lock):
Spin locks are similar to mutex locks, except that the spin lock will not cause the caller to sleep. If the spin lock has been held by another execution unit, the caller will always loop there to see if the holder of the spin lock has already been held. When the lock is released, the word "spin" is named after it. Because spin lock users generally keep the lock for a very short time, it is very necessary to choose spin instead of sleep. The efficiency of spin locks is much higher than that of mutex locks.
Semaphores and read-write semaphores are suitable for longer hold times. They will cause the caller to sleep, so they can only be used in the context of the process (variants of _trylock can be used in the interrupt context), while the spin lock is suitable for holding time. In the short case, it can be used in any context. If the protected shared resource is only accessed in the context of the process, it is very suitable to use semaphores to protect the shared resource. If the access time to the shared resource is very short, a spin lock is also possible. But if the protected shared resource needs to be accessed in the interrupt context (including the bottom half that is the interrupt handler and the top half that is the soft interrupt), a spin lock must be used.
The preemption is invalid during the spin lock hold period, while the semaphore and read-write semaphore can be preempted during the hold period. The spin lock is really needed only when the kernel is preemptible or SMP. In a single-CPU and non-preemptible kernel, all spin lock operations are no-ops.
Like mutex locks, if an execution unit wants to access a shared resource protected by a spin lock, it must first obtain the lock, and after accessing the shared resource, it must release the lock. If no execution unit holds the lock when the spin lock is acquired, the lock will be acquired immediately; if the lock has a holder when the spin lock is acquired, then the lock acquisition operation will spin there until the spin lock The holder released the lock.
Whether it is a mutex lock or a spin lock, there can be at most one holder at any time, that is, at most one execution unit can acquire the lock at any time.