待ち状態のない ITRON カーネル仕様案
RTOS 自動車応用技術委員会

編: 高田 広章 (豊橋技術科学大学 情報工学系／ ITRON 専門委員会)
31-Mar-1998

このドキュメントでは、 RTOS 自動車応用技術委員

会で検討を行った待ち状態のない ITRON カーネル仕様案と、その実装方法について述べる。本ドキュメ
ントに記述する仕様を

ITRON4.0 仕様の 1 つのプ

初期優先度あたりのタスク数
同一初期優先度のタスクを 1 つに限るか複数許すかの選択肢がある。 1 つに限る方法は、レディキューが単純になるという利点があるのに対して、複数許した場ロファイルにすることを、 RTOS 自動車応用技術委員

合には、同一優先度のタスクが同時に実行されること会から提案する。本ドキュメントに紹介する実装方法はないことから、さらなるスタックエリアの削減につは、提案した仕様が容易に実装できることを検証するながる。

ことを目的しており、あくまでも 1 つの実装方法の例にすぎない。

1

そこで以下では、この両者の方法について検討する。 2 つの方法で違ってくる箇所には、 (a) 同一初期優先度のタスクを 1 つに限る場合、 (b) 同一の初期優待ち状態をなくすメリット

待ち状態をなくす動機は、メモリ容量 (特に RAM 容量) を減らすことと、タスク切り替えの速度を向上させることである。
待ち状態 (強制待ち状態も含む) がなく、レディキューの回転 (rot rdq) もない場合には、タスクが実行できなくなるのはプリエンプトされる場合のみ先度のタスクを複数許す場合、のいずれについての記述であるかを明記する。
ここで、実行時優先度の動的変更 (chg pri) を許した場合、 (a) の仕様でも、同一の実行時優先度のタスクは複数あっても良いものとする。これは、同一の実行時優先度のタスクを複数許しても実装がほとんど複雑にならないのに対して、同一の実行時優先度を許したで、すべてのタスクで 1 つのスタックエリアを共有で方が必要な優先度段数を減らせるためである。

きる。また、スタックを切り替える必要がないことかタスクのら、タスク切り替え速度の向上も期待できる。
ただし、必要なスタックエリアのサイズは、同時に動作する可能性があるタスクの集合に含まれるタスクが使うスタックサイズの和の最大値となるため、 1 つのスタックエリアを共有できることが、ただちに RAM容量の削減につながるとは限らない。
このような待ち状態のないカーネルが、リアルタイムカーネルと呼べるかどうか (リアルタイムカーネルの要件を満たしているか) は議論の分かれるところであるが、これだけの機能でも十分なアプリケーションも多いと思われることから、本格的なリアルタイムカーネルへの入門的な位置付けで、このような仕様を

ID と初期優先度(a) の場合には、タスクの ID をタスクの初期優先度と一致させることで、タスクの初期優先度を記憶する領域 (ROM) を節約する方法もある。

3カーネル仕様案

ここでは、 ITRON3.0 仕様のレベル S をベースに検討する。明示的に書かない限り、 ITRON3.0 仕様のレベル E の機能はサポートしない。また、 ITRON仕様のサブセットとすることから、エラーコードについては、 ITRON 仕様と同様とする。

ITRON 仕様のサブセットとして定義することは、用サポートしない機能語やシステムコール名称の統一の点からは意味がある

待ち状態がないため、 rel wai, slp tsk, wup tsk,
can wup, sus tsk, rsm tsk, dly tsk の各シスものと考えられる。

テムコールはサポートしない。また上に述べた通り、

2複数の仕様案が考えられるポイント

本ドキュメントで提案する仕様には、以下の点で大きな選択肢が残っている。細かな選択肢は他にも残っている。

rot rdq もサポートしない。
待ち状態があることが前提になっている同期・通信オブジェクトは使えない。具体的には、イベントフラグとセマフォは仕様から外す。メイルボックスは、待ちを使わない形で導入する。

カーネルオブジェクト (タスク，メイルボックスな

ter tsk (タスクの強制終了)

ど) の生成は、カーネル構成時に静的に行うものとし、サポートしない。

そのためのシステムコール (cre XXX) はサポートしな

アプリケーションサイドから見た場合に、タスクい。また、割込みハンドラの定義 (def XXX) も同様とする。 ITRON4.0 仕様にあわせて、これらのカーネル構成の記述方法を標準化する。

タスクの状態の強制終了は過渡的な状態で止まる可能性があるので危険である (多くの場合に、終了する必要があるかを時々チェックする方法で十分)。実装上も、

