Spinlock vs Busy wait [closed]

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