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.

Solution 1

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.

Solution 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.

Solution 3

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.

Comments

[mousey]

@mfukar I know the reason but I didnt understand why double acquire deadlocks can occur because of sleeping and not while using spin locks

[mousey]

Also I would like to know why spin_trylock() is needed ?

[caf]

@mousey: double-acquire deadlocks cannot occur with spinlocks, because if a spinlock is shared with an interrupt handler all lockers of the spinlock must use the interrupt-disabling variant of the lock function.

[mousey]

@caf who shares spin lock with an interrupt handler ? Can you please explain. Similarly mutexes can be done in the same way right. we can disable all the interrupts.

[Michael Foukarakis]

@mousey: spin_trylock() is commonly used where the critical section is optional, and can be skipped.

[caf]

@mousey: Someone shares a spin lock with an interrupt handler if they access the same shared data that the interrupt handler does. Mutexes cannot disable interrupts, since if you disable interrupts and sleep, you will never wake up!

[mousey]

@caf Now I got it. Thank you very much.

[Dipstick]

Seem to have missed the point that when an interrupts uses a spinlock it is to cater for the case where the spinlock has been taken by software running on another processor - the interrupt handler spins whilst the other processor finishes its access to the guarded resource and releases the spinlock. If an interrupt handler - running with interrupts disabled - hits a locked spinlock held by a thread on the same processor then you have a deadlock. As mentioned above, mutex between a thread and an interrupt handler on the same processor is handled by the thread disabling interrupts.