ter tsk をサポートするためには、タスクが使っているスタックの底や、タスク起動前のレジスタ待ち状態 (強制待ち状態も含む) がなく、タスクの動を保存することが必要になる。

的な生成も無いことから、タスクの状態は、 RUN 状

chg pri (タスクの優先度の変更)

態、 READY 状態、 DORMANT 状態の 3 つのみである。
カーネルの実装上は、 READY 状態を、 sta tsk で起動されたがまだ実行は開始していない状態と、実行開始後により優先度の高いタスクにプリエンプトされた状態とに分けて考えた方がわかりやすい。

各システムコールの仕様
以下、それぞれのシステムコール (ないしは機能) について、必要性とその理由を述べる。

sta tsk (タスクの起動)必須の機能。すでに起動されているタスクを再度sta tsk した場合に、起動要求をキューイングす

自タスクの優先度を変更するための chg pri のみサポートする。ただし、初期優先度より低い優先度に変更することはできないという制限を設ける。
Priority ceiling protocol (厳密には highest lockerprotocol) を実現するためには、自タスクの優先度が変更できることが必要である。それに対して、他のタスクに対する chg pri は、スタックが 1 本で済まなくなるのでサポートしない。そのため、タスク ID を渡す必要がなくなり、 chg pri のパラメータが 1 つですむことになるが、上位互換性のために自タスクを明示的に指定させる方法が妥当と思われる。

る機能を持たせる。

自タスクを初期優先度より低い優先度に変更するプログラムの移植性を高めるためには、キューイことを許すと、自タスクが実行開始される前に実ングの最大回数を定めることが望ましい。キュー行されていたタスクへ切り替える必要がある場合

イングの最大回数を増やすと、その分、 TCB (タが発生するため、初期優先度より低い優先度へのスク制御ブロック) のサイズが大きくなる。最低限変更は許さない (変更しようとした場合にはエラーとしては、 1 回のキューイングをサポートすればとする)。

大抵の応用には耐えられるものと思われる。

ITRON3.0 仕様にある起動されるタスクに起動コードを渡す機能も有益ではあるが、タスク起動のキューイング機能と起動コードを渡す機能の 2つを同時に実現すると、メモリの使用量が増えるので望ましくない。起動コードは、 sta tsk 発行前に共有変数に置いておく方法もあり、その機能を sta tsk に持たせる必然性はないと考えられるので、サポートしない (この方針は ITRON4.0仕様案と整合している)。

ext tsk (タスクの終了)
サポートしない。トップレベルの関数から戻ることでタスクが終了する。
タスクを終了させる機能が必要なのは言うまでもないが、タスク内の任意の場所で ext tsk を発行してタスクを終了できるようにすると、そのタスクが使っているスタックの底や、タスク起動前のレジスタを保存することが必要になる。それに対して、トップレベルの関数から戻ることでタスクが終了することとし、 ext tsk は用意しないとすると、メモリ容量の節約が図れる。

dis dsp, ena dsp (タスクディスパッチの禁止 / 許可)
必要な機能。 dis dsp は、自タスクを最高優先度に chg pri することと等価であることから、実装も容易。

get tidサポートする。
必要性については疑問があるが、実装上の負担はなく、使わない時はリンクされないので、あえて除く理由がないものと思われる。
メイルボックス
メイルボックス機能はサポートするが、待ちを伴う rcv msg はサポートしない。つまり、メッセージを送信する snd msg (ITRON4.0 仕様では snd mbx と改名される予定) と、受信するprcv msg (同 prcv mbx) だけをサポートする。

ただし、 ITRON4.0 仕様案では、メイルボック
スの実装方法はリンクリストによるものに一本化され、リングバッファによる方法はスタンダードプロファイルではサポートされない。自動車制御
目的には、リングバッファによる方法を採用する

方が適当と思われ、その場合、システムコールの 実行中のタスクの TCB へのポインタ (またはタスク ID)

名称は変更する必要があるだろう。
いずれにしても、実装上はメイルボックス機能は 実行中のタスクの優先度単なるライブラリ関数として実現できることか ディスパッチ禁止フラグら、両方提供するとしてもオーバヘッドはない。
また、その他のバリエーションの提供も容易である。

レディキューの構造は、 (a) の場合と (b) の場合で大きく異なる。 (b) の場合は、通常のリアルタイムカーネルと同様の構造になるのに対して、 (a) の場合は各初

メッ セージ送 信により タスクを 起動す る機能が期優先度を持ったタスクが READY 状態かどうかをあ欲しいが、そのような新しい機能を導入するとらわすビットマップだけで十分である。実行中のタス

