3

私はいくつかのリアルタイムOS仕様を調べていましたが、RTOSでは通常mallocの使用を好まないことを読みました。この理由は次のとおりです。パフォーマンスの問題については、mallocを介してメモリを割り当てるのに時間がかかり、割り当てられたメモリを追跡するためのオーバーヘッドが高くなるため、mallocを使用しないでください。

現在、リアルタイムシステムでは、すべてのプロセスに時間の制約があり、通常、mallocは使用しません。私は興味を持ち、RTOSで実行時にメモリが実際にどのように割り当てられるかについて少し調べ始めました。メモリプールを見つけました。現在、メモリプールは実際には固定サイズのブロック割り当てを意味すると書かれています。メモリプールの利点は、断片化の影響を受けないことです。どうしてそれは可能ですか？4バイトのプールが3つあり、アプリケーションに10バイトが必要であるとすると、この場合、メモリプールは内部フラグメンテーションの影響を受けます。

メモリプールはどのように機能し、メモリはどのように割り当てられますか？特定のアプリケーションが4バイトのプールサイズから3つのプールを取得するように、アプリケーションはコンパイル時にプールを取得しますか？プールに収まらないメモリが必要な場合はどうなりますか。そのようなシステムには、さまざまなサイズのメモリプールが多数存在しますか？説明してください。

4

2 に答える 2

1

まあ、断片化はメモリプールの実装に依存します。一般に、メモリー・プールは、固定サイズのメモリー・ブロックのプールです。そのサイズのメモリ ブロックが必要な場合は、そのプールに移動します。したがって、そのサイズのブロックを必要とするものはすべて、そのサイズのブロックのプールから取得するため、断片化はありません。

現在、特定のサイズのブロックのプールが存在しない場合は、より大きなサイズのプールを使用できます。これが発生した場合、技術的には、割り当てられたメモリ ブロックの特定の部分が使用されていない (断片化されている) ため、断片化が発生しています。

すべてのメモリ プールが必要なすべてのサイズのブロックを提供した場合、断片化は発生しません。

于 2012-09-22T15:41:09.080 に答える
0

プールは断片化をなくすわけではありませんが、断片化を劇的に減らすことができます。また、非常に多数の非常に小さなブロックを割り当てるオーバーヘッドを減らすこともできます。優れたスキームの 1 つは、クライアント コードが高度にスケーリングされた構造体ごとにプールを作成できるようにするライブラリです。プールの作成時に、ブロック サイズ、最初に割り当てて拡張するブロックの数、およびデバッグ用のテキスト名を指定します。

ブロックを割り当てるには、プール ID をアロケーターに渡します。プールに空きブロックがない場合は常に、ブロックの連続したチャンクを割り当てて使用可能にし、そのうちの 1 つを返します。ブロックが解放されるたびに、そのブロックのチャンク内のすべてのブロックが解放されていれば、チャンクが解放されます。

デバッグ用に、すべてのプールを出力するルーチンがあり、説明、割り当てられた数、および使用可能な空きプールの数 (これが高い場合は断片化の問題があります) や割り当てられた最大数などの他の統計情報を提供します。メモリ リークを見つけるのに非常に役立ちます。

このタイプのライブラリの最悪のケースは、システムのライフサイクルの早い段階で、多数のブロックを割り当ててからそれらの大部分を無作為に解放するサブシステムの場合です。多くのチャンクが割り当てられたままになりますが、使用中のブロックはほとんどありません。(malloc と比較して) 最良のケースは、特定の組み込みシステムのように長期間稼働しなければならないシステムで、寿命が大きく異なる新しいブロックを必要とする継続的なサイクルです。

これは最も単純で、シングルスレッド アプリケーションに最適です。マルチスレッド アプリケーションの場合は、スレッド セーフにするように注意する必要があります。ロックのオーバーヘッドを最小限に抑えるために、malloc() が内部で行う最適化を模倣する必要がある場合があります (スレッドごとの「アリーナ」など)。

于 2016-12-02T04:35:01.483 に答える