I would like to know why spin locks are used instead of semaphores inside an interrupt handler.
Because they usage in the IH can dramatically increases the interrupt handling latencies (in case of IH running in the context of low priority thread) and is able to produce deadlocks (in case of IH running in the context of thread which hold the lock).
To synchronize access to the shared data, we disable the interrupts and use the spinlock lock, i.e. the spin_lock_irqsave() and spin_unlock_irqrestore() functions. In the interrupt handling routine, we use the spin_lock() and spin_unlock() functions to access the shared resource.
This version also acquires the lock; in addition, it disables interrupts on the local processor and stores the current interrupt state in flags . Note that all of the spinlock primitives are defined as macros, and that the flags argument is passed directly, not as a pointer.
It cannot be used in interrupt context either since a mutex must be released by the same task that acquired it.
Semaphores cause tasks to sleep on contention, which is unacceptable for interrupt handlers. Basically, for such a short and fast task (interrupt handling) the work carried out by the semaphore is overkill. Also, spinlocks can't be held by more than one task.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With