Spinlock is a lock which causes a thread trying to acquire it to simply wait in a loop while repeatedly checking if the lock is available. This is similar to busy-waiting, since the thread is active but is not doing any useful work.
Question #157: Which of the following makes sense regarding spinlocks?
Options:
1. Spinlock is more useful for uni-processor systems, than multiprocessor systems.
2. Spinlock is more useful for multiprocessor systems, than uni-processor systems.
3. Spinlocks can be useful as they avoid the overhead of context switch and CPU scheduling.
4. Acquiring a lock cannot happen without spinlocks.
Solution: In a uni-processor system, if a thread has nothing better to do than just wait, it makes more sense to release the control of processor and go to sleep, so that some other thread/process can take over the processor and do some useful work. However, in a multiprocessor system, it’s okay for a thread to waste a few CPU cycles in spinlock, since other processes can still run on the other processors during that time. Imagine a scenario where process A is running and it holds lock L, but a higher priority process B comes along, causes context switch and gets hold of the CPU. Now, process B starts running but needs lock L. If process B goes into spin lock, then all the CPU cycles are wasted as unless process A is allowed to run, it cannot release L. Hence option 2 is right over option 1.
Option 3 is also correct, since if a process has to wait for a short time, and then run again, it makes sense to use spinlocks than to do context switches. Option 4 is false, since it is not necessary to implement spinlock for acquiring locks. A thread can go to sleep if a lock is unavailable and be woken up when a lock becomes available again.
So both options 2 & 3 are correct here.
Bytes of the day 