在任务关键型/生命关键型软件中使用动态分配

Question

在任务关键型/生命关键型系统中使用动态分配是否安全，还是应该避免？

Answer 1

如果您正在编写此类软件，那么您应该拥有一本适合您所遵循的规范（FAA，NATO，FDA，等等）的大型书籍，您可以做什么和不能做什么，它会告诉您。

然而，一般而言;不，因为你描述的系统很难证明是正确的。虽然在生命关键软件中通常必须有硬件负责重新启动软件，如果发出错误信号（即，软件必须复位的看门狗定时器延迟100ms以防止硬件复位）< / p>

Answer 2

使用关键软件，您希望系统具有尽可能确定的行为。

动态内存，内存碎片，可能的泄漏，以及在某些极端情况下（不太罕见）malloc的不当行为将使得获得100％确定性变得更加困难。

也就是说，如果您的程序的一部分（比如算法）需要动态分配，您可以证明您的内存分配和解除分配（免费）将是确定性的（参见RickNZ的有价值的说明）那么你就更接近拥有一个确定性的系统了。

Answer 3

当我无法完全避免“无法失败”类型应用程序中的动态分配时，我使用的一种方法是在应用程序首次启动时分配我只需要一次的缓冲区和其他数据结构 - 所以它们永远不需要被释放。它的循环和释放/删除与新闻/分配不对应，往往会导致问题......

当这还不够时，我使用的另一个技巧是使用我自己的自定义版本的malloc和free运行，代码需要特别注意检查常见的错误情况，比如释放已经释放的东西，定期验证freelist指针完整性，查看总内存使用量是否随着时间的推移而增加等等。

Answer 4

我曾经研究过的所有交易系统和其他银行软件都非常重视动态分配，对于使用它们的IB来说，它们是关键任务。我宁愿避免在生命关键系统上工作，所以不能代表它们。

Answer 5

更好地避免它。系统中最小的内存泄漏会随着时间的推移而导致系统崩溃。例如，汽车和飞机等生命关键系统不使用动态分配。

Answer 6

我是c ++的新手; 但因为一切都在记忆中;你会以某种方式使用它。 所以;程序员为什么要避免它？

PS：感谢您的评论。 ：）

Answer 7

我觉得你绝对可以在关键任务应用程序中使用动态内存分配，MC应用程序，不一定是RT应用程序，它们只是意味着它们对于业务运作至关重要。当使用动态内存分配结构时，在模拟真实客户环境时，进行大型压力测试（显示内存泄漏）总是必不可少的，这样你就能理解动态内存分配的影响，是否有一个。

Answer 8

在嵌入式系统和生活中任务关键型应用程序，目标是减少对动态内存分配的依赖。通常，在运行时无法确定实例数时，需要动态内存。例如，在从用户获得输入时使用动态存储器。

从传感器读取数据并从其他来源获取实时数据时，不使用动态存储器。许多应用程序使用队列并仅保留当前数据。

当使用动态内存分配时，嵌入式系统将具有某种内存回收算法，无论是垃圾收集（GC）还是内存在分配时进行合并。如果没有可用的内存，许多多线程和多任务系统将强制垃圾收集，删除不必要的变量或等待一段时间并再次尝试分配。

如果绝对没有可用的内存（并且所有回收内存的努力都已用尽），现在是时候参考需求规范并查看它的内容。

Answer 9

我认为在没有动态内存分配的情况下编写任何相当大的系统都会非常困难。

但默认的内存管理是一般的内存管理器，只有非常有限的保证 如果您有特定要求，那么您应该编写一个符合您所需要的专用内存管理库。

Answer 10

当然，这没有问题。但是：分配失败不应该导致程序失败。

这个原则延伸到实时程序。实时malloc应该有一个上限时间;可能存在内存根本无法及时获得并且必须返回NULL的情况。

现在，人们可能想知道为什么任务关键型系统在内存分配失败时可以正常工作。这很简单：“工作”通常不是黑白条件。任何有趣的任务关键型系统都有“SHALL”和“SHOULD”的要求。当分配内存失败违反“应该”要求时，可以使用动态内存分配。例如。 “系统应该支持200个小部件并且应该支持400个” - 静态分配前200个小部件并动态分配下两个小部件。

Answer 11

好吧，你无法避免动态分配。不知何故，在某个地方，您的堆栈必须至少分配。通常当人们开始过度担心某些东西是在堆栈还是堆上时，这是一个迹象，他们已经有点好笑了。您可以拥有与堆相关的堆栈相关错误，但只要您避免使用自己的内存管理的库，您就可以非常轻松地在测试中捕获与堆相关的错误。但是，首先，C ++并不是这类应用程序的最佳语言。