ITRON のサブセットでなくなってしまうため、メッセージを送って、タスクを起動するという複合コールを、ユーザサイドで用意する方法が妥当と考えられる。

loc cpu, unl cpu, ret int (割込み管理)
必要な機能。実装も容易。

dis int, ena int, chg iXX, ref iXX (割込み管理)
実装依存の機能として残す。

set tim, get tim (時間管理)

クの優先度の最上位ビットをディスパッチ禁止フラグに使うことで、ディスパッチ禁止フラグをチェックするオーバヘッドをなくすことができる。
各タスクの TCB は、 RAM 上に置く必要がある情報と、 ROM 内に置けばよい情報に分けられる。 RAM上に置く必要がある情報としては、次のものが考えれる。

 タスクの状態 (1 bit;

RUN/READY 状態か、DORMANT 状態か)サポートする。ただし、システムクロックのビッ sta tsk のキューイングフラグ (1 bit)

ト数は実装依存とする。

 レディーキューにつなぐためのエリア ((b) の場合必要性については疑問があるが、実装上の負担はなく、使わない時はリンクされないので、あえて除く理由がないものと思われる。
周期起動ハンドラ
サポートする。

ITRON3.0 仕様では、周期起動ハンドラはレベル E になっているが、 ITRON4.0 仕様案ではスタンダードプロファイルに入っている。ただし、のみ)
また、 ROM 内に必要な各タスク毎の情報として、次のものがある。

 タスクの開始番地
 タスクの初期優先度 ((a) で初期優先度をタスクID と一致させた場合には不要) タスクの拡張情報 (下の説明参照)

ITRON3.0 仕様の周期起動ハンドラの仕様にはやや問題があるので、 ITRON4.0 仕様におけるタスクの拡張情報は、タスクの起動時にタスクのメイ仕様を採用する。

チンを使って複数のタスクを動かす場合には有用でアラームハンドラサポートしない。
マイクロ秒単位の時間指定ができるなら有用と思われるが、そうでないなら必要性は低い。

仕様のまとめンルーチンにパラメータとして渡される。同一のルーあるが、そうでない場合には必要性が低い。 ROM 容
量の制約が厳しい場合には、タスクのメインルーチンにタスク ID を渡す方法も考えられる。タスク ID はget tid で取り出せるため、それで代用させる方法も考えられる。
その他に、メイルボックスの管理ブロック、周期起以上で、いくつかの選択肢を除いて、カーネルの仕様動ハンドラの管理ブロックなどが必要となる。

としてはほぼ固まっている。機能的には、 OSEK/VDX

各システムコールの実装方法

OS 仕様の、 BCC2 に相当するものとなる。

4

実装方法 (例)sta tsk
起動対象のタスクが RUN 状態または READY 状態であれば、 TCB 中の sta tsk のキューイング

ここでは、以上で定義した仕様の 1 つの実装方法を示フラグをセットする。すでにキューイングフラグす。これとは別の実装方法が考えられることは言うまがセットされていた場合にはエラーとする。

でもない。

以下、起動対象のタスクが DORMANT 状態でデータ構造あった場合を考える。まず、起動対象タスクを READY状態に移行させる (TCB 中のタスク状態を更新システム全体で共有する情報として、次のようなものし、レディーキューに入れる)。起動対象のタスクが必要と考えられる。の初期優先度が、現在実行中のタスクの優先度以 レディーキュー下であった場合、またはディスパッチ禁止フラグがセットされている場合はこれで完了。起動対象

実行中のタスクの TCB へのポインタからタスクタスクの方が優先度が高い場合、実行中のタスクID を求めて返す (タスク ID が記憶されている場の TCB へのポインタ、優先度をスタックに保存

合には、そのまま返せばよい)。

し、それらの変数をそれぞれ、起動対象タスクのメイルボックス

TCB へのポインタ、起動対象タスクの初期優先度

タスク切り替えを伴わないので、単なるライブラに設定する。また、起動対象タスクで壊されるレリ関数である。

ジスタもスタックに保存する (スタックへの保存順序は要検討)。以上の処理の後、タスクのメインルーチンに渡すパラメータを設定し、起動対象タ

loc cpu, unl cpu
loc cpu は割込み禁止状態に設定し、 unl cpu はそれを解除する。 ITRON3.0 仕様では、ディススクの開始番地をサブルーチンコールする。

パッチ禁止状態を unl cpu で解除することも許タスクの終了されているので、 unl cpu でディスパッチ禁止タスクのトップレベルの関数から戻った場合、終フラグをリセットする必要がある。ディスパッチ

