When a thread of control must wait for an event to occur, it normally blocks, expecting to awaken when it receives a signal notifying it that the event occurred. The problem with blocking is that the thread of control must make a relatively expensive system call into the kernel, and then give up the rest of its time slice. The overhead of blocking can be avoided if the event will happen very soon, or has already happened, by polling for the event in a loop.
Spin-waits may be more appropriate than blocking awaiting a signal when an operation is waiting on hardware, and must respond very rapidly.
In a multi-core processor where threads of control may be truly concurrent, spin-waiting may make a carefully-designed system more responsive to events. On a single-core processor, a spin-wait can only be effective if the event has already occurred, or if the spin-waiting thread of control is preempted in favor of another thread of control that signals the event. This may happen if an interrupt causes the preemption.
If the expected event does not happen very soon (on the order of microseconds), a spin-wait can be very wasteful of CPU time.
A short initial spin-wait is often followed by a blocking wait in synchronization mechanisms provided by the operating system.
Spin-waits must be designed carefully, because they can be affected by the hardware's memory model, or by optimizations performed by the compiler that may cause the memory location not to be written or read as expected by the developer. See the Double-Checked Locking Pattern for some warnings about how tricky this is.