Semaphores in Linux are sleeping locks.When a task attempts to acquire a semaphore that is unavailable, the semaphore places the task onto a wait queue and puts the task to sleep.The processor is then free to execute other code.When the semaphore becomes available, one of the tasks on the wait queue is awakened so that it can then acquire the semaphore.
Important Points
1.Semaphores are well suited to locks that are held for a long time
2.Because a thread of execution sleeps on lock contention, semaphores must be obtained only in process context because interrupt context is not schedulable.
3.You can (although you might not want to) sleep while holding a semaphore because you will not deadlock when another process acquires the same semaphore. (It will just go to sleep and eventually let you continue.)
4.You cannot hold a spin lock while you acquire a semaphore, because you might have to sleep while waiting for the semaphore, and you cannot sleep while holding a spin lock.
5.Unlike spin locks, semaphores do not disable kernel preemption and, consequently, code holding a semaphore can be preempted.This means semaphores do not adversely affect scheduling latency.
Important Points
1.Semaphores are well suited to locks that are held for a long time
2.Because a thread of execution sleeps on lock contention, semaphores must be obtained only in process context because interrupt context is not schedulable.
3.You can (although you might not want to) sleep while holding a semaphore because you will not deadlock when another process acquires the same semaphore. (It will just go to sleep and eventually let you continue.)
4.You cannot hold a spin lock while you acquire a semaphore, because you might have to sleep while waiting for the semaphore, and you cannot sleep while holding a spin lock.
5.Unlike spin locks, semaphores do not disable kernel preemption and, consequently, code holding a semaphore can be preempted.This means semaphores do not adversely affect scheduling latency.
No comments:
Post a Comment