Spinlocks can be useful in multi-threaded real-time audio code. Audio processing has to meet tight deadlines (in the order of a few milliseconds) and the thread

Spinlocks can be useful in multi-threaded real-time audio code. Audio processing has to meet tight deadlines (in the order of a few milliseconds) and the thread(s) must not be preempted/rescheduled, so traditional mutexes are off the table. (Here's a good introduction to the topic: http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing http://www.rossbencina.com/code/real-time-audio-programming-...) Now, let's say several threads have to write their results into a common buffer. Ideally, they would first write into individual buffers which you can safely sum after a synchronization point. However, depending on the architecture, this might not always be possible and a spinlock might be the only practical solution. Note again that audio threads typically run with real-time priority and should not be preempted, so the major issues with spinlocks - that Linus correctly points out! - don't apply, AFAICT. One example for audio software that uses spinlocks is "Supernova", a multi-threaded reimplementation of the "scsynth" audio server. Here the author describes the locking strategy: https://www.complang.tuwien.ac.at/Diplomarbeiten/blechmann11.pdf https://www.complang.tuwien.ac.at/Diplomarbeiten/blechmann11... (section 4.3)