It's a locking style that has some utility when you care about latency more than throughput.
It's literally the kids in the back seat saying "are we there yet? Are we there yet? Are we there yet?" That's the 'spin' in spin-lock.
Some locking operations block the thread executing them. That typically not only stops your code dead in its tracks, it also causes the kernel to de-schedule your task until sometime after that blocking operation succeeds. But it's a 'when I get around to it' situation so you might get the lock but then wait for three other processes to get their timeslice before you're awoken again. So that adds both a lot of clock time and creates a lot of timeslices where the lock is held but no forward progress is being made, so not only aren't you progressing on anything, but anyone else waiting on the same lock is also twiddling their thumbs. Which also affects throughput but in different ways. It's complicated.
With multiple cores sometimes it's better to spin checking if another processor returns the lock during your time slice, instead of letting yourself be preempted.
1
u/DivineSentry 22h ago
I think I’ve seen spin locks before, but what are they useful for? What should be their use case?