请解释为什么 Busy Waiting 通常不受欢迎，而 Spinning 通常被认为没问题。据我所知，它们都无限循环，直到满足某些条件。
【问题讨论】：
标签： spinlock busy-waiting
标准与自旋互斥锁：当一个线程调用该函数时 锁定并获取互斥体，该函数直到 互斥锁被锁定。这对于事件同步来说很典型：一个线程 等待一个事件，即它已获得互斥锁的事实 所有权。发生这种情况的方式有两种：
• 空闲等待：等待锁定互斥锁的线程被阻塞在一个 等待状态，如第 2 章所述。它释放 CPU，它可以 然后用于运行另一个线程。当互斥体可用时， 运行时系统唤醒并重新调度等待线程，这 然后可以锁定现在可用的互斥锁。
• 忙等待，也称为自旋等待，其中线程等待 锁定互斥锁不会释放 CPU。依旧如期而至， 执行一些琐碎的无操作指令，直到互斥体 发布。
标准互斥锁通常订阅第一个策略，并执行 一个空闲的等待。但是一些库也提供了订阅的互斥锁 到旋转等待策略。最好的取决于应用程序 语境。对于非常短的等待，在用户空间中旋转更有效 因为将线程置于阻塞状态需要循环。但 对于长时间等待，睡眠线程释放其 CPU 生成周期 其他线程可用
我发现这与此来源非常相关：https://www.sciencedirect.com/topics/computer-science/waiting-thread
【讨论】：
当您了解某条规则的确切原因并拥有详细的平台和应用知识时，您就会知道何时适合违反该规则。自旋锁由完全了解他们正在开发的平台和自旋锁的预期应用程序的专家实施。
忙等待的问题很多，但在大多数平台上，都有解决方案。问题包括：
但是设计自旋锁的人了解所有这些问题，并且确切地知道如何在平台上缓解这些问题。他们不编写天真的旋转代码，他们编写智能旋转代码。
所以是的，它们都无限循环，直到满足某些条件，但它们循环不同。
【讨论】：
自旋锁 通常在资源争用较少的情况下使用，因此 CPU 只需进行几次迭代即可继续进行生产性工作。但是，锁定功能的库实现通常使用自旋锁，然后是常规锁。如果无法在合理的时间范围内获取资源，则使用常规锁。这样做是为了减少在通常快速获得锁的设置中进行上下文切换的开销。
busy-waiting 一词往往意味着您愿意旋转并等待硬件寄存器或内存位置发生变化。该术语不一定意味着锁定，但它确实意味着在一个紧密的循环中等待，反复探测变化。
您可能想要使用忙等待来检测您想要立即响应的环境中的某种变化。因此使用忙等待来实现自旋锁。忙碌等待在任何情况下都非常有用，因为非常低的延迟响应比浪费 CPU 周期更重要（例如在某些类型的嵌入式编程中）。
与此相关的是术语«lock-free»和«wait-free»：
所谓的无锁算法倾向于使用紧忙等待和CAS 指令，但在普通情况下争用非常低，CPU 通常只需要迭代几次次。
所谓的无等待算法根本不做任何忙等待。
（请注意，«lock-free» 和 «wait-free» 在学术环境中的使用略有不同，请参阅维基百科在 Non-blocking algorithms 上的文章。）
【讨论】：