Local locks in the kernel (spinlocks vs. RT workloads)

"code that needs to respond to an event quickly may be blocked on a lock": this statement is true whether your lock is spinning or sleeping (e.g. a mutex). And you solve this problem with thread priorities and priority inheritance.

So.. the reason why spinning locks are problematic for real-time operating systems is a bit more subtle than that.

Preemption must be disabled while acquiring a spinlock. This means that higher priority threads (including RT threads) cannot get scheduled during the whole period of a spinlock critical section (on that CPU). This means that if you have "sufficiently large" spinlock critical sections in your kernel, your RT threads latency will get badly affected.

Non-spinning locks do not have this problem, because their critical sections can be preempted at will. Meanwhile, spinlocks must disable preemption because if a thread holding a spin lock got preempted, it will let a possibly huge number of other threads consume their entire time slice just spinning.