Some common doubts on spinlocks:

* Suppose a user program has two threads T1 and T2. Both T1 and T2 are contending for a userspace spinlock L. T1 acquires L and T2 is waiting for this lock. Will anything go wrong if T1 is interrupted when holding this spinlock, and the kernel runs T2? No, it is fine, but inefficient. The OS doesn't know this locking based dependency between T1 and T2. So while T1 holds the lock, the OS may context switch T1 out, and start running T2. T2 cannot do anything useful, as it is just spinning on the CPU for the lock. After it runs in this way (unproductively) for some time, the OS may go back to running T1 again, which will release the lock. So the next time T2 runs, it can make progress. Overall, it is inefficient but nothing bad happens. A similar story will happen when T2 is spinning on a different CPU core as wel. Until T1 releases the lock, T2 simply wastes CPU. So nothing bad happens if T2 runs while T1 holds the lock, except wasting CPU.

* Suppose a user program has two threads T1 and T2. T1 has gone into kernel mode and acquired a kernel spinlock L. Now, is it ok for the OS to interrupt T1 and switch context to T2 (or to any other process)? No, it is not okay, because T2 can go into kernel mode and request for the same kernel spinlock L. At this point, we have a deadlock. T2 will keep spinning forever for this lock in an infinite loop, and the OS becomes unresponsive. To avoid such situations, whenever a process or thread acquires a spinlock in kernel mode, we always disable interrupts on that CPU core, let the thread/process quickly finish its critical section, and then reenable interrupts. This discipline of holding spinlocks for a quick short duration, and disabling any interrupts on that core when the spinlock is held, is required when writing kernel code.

* When a process moves into kernel mode and acquires a spinlock L (when executing on core C0), should we disable interrupts on all other CPU cores also? No, not required. Can some other process enter into kernel mode on another core C1 and request for the same lock L on core C1? Yes. It is ok for some other process to spin for lock L on another core C1. Nothing bad will happen here, because the original process is still running on C0 and it will release the lock soon, and the process on C1 will end its spinning eventually. It is not ok for two processes to spin for the same kernel spinlock on the same core, but it is ok for them to spin on different cores, because they are not causing a deadlock and blocking each other from running when spinning on different cores.

* We have already seen that when a process enters kernel mode and acquires a kernel spinlock, it must disable all interrupts on that CPU core, in order to avoid the deadlock scenario where an interrupt occurs and the interrupt handler also spins for the same spinlock. Now, a subtle question: when should interrupts be disabled? After acquiring the lock, or before attempting to acquire the lock? The answer is that interrupts should be disabled before attempting to acquire the lock itself, because we do not want to leave any vulnerable window between acquiring a spinlock and disabling interrupts. What if an interupt occurs in the small window between acquiring a lock, and disabling interrupts, leading to deadlock? Therefore, always disable interrupts on that core before proceeding to acquire (or spinning for while waiting to acquire) a spinlock. Similarly, re-enable interrupts only after the lock has been released.