1
$\begingroup$

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?

Improve this question
$\endgroup$
1
  • $\begingroup$ On a uniprocessor system the spin lock only disables interrupts - this guarantees that no other thread or interrupt can break the critical section. On a multiprocessor system the spinlock spins on a compare and swap operation. Such a system has the additional requirement that only one cpu at a time should ever be in the critical section. $\endgroup$
    – Martin
    Commented Oct 6, 2023 at 6:18

3 Answers 3

Reset to default
4
$\begingroup$

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.

Improve this answer
$\endgroup$
4
  • $\begingroup$ 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. $\endgroup$
    – Zephyr
    Commented Oct 31, 2017 at 19:29
  • $\begingroup$ 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. $\endgroup$
    – Amaury Pouly
    Commented Oct 31, 2017 at 19:38
  • $\begingroup$ Hmmm, I will have a look at that. Thanks. $\endgroup$
    – Zephyr
    Commented Oct 31, 2017 at 19:39
  • $\begingroup$ You can not be preempted while holding a spinlock. That's the whole point of a spinlock. You can only have multiple CPUs contending for the same lock. Which is solved by spinning until the other cpu releases the lock. $\endgroup$
    – Martin
    Commented Oct 6, 2023 at 6:19
2
$\begingroup$

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.

Improve this answer
$\endgroup$
2
  • $\begingroup$ 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 ? $\endgroup$
    – Zephyr
    Commented Nov 1, 2017 at 22:25
  • $\begingroup$ You can not be preempted on the same CPU if you are holding a spinlock. Busy looping only happens if you have more than one cpu. And yes, the threads mist by definition run on different cores because you can not be preempted by another thread on the same core while you have the lock. No thread will run on that core besides you $\endgroup$
    – Martin
    Commented Oct 6, 2023 at 6:22
0
$\begingroup$

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

Improve this answer
$\endgroup$
2
  • $\begingroup$ This is more BS. You can not be preempted while holding a spinlock. It literally has two functions: disable interrupts and spin if lock is held by another cpu. There is no "system taking the cpu" because scheduler is never going to run because interrupts are disabled. This is by design. It has to be done this way. $\endgroup$
    – Martin
    Commented Oct 6, 2023 at 6:24
  • $\begingroup$ That’s the whole idea of a spin lock. You use a spin lock if you expect the condition to be fixed by another CPU so quickly that it is cheaper to waste time spinning while waiting than giving up the CPU. If there is no other CPU then this is a deadlock. $\endgroup$
    – gnasher729
    Commented Oct 16, 2023 at 14:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.