了したタスクが実行される前に実行されていたタ禁止フラグをリセットした場合の処理についてはスクの優先度 (スタックの先頭付近に記憶されていena dsp と同様。

る) と、レディーキュー中の最高優先度タスクの優先度を比較する。

割込みハンドラの起動と ret int
割込みハンドラの起動は、プロセッサの機能に任前者の方が優先度が高いか同じ場合、終了したタせる。割込みハンドラとタスクが同一のスタックスクが実行される前に実行されていたタスクの実を共有することが可能。

行を再開することになる。まず、スタックに保存

ret int 発行時に、タスクの終了時と同様のタスされているレジスタ、再開するタスクの TCB へク切り替え処理が必要になる。すなわち、実行中のポインタ、再開するタスクの優先度を、実行中のタスクの優先度と、レディーキュー中の最高優のタスクの TCB へのポインタ、優先度を示す変先度タスクの優先度を比較し、後者が優先度が高数に戻し、やはりスタック上に保存されているタい場合には、レディーキュー中の最高優先度タススクの実行再開番地へと戻る。

クの実行を開始する。実行を開始する方法につい後者の方が優先度が高い場合、レディーキュー中ては、 sta tsk と同様だが、割込みハンドラの中の最高優先度タスクの実行を開始する。具体的にでの処理なので、処理内容は少し変わるものと思は、実行中のタスクの TCB へのポインタ、優先度を、それぞれ、実行を開始するタスクの TCBへのポインタ、そのタスクの初期優先度に設定し、タスクのメインルーチンに渡すパラメータを設定した後、そのタスクの開始番地をサブルーチわれる。

dis int, ena int, chg iXX, ref iXX
実装依存であるが、素直に実装可能と思われる。

set tim, get tim
実装依存であるが、素直に実装可能と思われる。

ンコールする。

chg pri

周期起動ハンドラ

実行中のタスク優先度を更新する。その結果、レタイマに対する割込みハンドラを作り込むだけなディーキュー中の最高優先度タスクの優先度が、ので、素直に実装可能。

実行中のタスク優先度よりも大きくなる場合、レ

周期起動ハンドラの生成は静的に行うことから、ディーキュー中の最高優先度タスクの実行を開始生成される周期起動ハンドラの周期から、割込みする。実行を開始する方法については sta tsk とハンドラ (の周期起動ハンドラ呼出し部) を静的に同様。そうでない場合には、実行中のタスクの実生成して効率を上げる方法も考えられる。

行をそのまま継続する。

dis dsp, ena dsp
dip dsp はディスパッチ禁止フラグをセットし、ena dsp はそれをリセットする。ディスパッチ5

自動車制御用リアルタイム OS 仕様 (案)との関連禁止フラグをリセットした場合には、実行中のタ「自動車制御用リアルタイム OS 仕様 (案)」では、ススクの優先度と、レディーキュー中の最高優先度タックエリアを節約するための機構として、同一優先タスクの優先度を比較する。後者の方が優先度が度タスクで 1 つのスタックエリアを共有し、そのよう高い場合、レディーキュー中の最高優先度タスクなタスクは待ち状態に入れなくする方法を提案していの実行を開始する。実行を開始する方法についてる。待ち状態に入る必要があるタスクには、他のタスは、 sta tsk と同様。そうでない場合には、実行クと異なる優先度を与えばよい。

中のタスクの実行をそのまま継続する。

get tid

本ドキュメントで提案する仕様では、タスクが同一優先度でなくても、待ち状態に入らなくすることでスタックエリアが 1 つですむ。このアイデアを適用す
ると、待ち状態に入れないすべてのタスクは 1 つのスタックエリアを共有し、待ち状態に入れるタスクには個々にスタックエリアを割り付ける方法が考えられる。
待ち状態に入れるタスクに他のタスクと同一の優先度を割り付けられることから、この仕様の方が、原案よりも柔軟と考えられる。逆に、各タスクの属性として、待ちに入れるか否かを指定する必要がある。
「待ち状態のないカーネル仕様案」と「自動車制御用リアルタイム OS 仕様 (案)」を 1 つのカーネル仕様の中で定義する場合には、この考え方の方が整合性がよいものと考えられる。
なおこの方法は、 OSEK/VDX OS 仕様の basic
task と extended task への分類に対応し、奇抜な方法ではない。

6

まとめ本ドキュメントに定義した仕様を、 ITRON4.0 仕様の 1 つのプロファイルとすることを、 ITRON プロジェクトに対して、 RTOS 自動車応用技術委員会から提案する。
以上