【发布时间】：2014-12-29 10:51:23
【问题描述】：
我的团队正在为一种产品开发嵌入式 Linux 解决方案，其中中心应用程序从硬件接收和处理数据，并将其发送到数据库和接口应用程序。为此，我们正在使用五个线程：
- 主线程：创建其他线程并做一些辅助处理（从界面应用读取数据等）
- UPP 线程：从硬件接收数据并将其放入缓冲区中
- DSP 线程：从前一个缓冲区中提取数据，并要求 DSP 处理器使用该数据进行计算。返回的数据存储在第二个缓冲区中
- DB 线程：一段时间后，选择合理数量的计算数据并将它们存储在文件系统中。
- 接口线程：选择当前数据并发送到接口应用程序
此应用程序不会错过任何来自 UPP 线程的数据包，它每 200 毫秒获取新数据。 DSP 线程通常花费的时间少于这 200 毫秒（现在大约需要 30 毫秒，但将来会花费更多时间）。 DB线程通常每30秒调用一次，接口线程以5 Hz的频率调用。
我们面临的问题是，线程有时会花费更多时间来完成它们的工作，特别是 DB 和 DSP 线程。 IOW，虽然系统在每次运行 UPP 时运行 DSP，但有时 UPP 最多运行 15 次，而不会对 DSP 进行任何调用，从而丢失接收到的数据。线程中的这些零星“滞后”发生在所有线程中，但 DB 和接口中的滞后没有问题，只有当它们发生在 UPP 或 DSP 线程中时。
我们检查所有可以尝试在我们的代码中找出问题所在但没有成功的地方 - 大多数情况下，系统运行时没有任何延迟。不过，我们注意到了一些模式：
- 当界面运行时显示最“重”的小部件之一时，更容易出现滞后。
- 然而，所需处理的增加似乎不是原因：用一些“垃圾处理”对系统施加压力，并且打开界面并没有增加延迟的发生。
- 这可能与界面和特定小部件没有直接关系；它的所有处理在时间上都是相似的（所以任何错误都可能以非随机结束，但事实并非如此）
我们开始认为这与 Linux 有关。通常，在 PC 的日常使用中，鼠标或应用程序确实会出现一些滞后现象，Linux 可能正在对我们这样做。我们还考虑使用 RAM 内存，在主 Omap L138 处理器和 DSP 处理器之间共享，但一些测试为该假设提供了负面证据。
你有什么建议吗？ Linux 真的是问题的根源吗？我们怎么知道，又该如何解决？
任何帮助将不胜感激。
P.s.：同this
【问题讨论】：
-
如果您需要帮助，请显示您的源代码。你
strace和oprofile你的申请了吗？ “Linux 是问题的根源”没有多大意义。 -
top或ps auxw和free对您的整个系统有何评价？ -
@BasileStarynkevitch 这个问题涉及的源代码巨大，这里无法复制和粘贴=T 我没有使用
strace也没有oprofile，但我正在考虑使用那些简而言之时间。 -
@BasileStarynkevitch
top没有显示太多，因为滞后非常快。我不知道看到ps auxw应该期待什么，因为它只显示正在运行的进程（一切正常）。关于free，一般记忆还可以。
标签： c++ linux multithreading performance lag