Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why is "sleeping" not allowed while holding a spinlock? [duplicate]

Possible Duplicate:
Why can't you sleep while holding spinlock?

As far as I know, spinlocks should be used in short duration, and are only choices in code such as interrupt handler where sleeping (preemption) is not allowed.

However, I do not know why there is such a "rule" that there SHOULD BE no sleeping at all while holding a spinlock. I know that it is not a recommended practice (since it is detrimental in performance), but I see no reason why sleeps SHOULD NOT be allowed in spinlocks.

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 (from "Linux Kernel Development" by Robert Love).

The only reason I can see is for portability reasons, because in uniprocessors, spinlocks are implemented as disabling interrupts, and by disabling interrupts, sleeping is of course not allowed (but sleeping will not break code in SMP systems).

But I am wondering if my reasoning is correct or if there are any other reasons.

like image 926
SHH Avatar asked Oct 23 '11 18:10

SHH


People also ask

Can a thread to sleep while holding a spinlock?

It cannot sleep; in fact, it cannot relinquish the processor for any reason except to service interrupts (and sometimes not even then). Any deadlock like mentioned above may result in an unrecoverable state.

Can spinlock be interrupted?

The interrupt handler, before accessing the device, must also obtain the lock. Taking out a spinlock in an interrupt handler is a legitimate thing to do; that is one of the reasons that spinlock operations do not sleep.

Why spinlock Why can't only mutex?

Spinlock is a lock which causes a thread trying to acquire it to simply wait in the loop and repeatedly check for its availability. In contrast, a mutex is a program object that is created so that multiple processes can take turns sharing the same resource. Thus, this is the main difference between spinlock and mutex.

Why does the Linux kernel have a policy that a process Cannot hold a spinlock while attempting to acquire a semaphore?

This policy is in place because a spin lock cannot be hold while a semaphore is acquired. If this happens, it would take more than six to seven hours before semaphore is acquired and with spin lock in hold, one cannot do so. Linux is an operating system kernel, and it is like Unix; while semaphore is a variable.


1 Answers

There are several reasons why, at least in Linux, sleeping in spinlocks is not allowed:

  1. If thread A sleeps in a spinlock, and thread B then tries to acquire the same spinlock, a uniprocessor system will deadlock. Thread B will never go to sleep (because spinlocks don't have the waitlist necessary to awaken B when A is done), and thread A will never get a chance to wake up.
  2. Spinlocks are used over semaphores precisely because they're more efficient - provided you do not contend for long. Allowing sleeping means that you will have long contention periods, erasing all the benefit of using a spinlock. Your system would be faster just using a semaphore in this case.
  3. Spinlocks are often used to synchronize with interrupt handlers, by additionally disabling interrupts. This use case is not possible if you sleep (once you enter the interrupt handler, you cannot switch back to the thread to let it wake up and finish its spinlock critical section).

Use the right tool for the right job - if you need to sleep, semaphores and mutexes are your friends.

like image 74
bdonlan Avatar answered Sep 30 '22 13:09

bdonlan