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?
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:
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.
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.