Is spin lock useful in a single processor uni core architecture?

Question

I am confused by the function of spin lock.

The spin lock is used to stop the process from re-scheduling. However, in a machine with just one core, is it useful to use s

Answer 1

Your observation is good: on a uniprocessor system, there is no point in spinning to wait for a resource, because you will may as well switch threads sooner rather than later. Mutexes and semaphores do exactly this.

On a multiprocessor system, a thread on another processor may release the lock without you context-switching. Spinlocks can be useful, then, if you don't expect to be waiting long, because it may be faster just to hang around until the other thread unlocks the thing. If you go to sleep on a mutex, you're basically assured some significant dead time before you will get rescheduled.

In kernel code, however, the situation changes: Interrupt handlers need to access shared resources with the rest of the kernel, but they cannot sleep. Mutexes will put the kernel to sleep, so you can't use them, but spinlocks aren't useful either because nothing will interrupt an interrupt handler on a uniprocessor (well, maybe another interrupt, but that's scary).

In a kernel, then, spinlocks within an interrupt handler compile to a no-op. They are completely elided, just like you might think. At the same time, to prevent races, spinlocks in the rest of the kernel disable interrupts just before they actually spin on something (because kernel tasks can be scheduled). These codes only need spinlocks (as opposed to mutexes) if they share code with an interrupt handler.

In general, you're right: spinlocks really don't make much sense on a uniprocessor if you have mutexes, because mutexes waste less time.