實時應用中malloc的使用

Question

我們的一個實時應用程序有問題。 這個想法是每 2 毫秒（500 赫茲）運行一個線程。 應用程序運行了半小時或一個小時后……我們注意到線程落后了。

經過幾次討論，人們抱怨實時線程中的 malloc 分配或根本原因是 malloc 分配。

我想知道，在實時線程中避免所有動態內存分配總是一個好主意嗎？

互聯網上很少有這方面的資源？ 如果你能指出一些討論，我們也會很棒..

謝謝

Answer 1

第一步是分析代碼並確保您准確了解瓶頸所在。 人們通常不擅長猜測代碼中的瓶頸，您可能會對這些發現感到驚訝。 您可以自己簡單地檢測此例程的幾個部分，並定期轉儲最小/平均/最大持續時間。 您希望看到最壞的情況（最大值），以及平均持續時間是否隨着時間的推移而增加。

我懷疑malloc是否會在能夠運行 Linux 的合理微控制器上占用這 2ms 的任何重要部分； 我想說的是，與性能問題相比，由於碎片而導致內存不足的可能性更大。 如果您的函數中有任何其他系統調用，它們將很容易比malloc一個數量級。

但是，如果malloc確實是問題所在，取決於您的對象的生命周期有多短、您可以浪費多少內存以及您提前知道多少您的需求，您可以采取以下幾種方法：

1. 通用分配（來自您的標准庫或任何第三方實現的malloc ）：如果您擁有“足夠多”的 RAM、許多短期對象且沒有嚴格的延遲要求，則是最佳方法

   • 優點：適用於任何開箱即用的對象大小，熟悉的界面，動態共享內存，如果內存不是問題，則無需“提前計划”
   • 缺點：分配和/或解除分配期間的輕微性能損失，對不同大小的對象進行大量分配/解除分配時的內存碎片問題，運行時分配是否會失敗不太確定並且在運行時不能輕易緩解

2. 內存池：大多數情況下內存有限、需要低延遲並且對象需要比單個塊作用域存活時間更長的最佳方法

   • 優點：在任何合理的實現中，分配/釋放時間都保證為O(1) ，不會受到碎片的影響，更容易提前計划其大小，在運行時分配失敗（可能）更容易緩解
   • 缺點：適用於單個特定對象大小 - 程序的其他部分之間不共享內存，需要規划正確大小的池或存在潛在的內存浪費風險

3. 基於堆棧的（自動持續時間）對象：最適合更小、壽命短的對象（單塊范圍）

   • 優點：分配和釋放是自動完成的，允許在對象的生命周期內優化使用 RAM，有一些工具有時可以對代碼進行靜態分析並估計堆棧大小
   • 缺點：對象僅限於單個塊范圍 - 不能在中斷調用之間共享對象

4. 單個靜態分配的對象：長壽命對象的最佳方法

   • 優點：沒有任何分配——所有需要的對象在整個應用程序生命周期中都存在，分配/釋放沒有問題
   • 缺點：如果對象應該是短暫的，則會浪費內存

即使您決定在整個程序中使用內存池，也要確保將分析/檢測添加到您的代碼中。 然后將它永遠留在那里，看看性能如何隨時間變化。

Answer 2

作為航空航天行業的實時軟件工程師，我們經常看到這個問題。 即使在我們自己的工程師中，我們也看到軟件工程師試圖使用他們在別處學到的非實時編程技術或在他們的程序中使用開源代碼。 切勿在實時期間從堆分配。 我們的一位工程師創建了一個工具來攔截 malloc 並記錄開銷。 您可以在數字中看到，您無法預測分配嘗試何時需要很長時間。 即使在運行實時混合 Linux 的非常高端的計算機（72 核，256 GB RAM 服務器）上，我們也記錄了花費 100 毫秒的 malloc。 這是一個跨環的系統調用，開銷如此之大，而且您不知道什么時候會被垃圾回收擊中，或者什么時候它決定必須為操作系統的任務請求另一個大塊或內存。