How spinlock prevents the process to be interrupted?

Question

I read an answer on this site says the spin-lock reduce the overhead with context switches, and after that I read an textbook statement related to this:

Spin-lock makes a busy waiting program not be interrupted.

My question is on the title.

Since the book uses while-loop to indicate the implementation of the spin part of a spin-lock, the following is my reasoning trying to explain myself with this consideration.

This sounds like if there is a program with a busy waiting while loop then all the others program(processes) won't be executed forever, but won't this make a multiprogramming environment broken down, since the others processes can no longer to be executed after certain time interval has past? But I remember that the OS will prevent any process from dominate the CPU forever?

Or this is generally true in most architecture so it's not recommended since the degree of multiprogramming decrease, or one has to know precisely how long it will stop? Sorry for vague question but what I typed is exactly the same as the book states.

For more details about my confusion: I think for a given while loop

while (this == true);

is nothing more than the expended version

if (this == true);
if (this == true);
if (this == true);
...
...    
if (this == true); // (*)
...            
...
if (this == true);
...

So why it won't be interrupted at some (*) step above, for some reason like the time interval for the process is ended and another process is chosen from the ready queue?

Trigger

So, your real question is "How spinlock prevents the process to be interrupted?", isn't it? BTW, expression while (this == true); express a spin (busy waiting), but not a spinlock, which additionally provides a protection from switching a process. – Rockhampton

Answer 1

A spinlock really prevents the process to be interrupted by other processes. Implementation of this prevention is OS-specific: since OS by itself performs process scheduling, it is able to mark the process as "cannot be rescheduled".

But you ask about whether it is fair for other processes to mark the one as uninterruptible. Actually, there are 2 (at least) notions of "spinlock": one for kernel space threads, and one for user-space threads:

1. Kernel processes, as part of OS kernel, trusts themselves: if one process acquire spinlock, it expects to release it in a short time. Once the spinlock is released, the process is no longer treated as uninterruptible and can be switched from.

   Most books which describes spinlocks talk about kernel (trusted) processes.

2. User processes, in opposite, do not "trust" themselves. This is why a "true" spinlock, which renders a process as uninterruptible for an infinite time, is not provided for user processes. At most, OS provides hybrid version of a spinlock and a mutex: during the short period of time the process, which tries to grab a spinlock, is actually rendered as uninterruptible. But if the time expires before the process acquires the spinlock, the process is moved to the waiting state, allowing other processes to be run on the same core. So "fairness" is provided.

---

Actually, "true" spinlock renders the process as uninterruptible not only while it waits, but also while it holds the spinlock. It is required for avoiding deadlocks. This is works for kernel processes (which trusts themselves). As for user processes, OS may give for the process some (also short) time of uninterruptible state until it releases the spinlock. If the time expires before spinlock is released, the process becomes interruptible again.

Rockhampton

Think of such spinlock as a mutex. A critical section, provided by a mutex, can be freely interrupted. – Rockhampton

So the point is just the other threads cannot into the critical section? And thanks for your kindness – Trigger

The main purpose of spinlock and mutex in the user space is to provide a critical section with exclusive access. This aspect is responsible for a program's correctness, and both a spinlock and a mutex perform this task well and without limitations. As an additional purpose, a spinlock tries to reduce CPU costs related to the process switching in case of attempt to grab a spinlock which is currently hold by the other process. This task doesn't affect on a program's correctness. – Rockhampton

"only one thread can be scheduled to run?" - Not quire true. Only one thread may proceed the critical section. Other threads may be in a waiting state, or busy wait. – Rockhampton

No process can enter to a critical section while the section is hold by someone else. The property "hold" is unrelated to whether the holder is currently running or not. – Rockhampton

Now I think I misused the word preemptive with interrupted, and cause myself a lot of questions, your "cannot be rescheduled" is much better than cannot be interrupted, sorry that's my fault. – Trigger