马尔特·斯卡鲁普（Malte Skarupke） 游戏开发商我发布了基于Mutex和Spinlock的锁的性能比较 使用各种任务计划程序。 测试显示异常延迟 自旋锁的长度 在Linux上使用默认任务计划程序。
测试的作者 得出结论，Linux任务计划程序存在问题 影响 消极地 为Google Stadia服务创建的游戏， 游戏在云端环境中的GPU上运行，而客户端仅以每秒60帧的速度流式传输屏幕内容。
在这种情况下，有必要确保在屏幕上及时显示帧，并注意到超过一毫秒的延迟。
莱纳斯·托瓦尔兹（Linus Torvalds）加入了对证据的讨论，该人称其为“纯垃圾”。 以及如何在不完全了解主题的情况下获取无法反映真实情况的指标的示例。
托瓦尔兹写道：
整篇文章似乎是错误的，并且所得出的结论与作者所认为和所宣称的完全不同。
首先，只有在您真正知道自己没有使用自旋锁的情况下，才能使用自旋锁。基本上，它读取释放锁之前的时间，然后在重新获取锁后读取该时间，并指出时间是不保持锁定的时间。 这是愚蠢和无用的，完全是错误的。
那是纯垃圾。
自旋锁是一个低级原语，必须在用户空间中谨慎使用并充分了解细节。 否则，您可以得到测试人员演示的内容。
Linus建议游戏开发商不要使用自旋锁 并且他们不尝试基于此来阻止自己的阻止系统， 而是使用现有的成熟机制 通知系统他们正在等待释放锁，以消除程序员的影响。
只有在完全确信程序员不会中断其执行的情况下，才能使用基于Spinlock的插件。 测试中使用的基于自旋锁的锁是通过在用户空间中工作的自制绑定实现的。
任务计划程序可以在执行此链接期间的任何时间进行控制，并切换到另一个任务。
给定什么性能测量基于绝对计时器值，定义的延迟 在测试中，它们不仅涵盖了控制器中的延迟 阻止，但是 还有在不同上下文中运行的代码， 也就是说。
它不仅可以测量测试人员要测量的内容，还可以测量系统中其他计算的“噪音”。
问题是 开发人员不应该一开始就使用自旋锁r，就 并不是由Linux程序员责怪，而是开发人员使用它的方法。
测试的作者试图反对Linus， 请注意，在游戏中实际上经常使用基于自旋锁的专有锁定系统，因为使用比Linux更为简单的编程器时，测试显示出更好的性能。
Linus提到Linux调度程序是通用的，经过数十年的精炼 并且不仅针对台式机进行了优化 和游戏，但也适用于其他类型的负载 例如在服务器系统上工作，因此在计划任务时要考虑许多细微差别。
添加特定的优化措施以减少游戏延迟 Google Stadia在特定情况下可能会提高响应速度，但可能会降低程序员的整体性能。
例如，Windows Scheduler在讨论中的测试中表现更好，因为它比Linux Scheduler简单得多，并且主要针对特定的桌面任务进行了优化。
数据来源： https://probablydance.com/