A "spin lock" is a programming
concept used in multiprocessor
systems to protect a critical section
of code. When a process attempts to "get" the spin lock, that is, to enter the critical section of code while preventing other processes (which may be running on other processors) from simultaneously entering the critical section, if it cannot "get" the lock, it will disable interrupts (for that processor) then busy wait
, or "spin", trying to get the lock, until it eventually succeeds in getting the lock. This may seem counter-intuitive, "wasting" the processors time spinning waiting for a lock to become available, and you might wonder if it wouldn't be better to put the process to sleep and have it woken up when the lock becomes available. The thing is, in many cases, the critical section is so short that no single process ever holds it for long enough to make a context switch
(which is what putting the process to sleep would entail) worth while. So, as a practical matter, for short critical sections on multiprocessor systems, it's better to use a spin lock.
On single processor systems you "get" the spin lock
by just disabling interrupts. This prevents the scheduler
from taking the processor away from you while you're in the critical section. There's no such thing on a single processor system of waiting for (what would otherwise be) a spin lock. If you are running, you know that you are the only process running since there is only one processor, so you don't need to worry that another process might be in the critical section. Your process wouldn't have gotten the processor until the other process left the critical section and re-enabled interrupts. So it's safe to just disable interrupts and proceed into the critical section. Usually this distinction is handled transparently by the OS, that is, your code is written the same regardless of how many processors you have, and the code that you call to obtain the lock just does the right thing.