コンテキストとシステム状態

3.5.1 処理単位とコンテキスト

µITRON4.0仕様のカーネルは，次の処理単位の実行制御を行う．

(a) 割込みハンドラ

(a.1) 割込みサービスルーチン (b) タイムイベントハンドラ

(c) CPU例外ハンドラ

(d) 拡張サービスコールルーチン (e) タスク

(e.1) タスク例外処理ルーチン

割込みハンドラおよび割込みサービスルーチンは，それぞれ独立したコンテキ ストで実行される．以下この節では，割込みサービスルーチンに関する記述が

別にない限りは，割込みハンドラに関する記述は割込みサービスルーチンにも 適用される．

タイムイベントハンドラは，時間をきっかけとして起動される処理で，周期ハ ンドラ，アラームハンドラ，オーバランハンドラの3つの種類がある．タイム イベントハンドラは，それぞれ独立したコンテキストで実行される．周期ハン ドラについては4.7.2節，アラームハンドラについては4.7.3節，オーバランハ ンドラについては4.7.4節で述べる．

CPU例外ハンドラは，CPU例外毎およびCPU例外が発生したコンテキスト毎 に，それぞれ独立したコンテキストで実行される．

拡張サービスコールルーチンは，拡張サービスコールの呼出しにより起動され る処理で，アプリケーションによって登録される．拡張サービスコールルーチ ンは，拡張サービスコール毎および拡張サービスコールが呼び出されたコンテ キスト毎に，それぞれ独立したコンテキストで実行される．拡張サービスコー ルルーチンについては，4.10節で述べる．

タスクは，それぞれ独立したコンテキストで実行される．タスク例外処理ルー チンは，そのタスクのコンテキスト内で実行される．以下この節では，タスク 例外処理ルーチンに関する記述が別にない限りは，タスクに関する記述はタス ク例外処理ルーチンにも適用される．

以上の処理単位に分類されない処理として，カーネル自身の処理がある．カー ネルの処理は，サービスコール処理，ディスパッチャ，割込みハンドラ（また は割込みサービスルーチン）とCPU例外ハンドラの出入口処理などから構成さ れる．カーネルが実行されるコンテキストは，アプリケーションの振舞いには 影響しないため，特に規定しない．

【µITRON3.0仕様との相違】

タイマハンドラに代えて，タイムイベントハンドラという用語を用いることに した．また，拡張SVCハンドラに代えて，拡張サービスコールルーチンという 用語を用いることにした．

3.5.2 タスクコンテキストと非タスクコンテキスト

タスクの処理の一部とみなすことのできるコンテキストを総称してタスクコ ンテキスト，そうでないコンテキストを総称して非タスクコンテキストと呼 ぶ．

タスクの実行されるコンテキストは，タスクコンテキストに分類される．割込 みハンドラおよびタイムイベントハンドラが実行されるコンテキストは，非タ スクコンテキストに分類される．CPU例外ハンドラおよび拡張サービスコール ルーチンが実行されるコンテキストがいずれに分類されるかは，それぞれ，

CPU例外が発生したコンテキストおよび拡張サービスコールが呼び出された コンテキストに依存して，次のように定められる．

タスクコンテキストを実行中にCPU例外が発生した場合には，CPU例外ハンド

ラが実行されるコンテキストがタスクコンテキストと非タスクコンテキスト のいずれに分類されるかは実装定義とする．非タスクコンテキストを実行中に

CPU例外が発生した場合には，CPU例外ハンドラが実行されるコンテキストは

非タスクコンテキストに分類される．

タスクコンテキストから拡張サービスコールを呼び出した場合には，拡張サー ビスコールルーチンが実行されるコンテキストはタスクコンテキストに分類 される．非タスクコンテキストから拡張サービスコールを呼び出した場合に は，拡張サービスコールルーチンが実行されるコンテキストは非タスクコンテ キストに分類される．

µITRON4.0仕様では，タスクコンテキストから呼び出すサービスコールと，非 タスクコンテキストから呼び出すサービスコールを区別して扱う．非タスクコ ンテキストからのサービスコール呼出しについては，3.6節で述べる．

非タスクコンテキストから，暗黙で自タスクを指定するサービスコールや，自 タスクを広義の待ち状態にする可能性のあるサービスコールが呼び出された 場合には，E_CTXエラーを返す．また，サービスコールに渡すパラメータとし て，自タスクを指定するTSK_SELF（＝0）を用いることもできない．渡され た場合には，E_IDエラーとなる．

