Why spinlocks are used in interrupt handlers

Question

I would like to know why spin locks are used instead of semaphores inside an interrupt handler.

Answer 1

The problem is that interrupt handlers (IH) are triggered asynchronously and in unpredictable way, out of the scope of any other activities running in the system. In fact, IHs run out of the scope of concept of the threads and scheduling at all. Due to this all mutual exclusion primitives which rely to the scheduler are unacceptable. 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).

You can look at nice and detailed description of spinlocks at http://www.makelinux.net/ldd3/chp-5-sect-5.

Answer 2

Whats the problem with semaphore & mutex. And why spinlock needed ?

• Can we use the semaphore or mutex in interrupt handlers. The answer is yes and no. you can use the up and unlock, but you can’t use down and lock, as these are blocking calls which put the process to sleep and we are not supposed to sleep in interrupt handlers.

• Note that semaphore is not a systemV IPC techniques, its just a synchronization techniques. And there are three functions to acquires the semaphore.

  • down() : acquire the semaphore and put into un-interruptible state.

  • down_trylock() : try if lock is available, if lock is not available , don't sleep.

  • up() :- its useful for releasing the semaphore

• So, what if we want to achieve the synchronization in interrupt handlers ? Use spinlocks.

What spinlocks will do ?

• Spinlock is a lock which never yields.

• Similar to mutex, it has two operations – lock and unlock.

• If the lock is available, process will acquire it and will continue in the critical section and unlock it, once its done. This is similar to mutex. But, what if lock is not available ? Here, comes the interesting difference. With mutex, the process will sleep, until the lock is available. But,

in case of spinlock, it goes into the tight loop, where it continuously checks for a lock, until it becomes available

.

• This is the spinning part of the spin lock. This was designed for multiprocessor systems. But, with the preemptible kernel, even a uniprocessor system behaves like an SMP.

Answer 3

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.