我不在乎成为CPU猪，因为我为每个内核分配了一个线程，并且系统线程被阻止到它们自己的集合中。我的理解是，当其他任务要运行时，互斥锁是有用的，在这种情况下，这并不重要，所以我正在考虑在内存中的地址上有一个消费者线程循环，等待其值不为零 - 就像在单个生产者线程中一样，它循环 recv（）ing TCP_NONBLOCK设置刚刚存入的信息，它现在不为零。
考虑到我的情况，我的植入是聪明的，还是我应该使用互斥锁或自定义中断，即使没有其他任务会运行。
除了@ugoren的分数和其他人的评论：
即使您有一个有效的用例来繁忙等待和刻录核心（这确实很少见），您也需要：
- 保护线程之间共享的数据。这就是锁发挥作用的地方 - 在访问任何复杂的共享数据结构时，您需要
mutual exclusion。人们倾向于在这里研究lock-free算法，但这些算法并不明显且容易出错，并且仍然被认为是深奥的黑魔法。在对并发有深入的了解之前，甚至不要尝试这些。 - 通知线程有关更改的状态。这是您使用
conditional variables或显示器的地方。还有其他方法，例如在Linux上eventfd(2)。
这里有一些链接供您显示它比您似乎认为的要困难得多：
- 内存排序
- 乱序执行
- ABA 问题
- 缓存一致性
在某些情况下，
忙碌等待可以为您提供更低的延迟和更好的性能。
让其他线程使用 CPU 是不这样做的明显原因，但还有其他原因：
您消耗更多电量。空闲 CPU 进入低功耗状态，从而显著降低功耗。功耗是数据中心的一个主要问题，任何严肃的应用都必须浪费电力。
如果您的代码在虚拟机中运行（并且现在一切都在虚拟化），那么您的机器将与其他机器竞争 CPU。消耗 100% 的 CPU 会减少其他人的 CPU 开销，并且可能会导致虚拟机管理程序在真正需要时为您的计算机提供更少的 CPU。
你应该始终坚持主流方法，除非有充分的理由不这样做。在这种情况下，主流是使用
select或poll（或epoll）。这使您可以根据需要在等待时执行其他操作，并且不会浪费CPU时间。性能差异是否大到足以证明繁忙等待是合理的？