Kode Vicious - @kode_vicious
PDF实时才是真谛
KV是一位态度鲜明的程序员，他回答你的问题。他可不是曼纳斯小姐。
亲爱的KV，
我正在开发一个网络系统，它对时序问题变得非常敏感。当系统最初开发时，带宽需求完全在现成的硬件和软件的容忍范围之内，但在过去的三年里，情况发生了变化。数据流保持不变，但现在系统被要求对到达的事件做出更快速的反应。该系统是用C++编写的，并在Linux之上运行。在最近的项目会议上，我建议减少延迟的最快途径是迁移到Linux的实时版本，因为实时操作系统旨在为应用程序提供最低延迟的服务。我们的代码已经在Linux上运行，因此切换到实时Linux并收获更低延迟的回报应该是显而易见的。
当然，总会有人唱反调，我们团队中就有一个这样的人。他声称更换操作系统版本并不会真正提高性能，我们真正应该做的是测量系统瓶颈所在，然后修改我们自己的代码来改进它。问题是，我们已经这样做了几次，每次都获得了一些小的改进，但不足以证明工程师时间和精力的投入是值得的。我真的认为他只是想重新实现系统，因为那比更改底层操作系统更有趣。显然，如果你想要更低的延迟和更好的响应时间，你真的应该从底层入手，不是吗？
反应更快
亲爱的反应更快，
跟我重复，“没有万能的解决方案。” 现在，在黑板上写500遍，擦干净黑板擦，然后回家。仅仅因为你的代码在Linux上运行，并不意味着它会自动从运行在“实时”Linux之上获得任何改进，原因有很多，我现在将详细说明。这只能怪你自己。
首先，我不明白你是如何得出这样的结论的：仅仅因为底层操作系统可能是实时系统，这就会转化为你代码的改进。你的代码是否使用了任何特殊的机制来与操作系统对话，而这些机制可能会通过使用RTOS（实时操作系统）得到改进？如果你正在使用标准设施，例如进程、线程，以及——既然你提到了网络——套接字API，那么你不太可能通过迁移到RTOS获得任何优势。为实时系统编写代码的人员混合使用标准API和系统特定的API，这取决于他们代码的哪些部分需要实时功能。如果代码可以“一次编写，处处运行”就好了，但这甚至在RTOS环境之外的各种Linux版本之间都不是真的。
是什么让你认为迁移到更高度专业化的环境（例如RTOS）会与在2.x内核和2.x+n内核之间迁移有任何不同？如果有什么不同的话，迁移到RTOS将是一个巨大的时间陷阱，因为你的团队几个月没看过的代码片段开始崩溃，原因是底层操作系统假设的改变。
你将面临的第二个问题是现在强制执行的实时定义的转变。曾几何时，实时有一个相当狭隘的定义。它意味着系统在有限的时间内对输入做出反应。公司内部为特定项目构建了自己的实时操作系统，或从供应商处购买了商业系统。每个RTOS的设计都
有一个狭隘的目标，即在有限的时间段内为事件提供服务。特定的算法、数据结构和技巧被用来实现这个目标。系统中的一切都围绕着低延迟服务的理念进行设计，从调度器到同步原语、I/O子系统、网络协议栈、内存管理等等。
不幸的是，实时这个术语已经被扩大了，主要是营销人员，意味着任何不是桌面系统的系统。现在，实时和嵌入式几乎意味着同一件事。这是具有误导性的，因为即使一个系统可能只占用几兆字节的内存（即，是嵌入式的），这也说明不了它的时序特性。事实上，这些系统通常基于更大的系统，例如Linux、BSD，甚至Windows，并且只是裁剪掉大部分“臃肿”的部分。通常，系统中唯一被更改的部分是调度器，虽然这是必要的，但不足以将桌面或服务器操作系统转变为RTOS。
为什么不能？你不能“只是缩小”一个操作系统到RTOS的原因是，有数百个组件可能会破坏系统的实时要求。设备驱动程序就是一个例子。如果加载到系统中的任何驱动程序都可以持有资源，阻止另一个任务运行，那么拥有一个确保最高优先级任务运行完成的抢占式优先级调度器又有什么用呢？RTOS中的每个组件都必须遵守与整个系统相同的时序特性，否则整个努力将会失败。在RTOS中，一个坏苹果会坏了一整堆。在切换到RTOS时，你和你的团队将不得不验证他们使用的每个组件、每个驱动程序、每个内核设施都遵守你期望的实时质量——即使对于你可以阅读代码的开源系统来说，这也是一项艰巨的任务。
你的万能解决方案需要考虑的下一件事是，通过切换到一个你现在不仅要调试你的应用程序，还要调试它与一种非常不同的操作系统的交互的系统，你将引发的问题。如果你认为在你的用户空间代码中发现时序错误和竞争条件很难，那么在RTOS内部就更难几个数量级。你准备好坐在连接到你的板子上的逻辑分析仪旁边，来找到时序错误的位置吗？我做过，这不好玩，我尽量避免它。此外，没有什么比不得不斥责你周围的硬件人员更糟糕的了，他们会对拿着螺丝刀的软件工程师说尖酸刻薄的评论。
虽然你提到你的团队已经对你的系统进行了工作，以至于你认为你已经用尽了所有你可以做的优化，但你没有说你是否测量了额外延迟来自哪里。你似乎只是假设是操作系统拖慢了你的速度。很有可能就是这种情况，但你最好首先非常确定，因为你将走向痛苦的道路，因为更换操作系统，而你真的不想触底并发现实际上是其他原因，例如你正在使用的网卡类型，或者你在你的代码中尚未考虑的一些问题。
这并不是说RTOS不能使需要更低延迟服务的应用程序受益，但在你更换那个相当大的组件之前，你最好已经解决所有其他可能出错的问题，包括我刚刚提供的清单。
KV
KODE VICIOUS，凡人称之为 George V. Neville-Neil，为了乐趣和利润而从事网络和操作系统代码工作。他还教授各种与编程相关的课程。他的兴趣领域是代码探险、操作系统和重构你的不良代码（好吧，也许不是最后一个）。他获得了马萨诸塞州波士顿的东北大学计算机科学学士学位，并且是、Usenix 协会和 IEEE 的成员。他是一位狂热的自行车爱好者和旅行者，目前居住在纽约市。
最初发表于 Queue 第 6 卷，第 6 期—
在 数字图书馆 中评论本文
© 保留所有权利。