继续Mecki的建议，Alexander Sandler的博客，Alex on Linux上的文章pthread互斥锁vs pthread自旋锁展示了如何使用#ifdef实现自旋锁和互斥锁来测试行为。

但是，一定要根据你的观察来做最后的决定，理解正如所举的例子是一个孤立的案例，你的项目要求、环境可能完全不同。

还请注意，在某些环境和条件下(例如在调度级别>= dispatch level的windows上运行)，您不能使用互斥，而应该使用自旋锁。 在unix上-同样的事情。

这是竞争对手stackexchange unix网站上的等效问题: https://unix.stackexchange.com/questions/5107/why-are-spin-locks-good-choices-in-linux-kernel-design-instead-of-something-more

windows系统上的调度信息: http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b45/IRQL_thread.doc

在单核/单CPU系统上使用自旋锁通常没有意义，因为只要自旋锁轮询阻塞了唯一可用的CPU核心，就没有其他线程可以运行，而且由于没有其他线程可以运行，锁也不会被解锁。低，自旋锁只在这些系统上浪费CPU时间，没有真正的好处

这是错误的。在单处理器系统上使用自旋锁不会浪费cpu周期，因为一旦一个进程使用了自旋锁，抢占就被禁用了，因此，就不会有其他进程自旋了!只是使用它没有任何意义!因此，在Uni系统上的自旋锁被内核在编译时用preempt_disable代替!

继续Mecki的建议，Alexander Sandler的博客，Alex on Linux上的文章pthread互斥锁vs pthread自旋锁展示了如何使用#ifdef实现自旋锁和互斥锁来测试行为。

但是，一定要根据你的观察来做最后的决定，理解正如所举的例子是一个孤立的案例，你的项目要求、环境可能完全不同。

使用自旋锁的规则很简单:当且仅当锁持有的实际时间有界且足够小时使用自旋锁。

注意，通常用户实现的自旋锁不满足这个要求，因为它们不禁用中断。除非禁用了抢占，否则在自旋锁进行时进行抢占违反了有限时间要求。

足够小是一种判断，取决于上下文。

例外:一些内核编程即使在时间没有限制的情况下也必须使用自旋锁。特别是如果CPU没有工作要做，它别无选择，只能旋转，直到有更多的工作出现。

Special danger: in low level programming take great care when multiple interrupt priorities exist (usually there is at least one non-maskable interrupt). In this higher priority pre-emptions can run even if interrupts at the thread priority are disabled (such as priority hardware services, often related to the virtual memory management). Provided a strict priority separation is maintained, the condition for bounded real time must be relaxed and replaced with bounded system time at that priority level. Note in this case not only can the lock holder be pre-empted but the spinner can also be interrupted; this is generally not a problem because there's nothing you can do about it.

梅基的回答非常准确。然而，在单个处理器上，当任务等待中断服务例程提供的锁时，使用自旋锁可能是有意义的。中断将控制权传递给ISR, ISR将准备好资源供等待任务使用。在将控制权交还给被中断的任务之前，它将以释放锁结束。旋转任务将发现自旋锁可用并继续。