# How can a spinlock progress when it's busy-waiting?

I read that in spinlock, process keeps on waiting for the lock continuously in a loop until it receives signal(lock) or release(lock) from other processes. This causes busy waiting and hence CPU cycles are wasted.

My doubt is, if CPU is continuously checking the value of lock variable in loop, then how will some other process completely execute critical section and release the lock as executing critical section also needs CPU and CPU is busy checking the value of lock in other process?

There might be other CPUs in the system, if one is busy waiting, another can be doing something. Furthermore, if the OS uses preemptive scheduling, the thread doing the busy wait might be preempted and another thread will do something and release the lock for example. The signal might also come from an interrupt handler, for example if the thread is waiting for the completion of some I/O operation, and an interrupt will stop the execution of the thread temporarily, signal the lock, and resume the thread.

• Suppose we have 2 processes P1 and P2. If process P1 is in critical section and gets preempted by high priority process P2. Now if P2 uses spinlock then it will be keep on waiting for the lock(as P1 is in critical section). Now the CPU cannot even switch to P1 as it has lower priority than P2. Now what will happen in this case ? Here all CPU cycles will be wasted for P2 forever. – Zephyr Oct 31 '17 at 19:29
• What you are describing is the typical case of priority inheritance and also points out to one of the problem of spinlocks. If the high priority thread uses a regular lock (like mutex), typically a priority inheritance mecanism will boost the priority of P1 to that of P2 so that there is no starvation. In the case of spinlocks, things gets tricky but the same principle works. This article gives more details: Linux simply will not preempt a thread holding a spinlock for example. – Amaury Pouly Oct 31 '17 at 19:38
• Hmmm, I will have a look at that. Thanks. – Zephyr Oct 31 '17 at 19:39

A spinlock is indeed wasting CPU time while the lock is held by another thread. So why / when would you use a spin lock? You use it when the lock is held for very, very short times.

A "real" lock that stops the thread from running until the lock isn't held anymore has some significant overhead for stopping / restarting the thread. So as long as the average time the lock is held is smaller than this overhead, the spinlock wins. If you hold locks for a long time, a spinlock is terribly inefficient.

• Here we assume that both the threads run on different processors right ? Otherwise how will CPU simultaneously loop inside spinlock and also execute other processes critical section ? – Zephyr Nov 1 '17 at 22:25

Checking some value is equivalent to doing some work by CPU. Now if you have read scheduling properly you would have known that the CPU can be taken from any process even in the middle of a task. So even when a process is stuck on spinlock, nothing will prevent the scheduler from taking the cpu from this process and giving a chance to some other process(maybe the one which is in its critical section).