uClibc vs glibc 用于实时 Linux 应用程序编程

Posted 2023-02-22

【中文标题】uClibc vs glibc 用于实时 Linux 应用程序编程

【英文标题】：uClibc vs glibc for real time Linux application programming

【发布时间】：2013-01-22 17:20:09

【问题描述】：

我正在编写一个在 Linux (Kernel 3.0) 上运行的用户空间音频应用程序，它需要实时行为。我应该选择 glibc 还是 uClibC ？ uClibC 和 glibc 在实时行为方面如何比较？

（编辑：我的是一个带有 nand flash 的嵌入式系统。它使用带有 glibc 的外部 gcc 工具链的 buildroot。如果需要，我还可以使用带有 uClibc 的 buildroot 内部工具链）

【问题讨论】：

这应该在哪里运行？如果在“普通”Linux 用户空间上，您别无选择，只能使用 glibc。而且我非常怀疑任何使用 libc 函数都会成为性能瓶颈。如果 glibc 有效，请使用它。如果您确定 glibc 不能提供您想要的，请测量。

你也可以考虑musl-libc.org

【参考方案1】：

实际上，我认为没有人可以肯定地说任何一种方式。原因是您的代码很可能以一种比另一种变体更好/更差的方式使用 C 库。

唯一合理的方法是使用 glibc 运行代码，然后在相同的条件下使用 uclibc。比较完成这项工作所需的时间。在你的情况下哪个更好？ - 如果这要进入某种嵌入式系统，请确保您在您希望它运行的处理器上进行测量，而不是某些具有完全不同指令集、不同缓存大小、不同内存速度等的 PC 处理器.

你说你使用了很多 malloc - 也许如果你认为这是你速度的限制因素，你应该考虑一种你不使用 malloc 的方法。特别是，在你的“热路径”中调用 malloc 不是一个好主意，除非你绝对必须这样做。

另请注意，Linux 不是实时操作系统。你只能期待 Linux 的半实时行为，如果你的应用程序真的依赖于能够在一定时间内处理它的音频，并且在特定条件下它可以“​​不运行”多长时间等，你将需要向内核添加扩展 - 我不太熟悉哪些适用于内核版本、工作负载类型等。

【讨论】：

半实时行为是什么意思？

半实时意味着“未能按时完成并不是灾难性的”——换句话说，就是出现严重问题的情况，例如“如果你错过了这个最后期限，所有当前调用手机基站宕机”或“如果错过这个期限，系统必须重新启动”。这类系统是“硬实时”的。

【参考方案2】：

我会以可移植的方式编写您的应用程序，这样您就可以推迟决定构建时间。为了给您更好的答案，我们需要知道您想要使用哪些实时功能。

【讨论】：

我的应用程序需要每 20 毫秒处理一次音频数据而不会丢失数据。我的代码每 20 毫秒使用大量 malloc、字符串比较和其他函数。

只需使用 sched 函数将其设置为实时优先级并调用 mlockall ，无论哪种方式你都应该是安全的。唯一能让你延迟 20 毫秒的事情就是交换。

如果需要实时保证，就不能使用malloc。

@Mahmoud：你的依据是什么？假设系统需要交换，是的。但是考虑到系统中有足够的 RAM，这应该不是问题。如果系统在 RAM 上过度使用，不使用 malloc 很可能会导致交换，因此不使用 malloc 实际上不会有任何帮助[我并不是说 malloc 在热路径中是一个好主意，正如我在回答中解释的那样，但在我心中并不是“你不能使用它”]。

好吧，你只是说一个异常缓慢的异常值不会影响 big-O，当然这是真的。所以我应该使用更清晰的语言。关键是 malloc 执行的用户空间指令的数量对于所有运行来说基本上是相同的，并且时间主要取决于缓存/TLB 未命中、页面错误以及对某些请求进行系统调用的需要等因素。假设没有发生交换，这些意外事件都不会非常昂贵（当然不是毫秒级），所以 OP 应该是安全的。

【参考方案3】：

使用安装在您系统上的 C 库。任何给定的 Linux 发行版通常会使用 glibc（对于大多数发行版，包括桌面和服务器系统）或 uClibc（在某些嵌入式发行版中）。混合和匹配这两者非常混乱，并且会使构建、调试和分发您的应用程序变得异常复杂。

这两个库的性能特征通常非常相似，不太可能对您的应用程序产生任何重大影响。