Spinlock vs Busy wait

Question

Please explain why Busy Waiting is generally frowned upon whereas Spinning is often seen as okay. As far as I can tell, they both loop infinitely until some condition is met.

Answer 1

A spin-lock is usually used when there is low contention for the resource and the CPU will therefore only make a few iterations before it can move on to do productive work. However, library implementations of locking functionality often use a spin-lock followed by a regular lock. The regular lock is used if the resource cannot be acquired in a reasonable time-frame. This is done to reduce the overhead with context switches in settings where locks usually are quickly obtained.

The term busy-waiting tends to mean that you are willing to spin and wait for a change in a hardware register or a memory location. The term does not necessarily mean locking, but it does imply waiting in a tight loop, repeatedly probing for a change.

You may want to use busy-waiting in order to detect some kind of change in the environment that you want to respond to immediately. So a spin-lock is implemented using busy-waiting. Busy-waiting is useful in any situation where a very low latency response is more important than wasting CPU cycles (like in some types of embedded programming).

Related to this are the terms «lock-free» and «wait-free»:

So-called lock-free algorithms tend to use tight busy-waiting with a CAS instruction, but the contention is in ordinary situations so low that the CPU usually have to iterate only a few times.

So-called wait-free algorithms don't do any busy-waiting at all.

(Please note that «lock-free» and «wait-free» is used slightly differently in academic contexts, see Wikipedia's article on Non-blocking algorithms.)

Answer 2

Standard versus spin mutexes: When a thread calls the function that locks and acquires a mutex, the function does not return until the mutex is locked. This is typical for event synchronization: a thread waiting for an event, namely, the fact that it has acquired mutex ownership. There are two ways in which this can happen:

• An idle wait: the thread waiting to lock the mutex is blocked in a wait state as explained in Chapter 2. It releases the CPU, which can then be used to run another thread. When the mutex becomes available, the runtime system wakes up and reschedules the waiting thread, which can then lock the now available mutex.

• A busy wait, also called a spin wait, in which a thread waiting to lock the mutex does not release the CPU. It remains scheduled, executing some trivial do nothing instruction until the mutex is released.

Standard mutexes normally subscribe to the first strategy, and perform an idle wait. But some libraries also provide mutexes that subscribe to the spin wait strategy. The best one depends on the application context. For very short waits spinning in user space is more efficient because putting a thread to sleep in a blocked state takes cycles. But for long waits, a sleeping thread releases its CPU making cycles available to other threads

I found this quite related from this source: https://www.sciencedirect.com/topics/computer-science/waiting-thread

Answer 3

When you understand the precise reason for a rule and have detailed platform and application knowledge, you know when it's appropriate to violate that rule. Spinlocks are implemented by experts who have a complete understanding of the platform they're developing on and the intended applications for spinlocks.

The problems with busy waiting are numerous, but on most platforms, there are solutions for them. Issues include:

1. For CPUs with hyper-threading, a busy-waiting thread can starve another thread in the same physical core, even the very thread it's waiting for.
2. When you busy wait, when you finally do get the resource you're waiting for, you take the mother of all mispredicted branches.
3. Busy waiting interferes with CPU power management.
4. Busy waiting can saturate inter-core buses as the thing you keep checking causes cache synchronization traffic.

But the people who design spinlocks understand all these issues and know precisely how to mitigate them on the platform. They don't write naive spinning code, they write intelligent spinning code.

So yes, they both loop infinitely until some condition is met, but they loop differently.