【補足説明】

3.5.3節で述べるように，CPU例外ハンドラの優先順位はディスパッチャよりも

高いため，CPU例外ハンドラ実行中はディスパッチが起こらない．そのため，

CPU例外ハンドラがタスクコンテキストで実行される実装で，CPU例外ハンド

ラ内で自タスクを広義の待ち状態にする可能性のあるサービスコールを呼び 出した場合の振る舞いは未定義である．ただし，エラーを報告する場合は E_CTXを返すものとする．

【µITRON3.0仕様との相違】

タスク部とタスク独立部に代えて，それぞれタスクコンテキストと非タスクコ ンテキストという用語を用いることとした．カーネルが実行されるコンテキス トは規定していないため，過渡的な状態という用語は用いていない．また，

µITRON4.0仕様ではプロセッサの動作モードについて規定していないため，準 タスク部の概念は定義せず，タスクコンテキストに含まれるものとした．

3.5.3 処理の優先順位とサービスコールの不可分性

µITRON4.0仕様のカーネルが，各処理単位とディスパッチャを実行する優先順 位は次のように規定される．

各処理単位とディスパッチャの間では，次の順序で優先順位が高い．

(1) 割込みハンドラ，タイムイベントハンドラ，CPU例外ハンドラ

(2) ディスパッチャ（カーネルの処理の一部）

(3) タスク

割込みハンドラの優先順位は，ディスパッチャの優先順位よりも高い．割込み ハンドラおよび割込みサービスルーチン相互間の優先順位は，それらを起動す る外部割込みの優先度に対応して定めることを基本に，実装定義で定める．

タイムイベントハンドラ（オーバランハンドラを除く）の優先順位は，isig_tim を呼び出した割込みハンドラの優先順位以下で，ディスパッチャの優先順位よ りも高いという範囲内で，実装定義で定める．オーバランハンドラの優先順位 は，ディスパッチャの優先順位よりも高いという範囲内で，実装定義で定める．

CPU例外ハンドラの優先順位は，CPU例外が発生した処理の優先順位と，ディ スパッチャの優先順位のいずれよりも高い．割込みハンドラやタイムイベント ハンドラとの間の優先順位は，実装定義である．

拡張サービスコールルーチンの優先順位は，拡張サービスコールを呼び出した 処理の優先順位よりも高く，拡張サービスコールを呼び出した処理よりも高い 優先順位を持つ他のいずれの処理の優先順位よりも低い．

タスクの優先順位は，ディスパッチャの優先順位よりも低い．タスク相互間の 優先順位は，タスクのスケジューリング規則によって定められる．

カーネルのサービスコール処理は不可分に実行され，サービスコール処理の途 中の状態がアプリケーションから見えないのが基本であるが，システムの応答 性を向上させるために，サービスコール処理の途中でアプリケーションプログ ラムが実行される実装も認める．この場合にも，アプリケーションがサービス コールを用いて観測できる範囲で，サービスコールが不可分に実行された場合 と同様に振る舞わなければならない．このように振る舞わせることを，サービ スコールの不可分性を保証するという．ただし，実装独自の機能を追加する場 合には，実装方式によっては高い応答性を保ちつつサービスコールの不可分性 を保証することが難しい場合が考えられる．そのような場合には，サービス コールの不可分性の原則を緩めることを認める．

カーネルのサービスコール処理が不可分に実行される場合には，サービスコー ル処理は最も高い優先順位を持つことになるが，上述の理由から，サービス コール処理の優先順位は，サービスコールを呼び出した処理の優先順位よりも 高いという条件を満たす範囲で，実装依存とする．

サービスコール処理以外のカーネルの処理（ディスパッチャ，割込みハンドラ とCPU例外ハンドラの出入口処理など）も，サービスコール処理と同様とする．

【スタンダードプロファイル】

スタンダードプロファイルに準拠する実装では，スタンダードプロファイル機 能の範囲内で，サービスコールの不可分性を保証しなければならない．

【補足説明】

ディスパッチャの優先順位は割込みハンドラの優先順位よりも低いため，すべ ての割込みハンドラの処理を終えるまで，ディスパッチは起こらない．これ を，従来の仕様では遅延ディスパッチの原則と呼んでいた．タイムイベントハ ンドラ，CPU例外ハンドラについても同様である．