TCB以外にも，セマフォやメールボックスなどのRTOSオブジェクトを生成すると，それぞれにコントロールブロックが生成され，RAMを消費する．セマフォコントロールブロックやメールボックスコントロールブロックである．実行時に，これらのオブジェクトの生成・削除を繰り返すと，ヒープ領域でフラグメンテーションが起こり，その結果リアルタイム性が失われ（後述），パフォーマンスが低下する．

　ヒープ領域という呼び方はコンパイラの世界における呼び方で，RTOSの世界ではメモリプールと呼ぶことが多い．mallocを呼び出すとprintfと同様に標準ライブラリが呼び出され，標準ライブラリからRTOSの可変長メモリプール関係のシステムコールが呼び出される．mallocを使わずに直接システムコールを呼び出したほうがパフォーマンスは良くなるが，移植性はなくなる．つまり，mallocを使っておけばホストでも単体テストが可能になる．

　一方，mallocを使うとprintfと同様に移植作業が発生する．プロジェクトを進める際に，プロジェクトリーダーがmallocを使うのかシステムコールを使うのかを決めておかないと，ホストでテストできないため移植作業が必要なソフトができあがる．#defineでmallocをシステムコールに化けさせるにしても，mallocを使っていなければどうしようもない．

　話をリアルタイム性に戻す．可変長メモリプールの未使用領域は，リスト構造で管理される．mallocで新しい領域を確保しようとすると，このリストを要求されたサイズと比較しながらたどっていく．フラグメンテーションが進むと，未使用領域が瀬戸内海の小島のように点在することになる．

　そして，確保できるまでの時間が見積もれなくなるのでリアルタイム性が失われるのである．これは，たまたま大きな領域を確保しようとしたタスクだけがリアルタイム性を失うのではない．メモリプールは共有され排他制御されるので，mallocを使うすべてのタスクのブロック時間の上限が抑えられないことになり，システム全体に影響がおよぶのである．

　未使用領域の管理の仕方，たとえば大きい順にソートするとか，ヒットのさせ方，たとえばファーストヒット・ミニマムヒットなど，アルゴリズム的な研究もいろいろ行われているが，決定打はまだ出ていない．つまり，RTOS側で何とかできるものではない．C++のように，オブジェクトの生成/削除を頻繁に行う場合も，その結果としてメモリプールがどうなるのかを考えると，リアルタイム性の観点からは気になるのである．

Copyright 2001 藤倉俊幸