スタンドアロン方式とリアルタイム性能：LinuxによるRTOSの実現（3）（1/3 ページ）

リアルタイム機能をLinuxカーネル自身で実現するスタンドアロン方式。この方式の具体的な実装やリアルタイム性能を検証する

[近藤 純司 富士通プライムソフトテクノロジ，＠IT MONOist]

　前回は、マイクロカーネル方式によるLinuxのリアルタイム機能実現について説明した。今回は、時分割処理システムとして設計されたLinuxカーネル自身に大きく手を加えることにより、リアルタイム機能を追加する動向を説明する。本連載では、この方式を便宜上「スタンドアロン方式」と呼んでいるが、一般性を持った用語ではないので注意していただきたい。

リアルタイム処理実現への課題

　具体的な実装の説明に入る前に、リアルタイム処理のあるべき姿をイメージしてみたい。一番大切なのは、現在実行している処理よりも優先すべき処理が見つかった場合、速やかに処理を切り替えることである。すなわち、どんな場合でも遅延なくプリエンプションを行うことが理想である。

　これを実現するには、システム内のすべての処理に優先度を持たせて制御する必要がある。しかし、現状のupstreamカーネルを見てみると、理想には程遠い状態である。では、upstreamカーネルにどのような課題があるのだろうか。

　まず、Linuxシステムにおける「処理」は、次の2つに大別できる。

• カーネルの内部コードを実行する処理
• ユーザープログラムのコードを実行する処理

　それぞれの処理には、プロセスまたはスレッドを切り替えることができない期間が存在する。

クリティカルセクション

　カーネルの内部コードには「クリティカルセクション」と呼ばれる区間が存在する。これは、以下の2つに大別できる。

• 割り込み禁止区間
• プリエンプション禁止区間

　割り込み禁止区間は、ハードウェアの割り込みを契機に実行される「割り込みハンドラ」と呼ばれる処理や、割り込みハンドラの実行時に参照されるデータを排他制御して処理することが該当する。この区間が長くなると、ハードウェアからの割り込み通知を受け取ることができず、一般にいう割り込みレイテンシの増加の原因となる。

　プリエンプション禁止区間は、スピンロックなどの「同期プリミティブ」により、プロセス／スレッド間でデータの排他制御を行う。このとき、スケジューリングが禁止されるので、排他が解除されるまで処理の切り替えが遅延する。

同期プリミティブの獲得待ち

　ユーザープログラムのコードを実行する処理に目を向けると、同期プリミティブの獲得状況（下表）により、優先度の高いプロセス／スレッドに即座に処理を切り替えることができない場面が発生する。

	同期プリミティブ	利用するコンテキスト
	SYSVセマフォ	プロセス
	POSIXセマフォ	POSIXスレッド
	POSIX条件変数	POSIXスレッド
	mutex	POSIXスレッド

処理を切り替える時間の予測

　リアルタイム処理は、一般的に処理を切り替えるために費やす最大時間、つまりワーストケースのレイテンシがどの程度保証できるかで大別される。100％保証できるものを「ハード・リアルタイム」、100％まではいかないが、高い確率で規定した時間内に収まるものを「ソフト・リアルタイム」と呼ぶ。最近のLinux Kernelメーリングリストの議論では、論理的に100％保証できるものを「ダイヤモンド・ハード」、実測では100％保証できたものを「ルビー・ハード」「メタル・ハード」とも呼んでいる。

　upstreamカーネルについて考えると、長期間、割り込みまたはプリエンプションを禁止する期間があり、その長さを決定することができないので、ハード・リアルタイムを実現するのは困難である。