TOPPERS 新世代カーネルは， ASP カーネルをベースとして，保護機能，マルチプ ロセッサ，カーネルオブジェクトの動的生成，機能安全などに対応した一連の カーネルで構成される．

この仕様では， TOPPERS 新世代カーネルを構成する一連のカーネルの仕様を統合 的に記述するが，言うまでもなく，カーネルの種類によってサポートする機能 は異なる．サポートする機能をカーネルの種類毎に記述する方法もあるが，カー ネルの種類はユーザ要求に対応して増える可能性もあり，その度に仕様書を修 正するのは得策ではない．

そこでこの仕様では，サポートする機能を，カーネルの種類毎ではなく，カー ネルの対応する機能セット毎に記述する．具体的には，保護機能を持ったカー ネルを保護機能対応カーネル，マルチプロセッサに対応したカーネルをマルチ プロセッサ対応カーネル，カーネルオブジェクトの動的生成機能を持ったカー ネルを動的生成対応カーネルと呼ぶことにする．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルは，保護機能対応カーネル，マルチプロセッサ対応カーネル，動的 生成対応カーネルのいずれでもない． ただし，動的生成機能拡張パッケージを 用いると，動的生成対応カーネルとなる．

【 TOPPERS/FMP カーネルにおける規定】

FMP カーネルは，マルチプロセッサ対応カーネルであり，保護機能対応カーネル， 動的生成対応カーネルではない．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルは ，保護機能対応カーネルであり，マルチプロセッサ対応カーネ ル，動的生成対応カーネルではない．

【 TOPPERS/SSP カーネルにおける規定】

SSP カーネルは，保護機能対応カーネル，マルチプロセッサ対応カーネル，動的 生成対応カーネルのいずれでもない．

【μ ITRON4.0 仕様，μ ITRON4.0/PX 仕様との関係】

μ ITRON4.0 仕様は，カーネルオブジェクトの動的生成機能を持っているが，保 護機能を持っておらず，マルチプロセッサにも対応していない．μ ITRON4.0/PX 仕様は，μ ITRON4.0 仕様に対して保護機能を追加するための仕様であり，カー ネルオブジェクトの動的生成機能と保護機能を持っているが，マルチプロセッ サには対応していない．

TOPPERS 新世代カーネルは，アプリケーションプログラムの再利用性を向上させ るために，ターゲットハードウェアや開発環境の違いをできる限り隠蔽するこ とを目指している．ただし，ターゲットハードウェアや開発環境の制限によっ て実現できない機能が生じたり，逆にターゲットハードウェアの特徴を活かす ためには機能拡張 が不可欠になる場合がある．また，同一のターゲットハード ウェアであっても，アプリケーションシステムによって使用方法が異なる場合 があり，ターゲットシステム毎に仕様の細部に違いが生じることは避けられな い．

そこで， TOPPERS 新世代カーネルの仕様は，ターゲットシステムによらずに定め るターゲット非依存（ target -independent ）の規定と，ターゲットシステム毎 に定めるターゲット定義（ target -defined ）の規定に分けて記述する．この仕 様書は，ターゲット非依存の規定について記述するものであり，この仕様書で 「ターゲット定義」とした事項は，ターゲットシステム毎に用意するドキュメ ントにおいて規定する．

また，この仕様書でターゲット非依存に規定した事項であっても，ターゲット ハードウェアや開発環境の制限によって実現できない場合や，実 現するための オーバヘッドが大きくなる場合には，この仕様書の規定を逸脱する場合がある． このような場合には，ターゲットシステム毎に用意するドキュメントでその旨 を明記する．

この仕様では，アプリケーションシステムを構成するソフトウェアを，アプリ ケーションプログラム（以下，単にアプリケーションと呼ぶ），システムサー ビス，カーネルの 3階層に分けて考える（図 2-1）．カーネルとシステムサービ スをあわせて，ソフトウェアプラットフォームと呼ぶ．

カーネルは，コンピュータの持つ最も基本的なハードウェア資源であるプロセッ サ，メモリ，タイマを抽象化し，上位階層のソフトウェア（アプリケーション およびシステムサービス） に論理的なプログラム実行環境を提供するソフトウェ アである．

システムサービスは，各種の周辺デバイスを抽象化するソフトウェアで，ファ イルシステムやネットワークプロトコルスタック，各種のデバイスドライバな どが含まれる．

また，この仕様では，プロセッサと各種の周辺デバイスの接続方法を隠蔽する ためのソフトウェア階層として，システムインタフェースレ イヤ（ SIL ）を規定 する．

システムインタフェースレイヤ，カーネル，各種のシステムサービス（これら をモジュールと呼ぶ）を，上位階層のソフトウェアから使うためのインタフェー スを， API （ Application Programming Interface ）と呼ぶ．

この仕様書では，第 3章においてシステムインタフェースレイヤの API 仕様を， システムサービス毎の仕様書で規定される．

【μ ITRON4.0 仕様との関係】

μ ITRON4.0 仕様では，カーネルとアプリケーションの中間にあるソフトウェア をソフトウェア部品と呼んでいたが， TOPPERS 組込みコンポーネントシステム （ TECS ）においてはカーネルもソフトウェア部品の 1つと捉えることから，この 仕様ではシステムサービスと呼ぶことにした．

この仕様では，カーネルがサポートするハードウェア構成として，以下のこと を想定している．これらに合致しないターゲットハードウェアでカーネルを動 作させることは可能であるが，合致しない部分へ の適応はアプリケーションの 責任になる．

• (a) メモリ番地は，常に同一のメモリを指すこと（オーバレイのように，異な るメモリを同一のメモリ番地でアクセスすることがないこと）．マルチプロセッ サ対応カーネルにおいては，同一のメモリに対しては，各プロセッサから同一 の番地でアクセスできること．
• (b) マルチプロセッサ対応カーネルにおいては，各プロ セッサが同一の機械語 命令を実行できること．

この仕様における API 仕様は， ISO/IEC 9899:1990 （以下， C90 と呼ぶ）または ISO/IEC 9899:1999 （以下， C99 と呼ぶ）に準拠した C言語を，フリースタンディ ング環境で用いることを想定して規定している．

ただし ， C90 の規定に加えて，以下のことを仮定している．

• ・ 16 ビットおよび 32 ビットの整数型があること
• ・ポインタが格納できるサイズの整数型があること

• (1) サービスコール

  上位階層のソフトウェアから，下位階層のソフトウェアを呼び出すインタフェー スをサービスコール（ service call ）と呼ぶ．カーネルのサービスコールを， システムコール（ system call ）と呼ぶ場合もある．

• (2) コールバック

  下位階層のソフトウェアから，上位階層のソフトウェアを呼び出すインタフェー スをコールバック（ callback ）と呼ぶ．

• (3) 静的 API

  オブジェクトの生成情報や初期状態などを定義するために，システムコンフィ ギュレーションファイル中に記述するインタフェースを，静的 API （ static API ）と呼ぶ．

• (4) 構成マクロ

  下位階層のソフトウェアに関する各種の情報を取り出すために，上位階層のソ フトウェアが用いるマクロを，構成マクロ（ configuration macro ）と呼ぶ．

サービスコールやコールバックに渡すデータをパラメータ（ parameter ），それ らが返すデータをリターンパラメータ（ return parameter ）と呼ぶ．また，静 的 API に渡すデータもパラメータと呼ぶ．

オブジェクトを生成するサービスコールなど，パラメータの数が多い場合やター ゲット定義のパラメータを追加する可能性がある場合には，複数のパラメータ を 1つの構造体に入れ，その領域へのポインタをパラメータとして渡す．また， パラメータのサイズが大きい場合にも，パラメータを入れた領域へのポインタ をパラメータとして渡す場合がある．

C 言語 API では，リターンパラメータは，関 数の返値とするか，リターンパラメー タを入れる領域へのポインタをパラメータとして渡すことで実現する．オブジェ クトの状態を参照するサービスコールなど，リターンパラメータの数が多い場 合やターゲット定義のリターンパラメータを追加する可能性がある場合には， 複数のリターンパラメータを 1つの構造体に入れて返すこととし，その領域への ポインタをパラメータとして渡す．

複数のパ ラメータまたはリターンパラメータを入れるための構造体を，パケッ ト（ packet ）と呼ぶ．

サービスコールやコールバックに，パケットを置く領域へのポインタやリター ンパラメータを入れる領域へのポインタを渡す場合，別に規定がない限りは， サービスコールやコールバックの処理が完了した後は，それらの領域が参照さ れることはなく，別の目的に使用できる．

一部の例外を除いて，サービスコールおよびコールバックの返値は，処理が正 常終了したかを表す符号付き整数とする．処理が正常終了した場合には， E_OK （＝ 0）または正の値が返るものとし，値の意味はサービスコールまたはコール バック毎に定める．処理が正常終了しなかった場合には，その原因を表す負の 値が返る．処理が正常終了しなかった原因を表す値を，エラーコード（ error code ）と呼ぶ．

エラーコードは，いずれも負の値のメインエラーコードとサブエラーコードで 構成される．メインエラーコードとサブエラーコードからエラーコードを構成 するマクロ（ ERCD ）と，エラーコードからメインエラーコードを取り出すマク ロ（ MERCD ），サブエラーコードを取り出すマクロ（ SERCD ）が用意されている．

メインエラーコードの名称・意味・値は，カーネルとシステムサービスで共通 に定める（「 2.14.4 TOPPERS 共通エラーコード」の節を参照）．サービスコー ルおよびコールバックの機能説明中の「 E_XXXXX エラーとなる」または 「 E_XXXXX エラーが返る」という記述は，メインエラーコードとして E_XXXXX が 返ることを意味する．

サブエラーコードは，エラーの原因をより詳細に表すために用いる．カーネル はサブエラーコードを使用せず，サブエラーコードとして常に -1が返る．サブ エラーコードの名称・意味・値は，サブエラーコードを使用するシステムサー ビスの API 仕様において規定する．

サービスコールが負の値のエラーコード（警告を表すものを除く）を返した場 合には，サービスコールによる副作用がないのが 原則である．ただし，そのよ うな実装ができない場合にはこの原則の例外とし，サービスコールの機能説明 にその旨を記述する．

サービスコールが複数のエラーを検出するべき状況では，その内のいずれか 1つ のエラーを示すエラーコードが返る．

コールバックが複数のエラーを検出するべき状況では，その内のいずれか 1つの エラーを示すエラーコードを返せばよい．

なお，静的 API は返値を持たない．静的 API の処理でエラーが検出された場合の 扱いについては，「 2.12.5 コンフィギュレータの処理モデル」の節および 「 2.12.6 静的 API のパラメータに関するエラー検出」の節を参照すること．

ソフトウェア割込みによりサービスコールを呼び出す場合などに用いるための サービスコールを識別するための番号を，機能コード（ function code ）と呼ぶ． 機能コードは符号付きの整数値とし，カーネルのサービスコールには負の値を 割り付け，拡張サービスコールには正の値を用いる．

カーネルやシステムサービスを用いるために必要な定義を含むファイル．

ヘッダファイルは，原則として，複数回 インクルードしてもエラーにならない ように対処されている．具体的には，ヘッダファイルの先頭で特定の識別子 （例えば， kernel.h なら "TOPPERS_KERNEL_H" ）がマクロ定義され，ヘッダファ イルの内容全体をその識別子が定義されていない場合のみ有効とする条件ディ レクティブが付加されている．

• (1) オブジェクト

  カーネルまたはシステムサービスが管理対象とするソフトウェア資源を，オブ ジェクト（ object ）と呼ぶ．特に，カーネルが管理対象とするソフトウェア資 源を，カーネルオブジェクト（ kernel object ）と呼ぶ．

  オブジェクトは，種類毎に，番号によって識別する．カーネルまたはシステム サービスで，オブジェクトに対して任意に識別番号を付与できる場合には， 1か ら連続する正の整数値でオブジェクトを識別する．この場合に，オブジェクト の識別番号を，オブジェクトの ID 番号（ ID number ）と呼ぶ．そうでない場合， すなわちカーネルまたはシステムサービスの内部または外部からの条件によっ て識別番号が決まる場合には，オブジェクトの識別番号を，オブジェクト番号 （ object n umber ）と呼ぶ．識別する必要のないオブジェクトには，識別番号を 付与しない場合がある．

  オブジェクト属性（ object attribute ）は，オブジェクトの動作モードや初期 状態を定めるもので，オブジェクトの登録時に指定する．オブジェクト属性に TA_XXXX が指定されている場合，そのオブジェクトを， TA_XXXX 属性のオブジェ クトと呼ぶ．複数の属性を指定する場合には，オブジェク ト属性を渡すパラメー タに，指定する属性値のビット毎論理和（ C言語の "|" ）を渡す．また，指定す べきオブジェクト属性がない場合には， TA_NULL を指定する．

• (2) 処理単位

  オブジェクトの中には，プログラムが対応付けられるものがある．プログラム が対応付けられるオブジェクト（または，対応付けられるプログラム）を，処 理単位（ processi ng unit ）と呼ぶ．処理単位に対応付けられるプログラムは， アプリケーションまたはシステムサービスで用意し，カーネルが実行制御する．

  処理単位の実行を要求することを起動（ activate ），処理単位の実行を開始す ることを実行開始（ start ）と呼ぶ．

  拡張情報（ extended information ）は，処理単位が呼び出される時にパラメー タとして渡される情報で，処理単位の登録時に指定する．拡張情報は，カーネ ルやシステムサービスの動作には影響しない．

• (3) タスク

  カーネルが実行順序を制御するプログラムの並行実行の単位をタスク（ task ） と呼ぶ．タスクは，処理単位の 1つである．

  サービスコールの機能説明において，サービスコールを呼び出したタスクを， 自タスク（ invoking task ）と呼ぶ．拡張サービスコールからサービスコールを 呼び出した場合には，拡張サービスコールを呼び出したタスクが自タスクであ る．

  カーネルには，静的 API により，少なくとも 1つのタスクを登録しなければなら ない．タスクが登録されていない場合には，コンフィギュレータがエラーを報 告する．

  【補足説明 】

  タスクが呼び出した拡張サービスコールが実行されている間は，「サービスコー ルを呼び出した処理単位」は拡張サービスコールであり，「自タスク」とは一 致しない．そのため，保護機能対応カーネルにおいて，「サービスコールを呼 び出した処理単位の属する保護ドメイン」と「自タスクの属する保護ドメイン」 は，異なるものを指す．

• (4) ディスパッチとスケジューリング

  プロセッサが実行するタスクを切り換えることを，タスクディスパッチまたは 単にディスパッチ（ dispatching ）と呼ぶ．それに対して，次に実行すべきタス クを決定する処理を，タスクスケジューリングまたは単にスケジューリング （ scheduling ）と呼ぶ．

  ディスパッチが起こるべき状態（すなわち，スケジューリングによって，現在 実行しているタスクとは異なるタスクが，実行すべきタスクに決定されている 状態）となっても，何らかの理由でディスパッチを行わないことを，ディスパッ チの保留（ pend dispatching ）という．ディスパッチを行わない理由が解除さ れた時点で，ディスパッチが起こる．

• (5) 割込みと CPU 例外

  プロセッサが実行中の処理とは独立に発生するイベントによって起動される例 外処理のことを，外部割込みまたは単に割込み（ interrupt ）と呼ぶ．それに対 して，プロセッサが実行中の処理に依存して起動される例外処理を， CPU 例外 （ CPU exception ）と呼ぶ．

  周辺デバイスからの割込み要求をプロセッサに伝える経路を遮断し，割込み要 求が受け 付けられるのを抑止することを，割込みのマスク（ mask interrupt ） または割込みの禁止（ disable interrupt ）という．マスクが解除された時点で， まだ割込み要求が保持されていれば，その時点で割込み要求を受け付ける．

  マスクすることができない割込みを， NMI （ non -maskable interrupt ）と呼ぶ．

  【μ ITRON4.0 仕様との関係】

  μ ITRON4.0 仕様において，未定義のまま使われていた割込みと CPU 例外という用 語を定義した．

• (6) タイムイベントとタイムイベントハンドラ

  時間の経過をきっかけに発生するイベントをタイムイベント（ time event ）と 呼ぶ．タイムイベントにより起動され，カーネルが実行制御する処理単位を， タイムイベントハンドラ（ time event handler ）と呼ぶ．

• (1) 優先順位と優先度

  優先順位（ precedence ）とは，処理単位の実行順序を説明するための仕様上の 概念である．複数の処理単位が実行できる場合には，その中で最も優先順位の 高い処理単位が実行される．

  優先度（ priority ）は，タスクなどの処理単位の優先順位や，メッセージなど の配送順序を決定するために，アプリケーションが処理単位やメッセージなど に与える値である．優先度は，符号付きの整数型である PRI 型で表し， 1から連 続した正の値を用いるのを原則とする．優先度は，値が小さいほど優先度が高 い（すなわち，先に実行または配送される）ものとする．

• (2) システム時刻と相対時間

  カーネルが管理する時刻を，システム時刻（ system time ）と呼ぶ．システム時 刻は，符号無しの整数型である SYSTIM 型で表し，単位はミリ秒とする．システ ム時刻は，タイムティック（ time tick ）を通知するためのタイマ割込みが発生 する毎に更新される．

  イベントを発生させる時刻を指定する場合には，基準時刻（ base time ）からの 相対時間（ relative time ）によって指定する．基準時刻は，別に規定がない限 りは，相対時間を指定するサービスコールを呼び出した時刻となる．

  相対時間は，符号無しの整数型である RELTIM 型で表し，単位はシステム時刻と 同一，すなわちミリ秒とする．相対時間には，少なくとも， 16 ビットの符号無 しの整数型（ uint16_t 型）に格納できる任意の値を指定することができるが， RELTIM 型（ uint_t 型に定義される）に格納できる任意の値を指定できるとは限 らない．相対時間に指定できる最大値は，構成マクロ TMAX_RELTIM に定義されて いる．

  イベントを発生させる時刻を相対時間で指定した場合，イベントの処理が行わ れるのは，基準時刻から相対時間によって指定した以 上の時間が経過した後と なる．ただし，基準時刻を定めるサービスコールを呼び出した時に，タイム ティックを通知するためのタイマ割込みがマスクされている場合（タイマ割込 みより優先して実行される割込み処理が実行されている場合を含む）は，相対 時間によって指定した以上の時間が経過した後となることは保証されない．

  イベントが発生する時刻を参照する場合には，基準時刻からの相対時間として 返される．基準時刻は，相対時間を返すサービスコールを呼び出した時刻とな る．

  イベントが発生する時刻が相対時間で返された場合，イベントの処理が行われ るのは，基準時刻から相対時間として返された以上の時間が経過した後となる． ただし，相対時間を返すサービスコールを呼び出した時に，タイムティックを 通知するためのタイマ割込みがマスクされている場合（タイマ割込みより優先 して実行される割込み処理が実行されている場合を含む）は，相対時間として 返された以上の時間が経過した後となることは保証されない．

  【補足説明】

  相対時間に 0を指定した場合，基準時刻後の最初のタイムティックでイベントの 処理が行われる．また， 1を指定した場合，基準時刻後の 2回目以降のタイム ティックでイベントの処理が行われる．これは，基準時刻後の最初のタイム ティックは，基準時刻の直後に発生する可能性があるため，ここでイベントの 処理を行うと，基準時刻からの経過時間が 1以上という仕様を満たせないためで ある．

  同様に，相対時間として 0が返された場合，基準時刻後の最初のタイムティック でイベントの処理が行われる．また， 1が返された場合，基準時刻後の 2回目以 降のタイムティックでイベントの処理が行われる．

  【μ ITRON4.0 仕様との関係】

  相対時間（ RELTIM 型）とシステム時刻（ SYSTIM 型）の時間単位は，μ ITRON4.0 仕様では実装定義としていたが，この仕様ではミリ秒と規定した．また，相対 時間の解釈について，より厳密に規定した．

TMAX_RELTIM は，μ ITRON4.0 仕様に規定されていないカーネル構成マクロである．

• (3) タイムアウトとポーリング

  サービスコールの中で待ち状態が指定した時間以上継続した場合に，サービス コールの処理を取りやめて，サービスコールからリターンすることを，タイム アウト（ timeout ）という．タイムアウトしたサービスコールからは， E_TMOUT エラーが返る．

  タイムアウトを起こすまでの時間（タイムアウト時間）は，符号付きの整数型 である TMO 型で表し，単位はシステム時刻と同一，すなわちミリ秒とする．タイ ムアウト時間に正の値を指定した場合には，タイムアウトを起こすまでの相対 時間を表す．すなわち，タイムアウトの処理が行われるのは，サービスコール を呼び出してから指定した以上の時間が経過した後となる．

  ポーリング（ polling ）を行うサービスコールとは，サービスコールの中で待ち 状態に遷移すべ き状況になった場合に，サービスコールの処理を取りやめてリ ターンするサービスコールのことをいう．ここで，サービスコールの処理を取 りやめてリターンすることを，ポーリングに失敗したという．ポーリングに失 敗したサービスコールからは， E_TMOUT エラーが返る．

  ポーリングを行うサービスコールでは，待ち状態に遷移することはないのが原 則である．そのため，ポーリングを行うサービスコールは，ディ スパッチ保留 状態であっても呼び出せる場合がある．ただし，サービスコールの中で待ち状 態に遷移する状況が複数ある場合，ある状況でポーリング動作をしても，他の 状況では待ち状態に遷移する場合がある．このような場合の振舞いは，該当す るサービスコール毎に規定する．

  タイムアウト付きのサービスコールは，別に規定がない限りは，タイムアウト 時間に TMO_POL （＝ 0）を指定し た場合にはポーリングを行い， TMO_FEVR （＝ -1） を指定した場合にはタイムアウトを起こさないものとする．

  【補足説明】

  エラーコードに関する原則により，サービスコールがタイムアウトした場合や ポーリングに失敗した場合には，サービスコールによる副作用がないのが原則 である．ただし，そのような実装ができない場合にはこの原則の例外とし，ど のよう な副作用があるかをサービスコール毎に規定する．

  タイムアウト付きのサービスコールを，タイムアウト時間を TMO_POL として呼び 出した場合には，ディスパッチ保留状態で呼び出すと E_CTX エラーとなることを 除いては，ポーリングを行うサービスコールと同じ振舞いをする．また，タイ ムアウト時間を TMO_FEVR として呼び出した場合には，タイムアウトなしのサー ビスコールと全く同じ振舞いをする．

  【μ ITRON4.0 仕様との関係】

  タイムアウト時間（ TMO 型）の時間単位は，μ ITRON4.0 仕様では実装定義として いたが，この仕様ではミリ秒と規定した．

  【仕様決定の理由】

  ディスパッチ保留状態において，ポーリングを行うサービスコールを呼び出せ る場合があるのに対して，タイムアウト付きのサービスコールをタイムアウト 時間を TMO_POL として呼び出すとエラーになるのは，ディスパッチ保留状態では， 別に規定がない限り，自タスクを広義の待ち状態に遷移させる可能性のあるサー ビスコール（タイムアウト付きのサービスコールはこれに該当）を呼び出すこ とはできないと規定されているためである．

• (4) ノンブロッキング

  サービスコールの中で待ち状態に遷移すべき状況になった時，サービスコール の処理を継続したままサービスコールからリターンする場合，そのサービスコー ルをノンブロッキング（ non -blocking ）という．処理を継続したままリターン する場合，サービスコールからは E_WBLK エラーが返る． E_WBLK は警告を表すエ ラーコードであり，サービスコールによる副作用がないという原則は適用され な い．

  サービスコールから E_WBLK エラーが返った場合には，サービスコールの処理は 継続しているため，サービスコールに渡したパラメータまたはリターンパラメー タを入れる領域はまだ参照される可能性があり，別の目的に使用することはで きない．継続している処理が完了した場合や，何らかの理由で処理が取りやめ られた場合には，コールバックを呼び出すなどの方法で，サービスコールを呼 び出したソフトウェアに通知するものとする．

  ノンブロッキングの指定は，タイムアウト時間に TMO_NBLK （＝ -2）を指定する ことによって行う．ノンブロッキングの指定を行えるサービスコールは，指定 した場合の振舞いをサービスコール毎に規定する．

  【補足説明】

  ノンブロッキングは，システムサービスでサポートすることを想定した機 能で ある．カーネルは，ノンブロッキングの指定を行えるサービスコールをサポー トしていない．

この節では，保護機能に関連する主な概念について説明する．この節の内容は， 保護機能対応カーネルにのみ適用される．

• (1) アクセス保護

  保護機能対応カーネルは，処理単位 が，許可されたカーネルオブジェクトに対 して，許可された種別のアクセスを行うことのみを許し，それ以外のアクセス を防ぐアクセス保護機能を提供する．

  アクセス制御の用語では，処理単位が主体（ subject ），カーネルオブジェクト が対象（ object ）ということになる．

• (2) メモリオブジェクト

  保護機能対応カーネルにおいては，メモリ領域をカーネルオブジェクトとして 扱い，アクセス保護の対象とする．カーネルがアクセス保護の対象とする連続 したメモリ領域を，メモリオブジェクト（ memory object ）と呼ぶ．メモリオブ ジェクトは，互いに重なりあうことはない．

  メモリオブジェクトは，その先頭番地によって識別する．言い換えると，先頭 番地がオブジェクト番号とな る．

  メモリオブジェクトの先頭番地とサイズには，ターゲットハードウェアでメモ リ保護が実現できるように，ターゲット定義の制約が課せられる．

• (3) 保護ドメイン

  保護機能を提供するために用いるカーネルオブジェクトの集合を，保護ドメイ ン（ protection domain ）と呼ぶ．保護ドメインは，保護ドメイン ID と呼ぶ ID 番 号によって識別する．

  カーネルオブジェクトは，たかだか 1つの保護ドメインに属する．処理単位は， いずれか 1つの保護ドメインに属さなければならないのに対して，それ以外のカー ネルオブジェクトは，いずれの保護ドメインにも属さないことができる．いず れの保護ドメインにも属さないカーネルオブジェクトを，無所属のカーネルオ ブジェクト（ independent kernel object ）と呼ぶ．

  処理単位がカーネルオブジェクトにアクセスできるかどうかは，処理単位が属 する保護ドメインにより決まるのが原則である．すなわち，カーネルオブジェ クトに対するアクセス権は，処理単位ではなく，保護ドメイン単位で管理され る．このことから，ある保護ドメインに属する処理単位がアクセスできること を，単に，その保護ドメインからアクセスできるという．

  ただし，タスクのユーザスタック領域は，ターゲット定義での変更がない限り は，そのタスク（とカーネルドメインに属する処理単位）のみがアクセスでき る（「 2.11.6 ユーザタスクのユーザスタック領域」の節を参照）．これは， 「処理単位がカーネルオブジェクトにアクセスできるかどうかは，処理単位が 属する保護ドメインにより決まる」という原則の例外となっている．

  デフォルトで は，保護ドメインに属するカーネルオブジェクトは，同じ保護ド メイン（とカーネルドメイン）のみからアクセスできる．また，無所属のカー ネルオブジェクトは，すべての保護ドメインからアクセスできる．

• (4) カーネルドメインとユーザドメイン

  システムには，カーネルドメイン（ kernel domain ）と呼ばれる保護ドメインが 1 つ存在する．カーネルドメインに属する処理単位 は，プロセッサの特権モード で実行される．また，すべてのカーネルオブジェクトに対して，すべての種別 のアクセスを行うことが許可される．この仕様で，「ある保護ドメイン（また はタスク）のみからアクセスできる」といった場合でも，カーネルドメインド メインからはアクセスすることができる．

  カーネルドメイン以外の保護ドメインを，ユーザドメイン（ user domain ）と呼 ぶ ．ユーザドメインに属する処理単位は，プロセッサの非特権モードで実行さ れる．また，どのカーネルオブジェクトに対してどの種別のアクセスを行える かを制限することができる．

  ユーザドメインには， 1から連続する正の整数値の保護ドメイン ID が付与される． カーネルドメインの保護ドメイン ID は， TDOM_KERNEL （＝ -1）である．

  この仕様では，システムに登録できるユーザドメインの数は， 32 個以下に制限 する．これを超える数のユーザドメインを登録した場合には，コンフィギュレー タがエラーを報告する．

  【補足説明】

  ユーザドメインは，システムコンフィギュレーションファイル中にユーザドメ インの囲みを記述することで，カーネルに登録する（「 2.12.3 保護ドメインの 指定」の節を参照）．ユーザドメインを動的に生成する機能は，現時点では用 意していない．

  保護機能対応でないカーネルは，カーネルドメインのみをサポートしていると みなすこともできる．

  【μ ITRON4.0/PX 仕様との関係】

  μ ITRON4.0/PX 仕様のシステムドメイン（ system domain ）は，現時点ではサポー トしない．システムドメインは，それに属する処理単位が，プロセッサの特権 モードで実行され，カーネルオブジェクトに対するアクセスを制限することが できる保護ドメインである．

• (5) システムタスクとユーザタスク

  カーネルドメインに属するタスクをシステムタスク（ system task ），ユーザド メインに属するタスクをユーザタスク（ user task ）と呼ぶ．

  【補足説明】

  特権モードで実行されるタスクをシステムタスク，非特権モードで実行される タスクをユーザタスクと定義する方法もあるが，ユーザタスクであっても，サー ビスコールの実行中は特権モードで実行されるため，上記の定義とした．

  μ ITRON4.0/PX 仕様のシステムドメインに属するタスクは，システムタスクと呼 ぶことになる．

• (6) アクセス許可パターン

  あるカーネルオブジェクトに対するある種別のアクセスが，どの保護ドメイン に属する処理単位に許可されているかを表現するビットパターンを，アクセス 許可パターン（ access permission pattern ）と呼ぶ．アクセス許可パターンの 各ビットは， 1つのユーザドメインに対応する．カーネルドメインには，すべて の アクセスが許可されているため，カーネルドメインに対応するビットは用意 されていない．

  アクセス許可パターンは，符号無し 32 ビット整数に定義されるデータ型 （ ACPTN ）で保持し，値が 1のビットに対応するユーザドメインにアクセスが許 可されていることを表す．そのため， 2つのアクセス許可パターンのビット毎論 理和（ C言語の "|" ）を求めることで，アクセスを許可されているユーザドメイ ンの和集合（ union ）を得ることができる．また， 2つのアクセス許可パターン のビット毎論理積（ C言語の "&" ）を求めることで，アクセスを許可されている ユーザドメインの積集合（ intersection ）を得ることができる．

  アクセス許可パターンの指定に用いるために，指定したユーザドメインのみに アクセスを許可することを示すアクセス許可パターンを構成するマクロ（ TACP ） が 用意されている．また，カーネルドメインのみにアクセスを許可することを 示すアクセス許可パターンを表す定数（ TACP_KERNEL ）と，すべての保護ドメイ ンにアクセスを許可することを示すアクセス許可パターンを表す定数 （ TACP_SHARED ）が用意されている．

• (7) アクセス許可ベクタ

  カーネルオブジェクトに対するアクセスは，カーネルオブジェクトの種類毎に， 通常操作 1，通常操作 2，管理操作，参照操作の 4つの種別に分類されている．あ るカーネルオブジェクトに対する 4つの種別のアクセスに関するアクセス許可パ ターンをひとまとめにしたものを，アクセス許可ベクタ（ access permission vector ）と呼び，次のように定義されるデータ型（ ACVCT ）で保持する．

typedef struct acvct {
    ACPTN   acptn1;     /*  通常操作 1のアクセス許可パターン  */
    ACPTN   acptn2;     /*  通常操作 2のアクセス許可パターン  */
    ACPTN   acptn3;     /*  管理操作のアクセス許可パターン  */
    ACPTN   acptn4;     /*  参照操作のアクセス許可パターン  */
} ACVCT;

【補足説明】

カーネルオブジェクトの種類毎のアクセスの種別の分類については，「 5.8 カー ネルオブジェクトに対するアクセスの種別」の節を参照すること．

【μ ITRON4.0/PX 仕様との関係】

μ ITRON4.0/PX 仕様では，アクセス許可ベクタを， 1つまたは 2つのアクセス許可 パターンで構成することも 許しているが，この仕様では 4つで構成するものと決 めている．

• (8) サービスコールの呼出し方法

  保護機能対応カーネルでは，サービスコールは，ソフトウェア割込みによって 呼び出すのが基本である．サービスコール呼出しを通常の方法で記述した場合， ソフトウェア割込みによって呼び出すコードが生成される．

  一般に，ソフトウェア割込みによるサービスコール呼出しはオーバヘッドが大 きい．そのため，カーネルドメインに属する処理単位からは，関数呼出しによっ てサービスコールを呼び出すことで，オーバヘッドを削減することができる． そこで，カーネルドメインに属する処理単位から関数呼出しによってサービス コールを呼び出せるように，以下の機能が用意されている．

  カーネルドメインに属する 処理単位が実行する関数のみを含んだソースファイ ルでは，カーネルヘッダファイル（ kernel.h ）をインクルードする前に， TOPPERS_SVC_CALL をマクロ定義することで，サービスコール呼出しを通常の方 法で記述した場合に，関数呼出しによって呼び出すコードが生成される．

  また，カーネルドメインに属する処理単位が実行する関数と，ユーザドメイン に属する処理単位が実行する関数の両方を 含んだソースファイルでは，関数呼 出しによってサービスコールを呼び出すための名称を作るマクロ（ SVC_CALL ） を用いることで，関数呼出しによって呼び出すコードが生成される．例えば， act_tsk を関数呼出しによって呼び出す場合には，次のように記述すればよい．

  ercd = SVC_CALL(act_tsk)(tskid);

【補足説明】

拡張サービスコールを，関数呼出しによって呼び出す方法は用意されていない． カーネルドメインに属する処理単位が，関数呼出しによって，拡張サービスコー ルとして登録した関数を呼び出すことはできるが，その場合には，処理単位が 呼び出した通常の関数であるとみなされ，拡張サービスコールであるとは扱わ れない．

この節では，マルチプロセッサ対応に関連する主な概念について説明する．こ の節の内容は，マルチプロセッサ対応カーネルにのみ適用される．

• (1) クラス

  マルチプロセッサに対応するために用いるカーネルオブジェクトの集合を，ク ラス（ class ）と呼ぶ．クラスは，クラス ID と呼ぶ ID 番号によって識別する．

  カーネルオブジェクトは， いずれか 1つのクラスに属するのが原則である．カー ネルオブジェクトが属するクラスは，オブジェクトの登録時に決定し，登録後 に変更することはできない．

  【補足説明】

  処理単位を実行するプロセッサを静的に決定する機能分散型のマルチプロセッ サシステムでは，プロセッサ毎にクラスを設ける方法が典型的である．それに 対して，対称型のマルチプロセッサシステムで，処理単位のマイグレーション を許す場合には，プロセッサ毎のクラスに加えて，どのプロセッサでも実行で きるクラスを（システム中に 1つまたは初期割付けプロセッサ毎に）設ける方法 が典型的である．

  カーネルオブジェクトはいずれか 1つのクラスに属するという原則に関わらず， 以下のオブジェクトはいずれのクラスにも属さない．

• ・オーバランハンドラ
• ・拡張サービスコール
• ・グローバル初期化ルーチン
• ・グローバル終了処理ルーチン

マルチプロセッサ対応でないカーネルは，カーネルによって規定された 1つのク ラスのみをサポートしているとみなすこともできる．

• (2) プロセッサ

  たかだか 1つの処理単位のみを同時に実行できるハードウェアの単位を，プロセッ サ（ processor ）と呼ぶ．プロセッサは，プロセッサ ID と呼ぶ ID 番号によって識 別する．

  複数のプロセッサを持つシステム構成をマルチプロセッサ（ multiprocessor ） と呼び，同時に複数の処理単位を実行することができる．

  システムの初期化時と終了時に特別な役割を果たすプロセッサを，マスタ プロ セッサ（ master processor ）と呼び，システムに 1つ存在する．どのプロセッサ をマスタプロセッサとするかは，ターゲット定義である．マスタプロセッサ以 外のプロセッサを，スレーブプロセッサ（ slave processor ）と呼ぶ．なお，カー ネル動作状態では，マスタプロセッサとスレーブプロセッサの振舞いに違いは ない．

• (3) 処理単位の割付けとマイグ レーション

  処理単位は，後述のマイグレーションが発生しない限りは，いずれか 1つのプロ セッサに割り付けられて実行される．処理単位を実行するプロセッサを，割付 けプロセッサと呼ぶ．また，処理単位が登録時に割り付けられるプロセッサを， 初期割付けプロセッサと呼ぶ．

  処理単位によっては，処理単位の登録後に，割付けプロセッサを変更すること が可能である．処理単位の登録後に割付けプロセッサを変更することを，処理 単位のマイグレーション（ migration ）と呼ぶ．

  割付けプロセッサを変更できる処理単位に対しては，処理単位を割り付けるこ とができるプロセッサ（これを，割付け可能プロセッサと呼ぶ）を制限するこ とができる．

• (4) クラスの持つ属性とカーネルオブジェクト

  タスクの初期割付けプロセッサや割付け可能プロセッサなど，カーネルオブジェ クトをマルチプロセッサ上で実現する際に設定すべき属性は，そのカーネルオ ブジェクトが属するクラスによって定まる．

  各クラスが持ち，それに属するカーネルオブジェクトに適用される属性は，次 の通りである．

• ・初期割付けプロセッサ
• ・割付け可能プロセ ッサ（複数のプロセッサを指定可能，初期割付けプロセッ サを含む）
• ・ ATT_MOD ／ ATA_MOD において，オブジェクトモジュール中に含まれる標準の セクションが配置されるメモリリージョン
• ・オブジェクト生成に必要なメモリ領域（オブジェクトの管理ブロック，タ スクのスタック領域やデータキューのデータキュー管理領域など）の配置 場所
• ・その他の管理情報（ロック単位など）

使用できるクラスの ID 番号とその属性は，ターゲット定義である．

【仕様決定の理由】

クラスを導入することで，カーネルオブジェクト毎に上記の属性を設定できる ようにしなかったのは，これらの属性をアプリケーション設計者が個別に設定 するよりも，ターゲット依存部の実装者が有益な組み合わせをあ らかじめ用意 しておく方が良いと考えたためである．

• (5) ローカルタイマ方式とグローバルタイマ方式

  システム時刻の管理方式として，プロセッサ毎にシステム時刻を持つローカル タイマ方式と，システム全体で 1つのシステム時刻を持つグローバルタイマ方式 の 2つの方式がある．どちらの方式を用いることができるかは，ターゲット定義 である．

  ローカルタイマ方式では，プロセッサ毎のシステム時刻は，それぞれのプロセッ サが更新する．異なるプロセッサのシステム時刻を同期させる機能は，カーネ ルでは用意しない．

  グローバルタイマ方式では，システム中の 1つのプロセッサがシステム時刻を更 新する．これを，システム時刻管理プロセッサと呼ぶ．どのプロセッサをシス テム時刻管理プロセッサとするかは，ターゲット定義であ る．

  【補足説明】

  システム時刻管理プロセッサが，マスタプロセッサと一致している必要はない．

  【未決定事項】

  ローカルタイマ方式の場合に，プロセッサ毎に異なるタイムティックの周期を 設定したい場合が考えられるが，現時点の実装ではサポートしておらず， TIC_NUME と TIC_DENO の扱いも未決定であるため，今後の課題とする．

• (1) オブジェクトモジュール

  プログラムのオブジェクトコードとデータを含むファイルを，オブジェクトモ ジュール（ object module ）と呼ぶ．オブジェクトファイルとライブラリは，オ ブジェクトモジュールである．

• (2) メモリリージョン

  オブジェクトモジュールに含まれるセクションの配置対象となる同じ性質を持っ た連続したメモリ領域をメモリリージョン（ memory region ）と呼ぶ．

  メモリリージョンは，文字列によって識別する．メモリリージョンを識別する 文字列を，メモリリージョン名と呼ぶ．

  【補足説明】

  この仕様では，メモリ領域（ memory area ）という用語は，連続したメモリの範 囲という一般的な意味で使っている．

• (3) 標準のセクション

  コンパイラに特別な指定をしない場合に出力するセクションを，標準のセクショ ン（ standard sections ）と呼ぶ．また，ターゲット定義で，コンパイラが出力 しないセクションを，標準のセクションと扱う場合もある．

• (4) 保護ドメイン毎の標準セクション

  保護機能対応カーネルにおいては，保護ドメイン毎に，標準のセクションを配 置するためのセクションが登録される．また，無所属の標準のセクションを配 置するためのセクションが登録される．これらのセクションを，保護ドメイン 毎の標準セクションと呼ぶ（ stand ard sections for each protection domain ）． 保護ドメイン毎の標準セクションのセクション名は，ターゲット定義で別に規 定がない限りは，標準のセクション名と保護ドメイン名（カーネルドメインの 場合は "kernel" ，無所属の場合は "shared" ）を "_" でつないだものとする．例え ば，カーネルドメインの ".text" セクションのセクション名は， ".text_kernel" とする．

カーネルが実行を制御する処理単位の種類は次の通りである．

• (a) タスク
  • (a.1) タスク例外処理ルーチン
• (b) 割込みハンドラ
  • (b.1) 割込みサービスルーチン
  • (b.2) タイムイベントハンドラ
• (c) CPU 例外ハンドラ
• (d) 拡張サービスコール
• (e) 初期化ルーチン
• (f) 終了処理ルーチン

  ここで，タイムイベントハンドラとは，時間の経過をきっかけに起動される処 理単位である周期ハンドラ，アラームハンドラ，オーバランハンドラの総称で ある．

  【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは，オーバランハンドラと拡張サービスコールをサポートしてい ない．ただし，オーバランハンドラ機能拡張パッケージを用いると，オーバラ ンハンドラ機能を追加することができる．

【 TOPPERS/FMP カーネルにおける規定】

FMP カーネルでは，オーバランハンドラと拡 張サービスコールをサポートしてい ない．

【 TOPPERS/SSP カーネルにおける規定】

SSP カーネルでは，タスク例外処理ルーチン，タイムイベントハンドラ，拡張サー ビスコールをサポートしていない．

処理単位の実行順序を規定するために，ここでは，処理単位の優先順位を規定 する．また，ディスパッチが起こるタイミングを規定するために，ディスパッ チを行うカーネル内の処理であるディスパッチャの優先順位についても規定す る．

タスクの優先順位は，ディスパッチャの優先順位よりも低い．タスク間では， 高い優先度を持つ方が優先順位が高く，同じ優先度を持つタスク間では，先に 実行できる状態となった方が優先順位が高い．詳しくは，「 2.6.3 タスクのス ケジューリング規則」の節を参照すること．

タスク例外処理ルーチンの優先順位は，例外が要求されたタスクと同じである が，タスクよりも先に実行される．

割込みハンドラの優先順位は，ディスパッチャの優先順位よりも高い．割込み ハンドラ間では，高い割込み優先度を持つ方が優先順位 が高く，同じ割込み優 先度を持つ割込みハンドラ間では，先に実行開始された方が優先順位が高い． 同じ割込み優先度を持つ割込みハンドラ間での実行開始順序は，この仕様では 規定しない．詳しくは，「 2.7.2 割込み優先度」の節を参照すること．

割込みサービスルーチンとタイムイベントハンドラの優先順位は，それを呼び 出す割込みハンドラと同じである．

CP U例外ハンドラの優先順位は， CPU 例外がタスクまたはタスク例外処理ルーチ ンで発生した場合には，ディスパッチャの優先順位と同じであるが，ディスパッ チャよりも先に実行される． CPU 例外がその他の処理単位で発生した場合には， CPU 例外ハンドラの優先順位は，その処理単位の優先順位と同じであるが，その 処理単位よりも先に実行される．

拡張サービスコールの優先順位は，それを呼び出した処理単位と 同じであるが， それを呼び出した処理単位よりも先に実行される．

初期化ルーチンは，カーネルの動作開始前に，システムコンフィギュレーショ ンファイル中に初期化ルーチンを登録する静的 API を記述したのと同じ順序で実 行される．終了処理ルーチンは，カーネルの動作終了後に，終了処理ルーチン を登録する静的 API を記述したのと逆の順序で実行される．

マルチプロセッサ対応カーネルでは，初期化ルーチンには，クラスに属さない グローバル初期化ルーチンと，クラスに属するローカル初期化ルーチンがある． グローバル初期化ルーチンがマスタプロセッサで実行された後に，各プロセッ サでローカル初期化ルーチンが実行される．また，終了処理ルーチンには，ク ラスに属さないグローバル終了処理ルーチンと，クラスに属するローカル終了 処理ルーチンがある．ローカル終 了処理ルーチンが各プロセッサで実行された 後に，マスタプロセッサでグローバル終了処理ルーチンが実行される．

【仕様決定の理由】

終了処理ルーチンを，登録する静的 API を記述したのと逆順で実行するのは，終 了処理は初期化の逆の順序で行うのがよいためである（システムコンフィギュ レーションファイルを分割すると，終了処理ルーチンを登録する静的 API だけ逆 順に記述するのは難しい）．

カーネルのサービスコール処理やディスパッチャ，割込みハンドラと CPU 例外ハ ンドラの入口処理と出口処理などのカーネル処理は不可分に実行されるのが基 本である．実際には，カーネル処理の途中でアプリケーションが実行される場 合はあるが，アプリケーションがサービスコールを用いて観測できる範囲で， カーネル処理が不可分に実行された場合と同様に振る舞うのが原則である．こ れを，カーネル処理の不可分性という．

ただし，マルチプロセッサ対応カーネルにおいては，カーネル処理が実行され ているプロセッサ以外のプロセッサから，カーネル処理の途中の状態が観測で きる場合がある．具体的には， 1つのサービスコールにより複数のオブジェクト の状態が変化する場合に，一部のオブジェクトの状態のみが変化し，残りのオ ブジェクトの状態が変化していない過渡的な状態が観測できる場合がある．

【補足説明】

マルチプロセッサ対応でないカーネルでは， 1つのサービスコールにより複数の タスクが実行できる状態になる場合，新しく実行状態となるべきタスクへのディ スパッチは，すべてのタスクの状態遷移が完了し た後に行われる．例えば，低 優先度のタスク Aが発行したサービスコールにより，中優先度のタスク Bと高優 先度のタスク Cがこの順で待ち解除される場合，タスク Bとタスク Cが待ち解除さ れた後に，タスク Cへのディスパッチが行われる．

マルチプロセッサ対応カーネルでは，上のことは， 1つのプロセッサ内では成り 立つが，他のプロセッサに割り付けられたタスクに対しては成り立たない．例 えば，プロセッサ 1で低優先度のタスク Aが実行されている時に，他のプロセッ サ 2で実行されているタスクが発行したサービスコールにより，プロセッサ 1に 割り付けられた中優先度のタスク Bと高優先度のタスク Cがこの順で待ち解除さ れる場合，タスク Cが待ち解除される前に，タスク Bへディスパッチされる場合 がある．

マルチプロセッサ対応カーネルでは，処理単位を実行するプロセッサ（割付け プロセッサ）は，その処理単位が属するクラスの初期割付けプロセッサと割付 け可能プロセッサから，次のように決まる．

タスク，周期ハンドラ，アラームハンドラは，登録時に，属するクラスの初期 割付けプロセッサに割り付けられる．また，割付けプロセッサを変更するサー ビスコール（ mact_tsk ／ imact_tsk ， mig_tsk ， msta_cyc ， msta_alm ／ imsta_alm ）によって，割付けプロセッサを，クラスの割付け可能プロセッサの いずれかに変更することができる．

割込みハンドラ， CPU 例外ハンドラ，ローカル初期化ルーチン，ローカル終了処 理ルーチンは，属するクラスの初期割付けプロセッサで実行される．クラスの 割 付け可能プロセッサの情報は用いられない．

割込みサービスルーチンは，属するクラスの割付け可能プロセッサのいずれか （オプション設定によりすべて）で実行される．クラスの初期割付けプロセッ サの情報は用いられない．

以上を整理すると，次の表の通りとなる．この表の中で，「○」はその情報が 使用されることを，「 － 」はその情報が使用されないことを示す．

オーバランハンドラ，拡張サービスコール，グローバル初期化ルーチン，グロー バル終了処理ルーチンは，いずれのクラスにも属さない．オーバランハンドラ は，オーバランを起こしたタスクの割付けプロセッサによって実行される．拡 張サービスコールは，それを呼び出した処理単位の割付けプロセッサによって 実行される．グローバル初期化ルーチンとグローバル終了処理ルーチンは，マ スタプロセッサによって実行される．

カーネルの初期化が完了した後，カーネルの終了処理が開始されるまでの間を， カーネル動作状態と呼ぶ．それ以外の状態，すなわちカーネルの初期化完了前 （初期化ルーチンの実行中を含む）と終了処理開始後（終了処理ルーチンの実 行中を含む）を，カーネル非動作状態と呼ぶ．プロセッサは，カーネル動作状 態かカーネル非動作状態のい ずれかの状態を取る．

カーネル非動作状態では，原則として， NMI を除くすべての割込みがマスクされ る．

カーネル非動作状態では，システムインタフェースレイヤの API とカーネル非動 作状態を参照するサービスコール（ sns_ker ）のみを呼び出すことができる．カー ネル非動作状態で，その他のサービスコールを呼び出した場合の動作は，保証 されない．

マルチプロセッサ対応カーネルでは，プロセッサ毎に，カーネル動作状態かカー ネル非動作状態のいずれかの状態を取る．

処理単位が実行される環境（用いるスタック領域やプロセッサの動作モードな ど）をコンテキストと呼ぶ．

カーネル動作状態において，処理単位が実行されるコンテキストは，タスクコ ンテキストと非タスクコンテキストに分類される．

タスク（タスク例外処理ルーチンを含む）が実行されるコンテキストは，タス クコンテキストに分類される．また，タスクコンテキストから呼び出した拡張 サービスコールが実行されるコンテキストは，タスクコンテキストに分類され る．

割込みハンドラ（割込みサービスルーチンおよびタイムイベントハンドラを含 む）と CPU 例外ハンドラが実行されるコンテキストは，非タスクコンテキストに 分類される．また，非タスクコンテキストから呼び出した拡張サービスコール が実行されるコンテキストは，非タスクコンテキストに分類される．

タスクコンテキストで実行される処理単位は，別に規定がない限り，タスクの スタック領域を用いて 実行される．非タスクコンテキストで実行される処理単 位は，別に規定がない限り，非タスクコンテキスト用スタック領域を用いて実 行される．

タスクコンテキストからは，非タスクコンテキスト専用のサービスコールを呼 び出すことはできない．逆に，非タスクコンテキストからは，タスクコンテキ スト専用のサービスコールを呼び出すことはできない．いずれも，呼び出した 場合には E_CTX エラーとなる．

カーネル動作状態において，プロセッサは，カーネルの振舞いに影響を与える 状態として，次の状態を持つ．

• ・全割込みロックフラグ（全割込みロック状態と全割込みロック解除状態）
• ・ CPU ロックフラグ（ CPU ロック状態と CPU ロック解除状態）
• ・割込み優先度マスク（割込み優先度マスク全解除状態と全解除でない状態）
• ・ディスパッチ禁止フラグ（ディスパッチ禁止状態とディスパッチ許可状態）

これらの状態は，それぞれ独立な状態である．すなわち，プロセッサは上記の 状態の任意の組合せを取ることができ，それぞれの状態を独立に変化させるこ とができる．

プロセッサは， NMI を除くすべての割込みをマスクするための全割込みロックフ ラグを持つ．全割込みロックフラグがセットされた状態を全割込みロック状態， クリアされた状態を全割込みロック解除状態と呼ぶ．すなわち，全割込みロッ ク状態では， NMI を除くすべての割込みがマスクされる．

全割込みロック状態では，システムインタフェースレイヤの API とカーネル非動 作状態を参照するサービスコール（ sns_ker ），カーネルを終了するサービスコー ル（ ext_ker ）のみを呼び出すことができ，その他のサービスコールを呼び出す ことはできない．全割込みロック状態で，その他のサービスコールを呼び出し た場合の動作は，保証されない．また，全割込みロック状態では，実行中の処 理単位からリターンしてはならない．リターンした場合の動作は保証されない．

マルチプロセッサ対応カーネルでは，プロセッサ毎に，全割込みロックフラグ を持つ．すなわち，プロセッサ毎に，全割込みロック状態か全割込みロック解 除状態のいずれかの状態を取る．

プロセッサは，カーネル管理の割込み（「 2.7.7 カーネル管理外の割込み」の 節を参照）をすべてマスクするための CPU ロ ックフラグを持つ． CPU ロックフラ グがセットされた状態を CPU ロック状態，クリアされた状態を CPU ロック解除状 態と呼ぶ．すなわち， CPU ロック状態では，すべてのカーネル管理の割込みがマ スクされ，ディスパッチが保留される．

NMI 以外にカーネル管理外の割込みを設けない場合には，全割込みロックフラグ と CPU ロックフラグの機能は同一となるが，両フラグは独立に存在する．

CPU ロック状態で呼び出すことができるサービスコールは次の通り．

• ・システムインタフェースレイヤの API
• ・ loc_cpu ／ iloc_cpu ， unl_cpu ／ iunl_cpu
• ・ unl_spn ／ iunl_spn （マルチプロセッサ対応カーネルのみ）
• ・ dis_int ， ena_int
• ・ sns_yyy ， xsns_yyy （ CPU 例外ハンドラからのみ）
• ・ get_utm
• ・ ext_tsk ， ext_ker
• ・ cal_svc （保護機能対応カーネルのみ）

CPU ロック状態で，その他のサービスコールを呼び出した場合には， E_CTX エラー となる．

マルチプロセッサ対応カーネルでは，プロセッサ毎に， CPU ロックフラグを持つ． すなわち，プロセッサ毎に， CPU ロック状態か CPU ロック解除状態のいずれかの 状態を取る．

【補足説明】

マルチプロセッサ対応カーネルにおいて，あるプロセッサが CPU ロック状態にあ る間は，そのプロセッサにおいてのみ，すべてのカーネル管理の割込みがマス クされ，ディスパッチが保留される．それに対して他のプロセッサにおいては， 割込みはマスクされず，ディスパッチも起こるため， CPU ロック状態を使って他 のプロセッサで実行される処理単位との排他制御を実現することはできない．

プロセッサは，割込み優先度を基準に割込みをマスクするための割込み優先度 マスクを持つ．割込み優先度マスクが TIPM_ENAALL （＝ 0）の時は，いずれの割 込み要求もマスクされない．この状 態を割込み優先度マスク全解除状態と呼ぶ． 割込み優先度マスクが TIPM_ENAALL （＝ 0）以外の時は，割込み優先度マスクと 同じかそれより低い割込み優先度を持つ割込みはマスクされ，ディスパッチは 保留される．この状態を割込み優先度マスクが全解除でない状態と呼ぶ．

割込み優先度マスクが全解除でない状態では，別に規定がない限りは，自タス クを広義の待ち状態に遷移させる可能性のあるサービスコ ールを呼び出すこと はできない．呼び出した場合には， E_CTX エラーとなる．

マルチプロセッサ対応カーネルでは，プロセッサ毎に，割込み優先度マスクを 持つ．

プロセッサは，ディスパッチを保留するためのディスパッチ禁止フラグを持つ． ディスパッチ禁止フラグがセットされた状態をディスパッチ禁止状態，クリア された状態をディスパッチ許可状態と呼ぶ．すなわち，ディスパッチ禁止状態 では，ディスパッチは保留される．

ディスパッチ禁止状態では，別に規定がない限りは，自タスクを広義の待ち状 態に遷移させる可能性のあるサービスコールを呼び出すことはできない．呼び 出した場合には， E_CTX エラーとなる．

マルチプロセッサ対応カーネルでは，プロセッサ毎に，ディスパッチ禁止フラ グを持つ．すなわち，プロセッサ毎に，ディスパッチ禁止状態かディスパッチ 許可状態のいずれかの状態を取る．

【補足説明】

マルチプロセッサ対応カーネルにおいて，あるプロセッサがディスパッチ禁止 状態にある間は，そのプロセッサにおいてのみ，ディスパッチが保留される ． それに対して他のプロセッサにおいては，ディスパッチが起こるため，ディス パッチ禁止状態を使って他のプロセッサで実行されるタスクとの排他制御を実 現することはできない．

非タスクコンテキストの実行中， CPU ロック状態，割込み優先度マスクが全解除 でない状態，ディスパッチ禁止状態では，ディスパッチが保留される．こ れら の状態を総称して，ディスパッチ保留状態と呼ぶ．

マルチプロセッサ対応カーネルでは，プロセッサ毎に，ディスパッチ保留状態 かそうでない状態のいずれかの状態を取る．

【補足説明】

全割込みロック状態はカーネルが管理しておらず，ディスパッチが保留される ことをカーネルが保証できないため，ディスパッチ保留状態に含めていない．

全割込みロック状態，カーネル管理外の割込みハンドラ実行中（「 2.7.7 カー ネル管理外の割込み」の節を参照），カーネル管理外の CPU 例外ハンドラ実行中 （「 2.8.4 カーネル管理外の CPU 例外」の節を参照）を総称して，カーネル管理 外の状態と呼ぶ．

それぞれの節で規定する通り，カーネル管 理外の状態では，システムインタ フェースレイヤの API と sns_ker ， ext_ker のみ（カーネル管理外の CPU 例外ハン ドラからは，それに加えて xsns_dpn と xsns_xpn ）を呼び出すことができ，その 他のサービスコールを呼び出すことはできない．カーネル管理外の状態から， その他のサービスコールを呼び出した場合の動作は，保証されない．

カーネル管理外の状態では，少なくとも，カー ネル管理の割込みはマスクされ ている．カーネル管理外の割込み（の一部）もマスクされている場合もある． 保護機能対応カーネルでは，カーネル管理外の状態になるのは，特権モードで 実行している間に限られる．

各処理単位が実行開始されるシステム状態の条件（実行開始条件），各処理単 位の実行開始時にカーネル によって行われるシステム状態の変更処理（実行開 始時処理），各処理単位からのリターン前（または終了前）にアプリケーショ ンが設定しておくべきシステム状態（リターン前または終了前），各処理単位 からのリターン時（または終了時）にカーネルによって行われるシステム状態 の変更処理（リターン時処理または終了時処理）は，次の表の通りである．

この表の中で「原則 (*1) 」とは，処理単位からのリタ ーン前（または終了前） に，アプリケーションが指定された状態に設定しておくことが原則であるが， この原則に従わなくても，リターン時（または終了時）にカーネルによって状 態が設定されるため，支障がないことを意味する．

「自優先度に (*2) 」 とは，割込みハンドラと割込みサービスルーチンの場合に はそれを要求した割込みの割込み優先度，周期ハンドラとアラームハンドラの 場合 にはタイマ割込みの割込み優先度，オーバランハンドラの場合にはオーバ ランタイマ割込みの割込み優先度に変更することを意味する．

「変更不可 (*3) 」 とは，その処理単位中で，そのシステム状態を変更する API が用意されていないことを示す．

保護機能対応カーネルでは，タスク例外処理ルーチンからのリターン時にディ スパッチ禁止フラグを元に戻す処理 (*4) は，タスクにディス パッチ禁止フラグ の変更を許可している場合にのみ行われる．カーネルは，ディスパッチ禁止フ ラグの元の状態をユーザスタック上に保存する．アプリケーションがユーザス タック上に保存されたディスパッチ禁止フラグの状態を書き換えた場合，タス ク例外処理ルーチンからのリターン時には，書き換えた後のディスパッチ禁止 フラグの状態に変更される（すなわち，元に戻されるとは限らない）．

また，タスクにディスパッチ禁止フラグの変更を許可していない場合で，タス ク例外処理ルーチン中で拡張サービスコールを用いてディスパッチ禁止フラグ を変更した場合，カーネルは元の状態に戻さない．このことから，タスク例外 処理ルーチンからの終了前に，ディスパッチ禁止フラグを元の状態に戻すのは， アプリケーションの責任とする．

【補足説明】

マルチプロセッサ対応カーネルにおいて，タスクがタスク例外処理ルーチンを 実行中にマイグレーションされた場合，マイグレーション先のプロセッサにお いて，割込み優先度マスクとディスパッチ禁止フラグが元に戻される．

【仕様決定の理由】

保護機能対応カーネルにおいて，タスク例外処理ルーチンからのリターン時に ディスパッチ禁止フラグを元に戻す処理 (*4) が，タスクにデ ィスパッチ禁止フ ラグの変更を許可している場合にのみ行われるのは，タスクがユーザスタック 上の状態を書き換えることで，許可していない状態変更を起こせてしまうこと を防止するためである．

割込みハンドラや CPU 例外ハンドラで，その処理単位中で割込み優先度マスクを 変更する API が用意されていないにもかかわらず，処理単位からのリターン時に 元の状態に戻す (*5) のは，プロ セッサによっては，割込み優先度マスクがステー タスレジスタ等に含まれており， API を用いずに変更できてしまう場合があるた めである．

CPU 例外ハンドラの実行開始時には， CPU ロックフラグは変更されない (*6) こと から， CPU ロック状態で CPU 例外が発生した場合， CPU 例外ハンドラの実行開始直 後は CPU ロック状態となっている． CPU ロック状態で CPU 例外が発生した場合，起 動される CPU 例外ハンドラはカーネル管理外の CPU 例外ハンドラであり（ xsns_dpn ， xsns_xpn とも true を返す）， CPU 例外ハンドラ中で iunl_cpu を呼び出して CPU ロッ ク状態を解除しようとした場合の動作は保証されない．ただし，保証されない にも関わらず iunl_cpu を呼び出した場合も考えられるため，リターン時には元 に戻すこととしている．

2. 6 タスクの状態遷移とスケジューリング規則

カーネルに登録したタスクは，実行できる状態，休止状態，広義の待ち状態の いずれかの状態を取る．また，実行できる状態と広義の待ち状態を総称して， 起動された状態と呼ぶ．さらに，タスクをカーネルに登録していない仮想的な 状態を，未登録状態と呼ぶ．

• (a) 実行できる状態（ runnable ）

  タスクを実行できる条件が，プロセッサが使用できるかどうかを除いて，揃っ ている状態．実行できる状態は，さらに，実行状態と実行可能状態に分類され る．

  • (a.1) 実行状態（ running ）

    タスクが実行されている状態．または，そのタスクの実行中に，割込みまたは CPU 例外により非タスクコ ンテキストの実行が開始され，かつ，タスクコンテキ ストに戻った後に，そのタスクの実行を再開するという状態．

  • (a.2) 実行可能状態（ ready ）

    タスク自身は実行できる状態にあるが，それよりも優先順位の高いタスクが実 行状態にあるために，そのタスクが実行されない状態．

• (b) 休止状態（ dormant ）

  タスクが実行すべき処理がない状態．タスクの実行を終了した後，次に起動す るまでの間は，タスクは休止状態となっている．タスクが休止状態にある時に は，タスクの実行を再開するための情報（実行再開番地やレジスタの内容など） は保存されていない．

• (c) 広義の待ち状態（ blocked ）

  タスクが，処理の途中で実行を止められている状態．タスクが広義の待ち 状態 にある時には，タスクの実行を再開するための情報（実行再開番地やレジスタ の内容など）は保存されており，タスクが実行を再開する時には，広義の待ち 状態に遷移する前の状態に戻される．広義の待ち状態は，さらに，（狭義の） 待ち状態，強制待ち状態，二重待ち状態に分類される．

  • (c.1) （狭義の）待ち状態（ waiting ）

    タスクが何らかの条件が揃 うのを待つために，自ら実行を止めている状態．

  • (c.2) 強制待ち状態（ suspended ）

    他のタスクによって，強制的に実行を止められている状態．ただし，自タスク を強制待ち状態にすることも可能である．

  • (c.3) 二重待ち状態（ waiting -suspended ）

    待ち状態と強制待ち状態が重なった状態．すなわち，タスクが何らかの条件が 揃うのを待つために自ら実行を止めている時に，他のタスクによって強制的に 実行を止められている状態．

    単にタスクが「待ち状態である」といった場合には，二重待ち状態である場合 を含み，「待ち状態でない」といった場合には，二重待ち状態でもないことを 意味する．また，単にタスクが「強制待ち状態である」とい った場合には，二 重待ち状態である場合を含み，「強制待ち状態でない」といった場合には，二 重待ち状態でもないことを意味する．

• (d) 未登録状態（ non -existent ）

  タスクをカーネルに登録していない仮想的な状態．タスクの生成前と削除後は， タスクは未登録状態にあるとみなす．

  カーネルによっては，これらのタスク状態以外 に，過渡的な状態が存在する場 合がある．過渡的な状態については，「 2.6.6 ディスパッチ保留状態で実行中 のタスクに対する強制待ち」の節を参照すること．

  【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは，タスクが未登録状態になることはない．また，上記のタスク 状態以外の過渡的な状態になることもない．ただし，動的生成機能拡張パッケー ジでは，タスクが未登録状態になる．

【 TOPPERS/FMP カーネルにおける規定】

FMP カーネルでは，タスクが未登録状態になることはない．上記のタスク状態以 外の過渡的な状態として，タスクが強制待ち状態［実行継続中］になることが ある．詳しくは，「 2.6.6 ディスパッチ保留状態で実行中のタスクに対する強 制待ち」の節を参照すること．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは，タスクが未登録状態になることはない．また，上記のタス ク状態以外の過渡的な状態になることもない．

【 TOPPERS/SSP カーネルにおける規定】

SSP カーネルでは，タスクが広義の待ち状態と未登録状態になることはない．ま た，上記のタスク状態以外の過渡的 な状態になることもない．

タスクの状態遷移を図 2-2に示す．

未登録状態のタスクをカーネルに登録することを，タスクを生成する（ create ） という．生成されたタスクは，休止状態に遷移する．また，タスク生成時の属 性指定により，生成と同時にタスクを起動し，実行できる状態にすることもで きる．逆に，登録されたタスクを未登録状態に遷移させることを，タスクを削 除する（ delete ）という．

休止状態のタスクを，実行できる状態にすることを，タスクを起動する （ activate ）という．起動されたタスクは，実行できる状態になる．逆に，起 動された状態のタスクを，休止状態（または未登録状態）に遷移させることを， タスクを終了する（ terminate ）という．

実行できる状態になったタスクは，まずは実行可能状態に遷移するが，そのタ スクの優先順位が実行状態のタスクよりも高い場合には，ディスパッチ保留状 態でない限りはただちにディスパッチが起こり，実行状態へ遷移する．この時， それまで実行状態であったタスクは実行可能状態に遷移する．この時，実行状 態に遷移したタスクは，実行可能状 態に遷移したタスクをプリエンプトしたと いう．逆に，実行可能状態に遷移したタスクは，プリエンプトされたという．

タスクを待ち解除するとは，タスクが待ち状態（二重待ち状態を除く）であれ ば実行できる状態に，二重待ち状態であれば強制待ち状態に遷移させることを いう．また，タスクを強制待ちから再開するとは，タスクが強制待ち状態（二 重待ち状態を除く）であれば実行できる状態に，二重待ち状態であれ ば待ち状 態に遷移させることをいう．

【補足説明】

タスクの実行開始とは，タスクが起動された後に最初に実行される（実行状態 に遷移する）時のことをいう．

実行できるタスクは，優先順位の高いものから順に実行される．すなわち，ディ スパッチ保留状 態でない限りは，実行できるタスクの中で最も高い優先順位を 持つタスクが実行状態となり，他は実行可能状態となる．

タスクの優先順位は，タスクの優先度とタスクが実行できる状態になった順序 から，次のように定まる．優先度の異なるタスクの間では，優先度の高いタス クが高い優先順位を持つ．優先度が同一のタスクの間では，先に実行できる状 態になったタスクが高い優先順位を持つ．すなわち，同じ優先度を持つタスク は， FCFS （ First Come First Served ）方式でスケジューリングされる．ただし， サービスコールの呼出しにより，同じ優先度を持つタスク間の優先順位を変更 することも可能である．

最も高い優先順位を持つタスクが変化した場合には，ディスパッチ保留状態で ない限りはただちにディスパッ チが起こり，最も高い優先順位を持つタスクが 実行状態となる．ディスパッチ保留状態においては，実行状態のタスクは切り 換わらず，最も高い優先順位を持つタスクは実行可能状態にとどまる．

マルチプロセッサ対応カーネルでは，プロセッサ毎に，上記のスケジューリン グ規則を適用して，タスクスケジューリングを行う．すなわち，プロセッサが ディスパッチ保留状態でない限りは，そのプロセッサに割り付けられた 実行で きるタスクの中で最も高い優先順位を持つタスクが実行状態となり，他は実行 可能状態となる．そのため，実行状態のタスクは，プロセッサ毎に存在する．

タスクが待ち解除される順序の管理のために，待ち状態のタスクがつながれて いるキューを，待ち行列と呼ぶ．また，タスクが同期・通信オブジェクトの待 ち行列につなが れている場合に，そのオブジェクトを，タスクの待ちオブジェ クトと呼ぶ．

待ち行列にタスクをつなぐ順序には， FIFO 順とタスクの優先度順がある．どち らの順序でつなぐかは，待ち行列毎に規定される．多くの待ち行列において， どちらの順序でつなぐかを，オブジェクト属性により指定できる．

FIFO 順の待ち行列においては，新たに待ち状態に遷移したタスクは待ち行列の 最後につながれる．それに対してタスクの優先度順の待ち行列においては，新 たに待ち状態に遷移したタスクは，優先度の高い順に待ち行列につながれる． 同じ優先度のタスクが待ち行列につながれている場合には，新たに待ち状態に 遷移したタスクが，同じ優先度のタスクの中で最後につながれる．

待ち解除の条件がタスクによって異なる場合には，待ち行列の先頭のタスクは 待ち解除の条件を満た さないが，後方のタスクが待ち解除の条件を満たす場合 がある．このような場合の振舞いとして，次の 2つのケースがある．どちらの振 舞いをするかは，待ち行列毎に規定される．

• (a) 待ち解除の条件を満たしたタスクの中で，待ち行列の前方につながれたも のから順に待ち解除される．すなわち，待ち行列の前方に待ち解除の条件を満 たさないタスクがあっても，後方のタスクが待ち解除の条件を満たしていれば， 先に待ち解除される．
• (b) タスクの待ち解除は，待ち行列につながれている順序で行われる．すなわ ち，待ち行列の前方に待ち解除の条件を満たさないタスクがあると，後方のタ スクが待ち解除の条件を満たしても，待ち解除されない．

  ここで， (b) の振舞いをする待ち行列においては，待ち行列につながれたタスク の強制終了，タスク優先度の変更（待ち行列がタスク の優先度順の場合のみ）， 待ち状態の強制解除が行われた場合に，タスクの待ち解除が起こることがある． 具体的には，これらの操作により新たに待ち行列の先頭になったタスクが，待 ち解除の条件を満たしていれば，ただちに待ち解除される．さらに，この待ち 解除により新たに待ち行列の先頭になったタスクに対しても，同じ処理が繰り 返される．

保護機能対応カーネルにおいて，ユーザタスクについては特権モードで実行し ている間（特権モードを実行している間に，実行可能状態や広義の待ち状態に なっている場合を含む．また，サービスコールを呼び出して，実行可能状態や 広義の待ち状態になっている場合も含む．タスクの実行開始前は含まない）， システムタスクについては拡張サービスコールを実行している間（拡張サービ スコールを実行している間に，実行可能状態や広義の待ち状態になっている場 合を含む）は，タスク例外処理ルーチンの実行は開始されない．これらの状態 を，タスク例外処理マスク状態と呼ぶ．

タスクは，タスク例外処理マスク状態である時に，基本的なタスク状態と重複 して，待ち禁止状態になることができる．

待ち禁止状態とは，タスクが待ち状態に入ることが一時的に 禁止された状態で ある．待ち禁止状態にあるタスクが，サービスコールを呼び出して待ち状態に 遷移しようとした場合，サービスコールは E_RLWAI エラーとなる．

タスクを待ち禁止状態に遷移させるサービスコールは，対象タスクがタスク例 外処理マスク状態である場合に，対象タスクを待ち禁止状態に遷移させる．そ の後，タスクがタスク例外処理マスク状態でなくなる時点（ユーザタスクにつ いては特権モードから戻る時点，システムタスクについて拡張サービスコール からリターンする時点）で，待ち禁止状態が解除される．また，タスクの待ち 禁止状態を解除するサービスコールによっても，待ち禁止状態を解除すること ができる．

【仕様決定の理由】

タスク例外処理ルーチンでは，タスクの本体のための例外処理（例えば，タス クに対して終了要求があっ た時の処理）を行うことを想定しており，タスクか ら呼び出した拡張サービスコールのための例外処理を行うことは想定していな い．そのため，拡張サービスコールを実行している間にタスク例外処理が要求 された場合に，すぐにタスク例外処理ルーチンを実行すると，拡張サービスコー ルのための例外処理が行われないことになる．

また，ユーザタスクの場合には，特権モードを実行中にタスク例外処理ルーチ ンを実行すると，システムスタックに情報を残したまま非特権モードに戻るこ とになる．この状態で，タスク例外処理ルーチンから大域脱出すると，システ ムスタック上に不要な情報が残ってしまう．

これらの理由から，タスクが拡張サービスコールを実行している間は，タスク 例外処理マスク状態とし，タスク例外処理ルーチンの実行を開始しないことと する．さらに，ユーザタスクについては，特 権モードを実行している間（拡張 サービスコールを実行している間を含む）を，タスク例外処理マスク状態とす る．

対象タスクに，タスク例外処理ルーチンをすみやかに実行させたい場合には， タスク例外処理の要求に加えて，待ち状態の強制解除を行う（必要に応じて， 強制待ち状態からの再開も行う）．保護機能対応でないカーネルにおいては， この方法により，対象タスクが正常に待ち解除さ れるのを待たずに，タスク例 外処理ルーチンを実行させることができる．

それに対して，保護機能対応カーネルにおいては，対象タスクがタスク例外処 理マスク状態で実行している間は，タスク例外処理ルーチンの実行が開始され ない．そのため，対象タスクに対して待ち状態の強制解除を行っても，その後 に対象タスクが待ち状態に入ると，タスク例外処理ルーチンがすみやかに実行 されないこと になる．

待ち禁止状態は，この問題を解決するために導入したものである．タスク例外 処理の要求（ ras_tex ／ iras_tex ）に加えて，待ち禁止状態への遷移（ dis_wai ／ idis_wai ）と待ち状態の強制解除（ rel_wai ／ irel_wai ）をこの順序で行うこと で，対象タスクが正常に待ち解除されるのを待たずに，タスク例外処理ルーチ ンを実行させることができる．

タスク例外処理マスク状態を，ユーザタスクについても拡張サービスコールを 実行している間とせず，特権モードで実行している間とした理由は，拡張サー ビスコールを実行している間とした場合に次のような問題があるためである．

ユーザタスクが，ソフトウェア割込みにより自タスクを待ち状態に遷移させる サービスコールを呼び出した直後に割込みが発生し，その割込みハンドラの中 で iras_tex ， idis_wai ， irel_wai が呼び出されると，この時点では待ち解除も されず待ち禁止状態にもならないために，割込みハンドラからのリターン後に 待ち状態に入ってしまう．ソフトウェア割込みによりすべての割込みが禁止さ れないターゲットプロセッサでは，ソフトウェア割込みの発生とサービスコー ルの実行を不可分にできないため，このような状況を防ぐことができない．

なお，拡張サービスコールは，待ち状態に入るサービスコールから E_RLWAI が返 された場合には，実行中の処理を取りやめて， E_RLWAI を返値としてリターンす るように実装すべきである．

【μ ITRON4.0 仕様，μ ITRON4.0/PX 仕様との関係】

待ち禁止状態は，μ ITRON4.0 仕様にはない概念であり，μ ITRON4.0/PX 仕様で導 入された．ただし， μ ITRON4.0/PX 仕様では，タスクの待ち状態を強制解除する サービスコールが，タスクを待ち禁止状態へ遷移させる機能も持つこととして いる．その結果μ ITRON4.0/PX 仕様は，待ち状態を強制解除するサービスコール の仕様において，μ ITRON4.0 仕様との互換性がなくなっている．

この仕様では，待ち状態の強制解除と待ち禁止状態への遷移を別々のサービス コールで行うこととした．これにより，待ち状態を強制解除するサービスコー ルの仕様が，μ ITRON4.0 仕様と互換になっている．一方，μ ITRON4.0/PX 仕様と は互換性がない．

ディスパッチ保留状態において，実行状態のタスクを強制待ち状態へ遷移させ るサービスコールを呼び出した 場合，実行状態のタスクの切換えは，ディスパッ チ保留状態が解除されるまで保留される．

この間，それまで実行状態であったタスクは，実行状態と強制待ち状態の間の 過渡的な状態にあると考える．この状態を，強制待ち状態［実行継続中］と呼 ぶ．一方，ディスパッチ保留状態が解除された後に実行すべきタスクは，実行 可能状態にとどまる．

タスクが強制待ち状態［実 行継続中］にある時に，ディスパッチ保留状態が解 除されると，ただちにディスパッチが起こり，タスクは強制待ち状態に遷移す る．

過渡的な状態も含めたタスクの状態遷移を図 2-3に示す．

タスクが強制待ち状態［実行継続中］である時の扱いは次の通りである．

• (a) プロセッサを占有して実行を継続する．

  強制待ち 状態［実行継続中］のタスクは，プロセッサを占有して，そのまま継 続して実行される．

• (b) 実行状態のタスクに関する情報を参照するサービスコールでは，実行状態 であるものと扱う．

  実行状態のタスクに関する情報を参照するサービスコール（ get_tid ／ iget_tid ， get_did ， sns_tex ）では，強制待ち状態［実行継続中］のタスクが， それを実行するプロセッサにおいて実行状態のタスクであるものと扱う．具体 的には，強制待ち状態［実行継続中］のタスクが実行されている時に get_tid ／ iget_tid を発行すると，そのタスクの ID 番号を参照する．また， get_did を発行 するとそのタスクが属する保護ドメインの ID 番号を， sns_tex を発行するとその タスクのタスク例外処理禁止フラグを参照する．

• (c) その他のサービスコールでは，強制待ち状態であるものと扱う．

  その他のサービスコールでは，強制待ち状態［実行継続中］のタスクは，強制 待ち状態であるものと扱う．

  なお， TOPPERS 新世代カーネルでは，ディスパッチ保留状態において，実行状態 のタスクを強制終了させるサービスコールはサポートしていない．

  【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは，ディスパッチ保留状態において実行状態のタスクを強制待ち 状態へ遷移させるサービスコールはサポートしていないため，タスクが強制待 ち状態［実行継続中］になることはない．

【 TOPPERS/FMP カーネルにおける規定】

FMP カーネルでは，ディスパッチ保留状態に おいて実行状態のタスクを強制待ち 状態へ遷移させるサービスコールを，他のプロセッサから呼び出すことができ るため，タスクが強制待ち状態［実行継続中］になる場合がある．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは，ディスパッチ保留状態において実行状態のタスクを強制待 ち状態へ遷移させるサービスコールはサポートしていないため，タスクが強制 待ち状態［実行継続中］になることはない．

【 TOPPERS/SSP カーネルにおける規定】

SSP カーネルでは，タスクが広義の待ち状態になることはないため，タスクが強 制待ち状態［実行継続中］になることもない．

制約タスク（ restricted task ）は，複数のタスクでスタック 領域を共有するこ とによるメモリ使用量の削減を目的に，通常のタスクに対して，広義の待ち状 態を持たないなどの機能制限を加えたものである．具体的には，制約タスクに は以下の機能制限がある．

• (a) 広義の待ち状態に入ることができない．
• (b) サービスコールにより優先度を変更することができない．
• (c) 対象優先度の中の先頭の タスクが制約タスクである場合には，タスクの優 先順位の回転（ rot_rdq ／ irot_rdq ）を行うことができない．
• (d) マルチプロセッサ対応カーネルでは，割付けプロセッサを変更することが できない．

  制約タスクに対して，機能制限により使用できなくなったサービスコールを呼 び出した場合には， E_NOSPT エラーとなる． E_NOSPT エラーが返ることに依存し ている場合を除いては，制約タスクを通常のタスクに置き換えることができる．

  【未決定事項】

  現状では，制約タスクの優先度を変更するサービスコールは設けていないが， 制約タスクが，自タスクの優先度を，起動時優先度（ SSP カーネルにおいては， 実行時優先度）と同じかそれよりも高い値に変更することは許してもよい．た だし，優先度の変更後は，同じ優先度内で 最高優先順位としなければならない ため， chg_pri とは振舞いが異なることになる．自タスクの優先度を起動時優先 度と同じかそれよりも高い値に変更するサービスコールを設けるかどうかは， 今後の課題である．

  【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは，制約タスクをサポートしていない．ただし，制約タスク拡張 パッケージを用いる と，制約タスクの機能を追加することができる．

【 TOPPERS/FMP カーネルにおける規定】

FMP カーネルでは，制約タスクをサポートしていない．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは，制約タスクをサポートしていない．

【 TOPPERS/SSP カーネルにおける規定】

SSP カーネルでは，制約タスクのみをサポートする．そのため，すべてのタスク と非タスクコンテキストがスタック領域を共有することができ，すべての処理 単位で同一のスタック領域を使用している．このスタック領域を，共有スタッ ク領域と呼ぶ．

【μ ITRON4.0 仕様との関係】

制約タスクは，μ ITRON4.0 仕様の自動車制御プロファイルで導入された機能で ある．この仕様における制約タスクは，μ ITRON4.0 仕様の制約タスクよりも機 能制限が少なくなっている．

周辺デバイス（以下，デバイスと呼ぶ）からの割込み要求は，割込みコントロー ラ（ IRC ）を経由して，プロセッサに伝えられる．デバイスから割込みコントロー ラに割込み要求を伝えるための信号線を，割込み要求ラインと呼ぶ．一般には， 1 つの割込み要求ラインに，複数のデバイスからの割込み要求が接続される．

プロセッサは，デバイスからの割込み要求を受け付ける条件が満たされた場合， 割込み要求を受け付ける．受け付けた割込み要求が，カーネル管理の割込みで ある場合には，カーネル内の割込みハンドラの入口処理（割込み入口処理）を 経由して，カーネル内の割込みハンドラを実行する．

カーネル 内の割込みハンドラは，アプリケーションが割込み要求ラインに対し て登録した割込みサービスルーチン（ ISR ）を呼び出す．割込みサービスルーチ ンは，プロセッサの割込みアーキテクチャや割込みコントローラに依存せず， 割込みを要求したデバイスのみに依存して記述するのが原則である． 1つの割込 み要求ラインに対して複数のデバイスが接続されることから， 1つの割込み要求 ラインに対して複数の割込みサービスルーチンを登録する ことができる．

ただし，カーネルが標準的に用意している割込みハンドラで対応できない特殊 なケースも考えられる．このような場合に対応するために，アプリケーション が用意した割込みハンドラをカーネルに登録することもできる．

カーネルが用いるタイマデバイスからの割込み要求の場合，カーネル内の割込 みハンドラにより，タイムイベントの処理が行われる．具体的には，タイムア ウト処理等が行われることに加えて，アプリケーションが登録したタイムイベ ントハンドラが呼び出される．

なお，受け付けた割込み要求に対して，割込みサービスルーチンも割込みハン ドラも登録していない場合の振舞いは，ターゲット定義である．

割込み要求は，割込み処理の優先順位を指定するための割込み優先度を持つ． プロセッサは，割込み優先度マスクの現在値よりも高い割込み優先度を持つ割 込み要求のみを受け付ける．逆に言うと，割込み優先度マスクの現在値と同じ か，それより低い割込み優先度を持つ割込みは，マスクされる．

プロセッサは，割込み要求を受け付けると，割込み優先度マスクを，受け付け た割込み要求の割込み優 先度に設定する（ただし，受け付けた割込みが NMI であ る場合には例外とする）．また，割込み処理からのリターンにより，割込み優 先度マスクを，割込み要求を受け付ける前の値に戻す．

これらのことから，他の方法で割込みをマスクしていない限り，ある割込み要 求の処理中は，それと同じかそれより低い割込み優先度を持つ割込み要求は受 け付けられず，それより高い割込み優先度を持つ割込み要求は受け付けられ る ことになる．つまり，割込み優先度は，多重割込みを制御するためのものと位 置付けることができる．それに対して，同時に発生している割込み要求の中で， 割込み優先度の高い割込み要求が先に受け付けられるとは限らない．

割込み優先度は， PRI 型で表現し，値が小さいほど優先度が高いものとするが， 優先度に関する原則には従わず， -1から連続した負の値を用いる．

割込み優先度の段階数は，ターゲット定義である．プロセッサが割込み優先度 マスクを実現するための機能を持たないか，実現するために大きいオーバヘッ ドを生じる場合には，ターゲット定義で，割込み優先度の段階数を 1にする（す なわち，多重割込みを許さない）場合がある．

【仕様決定の理由】

割込み優先度に -1から連続した負の値を用いるのは，割込み優先度とタスク優 先度を比較できるようになることと，いずれの割込みもマスクしない割込み優 先度マスクの値を 0にできるためである．

各割込み要求ラインは，以下の属性を持つ．なお， 1つの割込み要求ラインに複 数のデバイスからの割込み要求が接続されている場合，それらの割込み要求は 同一の属性を持つ．それらの割込み要求に別々の属性を設定することはできな い．

• (1) 割込み要求禁止フラグ

  割込み要求ライン毎に，割込みをマスクするための割込み要求禁止フラグを持 つ．割込み要求禁止フラグをセットすると，その割込み要求ラインによって伝 えられる割込み要求はマスクされる．

  プロセッサが割込み 要求禁止フラグを実現するための機能を持たないか，実現 するために大きいオーバヘッドを生じる場合には，ターゲット定義で，割込み 要求禁止フラグをサポートしない場合がある．また，プロセッサの持つ割込み 要求禁止フラグの機能がこの仕様に合致しない場合には，ターゲット定義で， 割込み要求禁止フラグをサポートしないか，振舞いが異なるものとする場合が ある．

  アプリケーションが， 割込み要求禁止フラグを動的にセット／クリアする機能 を用いると，次の理由でソフトウェアの再利用性が下がる可能性があるため， 注意が必要である．プロセッサによっては，この割込み処理モデルに合致した 割込み要求禁止フラグの機能を実現できない場合がある．また，割込み要求禁 止フラグをセットすることで，複数のデバイスからの割込みがマスクされる場 合がある．ソフトウェアの再利用性を上げるためには，あるデバイスからの割 込みのみをマスクしたい場合には，そのデバイス自身の機能を使ってマスクを 実現すべきである．

• (2) 割込み優先度

  割込み要求ライン毎に，割込み優先度を設定することができる．割込み要求の 割込み優先度とは，その割込み要求を伝える割込み要求ラインに対して設定さ れた割込み優先度のことである．

• (3) トリガモ ード

  割込み要求ラインに対する割込み要求が，レベルトリガであるかエッジトリガ であるかを設定することができる．エッジトリガの場合には，さらに，ポジティ ブエッジトリガかネガティブエッジトリガか両エッジトリガかを設定できる場 合もある．また，レベルトリガの場合には，ローレベルトリガかハイレベルト リガかを設定できる場合もある．

  プロセッサがトリガモ ードを設定するための機能を持たないか，設定するため に大きいオーバヘッドを生じる場合には，ターゲット定義で，トリガモードの 設定をサポートしない場合がある．

  属性が設定されていない割込み要求ラインに対しては，割込み要求禁止フラグ がセットされ，割込み要求はマスクされる．また，割込み要求禁止フラグをク リアすることもできない．

NMI 以外の割込み要求は，次の 4つの条件が揃った場合に受け付けられる．

• (a) 割込み要求ラインに対する割込み要求禁止フラグがクリアされていること
• (b) 割込み要求ラインに設定された割込み優先度が，割込み優先度マスクの現 在値よりも高い（優先度の値としては小さい）こと
• (c) 全割込みロックフラグがクリアされていること
• (d) 割込み要求がカーネル管理の割込みである場合には， CPU ロックフラグがク リアされていること

  これらの条件が揃った割込み要求が複数ある場合に，どの割込み要求が最初に 受け付けられるかは，この仕様では規定しない．すなわち，割込み優先度の高 い割込み要求が先に受け付けられるとは限らない．

割込み要求ラインを識別するための番号を，割込み番号と呼ぶ．割込み番号は， 符号無しの整数型である INTNO 型で表し，ターゲットハードウェアの仕様から決 まる自然な番号付けを基本として，ターゲット定義で付与される．そのため， 1 から連続した正の値であるとは限らない．

それに対して，アプリ ケーションが用意した割込みハンドラをカーネルに登録 する場合に，割込みハンドラの登録対象となる割込みを識別するための番号を， 割込みハンドラ番号と呼ぶ．割込みハンドラ番号は，符号無しの整数型である INHNO 型で表し，ターゲットハードウェアの仕様から決まる自然な番号付けを基 本として，ターゲット定義で付与される．そのため， 1から連続した正の値であ るとは限らない．

割 込みハンドラ番号は，割込み番号と 1対 1に対応するのが基本である（両者が 一致する場合が多い）．

ただし，割込みを要求したデバイスが割込みベクタを生成してプロセッサに渡 すアーキテクチャなどでは，割込み番号と割込みハンドラ番号の対応を，カー ネルが管理していない場合がある．そこで，ターゲット定義で，割込み番号に 対応しない割込みハンドラ番号や，割込みハンドラ番号に対応しない割込み番 号を設ける場合もある．ただし，割込みサービスルーチンの登録対象にできる 割込み番号は，割込みハンドラ番号との 1対 1の対応関係をカーネルが管理して いるもののみである．

この節では，マルチプロセッサにおける割込み処理について説明する．この節 の内容は，マルチプロセッサ対応カーネルにのみ適用される．

マルチプロセッサ対応カーネルでは， TOPPERS 標準割込み処理モデルの構成要素 の中で，図 2-4の破線に囲まれた部分はプロセッサ毎に持ち，それ以外の部分は システム全体で 1つのみ持つ．すなわち，全割込みロックフラグ， CPU ロックフ ラグ，割込み優先度マスクはプロセッサ毎に持つのに対して，割込み要求ライ ンおよびその属性（割込み要求禁止フラグ，割込み優先度，トリガモード）は システム全体で共通に持つ．

割込み番号は，割込み要求ラインを識別するための番号であることから，割込 み要求ラインが複数のプロセッサに接続されている場合でも， 1つの割込み要求 ラインには 1つの割込み番号を付与する．逆に，複数のプロセッサが同じ種類の デバイスを持っている場合でも，別のデバイスからの割込み要求ラインには異 なる割込み番号を付与する（図 2-5）．図 2-5において，ローカル IRC は個々のプ ロセッサに対する割込みを制御するための回路であり，グローバル IRC はデバイ スからの割込みをプロセッサに分配するための回路である．グローバル IRC は， 必ず備わっているとは限らない．

割込み要求禁止フラグは，この仕様上はシステム全体で共通に持つこととして いるが，実際のターゲットハードウェア（特に，グローバル IRC を備えていない もの）では，プロセッサ毎に持っている場合がある．そのため，ターゲット定 義で，あるプロセッサで割込み要求禁止フラグを動的にセット／クリアしても， 他のプロセッサに対しては割込みがマスク／マスク解除されない場合があるも のとする．

複数のプロセッサに接続された割込み要求ラインに対して登録された割込みサー ビスルーチンは，それらのプロセッサのいずれによっても実行することが でき る．ただし，その内のどのプロセッサで割込みサービスルーチンを実行するか は，割込みサービスルーチンが属するクラスの割付け可能プロセッサにより決 定される（「 2.4.4 処理単位を実行するプロセッサ」の節を参照）．

割込みサービスルーチンが属するクラスの割付け可能プロセッサは，登録対象 の割込み要求ラインが接続されたプロセッサの集合に含まれていなければなら ない． また，同一の割込み要求ラインに対して登録する割込みサービスルーチ ンは，同一のクラスに属していなければならない．

それに対して，割込みハンドラはプロセッサ毎に登録する．そのため，同じ割 込み要求に対応する割込みハンドラであっても，プロセッサ毎に異なる割込み ハンドラ番号を付与する（図 2-5）．割込みハンドラが属するクラスの初期割付 けプロセッサは，割込みが要求されるプロセッサと一致してい なければならな い．

【補足説明】

マルチプロセッサ対応カーネルにおける割込み番号の付与方法は，複数のプロ セッサに接続された割込み要求ラインに対しては，割込み番号の上位ビットを 0 とし， 1つのプロセッサのみに接続された割込み要求ラインに対しては，割込 み番号の上位ビットに，接続されたプロセッサの ID 番号を含める方法を基本と する．また，割込みハンドラ番号の付与方法は，割込みハンドラ番号の上位ビッ トに，その割込みハンドラを実行するプロセッサの ID 番号を含める方法を基本 とする（図 2-5）．

1 つのプロセッサのみに接続された割込み要求ラインに対して登録された割込み サービスルーチンは，そのプロセッサのみを割付け可能プロセッサとするクラ スに属していなければならない．

【使用上の注意】

複数のプロセッサで実行することができる割込みサービスルーチンは，それら のプロセッサのいずれかで実行されるものと設定した場合でも，複数回の割込 み要求により，異なるプロセッサで同時に実行される可能性がある．

高い割込み応答性を求められるアプリケーションでは，カーネル内で割 込みを マスクすることにより，割込み応答性の要求を満たせなくなる場合がある．こ のような要求に対応するために，カーネル内では，ある割込み優先度（これを， TMIN_INTPRI と書く）よりも高い割込み優先度を持つ割込みをマスクしないこと としている． TMIN_INTPRI を固定するか設定できるようにするか，設定できるよ うにする場合の設定方法は，ターゲット定義である．

TMIN_INTPRI よりも高い割込み優先度を持ち，カーネル内でマスクしない割込み を，カーネル管理外の割込みと呼ぶ．また，カーネル管理外の割込みによって 起動される割込みハンドラを，カーネル管理外の割込みハンドラと呼ぶ． NMI は， カーネル管理外の割込みとして扱う． NMI 以外にカーネル管理外の割込みを設け るか（設けられるようにするか）どうかは，ターゲット定義である．

それに対して， TMIN_INTPRI と同じかそれよりも低い割込み優先度を持つ割込み をカーネル管理の割込み，カーネル管理の割込みによって起動される割込みハ ンドラをカーネル管理の割込みハンドラと呼ぶ．

カーネル管理外の割込みハンドラは，カーネル内の割込み入口処理を経由せず に実行するのが基本である．ただし，すべての割込みで同じ番地に分岐するプ ロセッサでは，カーネル内 の割込み入口処理を全く経由せずにカーネル管理外 の割込みハンドラを実行することができず，入口処理の一部分を経由してカー ネル管理外の割込みハンドラが実行されることになる．

カーネル管理外の割込みハンドラが実行開始される時のシステム状態とコンテ キスト，割込みハンドラの終了時に行われる処理，割込みハンドラの記述方法 は，ターゲット定義である．カーネル管理外の割込みハンドラからは，システ ムインタフェースレイヤの API と sns_ker ， ext_ker のみを呼び出すことができ， その他のサービスコールを呼び出すことはできない．カーネル管理外の割込み ハンドラから，その他のサービスコールを呼び出した場合の動作は，保証され ない．

カーネル管理外の割込みの設定方法は，ターゲット定義で，次の 3つ の方法のい ずれかが採用される．

• (a -1) NMI 以外にカーネル管理外の割込みを設けない
• (a -2) カーネル構築時に特定の割込みをカーネル管理外にすると決める

  これら場合には，カーネル管理外とする割込みはカーネル構築時（ターゲット 依存部の実装時やカーネルのコンパイル時）に決まるため，カーネル管理外と する割込みをアプリケーション側で設定する必要はない．ここで，カーネル管 理外とされた割込みに対して，カーネルの API により割込みハンドラを登録でき るかと，割込み要求ラインの属性を設定できるかは，ターゲット定義である． 割込みハンドラを登録できる場合には，それを定義する API において，カーネル 管理外であることを示す割込みハンドラ属性（ TA_NONKERNEL ）を指定する．ま た，割込み要 求ラインの属性を設定できる場合には，設定する割込み優先度を TMIN_INTPRI よりも高い値とする．

• (b) カーネル管理外とする割込みをアプリケーションで設定できるようにする

  この場合には，カーネル管理外とする割込みの設定は，次の方法で行う．まず， カーネル管理外とする割込みハンドラを定義する API において，カーネル管理外 であることを示す割込みハンドラ属性（ TA_NONKERNEL ）を指定する．また，カー ネル管理外とする割込みの割込み要求ラインに対して設定する割込み優先度を， TMIN_INTPRI よりも高い値とする．

  いずれの場合にも，カーネル管理の割込みの割込み要求ラインに対して設定す る割込み優先度は， TMIN_INTPRI より高い値であってはならない．また，カーネ ル管理外の割込みに対して，割込みサービスルーチンを登録することはでき な い．

アプリケーションは，プロセッサが検出する CPU 例外の種類毎に， CPU 例外ハン ドラを登録することができる．プロセッサが CPU 例外の発生を検出すると，カー ネル内の CPU 例外ハンドラの入口処理（ CPU 例外入口処理）を経由して，発生し た CPU 例外に対して 登録した CPU 例外ハンドラが呼び出される．

CPU 例外ハンドラの登録対象となる CPU 例外を識別するための番号を， CPU 例外ハ ンドラ番号と呼ぶ． CPU 例外ハンドラ番号は，符号無しの整数型である EXCNO 型 で表し，ターゲットハードウェアの仕様から決まる自然な番号付けを基本とし て，ターゲット定義で付与される．そのため， 1から連続した正の値であるとは 限らない．

マルチプロセッサ対応カーネルでは，異なるプロセッサで発生する CPU 例外は， 異なる CPU 例外であると扱う．すなわち，同じ種類の CPU 例外であっても，異な るプロセッサの CPU 例外には異なる CPU 例外ハンドラ番号を付与し，プロセッサ 毎に CPU 例外ハンドラを登録する． CPU 例外ハンドラが属するクラスの初期割付 けプロセッサは， CPU 例外が発生するプロセッサと一致していなければならない．

CPU 例外ハンドラにおいては， CPU 例外が発生した状態からのリカバリ処理を行 う．どのようなリカバリ処理を行うかは，一般には CPU 例外の種類やそれが発生 したコンテキストおよび状態に依存するが，大きく次の 4つの方法が考えられる．

• (a) カーネルに依存しない形で CPU 例外の原因を取り除き，実行を継続する．
• (b) CPU 例外を起こしたタスクよりも優先度の高いタスクを起動ま たは待ち解除 し，そのタスクでリカバリ処理を行う（例えば， CPU 例外を起こしたタスクを強 制終了し，再度起動する）．ただし， CPU 例外を起こしたタスクが最高優先度の 場合には，この方法でリカバリ処理を行うことはできない（リカバリ処理を行 うタスクを最高優先度とし，タスクの起動または待ち解除後に優先順位を回転 させることで，リカバリ処理を行える可能性があるが， CPU 例外を起こしたタス クが制約タスクの場合には適用できないなど，推奨できる方法ではない）．
• (c) CPU 例外を起こしたタスクにタスク例外処理を要求し，タスク例外処理ルー チンでリカバリ処理を行う（例えば， CPU 例外を起こしたタスクを終了する）．
• (d) システム全体に対してリカバリ処理を行う（例えば，システムを再起動す る）．

  この中で (a) と (d) の方法は，カーネルの機能を必要としないため， CPU 例外が発 生したコンテキストおよび状態に依存せずに常に行える．それに対して (b) と

• (c) の方法は， CPU 例外ハンドラからそのためのサービスコールを呼び出せるこ とが必要であり，それが行えるかどうかは， CPU 例外が発生したコンテキストお よび状態に依存する．

  なお，発生した CPU 例外に対して， CPU 例外ハンドラを登録していない場合の 振 舞いは，ターゲット定義である．

  【使用上の注意】

CPU 例外入口処理で CPU 例外が発生し，それを処理するための CPU 例外ハンドラの 入口処理で同じ原因で CPU 例外が発生すると， CPU 例外が繰り返し発生し，アプ リケーションが登録した CPU 例外ハンドラまで処理が到達しない状況が考えられ る．このような状況が発生するかどうかはターゲットによるが， これが許容で きない場合には， CPU 例外入口処理を経由せずに，アプリケーションが用意した CPU 例外ハンドラを直接実行するようにしなければならない．

【補足説明】

マルチプロセッサ対応カーネルにおける CPU 例外ハンドラ番号の付与方法は， CPU 例外ハンドラ番号の上位ビットに，その CPU 例外が発生するプロセッサの ID 番号を含める方法を基本とする．

【μ ITRON4.0 仕様との関係】

μ ITRON4.0 仕様では， CPU 例外からのリカバリ処理の方法については，記述され ていない．

CPU 例外ハンドラからは， CPU 例外発生時のディスパッチ保留状態を参照するサー ビスコール（ xsns_dpn ）と， CPU 例外発生時にタスク例外処理ルーチンを実行開 始できない状態であったかを参照するサービスコール（ xsns_xpn ）を呼び出す ことができる．

xsns_dpn は， CPU 例外がタスクコンテキストで発生し，そのタスクがディスパッ チできる状態であった場合に false を返す． xsns_dpn が false を返した場合，そ の CPU 例外ハン ドラから，非タスクコンテキストから呼び出せるすべてのサービ スコールを呼び出すことができ， (b) の方法によるリカバリ処理が可能である． ただし， CPU 例外を起こしたタスクが最高優先度の場合には，この方法でリカバ リ処理を行うことはできない．

xsns_xpn は， CPU 例外がタスクコンテキストで発生し，そのタスクがタスク例外 処理ルーチンを実行できる状態であった場合に false を返す． xs ns_xpn が false を返した場合，その CPU 例外ハンドラから，非タスクコンテキストから呼び出せ るすべてのサービスコールを呼び出すことができ， (c) の方法によるリカバリ処 理が可能である．

xsns_dpn と xsns_xpn のいずれのサービスコールも true を返した場合，その CPU 例 外ハンドラからは， xsns_dpn と xsns_xpn に加えて，システムインタフェースレ イヤの API と sns_ker ， ext_ker のみを呼び出すことができ，その他のサービスコー ルを呼び出すことはできない．いずれのサービスコールも true を返したにもか かわらず，その他のサービスコールを呼び出した場合の動作は，保証されない． この場合には， (b) と (c) の方法によるリカバリ処理は行うことはできず， (a) ま たは (d) の方法によるリカバリ処理を行うしかないことになる．

【μ ITRON4.0 仕様との関係】

CPU 例外ハンドラで行える操作に関しては，μ ITRON4.0 仕様を見直し，全面的に 修正した．

エラーコードによってアプリケーションに通知できないエラーをカーネルが検 出した場合に，アプリケーションが登録したエラー処理を，カーネルが呼び出 す場合がある．この場合に，カーネルが検出するエラーを CPU 例外と同等に扱う ものとし，エミュレートされた CPU 例外と呼ぶ．また，エラー処理のためのプロ グラムを CPU 例外ハンドラと同等に扱うものとし，エミュレートされた CPU 例外 ハンドラと呼ぶ．

具体的には，エミュレートされた CPU 例外ハンドラに対しても CPU 例外ハンドラ 番号が付与され， CPU 例外ハンドラと同じ方法で登 録できる．また，エミュレー トされた CPU 例外ハンドラからも， CPU 例外ハンドラから呼び出せるサービスコー ルを呼び出すことができ， CPU 例外ハンドラと同様のリカバリ処理を行うことが できる．

【μ ITRON4.0 仕様との関係】

エミュレートされた CPU 例外および CPU 例外ハンドラは，μ ITRON4.0 仕様に定義 されていない概念である．

カーネル内のクリティカルセクションの実行中（これを，カーネル実行中と呼 ぶ），全割込みロック状態， CPU ロック状態，カーネル管理外の割込みハンドラ 実行中のいずれかで発生した CPU 例外を，カーネル管理外の CPU 例外と呼ぶ．ま た，それによって起動される CPU 例外ハンドラを，カーネル管理外の CPU 例外ハ ンド ラと呼ぶ．さらに，カーネル管理外の CPU 例外ハンドラ実行中に発生した CPU 例外も，カーネル管理外の CPU 例外とする．

それに対して，カーネル管理外の CPU 例外以外の CPU 例外をカーネル管理の CPU 例 外，カーネル管理の CPU 例外によって起動される CPU 例外ハンドラをカーネル管 理の CPU 例外ハンドラと呼ぶ．

カーネル管理外の CPU 例外ハンドラからは，システムインタ フェースレイヤの API と sns_ker ， ext_ker ， xsns_dpn ， xsns_xpn のみを呼び出すことができ，その 他のサービスコールを呼び出すことはできない．カーネル管理外の CPU 例外ハン ドラから，その他のサービスコールを呼び出した場合の動作は，保証されない．

カーネル管理外の CPU 例外ハンドラにおいては， xsns_dpn と xsns_xpn のいずれの サービスコールも true を返す．そのため，カーネル管理外の CPU 例外からは，

• (a) または (d) の方法によるリカバリ処理しか行えない．

  【補足説明】

  カーネル管理外の CPU 例外は，カーネル管理外の割込みと異なり，特定の CPU 例 外をカーネル外とするわけではない．同じ CPU 例外であっても， CPU 例外が起こ る状況によって，カーネル管理となる場合とカーネル管理外となる場合がある．

システムのリセット後，最初に実行するプログラムを，スタートアップモジュー ルと呼ぶ．スタートアップモジュールはカーネルの管理外であり，アプリケー ションで用意するのが基本であるが，スタートアップモジュールで行うべき処 理を明確にするために，カーネルの配布パッケー ジの中に，標準のスタートアッ プモジュールが用意されている．

標準のスタートアップモジュールは，プロセッサのモードとスタックポインタ 等の初期化， NMI を除くすべての割込みのマスク（全割込みロック状態と同等の 状態にする），ターゲットシステム依存の初期化フックの呼出し，非初期化デー タセクション（ bss セクション）のクリア，初期化データセクション（ data セク ション ）の初期化，ソフトウェア環境（ライブラリなど）依存の初期化フック の呼出しを行った後，カーネルの初期化処理へ分岐する．ここで呼び出すター ゲットシステム依存の初期化フックでは，リセット後に速やかに行うべき初期 化処理を行うことが想定されている．

マルチプロセッサ対応カーネルでは，すべてのプロセッサがスタートアップモ ジュールを実行し，カーネルの初期化処理へ分岐する．ただし，共有リソース の初期化処理（非初期化データセクションのクリア，初期化データセクション の初期化，ソフトウェア環境依存の初期化フックの呼出しなど）は，マスタプ ロセッサのみで実行する．各プロセッサがカーネルの初期化処理へ分岐するの は，共有リソースの初期化処理が完了した後でなければならないため，スレー ブプロセッサは，カーネルの初期化処理へ分岐する前に，マスタプロセッサに よる共有リソースの初期化処理の完了を待ち合わせる必要がある．

カーネルの初期化処理においては，まず，カーネル自身の初期化処理（カーネ ル内のデータ構造の初期化，カーネルが用いるデバイスの初期化など）と静的 API の処理（オブジェクトの登録など）が行われる．静的 API のパラメータに関 するエラーは，コンフィギュレータによって検出されるのが原則であるが，コ ンフィギュレー タで検出できないエラーが，この処理中に検出される場合もあ る．

静的 API の処理順序によりシステムの規定された振舞いが変化する場合には，シ ステムコンフィギュレーションファイルにおける静的 API の記述順と同じ順序で 静的 API が処理された場合と，同じ振舞いとなる．例えば，静的 API によって同 じ優先度のタスクを複数生成・起動した場合，静的 API の記述順が先のタスクが 高い優先順位を持つ．それに対して，周期ハンドラの動作開始順序は，同じタ イムティックで行うべき処理が複数ある場合の処理順序が規定されないことか ら（「 4.6.1 システム時刻管理」の節を参照），静的 API の記述順となるとは限 らない．

次に，静的 API （ ATT_INI ）により登録した初期化ルーチンが，システムコンフィ ギュレーションファイルにおける静的 API の記述順と同じ順序で実行される ．

マルチプロセッサ対応カーネルでは，すべてのプロセッサがカーネル自身の初 期化処理と静的 API の処理を完了した後に，マスタプロセッサがグローバル初期 化ルーチンを実行する．グローバル初期化ルーチンの実行が完了した後に，各 プロセッサは，自プロセッサに割り付けられたローカル初期化ルーチンを実行 する．すなわち，ローカル初期化ルーチンは，初期割付けプロセッサにより実 行される．

以上が終了すると，カーネル非動作状態から動作状態に遷移し（「 2.5.1 カー ネル動作状態と非動作状態」の節を参照），カーネルの動作が開始される．具 体的には，システム状態が，全割込みロック解除状態・ CPU ロック解除状態・割 込み優先度マスク全解除状態・ディスパッチ許可状態に設定され（すなわち， 割込みがマスク解除され），タスクの実行が開始される．

マルチプロセッサ対応カーネルでは，すべてのプロセッサがローカル初期化ルー チンの実行を完了した後に，カーネル非動作状態から動作状態に遷移し，カー ネルの動作が開始される．マルチプロセッサ対応カーネルにおけるシステム初 期化の流れと，各プロセッサが同期を取るタイミングを，図 2-6に示す．

【μ ITRON4.0 仕様との関係】

μ ITRON4.0 仕様においては，初期化ルーチンの実行は静的 API の処理に含まれる ものとしていたが，この仕様では，初期化ルーチンを登録する静的 API の処理は， 初期化ルーチンを登録することのみを意味し，初期化ルーチンの実行は含まな いものとした．

カーネルを終了させるサービスコール（ ext_ker ）を呼び出すと，カ ーネル動作 状態から非動作状態に遷移する（「 2.5.1 カーネル動作状態と非動作状態」の 節を参照）．具体的には， NMI を除くすべての割込みがマスクされ，タスクの実 行が停止される．

マルチプロセッサ対応カーネルでは，カーネルを終了させるサービスコール （ ext_ker ）は，どのプロセッサからでも呼び出すことができる． 1つのプロセッ サでカーネルを終了させるサービスコールを呼び出すと，そのプロセッサがカー ネル動作状態から非動作状態に遷移した後，他のプロセッサに対してカーネル 終了処理の開始を要求する．複数のプロセッサから，カーネルを終了させるサー ビスコール（ ext_ker ）を呼び出してもよい．

次に，静的 API （ ATT_TER ）により登録した終了処理ルーチンが，システムコン フィギュレーション ファイルにおける静的 API の記述順と逆の順序で実行される．

マルチプロセッサ対応カーネルでは，すべてのプロセッサがカーネル非動作状 態に遷移した後に，各プロセッサが，自プロセッサに割り付けられたローカル 終了処理ルーチンを実行する．すなわち，ローカル終了処理ルーチンは，初期 割付けプロセッサにより実行される．すべてのプロセッサでローカル処理ルー チンの実行が完了した後に，マスタプロセッサ がグローバル終了処理ルーチン を実行する．

以上が終了すると，ターゲットシステム依存の終了処理が呼び出される．ター ゲットシステム依存の終了処理は，カーネルの管理外であり，アプリケーショ ンで用意するのが基本であるが，カーネルの配布パッケージの中に，ターゲッ トシステム毎に標準的なルーチンが用意されている．標準のターゲットシステ ム依存の終了処理では，ソフトウェア環境 （ライブラリなど）依存の終了処理 フックを呼び出す．

マルチプロセッサ対応カーネルでは，すべてのプロセッサで，ターゲットシス テム依存の終了処理が呼び出される．マルチプロセッサ対応カーネルにおける システム終了処理の流れと，各プロセッサが同期を取るタイミングを，図 2-7に 示す．

【使用上の注意】

マルチプロセッサ対応カーネルで，あるプロセッサからカーネルを終了させる サービスコール（ ext_ker ）を呼び出しても，他のプロセッサがカーネル動作状 態で割込みをマスクしたまま実行し続けると，カーネルが終了しない．

プロセッサが割込みをマスクしたまま実行し続けないようにするのは，アプリ ケーションの責任である．例えば，ある時間を超えて割込みをマスクしたまま 実行し続 けていないかを，ウォッチドッグタイマを用いて監視する方法が考え られる．割込みをマスクしたまま実行し続けていた場合には，そのプロセッサ からもカーネルを終了させるサービスコール（ ext_ker ）を呼び出すことで，カー ネルを終了させることができる．

【μ ITRON4.0 仕様との関係】

μ ITRON4.0 仕様には，システム終了に関する規定はない．

ID 番号で識別するオブジェクトは，オブジェクトを生成する静的 API （ CRE_YYY ），サービスコール（ acre_yyy ），またはオブジェクトを追加す る静的 API （ ATT_YYY ， ATA_YYY ）によってカーネルに登録する．オブジェクトを 追加する静的 API によって登録されたオブジェクトは ID 番号を持たないため， ID 番号を指定して操作することができない．

オブジェクトを生成する静的 API （ CRE_YYY ）は，生成するオブジェクトに ID 番 号を割り付け， ID 番号を指定するパラメータとして記述した識別名を，割り付 けた ID 番号にマクロ定義する．同じ識別名のオブジェクトが生成済みの場合に は， E_OBJ エラーとなる．

オブジェクトを生成するサービスコール（ acre_yyy ）は，割付け可能な ID 番号 の数を指定する静的 API （ AID_YYY ）によって確保された ID 番号の中から，使用 されていない ID 番号を 1つ選び，生成するオブジェクトに割り付ける．割り付け た ID 番号は，サービスコールの返値としてアプリケーションに通知する．使用 されていない ID 番号が残っていない場合には， E_NOID エラーとなる．

割付け可能な ID 番号の数を指定する静的 API （ AID_YYY ）は，システムコンフィ ギュレーションファイル中に複数記述することができる．その場合，各静的 API で指定した数の合計の数の ID 番号が確保される．

オブジェクトを生成するサービスコール（ acre_yyy ）によって登録したオブジェ クトは，オブジェクトを削除するサービスコール（ del_yyy ）によって登録を解 除 することができる．登録解除したオブジェクトの ID 番号は，未使用の状態に 戻され，その ID 番号を用いて新しいオブジェクトを登録することができる．こ の場合に，登録解除前のオブジェクトに対して行うつもりの操作が，新たに登 録したオブジェクトに対して行われないように，注意が必要である．

オブジェクトを生成または追加する静的 API によって登録したオブジェクトは， 登録を解除することができない．登 録を解除しようとした場合には， E_OBJ エラー となる．

タスク以外の処理単位は，その処理単位が実行されている間でも，登録解除す ることができる．この場合，登録解除された処理単位に実行が強制的に終了さ せられることはなく，処理単位が自ら実行を終了するまで，処理単位の実行は 継続される．

同期・通信オブジェクトを削除した時に，そのオブジェクトを待っ ているタス クがあった場合，それらのタスクは待ち解除され，待ち状態に遷移させたサー ビスコールは E_DLT エラーとなる．複数のタスクが待ち解除される場合には，待 ち行列につながれていた順序で待ち解除される．削除した同期・通信オブジェ クトが複数の待ち行列を持つ場合には，別の待ち行列で待っていたタスクの間 の待ち解除の順序は，該当するサービスコール毎に規定する．

オブジェクトを再初期化するサービスコール（ ini_yyy ）は，指定したオブジェ クトを削除した後に，同じパラメータで再度生成したのと等価の振舞いをする． ただし，オブジェクトを生成または追加する静的 API によって登録したオブジェ クトも，再初期化することができる．

なお，動的生成対応カーネル以外では，オブジェクトを生成するサービスコー ル（ acre_yyy ），割付け可 能な ID 番号の数を指定する静的 API （ AID_YYY ），オ ブジェクトを削除するサービスコール（ del_yyy ）は，サポートされない．

【μ ITRON4.0 仕様との関係】

ID 番号を指定してオブジェクトを生成するサービスコール（ cre_yyy ）を廃止し た．また，オブジェクトを生成または追加する静的 API によって登録したオブジェ クトは，登録解除できないこととした．

μ ITRON4.0 仕様では，割付け可能な ID 番号の数を指定する静的 API （ AID_YYY ） は規定されていない．

複数の待ち行列を持つ同期・通信オブジェクトを削除した時に，別の待ち行列 で待っていたタスクの間の待ち解除の順序は，μ ITRON4.0 仕様では実装依存と されている．

【μ ITRON4.0/PX 仕様との関係】

アクセス許可ベクタを指定してオブジェクトを生成する静的 API （ CRA_YYY ）は 廃止し，オブジェクトの登録後にアクセス許可ベクタを設定する静的 API （ SAC_YYY ）をサポートすることとした．これにあわせて，アクセス許可ベ クタを指定してオブジェクトを登録するサービスコール（ cra_yyy ， acra_yyy ， ata_yyy ）も廃止した．

【仕様決定の理由】

ID 番号を指定してオブジェクトを生成するサービスコール（ cre_yyy ）とアクセ ス許可ベクタを指定してオブジェクトを登録するサービスコール（ cra_yyy ， acra_yyy ， ata_yyy ）を廃止したのは，必要性が低いと考えたためである． 静的 API についても，サービスコールに整合するよう変更した．

オブジェクト番号で識別するオブジェクトは，オブジェクトを定義する静的 API （ DEF_YYY ）またはサービスコール（ def_yyy ）によってカーネルに登録する．

オブジェクトを定義するサービスコール（ def_yyy ）によって登録したオブジェ クトは，同じサービスコールを，オブジェクトの定義情報を入れたパケットへ のポインタを NULL と して呼び出すことによって，登録を解除することができる． 登録解除したオブジェクト番号は，オブジェクト登録前の状態に戻され，同じ オブジェクト番号に対して新たにオブジェクトを定義することができる．登録 解除されていないオブジェクト番号に対して再度オブジェクトを登録しようと した場合には， E_OBJ エラーとなる．

オブジェクトを定義する静的 API によって登録したオブジェクトは，登録を解除 することができない．登録を解除しようとした場合には， E_OBJ エラーとなる．

なお，動的生成対応カーネル以外では，オブジェクトを定義するサービスコー ル（ def_yyy ）はサポートされない．

【μ ITRON4.0 仕様との関係】

この仕様では，オブジェクトの定義を変更したい場合には，一度登録解除した 後に，新たにオブジェクトを定義する必要がある．また，オブジェクトを定義 する静的 API によって登録したオブジェクトは，この仕様では，登録解除できな いこととした．

識別する必要がないために，識別番号を持たないオブジェクトは，オブジェク トを追加する静的 API （ ATT_YYY ）によってカーネルに登録する ．

カーネルオブジェクトを生成する際に，サイズが一定でないメモリ領域を必要 とする場合には，カーネルオブジェクトを生成する静的 API およびサービスコー ルに，使用するメモリ領域の先頭番地を渡すパラメータを設けている．このパ ラメータを NULL とした場合，必要なメモリ領域は，コンフィギュレータまたは カーネルにより確保される．

オブジェクト生成に必要なメモリ領域の中で，カーネルの内部で用いるものを， カーネルの用いるオブジェクト管理領域と呼ぶ．この仕様では，以下のメモリ 領域が，カーネルの用いるオブジェクト管理領域に該当する．

• ・データキュー管理領域
• ・優先度データキュー管理領域
• ・優先度別のメッセージキューヘッダ領域
• ・固定長メモリプール管理領域

【補足説明】

カーネルオブジェクトを生成する際には，管理ブロックなどを置くためのメモ リ領域も必要になるが，サイズが一定のメモリ領域はコンフィギュレータによ り確保されるため，カーネルオブジェクトを生成する静的 API およびサービスコー ルにそれらのメモリ領域の先頭番地を渡すパラメータを設けていない．

保護機能対応カーネルにおいて，カーネルオブジェクトが属する保護ドメイン は，オブジェクトの登録時に決定し，登録後に変更することはできない．

カーネルオブジェクトを静的 API によって登録する場合には，オブジェクトを登 録する静的 API を，そのオブジェクトを属させる保護ドメインの囲みの中に記述 する．無所属のオブジェクトを登録する静的 API は，保護ドメインの囲みの外に 記述する（「 2.12.3 保護ドメインの指定」の節を参照）．

カーネルオブジェクトをサービスコールによって登録する場合には，オブジェ クト属性に TA_DOM(domid) を指定することにより，オブジェクトを属させる保護 ドメインを設定する．ここで domid は，そのオブジェクトを属させる保護ドメイ ンの ID 番号であり， TDOM_KERNEL （＝ -1）を指定することでカーネルドメインに 属させることができる．また， domid に TDOM_SELF （＝ 0）を指定するか，オブジェ クト属性に TA_DOM(domid) を指定しないことで，自タスクが属する保護ドメイン に属させることができる．さらに，無所属のオブジェクトを登録する場合には， domid に TDOM_NONE （＝ -2）を指定する．

ただし，特定の保護ドメインのみに属することができるカーネルオブジェクト を登録するサービスコールの中には，オブジェクトを属させる保護ドメインを オブジェクト属性で設定する必要がないものもある．

割付け可能な ID 番号の数を指定する静的 API （ AID_YYY ）で確保した ID 番号は， どの保護ドメインに属するオブジェクトにも（また，無所属のオブジェクトに も）割り付けられる ．これらの静的 API は，保護ドメインの囲みの外に記述しな ければならない．保護ドメインの囲みの中に記述した場合には， E_RSATR エラー となる．

【補足説明】

この仕様では，カーネルオブジェクトの属する保護ドメインを参照する機能は 用意していない．

【仕様決定の理由】

カーネルオブ ジェクトをサービスコールによって登録する場合に，オブジェク トを属させる保護ドメインをオブジェクト属性で指定することにしたのは，保 護機能対応でないカーネルとの互換性のためには，サービスコールのパラメー タを増やさない方が望ましいためである．

マルチプロセッサ対応カーネルにおいて，カーネルオブジェクトが属するクラ スは，オブジェクトの登録時に決定し，登録後に変更することはできない．

カーネルオブジェクトを静的 API によって登録する場合には，オブジェクトを登 録する静的 API を，そのオブジェクトを属させるクラスの囲みの中に記述する． クラスに属さないオブジェクトを登録する静的 API は，クラスの囲みの外に記述 する（「 2.12.4 クラスの指定」の節を参照）．

カーネルオブジェクトをサービスコールによって登録する場合には，オブジェ クト属性に TA_CLS(clsid) を指定することにより，オブジェクトを属させるクラ スを設定する．ここで clsid は，そのオブジェクトを属させるクラスの ID 番号で あり， clsid に TCLS_SELF （＝ 0）を指定するか，オブジェクト属性に TA_CLS(clsid) を指定しないことで，自タスクが属するクラスに属させることが できる．

割付け可能な ID 番号の数を指定する静的 API （ AID_YYY ）で確保した ID 番号は， 静的 API を囲むクラスに属するオブジェクトにのみ割り付けられる．これらの静 的 API は，確保した ID 番号を割り付けるオブジェクトの属すべきクラスの囲みの 中に記述しなければならない．クラスの囲みの外に記述した場合には， E_RSATR エラーとなる．

【補足説明】

この仕様では，カーネルオブジェクトの属するクラスを参照する機能は用意し ていない．

【仕様決定の理由】

カーネルオブジェクトをサービスコールによって登録する場合に，オブジェク トを属させるクラスをオブジェクト属性で指定することにしたのは，マルチプ ロセッサ対応でないカーネルとの互換性のためには，サービス コールのパラメー タを増やさない方が望ましいためである．

ID 番号で識別するオブジェクトのすべてと，オブジェクト番号で識別するオブ ジェクトの一部に対して，オブジェクトの状態を参照するサービスコール （ ref_yyy ， get_yyy ）を用意する．

オブジェクトの状態を参照するサービスコールでは，オブジェクトの登録時に 指定し，その後に変化しない情報（例えば，タスクのタスク属性や初期優先度） を参照するための機能は用意しないことを原則とする．自タスクの拡張情報の 参照するサービスコール（ get_inf ）は，この原則に対する例外である．

カーネルオブジェクトに対するアクセスは，そのオブジェクトに対して設定さ れたアクセス許可ベクタによって保護される．ただし，アクセス許可ベクタを 持たないオブジェクトに対するアクセスは，システム状態に対する アクセス許 可ベクタによって保護される．また，オブジェクトを登録するサービスコール と，特定のオブジェクトに関連しないシステムの状態に対するアクセスについ ては，システム状態のアクセス許可ベクタによって保護される．

アクセス許可ベクタによって許可されていないアクセス（アクセス違反）は， カーネルによって検出され，以下の方法によって通知される．

サ ービスコールにより，メモリオブジェクト以外のカーネルオブジェクトに対 して，許可されていないアクセスを行おうとした場合，サービスコールから E_OACV エラーが返る．また，メモリオブジェクトに対して，許可されていない 管理操作または参照操作を行おうとした場合も，サービスコールから E_OACV エ ラーが返る．

メモリオブジェクトに対して，通常のメモリアクセスにより，許可されていな い書込みアクセスまたは読出しアクセス（実行アクセスを含む）を行おうとし た場合， CPU 例外ハンドラが起動される．どの CPU 例外ハンドラが起動されるか は，ターゲット定義である．ターゲットによっては，エミュレートされた CPU 例 外ハンドラの場合もある．また，ターゲット定義で，アクセス違反の状況に応 じて異なる CPU 例外ハンドラが起動される場合もある．この（これらの） CPU 例 外ハンドラを，メ モリアクセス違反ハンドラと呼ぶ．

メモリオブジェクトに対して，サービスコールを通じて，許可されていない書 込みアクセスまたは読出しアクセスを行おうとした場合，サービスコールから E_MACV エラーが返るか，メモリアクセス違反ハンドラが起動される． E_MACV エ ラーが返るかメモリアクセス違反ハンドラされるかは，ターゲット定義である．

メモリアクセス違反ハンドラでは， アクセス違反を発生させたアクセスに関す る情報（アクセスした番地，アクセスの種別，アクセスした命令の番地など） を参照する方法を，ターゲット定義で用意する．

メモリオブジェクトとしてカーネルに登録されていないメモリ領域に対して， カーネルドメイン以外の保護ドメインから，書込みアクセスまたは読出しアク セス（実行アクセスを含む）を行おうとした場合には，メモリオブジェクトに 対するアクセスが許可されていない場合と同様に扱われる．

【未決定事項】

マルチプロセッサ対応カーネルにおいて，システム状態のアクセス許可ベクタ をシステム全体で 1つ持つかプロセッサ毎に持つかは，今後の課題である．

【μ ITRON4.0/PX 仕様との関係】

μ ITRON4.0/PX 仕様では，アクセス保護の実装定義の制限について規定している が，この仕様では，メモリオブジェクトに対するアクセス許可ベクタのターゲッ ト定義の制限以外については規定していない．

【仕様決定の理由】

オブジェクトを登録するサービスコールを，そのオブジェクトのアクセス許可 ベクタによって保護しないのは，オブジェクトを登録する前 には，アクセス許 可ベクタが設定されていないためである．

メモリオブジェクトの書込みアクセスと読出しアクセス（実行アクセスを含む） に対して設定できるアクセス許可パターンは，ターゲット定義で制限される場 合がある．

ただし，少なくとも，次の 5つの組み合わせの設 定は，行うことができる．

• (a) メモリオブジェクトが属する保護ドメインのみに，読出しアクセス（実行 アクセスを含む）のみを許可する．これを，専有リードオンリー（ private read only ）と呼ぶ．
• (b) メモリオブジェクトが属する保護ドメインのみに，書込みアクセスと読出 しアクセス（実行アクセスを含む）を許可する．これを，専有リー ドライ ト（ private read/write ）と呼ぶ．
• (c) すべての保護ドメインに，読出しアクセス（実行アクセスを含む）のみを 許可する．これを，共有リードオンリー（ shared read only ）と呼ぶ．
• (d) すべての保護ドメインに，書込みアクセスと読出しアクセス（実行アクセ スを含む）を許可する．これを，共有リードライト（ shared read/write ） と呼ぶ．
• (e) メモリオブジェクトが属する保護ドメインに，書込みアクセスと読出しア クセス（実行アクセスを含む）を許可し，他の保護ドメインには，読出し アクセス（実行アクセスを含む）のみを許可する．これを，共有リード専 有ライト（ shared read private write ）と呼ぶ．

また，ターゲット定義で， 1つの保護ドメインに登録できるメモリオブジェクト の数が制限される場合がある．

静的 API によりカーネルオブジェクトを登録した直後は，次に規定されるデフォ ルトのアクセス許可ベクタが設定される．

保護ドメインに属するカーネルオブジェクトに対しては， 4つの種別のアクセス がいずれも，その保護ドメインのみに許可される．すなわち，カーネルドメイ ンに属するオブジェクトに対しては， 4つのアクセス許可パターンがいずれも TACP_KERNEL に，ユーザドメインに属するオブジェクトに対しては， 4つのアク セス許可パターンがいずれも TACP(domid) （ domid はオブジェクトが属する保護 ド メインの ID 番号）に設定される．

無所属のカーネルオブジェクトに対しては， 4つの種別のアクセスがいずれも， すべての保護ドメインに許可される．すなわち， 4つのアクセス許可パターンが いずれも， TACP_SHARED に設定される．

システム状態のアクセス許可ベクタは， 4つの種別のアクセスがいずれも，カー ネルドメインのみに許可される．すなわち， 4つのアクセス許可パターンがいず れも， TACP_KERNEL に設定される．

【未決定事項】

サービスコールによりカーネルオブジェクトを登録した直後のアクセス許可ベ クタについては，今後の課題である．

ア クセス許可ベクタをデフォルト以外の値に設定するために，カーネルオブジェ クトのアクセス許可ベクタを設定する静的 API （ SAC_YYY ）とサービスコール （ sac_yyy ）が用意されている．また，システム状態のアクセス許可ベクタを設 定する静的 API （ SAC_SYS ）とサービスコール（ sac_sys ）が用意されている．

ただし，静的 API によって登録したオブジェクトは，サービスコール（ sac_yyy ） によってアクセス許可ベクタを設定することができない．アクセス許可ベクタ を設定しようとした場合には， E_OBJ エラーとなる．

メモリオブジェクトに対しては，アクセス許可ベクタを設定する静的 API は用意 されておらず，オブジェクトの登録と同時にアクセス許可ベクタを設定する静 的 API （ ATA_YYY ）が用意されている．

オブジェクトに対するアクセスが許可 されているかは，そのオブジェクトにア クセスするサービスコールを呼び出した時点でチェックされる．そのため，ア クセス許可ベクタを変更しても，変更以前に呼び出されたサービスコールの振 舞いには影響しない．例えば，待ち行列を持つ同期・通信オブジェクトのアク セス許可ベクタを変更しても，呼び出した時点ですでに待ち行列につながれて いるタスクには影響しない．また，ミューテックスのアクセス許可ベクタを変 更しても，呼び出した時点ですでにミューテックをロックしていたタスクには 影響しない．

なお，動的生成対応カーネル以外では，アクセス許可ベクタを設定するサービ スコール（ sac_yyy ）はサポートされない．

この仕様では，カーネルオブジェクトに設定されたアクセス許可ベクタを参照 する機能は用意していない．

【μ ITRON4.0/PX 仕様との関係】

アクセス許可ベクタを指定してオブジェクトを生成する静的 API （ CRA_YYY ）は 廃止し，オブジェクトの登録後にアクセス許可ベクタを設定する静的 API （ SAC_YYY ）をサポートすることとした．

静的 API によって登録したオブジェクトは，サービスコール（ sac_yyy ）によっ てアクセス許可ベクタを設定することができないこ ととした．

オブジェクトの状態参照するサービスコール（ ref_yyy ）により，オブジェクト に設定されたアクセス許可ベクタを参照する機能サポートしないこととした． これは，オブジェクトの登録時に指定し，その後に変化しない情報を参照する ための機能は用意しないという原則に合わせるための修正である．

カーネルが動作するために，カーネルの内部で用いるメモリ領域を，カーネル の管理領域と呼ぶ．ユーザタスクからカーネルを保護するためには，カーネル の管理領域にアクセスできるのは，カーネルドメインのみでなければならない． そのため，カーネルの管理領域は， 4つの種別のアクセスがカーネルドメインの みに許可されたメモリオブジェクト（これを，カーネル専用のメモリオブジェ クトと呼ぶ）の中に置かれる．

カーネルの用いるオブジェクト管理領域（カーネルの管理領域に該当する． 「 2.10.4 オブジェクト生成に必要なメモリ領域」の節を参照）として，カーネ ル専用のメモリオブジェクトに含まれないメモリ領域を指定した場合， E_OBJ エ ラーとなる．また，カーネルの用いるオブジェクト管理領域の先頭番地に NULL を指定した場合，必要なメモリ領域が，カーネル専用のメモリオブジェクトの 中に確保される．

システムタスクのスタック領域，ユーザタスクのシステムスタック領域，非タ スクコンテキスト用のスタック領域は，カーネルの用いるオブジェクト管理領 域には該当しないが，カーネルドメインの実行中にのみアクセスされるため， カーネルの用いるオブジェクト管理領域と同様の扱いとなる．一方，ユーザタ スクのユーザスタック領域と固定長メモリプール領域は，ユーザドメインの実 行中にもアクセスされるため，カーネルの用いるオブジェクト管理領域とは異 なる扱いとなる．

ユーザタスクが非特権モードで実行する間に用いるスタック領域を，システム スタック領域（「 4.1 タスク管理機能」の節を参照）と対比させて，ユーザス タック領域と呼ぶ．ユーザスタック領域は，そのタスクと同じ保護ドメイ ンに 属する 1つのメモリオブジェクトとしてカーネルに登録されるが，他のメモリオ ブジェクトとは異なり，次のように扱われる．

タスクのユーザスタック領域に対しては，そのタスクのみが書込みアクセスお よび読出しアクセスを行うことができる．そのため，書込みアクセスと読出し アクセス（実行アクセスを含む）に対するアクセス許可パターンは意味を持た ない．ユーザスタック領域に対して実行アクセスを行えるかどうかは，ターゲッ ト定義である．

ただし，上記の仕様を実現するために大きいオーバヘッドを生じる場合には， ターゲット定義で，タスクのユーザスタック領域を，そのタスクが属する保護 ドメインのみからアクセスできるものとする場合がある．

【μ ITRON4.0/PX 仕様との関係】

この仕様では，タスクのユーザスタック領域は，そのタスクのみがアクセスで きるものとした．

カーネルやシステムサービスが管理するオブジェクトの生成情報や初期状態な どを記述するファイルを，システムコンフィギュレーションファイ ル（ system configuration file ）と呼ぶ．また，システムコンフィギュレーションファイ ルを解釈して，カーネルやシステムサービスの構成・初期化情報を含むファイ ルなどを生成するツールを，コンフィギュレータ（ configurator ）と呼ぶ．

システムコンフィギュレーションファイルには，カーネルの静的 API ，システム サービスの静的 API ，保護ドメインの囲み，クラスの囲 み，コンフィギュレータ に対する INCLUDE ディレクティブ， C言語プリプロセッサのインクルードディレ クティブ（ #include ）と条件ディレクティブ（ #if ， #ifdef など）のみを記述す ることができる．

コンフィギュレータに対する INCLUDE ディレクティブは，システムコンフィギュ レーションファイルを複数のファイルに分割して記述するために用いるもので， その文法は次のいずれかである（両者の違いは，指定されたファイルを探すディ レクトリの違いのみ）．

INCLUDE(" ファイル名 "); INCLUDE(< ファイル名 >);

コンフィギュレータは， INCLUDE ディレクティブによって指定されたファイル中 の記述を，システムコンフィギュレーションファイルの一部分として解釈する． すなわち， INCLUDE ディレクティブによって指定されたファイル中には，カーネ ルの静的 API ，システムサービスの静的 API ，コンフィギュレータに対する INCLUDE ディレクティブ， C言語プリプロセッサのインクルードディレクティブ と条件ディレクティブのみを記述することができる．

C 言語プリプロセッサのインクルードディレクティブは，静的 API のパラメータ を解釈するために必 要な C言語のヘッダファイルを指定するために用いる．また， 条件ディレクティブは，有効とする静的 API を選択するために用いることができ る．ただし，インクルードディレクティブは，コンフィギュレータが生成する ファイルでは先頭に集められる．そのため，条件ディレクティブの中にインク ルードディレクティブを記述しても，インクルードディレクティブは常に有効 となる．また， 1つの静的 API の記述の途中に，条件ディレクティ ブを記述する ことはできない．

コンフィギュレータは，システムコンフィギュレーションファイル中の静的 API を，その記述順に解釈する．そのため例えば，タスクを生成する静的 API の 前に，そのタスクにタスク例外処理ルーチンを定義する静的 API が記述されてい た場合，タスク例外処理ルーチンを定義する静的 API が E_NOEXS エラーとなる．

【μ ITRON4.0 仕様との関係】

システムコンフィギュレーションファイルにおける C言語プリプロセッサのディ レクティブの扱いを全面的に見直し，コンフィギュレータに対する INCLUDE ディ レクティブを設けた．また，共通静的 API を廃止した．μ ITRON4.0 仕様における

静的 API は，次に述べる例外を除いては， C言語の関数呼出しと同様の文法で記 述する．すなわち，静的 API の名称に続けて，静的 API の各パラメータを "," で区 切って列挙したものを "(" と ")" で 囲んで記述し，最後に ";" を記述する．ただし， 静的 API のパラメータに構造体（または構造体へのポインタ）を記述する場合に は，構造体の各フィールドを "," で区切って列挙したものを "{" と "}" で囲んだ形 で記述する．

サービスコールに対応する静的 API の場合，静的 API のパラメータは，対応する サービスコールのパラメータと同一とすることを原則とする．

静的 API のパラメータは，次の 4種類に分類される．

• (a) オブジェクト識別名

  オブジェクトの ID 番号を指定するパラメータ．オブジェクトの名称を表す単一 の識別名のみを記述することができる．

  コンフィギュレータは，オブジェクト生成のための静的 API （ CRE_YYY ）を処理 する際に，オブジェクトに ID 番号を割り付け，構成・初期化ヘッダファイルに， 指定された識別名を割り付けた ID 番号にマクロ定義する C言語プリプロセッサの ディレクティブ（ #define ）を生成する．

  オブジェクト生成以外の静的 API が，オブジェクトの ID 番号をパラメータに取る 場合（カーネルの静的 API では， SAC_TSK や DEF_TEX の tskid パラメータ等がこれ に該当する）には，パラメータとして記述する識別名は，生成済みのオブジェ クトの名称を表す識別名でなければならない．そうでない場合には，コンフィ ギュレータがエラーを報告する．

  静的 API の整数定数式パラメータの記述に，オブジェクト識別名を使用すること はできない．

• (b) 整数定数式パラメータ

  オブジェクト番号や機能コード， オブジェクト属性，サイズや数，優先度など， 整数値を指定するパラメータ．プログラムが配置される番地に依存せずに値の 決まる整数定数式を記述することができる．

  整数定数式の解釈に必要な定義や宣言等は，システムコンフィギュレーション ファイルから C言語プリプロセッサのインクルードディレクティブによってイン クルードするファイルに含まれていなければならない．

• (c) 一般定数式パラメータ

  処理単位のエントリ番地，メモリ領域の先頭番地，拡張情報など，番地を指定 する可能性のあるパラメータ．任意の定数式を記述することができる．

  定数式の解釈に必要な定義や宣言等は，システムコンフィギュレーションファ イルから C言語プリプロセッサのインクルードディレクティブによってインクルー ドするファイルに含まれていなければならない．

• (d) 文字列パラメータ

  オブジェクトモジュール名やセクション名など，文字列を指定するパラメータ． 任意の文字列を， C言語の文字列の記法で記述することができる．

  【μ ITRON4.0 仕様との関係】

  μ ITRON4.0 仕様においては，静的 API のパラメータを次 の 4種類に分類していた が，コンフィギュレータの仕組みを見直したことに伴い全面的に見直した．

• (A) 自動割付け対応整数値パラメータ
• (B) 自動割付け非対応整数値パラメータ
• (C) プリプロセッサ定数式パラメータ
• (D) 一般定数式パラメータ

  この仕様の (a) が，おおよそμ ITRON4.0 仕様の (A) に相当するが， (a) には整数値 を記述できない点が異なる． (b) ～ (c) と (B) ～ (D) の間には単純な対応関係がな いが，記述できる定数式の範囲には， (B) ⊂ (C) ⊂ (b) ⊂ (c) ＝ (D) の関係がある．

  μ ITRON4.0 仕様では，静的 API のパラメータは基本的には (D) とし，コンフィギュ レータが値を知る必要があるパラメータを (B) ，構成・初期化ファイルに生成す る C言語プリプロセッサの条件ディレクティブ（ #if ）中に含めたい可 能性のあ るパラメータを (C) としていた．

  それに対して，この仕様におけるコンフィギュレータの処理モデル（「 2.12.5 コンフィギュレータの処理モデル」の節を参照）では，コンフィギュレータの パス 2において定数式パラメータの値を知ることができるため， (B) ～ (D) の区別 をする必要がない．そのため，静的 API のパラメータは基本的には (b) とし，パ ス 2で値を知ることのできない定数式パラメータのみを (c) としている．

保護機能対応カーネルでは，オブジェクトを登録する静的 API 等を，そのオブジェ クトが属する保護ドメインの囲みの中に記述する．無所属のオブジェクトを登 録する静的 API は，保護ドメインの囲みの外に記述する．保護ドメインに属すべ きオブジェクトを登 録する静的 API 等を，保護ドメインの囲みの外に記述した場 合には，コンフィギュレータが E_RSATR エラーを報告する．

ユーザドメインの囲みの文法は次の通り．

DOMAIN( 保護ドメイン名 ) { ユーザドメインに属するオブジェクトを登録する静的 API 等 }

保護ドメイン名には，ユーザドメインの 名称を表す単一の識別名のみを記述す ることができる．

コンフィギュレータは，ユーザドメインの囲みを処理する際に，ユーザドメイ ンに保護ドメイン ID を割り付け，構成・初期化ヘッダファイルに，指定された 保護ドメイン名を割り付けた保護ドメイン ID にマクロ定義する C言語プリプロセッ サのディレクティブ（ #define ）を生成する．また，ユーザドメインの囲みの中 およびそれ以 降に記述する静的 API の整数定数式パラメータの記述に保護ドメイ ン名を記述すると，割り付けた保護ドメイン ID の値に評価される．

ユーザドメインの囲みの中を空にすることで，ユーザドメインへの保護ドメイ ン ID の割付けのみを行うことができる．

カーネルドメインの囲みの文法は次の通り．

KERNEL_DOMAIN { カーネルドメインに属するオブジェクトを登録する静的 API 等 }

同じ保護ドメイン名を指定したユーザドメインの囲みや，カーネルドメインの 囲みを，複数回記述してもよい．保護機能対応でないカーネルで保護ドメイン の囲みを記述した場合や，保護ドメインの囲みの中に保護ドメインの囲みを記 述した場合には，コンフィギュレータがエラーを報告する．

【μ ITRON4.0/PX 仕様との関係】

ユーザドメインの囲みの文法を変更した．

【仕様決定の理由】

保護ドメインに属すべきオブジェクトを登録する静的 API 等を保護ドメインの囲 みの外に記述した場合のエラーコードを E_RSATR としたのは，オブジェクトを動 的に登録する API においては，オブジェクトの属する保護ド メインを，オブジェ クト属性によって指定するためである．

マルチプロセッサ対応カーネルでは，オブジェクトを登録する静的 API 等を，そ のオブジェクトが属するクラスの囲みの中に記述する．クラスに属すべきオブ ジェクトを登録する静的 API 等を，クラスの囲みの外に記述した場合には，コン フィギュレータが E_RSATR エラーを報告する．

クラスの囲みの文法は次の通り．

CLASS( クラス ID) { クラスに属するオブジェクトを登録する静的 API 等 }

クラス ID には，静的 API の整数定数式パラメータと同等の定数式を記述すること ができる．使用できないクラス IDを指定した場合には，コンフィギュレータが E_ID エラーを報告する．

同じクラス ID を指定したクラスの囲みを複数回記述してもよい．マルチプロセッ サ対応でないカーネルでクラスの囲みを記述した場合や，クラスの囲みの中に クラスの囲みを記述した場合には，コンフィギュレータがエラーを報告する．

なお，保護機能とマルチプロセッサの両方に対応するカーネルでは，保護ドメ インの囲みとクラスの囲みはどちらが外側になっていてもよい．

【仕様決定の理由】

クラスに属すべきオブジェクトを登録する静的 API 等をクラスの囲みの外に記述 した場合のエラーコードを E_RSATR としたのは，オブジェクトを動的に登録する API においては，オブジェクトの属するクラスを，オブジェクト属性によって指 定するためである．

コンフィギュレータは，次の 3つないしは 4つのパスにより，システムコンフィ ギュレーションファイルを解釈し，構成・初期化情報を含むファイルなどを生 成する（図 2-8）．

最初のパス 1では，システムコンフィギュレーションファイルを解釈し，そこに 含まれる静的 API の整数定数式パラメータの値を Cコンパイラを用いて求めるた めに，パラメータ計算用 C言語ファイル（ cfg1_out.c ）を生成する．この時，シ ステムコンフィギュレーションファイルに含まれる C言語プリプロセッサのイン クルードディレクティブは，パラメータ計算用 C言語ファイルの先頭に集めて生 成する．また，条件ディレクティブは，順序も含めて，そのままの形でパラメー タ計算用 C言語ファイルに出力する．システムコンフィギュレーションファイル に文法エラーや未サポートの記述があった場合には，この段階で検出される．

次に， Cコンパイラおよび関連ツールを用いて，パラメータ計算用 C言語ファイ ルをコンパイルし，ロードモジュールを生成する．また，それを Sレコードフォー マットの形（ cfg1_out.srec ）に変換し，ロードモジュール中の各シンボルとア ドレスの対応表を含 むシンボルファイル（ cfg1_out.syms ）を生成する．静的 API のパラメータに解釈できない式が記述された場合には，この段階でエラーが 検出される．

コンフィギュレータのパス 2では，パス 1で生成されたオブジェクトファイルを S レコードフォーマットの形に変換したものとシンボルファイルから， C言語プ リプロセッサの条件ディレクティブによりどの静的 API が有効となったかと，そ れらの静的 API の整数定数式パラメータの値を取り出し，カーネルおよびシステ ムサービスの構成・初期化ファイル（ kernel_cfg.c など）と構成・初期化ヘッ ダファイル（ kernel_cfg.h など）を生成する．構成・初期化ヘッダファイルに は，登録できるオブジェクトの数（動的生成対応カーネル以外では，静的 API に よって登録されたオブジェクトの数に一致）やオブジェクトの ID 番号などの定 義を出力する．静的 API の整数定数式パラメータに不正がある場合には，この段 階でエラーが検出される．

パス 2で生成されたこれらのファイルを，他のソースファイルとあわせてコンパ イルし，アプリケーションのロードモジュールを生成する．また，それを Sレコー ドフォーマットの形（ system.srec ）に変換し，ロードモジュール中の各シンボ ルと番地の対応表を含むシンボルファ イル（ system.syms ）を生成する．

コンフィギュレータのパス 3では，パス 1で生成されたロードモジュールを Sレコー ドフォーマットの形に変換したものとシンボルファイル，パス 2で生成されたロー ドモジュールを Sレコードフォーマットの形に変換したものとシンボルファイル から，静的 API パラメータの値などを取り出し，妥当性のチェックを行う．静的 API の一般定数式パラメータに不正がある場 合には，この段階でエラーが検出さ れる．

保護機能対応カーネルにおいては，メモリ保護のための設定情報を生成するた めに，パス 3ではじめて得られる情報が必要となる．そこで，そのようなメモリ 保護のための設定情報は，パス 3においてメモリ構成・初期化ファイル （ kernel_mem.c ）に生成する．生成したメモリ構成・初期化ファイルは，他の ソースファイルとあわせてコンパイ ルし，アプリケーションの最終的なロード モジュールを生成する．

そのため，パス 2で生成されたファイルから生成したロードモジュールは，仮の ロードモジュールという位置付けになる．ここで，仮のロードモジュールと最 終的なロードモジュールでサイズが変化してはならないため，パス 3でメモリ構 成・初期化ファイルに生成するのと同じサイズのデータ構造を，パス 2において 仮のメモリ構 成・初期化ファイル（ kernel_mem2.c ）に生成し，これも含めて仮 のロードモジュールを生成しておく．また，仮のロードモジュールを Sレコード フォーマットの形に変換したもの（ cfg2_out.srec ），仮のロードモジュール中 の各シンボルと番地の対応表を含むシンボルファイル（ cfg2_out.syms ）も，混 乱を避けるためにファイル名を変更しておく（図 2-9）．

パス 3でメモリ保護のための設定情報を生成した場合には，パス 4を実行する． コンフィギュレータのパス 4では，パス 1で生成されたロードモジュールを Sレコー ドフォーマットの形に変換したものとシンボルファイル，パス 3で生成されたロー ドモジュールを Sレコードフォーマットの形に変換したものとシンボルファイル から，生成したロードモジュールの妥当性のチェックを行う．この段階で検出 されるエラーは，コ ンフィギュレーション処理の不具合を示すものである．

【μ ITRON4.0 仕様との関係】

コンフィギュレータの処理モデルは全面的に変更した．

静的 API のパラメータに関するエラー検出は，同じものがサービスコールとして 呼ばれた場合と同等とすることを原則とする．言い換える と，サービスコール によっても検出できないエラーは，静的 API においても検出しない．静的 API の 機能説明中の「 E_XXXXX エラーとなる」または「 E_XXXXX エラーが返る」という 記述は，コンフィギュレータがそのエラーを検出することを意味する．

ただし，エラーの種類によっては，サービスコールと同等のエラー検出を行う ことが難しいため，そのようなものについては例外とする．例えば，メモリ 不 足をコンフィギュレータによって検出するのは容易ではない．

逆に，オブジェクト属性については，サービスコールより強力なエラーチェッ クを行える可能性がある．例えば，タスク属性に TA_STA と記述されている場合， サービスコールではエラーを検出できないが，コンフィギュレータでは検出で きる可能性がある．ただし，このようなエラー検出を完全に行おうとするとコ ンフィギュレータが複雑になるため，このようなエラーを検出することは必須 とせず，検出できた場合には警告として報告する．

【μ ITRON4.0 仕様との関係】

μ ITRON4.0 仕様では，静的 API のパラメータに関するエラー検出について規定さ れていない．

コンフィギュレータのオプション機能として，アプリケーション設計者がオブ ジェクトの ID 番号を指定するための次の機能を用意する．

コンフィギュレータのオプション指定により，オブジェクト識別名と ID 番号の 対応表を含むファイルを渡すと，コンフィギュレータはそれに従ってオブジェ クトに ID 番号を割り付ける．それに従った ID 番号割付けができない場合（ ID 番 号に抜けができる場合など ）には，コンフィギュレータはエラーを報告する．

またコンフィギュレータは，オプション指定により，オブジェクト識別名とコ ンフィギュレータが割り付けた ID 番号の対応表を含むファイルを，コンフィギュ レータに渡すファイルと同じフォーマットで生成する．

【μ ITRON4.0 仕様との関係】

μ ITRON4.0 仕様では，オブジェクト生成のための静的 API の ID 番号を指定するパ ラメータに整数値を記述できるため，このような機能は用意されていない．

異なるモジュールの API の構成要素の名称が衝突することを避けるために，各モ ジュールに対して，それを識別するためのモジュール識別名を定める．モジュー ル識別名は，英文字と数字で構成し， 2～ 8文字程度の長さとする ．

カーネルのモジュール識別名は "kernel" ，システムインタフェースレイヤのモ ジュール識別名は "sil" とする．

API の構成要素の名称には，モジュール識別名を含めることを原則とするが，カー ネルの API など，頻繁に使用されて衝突のおそれが少ない場合には，モジュール 識別名を含めない名称を使用する．

以下では，モジュー ル識別名の英文字を英小文字としたものを www ，英大文字と したものを WWW と表記する．

各サイズの整数型など，データの意味を定めない基本データ型の名称は，英小 文字，数字， "_" で構成する．データ型であることを明示するために，末尾が "_t" である名称とする．

複合データ型やデータの意味を定めるデータ型の名称は，英大文字，数字， "_" で構成する．データ型であることを明示するために，先頭が "T_" または末尾 が "_T" である名称とする場合もある．

データ型の種類毎に，次のネーミングコンベンションを定める．

• (A) パケットのデータ型

関数の名称は，英小文字，数字， "_" で構成する．

関数の種類毎に，次のネーミングコンベンションを定める．

• (A) サービスコール

  サービスコールは， xxx_yyy または www_xxx_yyy の名称とする．ここで， xxx は操 作の方法， yyy は操作の対象を表す． xxx_yyy または www_xxx_yyy から派生したサー ビスコールは，それぞれ zxxx_yyy または www_zxxx_yyy の名称とする．ここで zは， 派生したことを表す文字である．派生したことを表す文字を 2つ付加する場合に は， zzxxx_yyy または www_zzxxx_yyy の名称となる．

  非タスクコンテキスト専用のサービスコールの名称は，派生したことを表す文 字として "i" を付加し， ixxx_yyy ， izxxx_yyy ， www_ixxx_yyy ， www_izxxx_yyy と いった名称とする．

  【補足説明】

  サービスコールの名称を構成する省略名（ xxx ， yyy ， z）の元になった英語につ いては，「 5.9 省略名の元になった英語」の 節を参照すること．

• (B) コールバック

  コールバックの名称は，サービスコールのネーミングコンベンションに従う．

変数（ const 修飾子のついたものを含む）の名称は，英小文字，数字， "_" で構 成する．データ型が異なる変数には，異なる名称を付けることを原則とする．

変数の名称に関して，次のガイドラインを設ける．

また，ポインタ変数（関数ポインタを除く）の名称に関して，次のガイドライ ンを設ける．

変数の種類毎に，次のネーミングコンベンションを定める．

• (A) パケットへのポインタ

定数（ C言語プリプロセッサのマクロ定義によるもの）の名称は，英大文字，数 字， "_" で構成する．

定数の種類毎に，次のネーミングコンベンションを定める．

• (A) メインエラーコード

  メインエラーコードは，先頭が "E_" である名称とする．

• (B) 機能コード

• (C) その他の定数

  その他の定数は，先頭が TUU_ または TUU_W WW_ である名称とする．ここで UU は， 定数の種類またはデータ型を表す．同じパラメータまたはリターンパラメータ に用いられる定数の名称については， UU を同一にすることを原則とする．

  また，定数の名称に関して，次のガイドラインを設ける．

マクロ（ C言語プリプロセッサのマクロ定義によるもの）の名称は，それが表す 構成要素のネーミングコンベンションに従う．すなわち，関数を表すマクロは 関数のネーミングコンベンションに，定数を表すマクロは定数のネーミングコ ンベンションに従う．ただし，簡単な関数を表すマクロや，副作用があるなど の理由でマクロであることを明示したい場合には，英大文字，数字， "_" で構成 する場合もある．

マクロの種類毎に，次のネーミングコンベンションを定める．

• (A) 構成マクロ

  構成マクロの名称は，英大文字，数字， "_" で構成し，次のガイドラインを設け る．

静的 API の名称 は，英大文字，数字， "_" で構成し，対応するサービスコールの 名称中の英小文字を英大文字で置き換えたものとする．対応するサービスコー ルがない場合には，サービスコールのネーミングコンベンションに従って定め た名称中の英小文字を英大文字で置き換えたものとする．

ファイルの名称は，英小文字，数字， "_" ， "." で構成する．英大文字と英小文 字を区別しないファイルシステムに対応するために，英大文字は使用しない． また， "-"も使用しない．

ファイルの種類毎に，次のネーミングコンベンションを定める．

• (A) ヘッダファイル

  モジュールを用いるために必要な定義を含むヘッダファイルは，そのモジュー ルのモジュール識別名の末尾に ".h" を付加した名前（すなわち， www. h）とする．

モジュール内部の名称が，他のモジュール内部の名称と衝突することを避ける ために，次のガイドラインを設ける．

モジュール内部に閉じて使われる関数や変数などの名称で，オブジェクトファ イルのシンボル表に登録されて外部から参照できる名称は， C言語レベルで，先 頭が _www _または _WWW_ である名称とする．例えば，カーネルの内部シンボルは， C 言語レベルで，先頭が "_kernel_" または "_KERNEL_" である名称とする．

また，モジュールを用いるために必要な定義を含むヘッダファイル中に用いる 名称で，それをインクルードする他のモジュールで使用する名称と衝突する可 能性のある名称は， "TOPPERS_" で始まる名称とする．

2. 14 TOPPERS 共通定義

TOPPERS ソフトウェアに共通に用いる定義を， TOPPERS 共通定義と呼ぶ．

TOPPERS 共通定義（共通データ型，共通定数，共通マクロ）は， TOPPERS 共通ヘッ ダファイル（ t_stddef.h ）およびそこからインクルードされるファイルに含ま れている． TOPPERS 共通定義を用いる場合には， TOPPERS 共通ヘッダファイルを インクルードする．

TOPPERS 共通ヘッダファイルは，カーネルヘッダファイル（ kernel.h ）やシステ ムインタフェースレイヤヘッダファイル（ sil.h ）からインクルードされるため， これらのファイルをインクルードする場合には， TOPPERS 共通ヘッダファイルを 直接インクルード する必要はない．

C90 に規定されているデータ型以外で， TOPPERS ソフトウェアで共通に用いるデー タ型は次の通りである．

ここで，データ型が「 Aまたは B」とは， Aか Bのいずれかの値を取ることを示す． 例えば ER_BOOL は，エラーコードまたは真偽値のいずれかの値を取る．

int8_t ， uint8_t ， int64_t ， uint64_t ， int128_t ， uint128_t ， float32_t ， double64_t が使用できるかどうかは，ターゲットシステムに依存する．これら が使用できるかどうかは，それぞれ， INT8_MAX ， UINT8_MAX ， INT64_MAX ， UINT64_MAX ， INT128_MAX ， UINT128_MAX ， FLOAT32_MAX ， DOUBLE64_MAX がマクロ 定義されているかどうかで判別することができる． IEEE754 準拠の浮動小数点数 がサポートされていないターゲットシステムでは， float32_t と double64_t は使 用できないものとする．

【μ ITRON4.0 仕様との関係】

B ， UB ， H， UH ， W， UW ， D， UD ， VP_INT に代えて， C99 準拠の int8_t ， uint8_t ， int16_t ， uint16_t ， int32_t ， uint32_t ， int64_t ， uint64_t ， intptr_t を用い ることにした．また， uintptr_t ， int128_t ， uint128_t を用意することにした．

VP は， void * と等価であるため，用意しないことにした．また，ターゲットシ ステムにより振舞いが一定しないことから， VB ， VH ， VW ， VD に代わるデータ型 は用 意しないことにした．

INT ， UINT に代えて， C99 の型名と相性が良い int_t ， uint_t を用いることにした． また， 32 ビット以上かつ int_t 型（または uint_t 型）以上のサイズが保証される 整数型として， long_t ， ulong_t を用意し， 8ビット以上のサイズで必ず存在す る整数型として， C99 準拠の int_least8_t ， uint_least8_t を導入することにし た． int_least16_t ， uint_least16_t ， int_least32_t ， uint_least32_t を導入 しなかったのは， 16 ビットおよび 32 ビットの整数型があることを仮定しており， それぞれ int16_t ， uint16_t ， int32_t ， uint32_t で代用できるためである．

TECS との整合性を取るために， BOOL に代えて， bool_t を用いることにした．ま た， IEEE754 準 拠の単精度浮動小数点数を表す型として float32_t ， IEEE754 準拠 の 64 ビットを表す型として double64_t を導入した．

性能評価用システム時刻のためのデータ型として SYSUTM を，オブジェクト管理 領域を確保するためのデータ型として MB_T を用意することにした

C90 に規定されている定数以外 で， TOPPERS ソフトウェアで共通に用いる定数は 次の通りである（一部， C90 に規定されているものも含む）．

• (1) 一般定数

【μ ITRON4.0 仕様との関係】

BOOL を bool_t に代えたことから， TRUE および FALSE に代えて， true および false を用いることにした．

• (2) 整数型に格納できる最大値と最小値

• (3) 整数型のビット数

• (4) オブジェクト属性

• (5) タイムアウト指定

• (6) アクセス許可パターン

TOPPERS ソフトウェアで共通に用いるメインエラーコードは 次の通りである．

• (A) 内部エラークラス（ EC_SYS ， -5～ -8）

• (B) 未サポートエラークラス（ EC_NOSPT ， -9～ -16 ）

• (C) パラメータエラークラス（ EC_PAR ， -17 ～ -24 ）

• (D) 呼出しコンテキストエラークラス（ EC_CTX ， -25 ～ -32 ）

• (E) 資源不足エラー クラス（ EC_NOMEM ， -33 ～ -40 ）

• (F) オブジェクト状態エラークラス（ EC_OBJ ， -41 ～ -48 ）

• (G) 待ち解除エラークラス（ EC_RLWAI ， -49 ～ -56 ）

• (H) 警告クラス（ EC_WARN ， -57 ～ -64 ）

このエラークラスに属するエラーコードは，警告を表すエラーコードであり， サービスコールがエラーコードを返した場合には副作用がないという原則の例 外となる．

【μ ITRON4.0 仕様との関係】

E_NORES は，μ ITRON4.0 仕様に規定されていないエラー コードである．

• (1) 整数定数を作るマクロ

【仕様決定の理由】

C99 に用意されていない UINT_C と ULONG_C を導入したのは，アセンブリ言語から も参照する定数を記述するためである． C言語のみで用いる定数をこれらのマク ロを使って記述する必要はない．

• (2) 型に関する情報を取り出すためのマクロ

• (3) assert マクロ

• (4) コンパイラの拡張機能のためのマクロ

• (5) エラーコード構成・分解マクロ

• (6) アクセス許可パターン構成マクロ

ここで， TACP のパラメータ（ domid ）には，ユーザドメインの ID 番号のみを指定 することができる． TDOM_SELF ， TDOM_KERN EL ， TDOM_NONE を指定した場合の動作 は，保証されない．

• (1) 相対時間の範囲

カーネルを用いるために必要な定義は，カーネルヘッダファイル（ kernel.h ） およびそこからインクルードされるファイルに含まれている．カーネルを用い る場合には，カーネルヘッダファイルをインクルードする．

ただし，カーネルを用いるために必要な定義の中で，コンフィギュレータによっ て生成されるものは，カーネル構成・初期化ヘッダファイル（ kernel_cfg.h ） に含まれる．具体的には，登録できるオブジェクトの数（ TNUM_YYY ）やオブジェ クトの ID 番号などの定義が，これに該当する．これらの定義を用いる場合には， カーネル構成・初期化ヘッダファイルをインクルードする．

μ ITRON4.0 仕様で規定されており，この仕様で廃止されたデータ型および定数 を用いる場合には， ITRON 仕様互換ヘッダファイル（ itron.h ）をインクルード する．

【μ ITRON4.0 仕様との関係】

この仕様では，コンフィギュレータが生成するヘッダファイルに，オブジェク トの ID 番号の定義に加えて，登録できるオブジェクトの数（ TNUM_YYY ）の定義 が含まれることとした．これに伴い，ヘッダファイルの名称を，μ ITRON4.0 仕 様の自動割付け結果ヘッダファイル（ kernel_id.h ）から，カーネル構成・初期 化ヘッダファイル（ kernel_cfg.h ）に変更した．

• (1) オブジェクト属性

【μ ITRON4.0 仕様との関係】

値が 0のオブジェクト属性（ TA_HLNG ， TA_TFIFO ， TA_MFIFO ， TA_WSGL ）は，デフォ ルトの扱いにして廃止した．これは，「 (tskatr & TA_HLNG) != 0U 」のような 間違いを防ぐためである． TA_ASM は，有効な使途がないために廃止した． TA_MPRI は，メールボックス機能でのみ使用するため，カーネル共通定義から外 した．

• (2) 保護ドメイン ID

• (3) その他のカーネル共通定数

• (4) カーネルで用いるメインエラーコード

  「 2.14.4 TOPPERS 共通エラーコード」の節で定義したメインエラーコードの中 で， E_CLS ， E_WBLK ， E_BOVR の 3つは，カーネルでは使用しない．

  【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは，サービスコールから， E_RSFN ， E_RSATR ， E_MACV ， E_OACV ， E_NOMEM ， E_NOID ， E_NORES ， E_NOE XS が返る状況は起こらない． E_RSATR は，コ ンフィギュレータによって検出される．ただし，動的生成機能拡張パッケージ では， E_RSATR ， E_NOMEM ， E_NOID ， E_NOEXS が返る状況が起こる．

【 TOPPERS/FMP カーネルにおける規定】

FMP カーネルでは，サービスコールから， E_RSFN ， E_RSATR ， E_MACV ， E_OACV ， E_NOM EM ， E_NOID ， E_NORES ， E_NOEXS が返る状況は起こらない． E_RSATR と E_NORES は，コンフィギュレータによって検出される．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは，サービスコールから， E_RSATR ， E_NOID ， E_NORES ， E_NOEXS が返る状況は起こらない． E_RSATR は，コンフィギュレータによって検 出される．

【 TOPPERS/SSP カーネルにおける規定】

SSP カーネルでは，サービスコールから， E_RSFN ， E_RSATR ， E_MACV ， E_OACV ， E_ILUSE ， E_NOMEM ， E_NOID ， E_NORES ， E_NOEXS ， E_RLWAI ， E_TMOUT ， E_DLT が返 る状況は起こらない． E_RSATR は，コンフィギュレータによって検出される．

• (1) スタック領域をアプリケーションで確保するためのデータ型とマクロ

  スタック領域をアプリケーションで確保するために，次のデータ型とマクロを 用意している．

これらを用いてスタック領域を確保する方法は次の通り．

この方法で確保したスタック領域を，サービスコールまたは静的 API に渡す場合 には，スタック領域の先頭番地に <スタック領域の変数名 >を，スタック領域の サ イズに ROUND_STK_T(< スタック領域のサイズ >) を指定する．

ただし，保護機能対応カーネルにおいては，上の方法によりタスクのユーザス タック領域を確保することはできない．詳しくは，「 4.1 タスク管理機能」の 節の CRE_TSK の機能の項を参照すること．

• (2) オブジェクト属性を作るマクロ

  保護機能対応カーネルでは，オブジェクトが属する保護ドメインを指定するた めのオブジェクト属性を作るマクロとして，次のマクロを用意している．

マルチプロセッサ対応カーネルでは，オブジェクトが属するクラスを指定する ためのオブジェクト属性を作るマクロとして，次のマクロを用意してい る．

• (3) サービスコールの呼出し方法を指定するマクロ

  保護機能対応カーネルでは，サービスコールの呼出し方法を指定するためのマ クロとして，次のマクロを用意している．

• (1) サポートする機能

【未決定事項】

マクロ名は，今後変更する可能性がある．

• (2) 優先度の範囲

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは，タスク優先度の最大値（ TMAX_TPRI ）は 16 に固定されている． ただし，タスク優先度拡張パッケージを用いると， TMAX_TPRI を 256 に拡張する ことができる．

【 TOPPERS/FMP カー ネルにおける規定】

FMP カーネルでは，タスク優先度の最大値（ TMAX_TPRI ）は 16 に固定されている．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは，タスク優先度の最大値（ TMAX_TPRI ）は 16 に固定されている．

【 TOPPERS/SSP カーネルにおける規定】

SSP カーネルでは，タスク優先度の最大値（ TMAX_TPRI ）は 16 に固定されている．

【μ ITRON4.0 仕様との関係】

メッセージ優先度の最小値（ TMIN_MPRI ）と最大値（ TMAX_MPRI ）は，メールボッ クス機能でのみ使用するため，カーネル共通定義から外した．

• (3) プロセッサの数

  マルチプロセッサ対応カーネルでは，プロセッサの数を知るためのマクロとし て，次の構成マクロを用意している．

• (4) 特殊な役割を持ったプロセッサ

  マルチプロセッサ対応カーネルでは，特殊な役割を持ったプロセッサを知るた めのマクロとして，次の構成マクロを用意している．

• (5) タイマ方式

  マルチプロセッサ対応カーネルでは， システム時刻の方式を知るためのマクロ として，次の構成マクロを用意している．

• (6) バージョン情報

カーネルのメーカコード（ TKERNEL_MAKER ）は， TOPPERS プロジェク トから配布 するカーネルでは， TOPPERS プロジェクトを表す値（ 0x0118 ）に設定されている．

カーネルの識別番号（ TKERNEL_PRID ）は， TOPPERS カーネルの種類を表す．

カーネル仕様のバージョン番号（ TKERNEL_SPVER ）は，上位 8ビット（ 0xf5 ）が TOPPERS 新世代カーネル仕様であることを，中位 4ビットがメジャーバージョン 番号，下位 4ビットがマイナーバージョン番号を表す．

カーネルのバージョン番号（ TKERNEL_PRVER ）は，上位 4ビットがメジ ャーバー ジョン番号，中位 8ビットがマイナーバージョン番号，下位 4ビットがパッチレ ベルを表す．

セマフォは，資源の数を表す 0以上の整数値を取るカウンタ（資源数）を介して， 排他制御やイベント通知を行うための同期・通信オブジェクトである．セマフォ の資源数から 1を減ずることを資源の獲得，資源数に 1を加えることを資源の返 却と呼ぶ．セマフォは，セマフォ ID と呼ぶ ID 番号によって識別する．

各セマフォが持つ情報は次の通 り．

• ・セマフォ属性
• ・資源数（の現在値）
• ・待ち行列（セマフォの資源獲得待ち状態のタスクのキュー）
• ・初期資源数
• ・最大資源数
• ・アクセス許可ベクタ（保護機能対応カーネルの場合）
• ・属する保護ドメイン（保護機能対応カーネルの場合）
• ・属するクラス（マルチプロセッサ対応カーネルの場合）

待ち行列は，セマフォの資源が獲得できるまで待っている状態（セマフォの資 源獲得待ち状態）のタスクが，資源を獲得できる順序でつながれているキュー である．

セマフォの初期資源数は，セマフォを生成または再初期化した際の，資源数の 初期値である．また，セマフォの最大資源数は，資源数が取りうる最大値であ る．資源数が最大資源数に一致している時に資源を返却しようとすると， E_QOVR エラーとなる．

セマフォ属性には，次の属性を指定することができる．

TA_TPRI を指定しない場合，待ち行列は FIFO 順になる．

セマフォ機能に関連するカーネル構成マクロは次の通り．

【μ ITRON4.0 仕様との関係】

TNUM_SEMID は，μ ITRON4.0 仕様に規定されていないカーネル構成マクロである．

【静的 API 】

【 C言語 API 】

【パラメータ】

＊セマフォの生成情報（パケットの内容）

【リターンパラメータ】

【エラーコード】

【機能】

各パラメータで指定したセマフォ生成情報に従って，セマフォを生成する．生 成されたセマフォの資源数は初期資源数に，待ち行列は空の状態に初期化され る．

静的 API においては， semid はオブジェクト識別名， isemcnt と maxsem は整数 定数 式パラメータである．

isemcnt は， 0以上で， maxsem 以下でなければならない．また， maxsem は， 1以上 で， TMAX_MAXSEM 以下でなければならない．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは， CRE_SEM のみをサポートする．ただし，動的生成機能拡張パッ ケージでは， acre _sem もサポートする．

【 TOPPERS/FMP カーネルにおける規定】

FMP カーネルでは， CRE_SEM のみをサポートする．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは， CRE_SEM のみをサポートする．

【静的 API 】

【パラメータ】

【エラーコード】

【機能】

nosem で指定した数のセマフォ ID を，セマフォを生成するサービスコールによっ て割付け可能なセマフォ ID として確保する．

nosem は整数定数式パラメー タである．

【静的 API 】

【 C言語 API 】

【パラメータ】

＊アクセス許可ベクタ（パケットの内容）

【リターンパラメータ】

【エラーコード】

【機能】

semid で指定したセマフォ（対象セマフォ）のアクセス許可ベクタ（ 4つのアク セス許可パターンの組）を，各パラメータで指定した値に設定する．

静的 API においては， semid はオブジェクト識別名， acptn1 ～ acptn4 は整数定数 式パラメータである．

SAC_SEM は，対象セマフォが属する保護ドメインの囲みの中に記述しなければな らない．そうでな い場合には， E_RSATR エラーとなる．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは， SAC_SEM ， sac_sem をサポートしない．

【 TOPPERS/FMP カーネルにおける規定】

FMP カーネルでは， SAC_SEM ， sac_sem をサポートしない．

【 TOPPERS/HRP 2カーネルにおける規定】

HRP2 カーネルでは， SAC_SEM のみをサポートする．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

semid で指定したセマフォ（対象セマフォ）を削除する．具体的な振舞いは以下 の通り．

対象セマフォの登録が解除され，そのセマフォ ID が未使用の状態に戻される． また，対象セマフ ォの待ち行列につながれたタスクは，待ち行列の先頭のタス クから順に待ち解除される．待ち解除されたタスクには，待ち状態となったサー ビスコールから E_DLT エラーが返る．

【使用上の注意】

del_sem により複数のタスクが待ち解除される場合，サービスコールの処理時間 およびカーネル内での割込み禁止時間が，待ち解除されるタスクの数に比例し て長くなる．特に，多くのタスクが待ち解除される場合，カーネル内での割込 み禁止時間が長くなるため，注意が必要である．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは， del_sem をサポートしない．ただし，動的生成機能拡張パッ ケージでは， del_sem をサポートする．

【 TOPPERS/FMP カーネルに おける規定】

FMP カーネルでは， del_sem をサポートしない．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは， del_sem をサポートしない．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

semid で指定したセマフォ（対象セマフォ）に資源を返却する．具体的な振舞い は以下の通り．

対象セマフォの待ち行列にタスクが存在する場合には，待ち行列の先頭のタス クが待ち解除される．この時，待ち解除されたタスクが資源を獲得したことに なるため ，対象セマフォの資源数は変化しない．待ち解除されたタスクには， 待ち状態となったサービスコールから E_OK が返る．

待ち行列にタスクが存在しない場合には，対象セマフォの資源数に 1が加えられ る．資源数に 1を加えるとそのセマフォの最大資源数を越える場合には， E_QOVR エラーとなる．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

semid で指定したセマフォ（対象セマフォ）から資源を獲得する．具体的な振舞 いは以下の通り．

対象セマフォの資 源数が 1以上の場合には，資源数から 1が減ぜられる．資源数 が 0の場合には，自タスクはセマフォの資源獲得待ち状態となり，対象セマフォ の待ち行列につながれる．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

semid で指定したセマフォ（対象セマフォ）を再初期化する．具体的な振舞いは 以下の通り．

対象セマフォの資源数は，初期資源数に初期化される．また，対象セマフォの 待ち行列につながれたタスクは，待ち行列の先頭のタスクから順に待ち解除さ れる．待ち解除されたタスクには，待ち状態となったサービスコールから E_DLT エラーが返る．

【使用上の注意】

ini_sem により複数のタスクが待ち解除される場合，サービスコールの処理時間 およびカーネル内での割込み禁止時間が，待ち解除されるタスクの数に比例し て長くなる．特に，多くのタスクが待ち解除される場合，カーネル内での割込 み禁止 時間が長くなるため，注意が必要である．

セマフォを再初期化した場合に，アプリケーションとの整合性を保つのは，ア プリケーションの責任である．

【μ ITRON4.0 仕様との関係】

μ ITRON4.0 仕様に定義されていないサービスコールである．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

＊セマフォの現在状態（パケットの内容）

【エラーコード】

【機能】

semid で指定したセマフォ（対象セマフォ）の現在状態を参照する．参照した現 在状態は， pk_rsem で指定したパケットに返される．

対象セマフォの待ち行列にタスクが存在しない場合， wtskid には TSK_NONE （＝ 0 ）が返る．

【使用上の注意】

ref_sem はデバッグ時向けの機能であり，その他の目的に使用することは推奨し ない．これは， ref_sem を呼び出し，対象セマフォの現在状態を参照した直後に 割込みが発生した場合， ref_sem から戻ってきた時には対象セマフォの状態が変 化している可能性があるためである．

イベントフラグは，イベントの発生の有無を表すビットの集合（ビットパター ン）を介して，イベント通知を行うための同期・通信オブジェクトである．イ ベントが発生している状態を 1，発生していない状態を 0とし，ビットパターン により複数のイベントの発生の有無を表す．イベントフラグは，イベントフラ グ ID と呼ぶ ID 番号によ って識別する．

1 つまたは複数のビットをセットする 1にする（セットする）ことを，イベント フラグをセットするといい， 0にする（クリアする）ことを，イベントフラグを クリアするという．イベントフラグによりイベントを通知する側のタスクは， イベントフラグをセットまたはクリアすることで，イベントの発生を通知する．

イベントフラグによりイベントの通知を受ける側のタスクは，待 ちビットパター ンと待ちモードにより，どのビットがセットされるのを待つかを指定する．待 ちモードに TWF_ORW （＝ 0x01U ）を指定した場合，待ちビットパターンに含まれ るいずれかのビットがセットされるのを待つ．待ちモードに TWF_ANDW （＝ 0x02U ）を指定した場合，待ちビットパターンに含まれるすべてのビットがセッ トされるのを待つ．この条件を，イベントフラグの待ち解除の条件と呼ぶ．

各イベントフラグが持つ情報は次の通り．

• ・イベントフラグ属性
• ・ビットパターン（の現在値）
• ・待ち行列（イベントフラグ待ち状態のタスクのキュー）
• ・初期ビットパターン
• ・アクセス許可ベクタ（保護機能対応カーネルの場合）
• ・属する保護ドメイン（保護機能対応カーネルの場合）
• ・属するクラス（マルチ プロセッサ対応カーネルの場合）

待ち行列は，イベントフラグが指定した待ち解除の条件を満たすまで待ってい る状態（イベントフラグ待ち状態）のタスクがつながれているキューである． 待ち行列につながれたタスクの待ち解除は，待ち解除の条件を満たした中で， 待ち行列の前方につながれたものから順に行われる（「 2.6.4 待ち行列と待ち 解除の順序」の節の (a) に該当）．

イベントフラグの初期ビットパターンは，イベントフラグを生成または再初期 化した際の，ビットパターンの初期値である．

イベントフラグ属性には，次の属性を指定することができる．

TA_TPRI を指定しない場合，待ち行列は FIFO 順になる． TA_WMUL を指定しない場 合， 1つのイベントフラグに複数のタスクが待つことを禁止する．

TA_CLR を指定した場合，タスクの待ち解除時に，イベントフラグのビットパター ンを 0にクリアする． TA_CLR を指定しない場合，タスクの待ち解除時にイベント フラグをクリアしない．

イベントフラグ機能に用いるデータ型は次の通り．

イベントフラグ機能に関連するカーネル構成マクロは次の通り．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは，イベントフラグのビット数（ TBIT_FLGPTN ）は 16 以上である．

【 TOPPERS/FMP カーネルにおける規定】

FMP カーネルでは，イベントフラグのビット数（ TBIT_FLGPTN ）は 16 以上である．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは，イベントフラグのビット数（ TBIT_FLGPTN ）は 16 以上である．

【μ ITRON4.0 仕様との関係】

TNUM_FLGID は，μ ITRON4.0 仕様に規定されていないカーネル構成マクロである．

【静的 API 】

【 C言語 API 】

【パラメータ】

＊イベントフラグの生成情報（パケットの内容）

【リターンパラメータ】

【エラーコード】

【機能】

各パラメータで指定したイベントフラグ生成情報に従って，イベントフラグを 生成する．生成された イベントフラグのビットパターンは初期ビットパターン に，待ち行列は空の状態に初期化される．

静的 API においては， flgid はオブジェクト識別名， iflgptn は整数定数式パラメー タである．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは， CRE_FLG のみをサポートする．ただし，動的生成機能拡張パッ ケージでは， acre_flg もサポートする．

【 TOPPERS/FMP カーネルにおける規定】

FMP カーネルでは， CRE_FLG のみをサポートする．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは， CRE_FLG のみをサポートする．

【静的 API 】

【パラメータ】

【エラーコード】

【機能】

noflg で指定した数のイベントフラグ ID を，イベントフラグを生成するサービス コールによって割付け可能なイベントフラグ ID として確保する．

noflg は整数定数式パラメータである．

【静的 API 】

【 C言語 API 】

【パラメータ】

＊アクセス許可ベクタ（パケットの内容）

【リターンパラメータ】

【エラーコード】

【機能】

flgid で指定したイベントフラグ（対象イベントフラグ）のアクセス許可ベクタ （ 4つのアクセス許可パターンの組）を，各パラメータで指定した値に設定する．

静的 API においては， flgid はオブジェクト識別名， acptn1 ～ acptn4 は整数定数 式パラメータである．

SAC_FLG は，対象イベントフラグが属する保護ドメインの囲みの中に記述しなけ ればならない．そうでない場合には， E_RSATR エラーとなる．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは， SAC_FLG ， sac_flg をサポートしない．

【 TOPPERS/FMP カーネルにおける規定】

FMP カーネルでは， SAC_FLG ， sac_flg をサポートしない．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは， SAC_FLG のみをサポートする．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

flgid で指定したイベントフラグ（対象イベントフラグ）を削除する．具体的な 振舞いは以下の通り．

対象イベントフラグの登録が解除され，そのイベントフラグ ID が未使用の状態 に戻される．また，対象イベントフラグの待ち行列につながれたタスクは，待 ち行列の先頭のタスクから順に待ち解除される．待ち解除されたタスクには， 待ち状態となったサービスコールから E_DLT エラーが返る．

【使用上の注意】

del_flg により複数のタスクが待ち解除される場合，サービスコールの処理時間 およびカーネル内での割込み禁止時間が，待ち解除されるタスクの数に比例し て長くなる．特に，多くのタスクが待ち解除される場合，カーネル内での割込 み禁止時間が長くなるため，注意が必要である．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは， del_f lg をサポートしない．ただし，動的生成機能拡張パッ ケージでは， del_flg をサポートする．

【 TOPPERS/FMP カーネルにおける規定】

FMP カーネルでは， del_flg をサポートしない．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは， del_flg をサポートしない．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

flgid で指定したイベントフラグ（対象イベントフラグ）の setptn で指定したビッ トをセットする．具体的な振舞いは以下の通り．

対象イベントフラグのビットパターンは，それまでの値と setptn で指定した値 のビット毎論理和（ C言語の "|" ）に更新される．対象イベントフラグの待ち行 列にタスクが存在する場合には，待ち解除の条件を満たしたタスクが，待ち行 列の前方につな がれたものから順に待ち解除される．待ち解除されたタスクに は，待ち状態となったサービスコールから E_OK が返る．

ただし，対象イベントフラグが TA_CLR 属性である場合には，待ち解除の条件を 満たしたタスクを 1つ待ち解除した時点で，対象イベントフラグのビットパター ンが 0にクリアされるため，他のタスクが待ち解除されることはない．

【使用上の注意】

対象イベントフラグが， TA_WMUL 属性であり， TA_CLR 属性でない場合， set_flg または iset_flg により複数のタスクが待ち解除される場合がある．この場合， サービスコールの処理時間およびカーネル内での割込み禁止時間が，待ち解除 されるタスクの数に比例して長くなる．特に，多くのタスクが待ち解除される 場合，カーネル内での割込み禁止時間が長くなるため，注意が必要である．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

flgid で指定したイベントフラグ（対象イベントフラグ）の clrptn で指定したビッ トをクリアする．対象イベントフラグのビットパターンは，それまでの値と clrptn で指定した値のビット毎論理積（ C言語の "&" ）に更新される．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

flgid で指定したイベントフラグ（対象イベントフラグ）が， waiptn と wfmode で 指定した待ち解除の条件を満たすのを待つ．具体的な振舞いは以下の通り．

対象イベントフラグが， waiptn と wfmode で指定した待ち解除の条件を満たして いる場合には，対象イベントフラグのビットパター ンの現在値が flgptn に返さ れる．対象イベントフラグが TA_CLR 属性である場合には，対象イベントフラグ のビットパターンが 0にクリアされる．

待ち解除の条件を満たしていない場合には，自タスクはイベントフラグ待ち状 態となり，対象イベントフラグの待ち行列につながれる．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

flgid で指定したイベントフラグ（対象イベントフラグ）を再初期化する．具体 的な振舞いは以下の通り．

対象イベントフラグのビットパターンは，初期ビットパターンに初期化される． また，対象イベントフラグの待ち行列につながれたタスクは，待ち行列の先頭 のタスクから順に待ち解除される．待ち解除されたタスクには，待ち状態となっ たサービスコールから E_DLT エラーが返る．

【使用上の注意】

ini_flg により複数のタスクが待ち解除される場合，サービスコールの処理時間 およびカーネル内での割込み禁止時間が，待ち解除されるタスクの数に比例し て長くなる．特に，多くのタスクが待ち解除される場合，カーネル内での割込 み禁止時間が長くなるため，注意が必要である．

イベントフラグを再初期化した場合に，ア プリケーションとの整合性を保つの は，アプリケーションの責任である．

【μ ITRON4.0 仕様との関係】

μ ITRON4.0 仕様に定義されていないサービスコールである．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

＊イベントフラグの現在状態（パケットの内容）

【エラーコード】

【機能】

flgid で指定したイベントフラグ（対象イベントフラグ）の現在状態を参照する． 参照した現在状態は， pk_rflg で指定したパケットに返される．

対象イベントフラグの待ち行列にタスクが存在しない場合， wtskid には TSK_NONE （＝ 0）が返る．

【使用上の注意】

ref_flg はデバッグ時向けの機能であり，その他の目的に使用することは推奨し ない．これは， ref_flg を呼び出し，対象イベントフラグの現在状態を参照した 直後に割込みが発生した場合， ref_flg から戻ってきた時には対象イベントフラ グの状態が変化している可能性があるためである．

データキューは， 1ワードのデータをメッセージとして， FIFO 順で送受信するた めの同期・通信オブジェクトである．より大きいサイズのメッセージを送受信 したい場合には，メッセージを置いたメモリ領域へのポ インタを 1ワードのデー タとして送受信する方法がある．データキューは，データキュー ID と呼ぶ ID 番 号によって識別する．

各データキューが持つ情報は次の通り．

• ・データキュー属性
• ・データキュー管理領域
• ・送信待ち行列（データキューへの送信待ち状態のタスクのキュー）
• ・受信待ち行列（データキューからの受信待ち状態のタス クのキュー）
• ・アクセス許可ベクタ（保護機能対応カーネルの場合）
• ・属する保護ドメイン（保護機能対応カーネルの場合）
• ・属するクラス（マルチプロセッサ対応カーネルの場合）

データキュー管理領域は，データキューに送信されたデータを，送信された順 に格納しておくためのメモリ領域である．データキュー生成時に，データキュー 管理領域に格納できるデータ数を 0とすることで， データキュー管理領域のサイ ズを 0とすることができる．

保護機能対応カーネルにおいて，データキュー管理領域は，カーネルの用いる オブジェクト管理領域として扱われる．

送信待ち行列は，データキューに対してデータが送信できるまで待っている状 態（データキューへの送信待ち状態）のタスクが，データを送信できる順序で つながれているキューである．また，受信待ち行列は，データキューからデー タが受信できるまで待っている状態（データキューからの受信待ち状態）のタ スクが，データを受信できる順序でつながれているキューである．

データキュー属性には，次の属性を指定することができる．

TA_TPRI を指定しない場合，送信待ち行列は FIFO 順になる．受信待ち行列は， FIFO 順に固定されている．

データキュー機能に関連するカーネル構成マクロは次の通り．

【μ ITRON4.0 仕様との関係】

TNUM_DTQID は，μ ITRON4.0 仕様に規定されていないカーネル構成マクロである．

【静的 API 】

【 C言語 API 】

【パラメータ】

＊データキューの生成情報（パケットの内容）

【リターンパラメータ】

【エラーコード】

【機能】

各パラメータで指定したデータキュー生成情報に従って，データキューを生成 する． dtqcnt と dtqmb からデータキュー管理領域が設定され，格納されているデー タがない状態に初 期化される．また，送信待ち行列と受信待ち行列は，空の状 態に初期化される．

静的 API においては， dtqid はオブジェクト識別名， dtqcnt は整数定数式パラメー タ， dtqmb は一般定数式パラメータである．コンフィギュレータは，静的 API の メモリ不足（ E_NOMEM ）エラーを検出することができない．

dtqmb を NULL とした場合， dtqcnt で指定した数のデー タを格納できるデータキュー 管理領域を，コンフィギュレータまたはカーネルが確保する．

〔 dtqmb に NULL 以外を指定した場合〕

dtqmb に NULL 以外を指定した場合， dtqmb を先頭番地とするデータキュー管理領 域は，アプリケーションで確保しておく必要がある．データキュー管理領域を アプリケーションで確保するために，次のマクロを用意している．

これらを用いてデータキュー管理領域を確保する方法は次の通り．

この時， dtqmb には <データキュー管理領域の変数名 >を指定する．

この方法に従わず， dtqmb にターゲット定義の制約に合致しない先頭番地を指定 した時には， E_PAR エラーとなる．また，保護機能対応カーネルにおいて， dtqmb で指定したデータキュー管理領域がカーネル専用のメモリオブジェクトに 含まれない場合， E_OBJ エラーとなる．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは， CRE_ DTQ のみをサポートする．また， dtqmb には NULL のみを指 定することができる． NULL 以外を指定した場合には， E_NOSPT エラーとなる．た だし，動的生成機能拡張パッケージでは， acre_dtq もサポートする． acre_dtq に対しては， dtqmb に NULL 以外を指定できないという制限はない．

【 TOPPERS/FMP カーネルにおける規定】

FMP カーネル では， CRE_DTQ のみをサポートする．また， dtqmb には NULL のみを指 定することができる． NULL 以外を指定した場合には， E_NOSPT エラーとなる．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは， CRE_DTQ のみをサポートする．また， dtqmb には NULL のみを 指定することができる． NULL 以外を指定した場合には， E_NOSPT エラーとなる．

【μ ITRON4.0 仕様との関係】

μ ITRON4.0/PX 仕様にあわせて，データキュー生成情報の最後のパラメータを， dtq （データキュー領域の先頭番地）から， dtqmb （データキュー管理領域の先 頭番地）に改名した．また， TSZ_DTQ を TSZ_DTQMB に改名した．

TCNT_DTQMB を新設し，データキュー管理領域をアプリケーションで確 保する方 法を規定した．

【静的 API 】

【パラメータ】

【エラーコード】

【機能】

nodtq で指定した数のデータキュー ID を，データキューを生成するサービスコー ルによって割付け可能なデータキュー ID として確保する．

nodtq は整数定数式パラメータである．

【静的 API 】

【 C言語 API 】

【パラメータ】

＊アクセス許可ベクタ（パケットの内容）

【リターンパラメータ】

【エラーコード】

【機能】

dtqid で指定したデータキュー（対象データキュー）のアクセス許可ベクタ（ 4 つのアクセス許可パターンの組）を，各パラメータで指定した値に設定する．

静的 API においては， dtqid はオブジェクト識別名， acptn1 ～ acptn4 は整数定数 式パラメータである．

SAC_DTQ は，対象データキューが属する保護ドメインの囲みの中に記述しなけれ ばならない．そうでない場合には， E_RSATR エラーとなる．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは， SAC_DTQ ， sac_dtq をサポートしない．

【 TOPPERS/FMP カーネルにおける規定】

FMP カーネルでは， SAC_DTQ ， sac_dtq をサポートしない．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは， SAC_DTQ のみをサポートする．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

dtqid で指定したデータキュー（対象データキュー）を削除する．具体的な振舞 いは以下の通り．

対象データキューの登録が解除され，そのデータキュー ID が未使用の状態に戻 される．また，対象データキューの送信待ち行列と受信待ち行列につながれた タスクは，それぞれの待ち行列の先頭のタスクから順に待ち解除される．待ち 解除されたタスクには，待ち状態となったサービスコールから E_DLT エラーが返 る．

データキューの生成時に，データキュー管理領域がカーネルによって確保さ れ た場合は，そのメモリ領域が解放される．

【補足説明】

送信待ち行列と受信待ち行列の両方にタスクがつながれていることはないため， 別の待ち行列で待っていたタスクの間の待ち解除の順序は，規定する必要がな い．

【使用上の注意】

del_dtq により複数のタスクが待ち解除される場合，サービスコールの処理時間 およびカーネル内での割込み禁止時間が，待ち解除されるタスクの数に比例し て長くなる．特に，多くのタスクが待ち解除される場合，カーネル内での割込 み禁止時間が長くなるため，注意が必要である．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは， del_d tq をサポートしない．ただし，動的生成機能拡張パッ ケージでは， del_dtq をサポートする．

【 TOPPERS/FMP カーネルにおける規定】

FMP カーネルでは， del_dtq をサポートしない．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは， del_dtq をサポートしない．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

dtqid で指定したデータキュー（対象デ ータキュー）に， data で指定したデータ を送信する．具体的な振舞いは以下の通り．

対象データキューの受信待ち行列にタスクが存在する場合には，受信待ち行列 の先頭のタスクが， data で指定したデータを受信し，待ち解除される．待ち解 除されたタスクには，待ち状態となったサービスコールから E_OK が返る．

対象データキューの受信待ち行列にタスクが存在せず，データキュー管 理領域 にデータを格納するスペースがある場合には， data で指定したデータが， FIFO 順でデータキュー管理領域に格納される．

対象データキューの受信待ち行列にタスクが存在せず，データキュー管理領域 にデータを格納するスペースがない場合には，自タスクはデータキューへの送 信待ち状態となり，対象データキューの送信待ち行列につながれる．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

dtqid で指定したデータキュー（対象データキュー）に， data で指定したデータ を強制送信する．具体的な振舞いは以下の通り．

対象データキューの受信待ち行列にタスクが存在する場合には，受信待ち行列 の先頭のタスクが， data で指定したデータを受信し，待ち解除される．待ち解 除されたタスクには，待ち状態となったサービスコールから E_OK が返る．

対象データキューの受信待ち行列にタスクが存在せず，データキュー管理領域 にデータを格納するスペースがある場合には， data で指定したデータが， FIFO 順でデータキュー管理領域に格納される．

対象データキューの受信待ち行列にタスクが存在せず，データキュー管理領域 にデータを格 納するスペースがない場合には，データキュー管理領域の先頭に 格納されたデータを削除し，空いたスペースを用いて， data で指定したデータ が， FIFO 順でデータキュー管理領域に格納される．

対象データキューのデータキュー管理領域のサイズが 0の場合には， E_ILUSE エ ラーとなる．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

dtqid で指定したデータキュー（対象データキュー）からデータを受信する．受 信したデータは， p_data で指定したメモリ領域に返される．具体的な振舞いは 以下の通り．

対象データキューのデータキュー管理領域にデータが格納されている場合には， データキュー管理領域の先頭に格納されたデータが取り出され， p_data で指定 したメモリ領域に返される．また，送信待ち行列にタスクが存在する場合には， 送信待ち行列の先頭のタスクの送信データが， FIFO 順でデータキュー管理領域 に格納され，そのタスクは待ち解除される．待ち解除されたタスクには，待ち 状態となったサービスコールから E_OK が返る．

対象データキューのデー タキュー管理領域にデータが格納されておらず，送信 待ち行列にタスクが存在する場合には，送信待ち行列の先頭のタスクの送信デー タが， p_data で指定したメモリ領域に返される．送信待ち行列の先頭のタスク は，待ち解除される．待ち解除されたタスクには，待ち状態となったサービス コールから E_OK が返る．

対象データキューのデータキュー管理領域にデータが格納されておらず，送信 待ち行列にタスクが存在しない場合には，自タスクはデータキューからの受信 待ち状態となり，対象データキューの受信待ち行列につながれる．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

dtqid で指定したデータキュー（対象データキュー）を再初期化する．具体的な 振舞いは以下の通り．

対象データキューのデータキュー管理領域は，格納されているデータがない状 態に初期化される．また，対象データキューの送信待ち行列と受信待ち行列に つながれたタスクは，それぞれの待ち行列の先頭のタスクから順に待ち解除さ れる．待ち解除されたタスクには，待ち状態となったサービスコールから E_DLT エラーが返る．

【補足説明】

送信待ち行列と受信待ち行列の両方にタスクがつながれていることはないため， 別の待ち行列で待っていたタスクの間の待ち解除の順序は，規定する必要がな い．

【使用上の注意】

ini_dtq により複数のタスクが待ち解除される場合，サービスコールの処理時間 およびカーネル内での割込み禁止時間が，待ち解除されるタスクの数に比例し て長くなる．特に，多くのタスクが待ち解除される場合，カーネル内での割込 み禁止時間が長くなるため，注意が必要である．

データキューを再初期化した場合に，アプリケーションとの整合性を保つのは， アプリケーションの責任である．

【μ ITRON4.0 仕様との関係】

μ ITRON4.0 仕様に定義されていないサービスコールである．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

＊データキューの現在状態（パケットの内容）

【エラーコード】

【機能】

dtqid で指定したデータキュー（対象データキュー）の現在状態を参照する．参 照した現在状態は， pk_rdtq で指定したパケットに返される．

対象データキューの送信待ち行列にタスクが存在しない場合， stskid には TSK_NONE （＝ 0）が返る．また，受信待ち行列にタスクが存在しない場合， rtskid には TSK_NONE （＝ 0）が返る．

【使用上の注意】

ref_dtq はデバッグ時向けの機能であり， その他の目的に使用することは推奨し ない．これは， ref_dtq を呼び出し，対象データキューの現在状態を参照した直 後に割込みが発生した場合， ref_dtq から戻ってきた時には対象データキューの 状態が変化している可能性があるためである．

優先度データキューは， 1ワードのデータをメッセージとして，データの優先度 順で送受信するための同期・通信カーネルオブジェクトである．より大きいサ イズのメッセージを送受信したい場合には，メッセージを置いたメモリ領域へ のポインタを 1ワードのデータとして送受信する方法がある．優先度データキュー は，優先度データキュー ID と呼ぶ ID 番号によ って識別する．

各優先度データキューが持つ情報は次の通り．

• ・優先度データキュー属性
• ・優先度データキュー管理領域
• ・送信待ち行列（優先度データキューへの送信待ち状態のタスクのキュー）
• ・受信待ち行列（優先度データキューからの受信待ち状態のタスクのキュー）
• ・送信できるデータ優先度の最大値
• ・アクセス許可ベクタ（保 護機能対応カーネルの場合）
• ・属する保護ドメイン（保護機能対応カーネルの場合）
• ・属するクラス（マルチプロセッサ対応カーネルの場合）

優先度データキュー管理領域は，優先度データキューに送信されたデータを， データの優先度順に格納しておくためのメモリ領域である．優先度データキュー 生成時に，優先度データキュー管理領域に格納できるデータ数を 0とすることで， 優先度デー タキュー管理領域のサイズを 0とすることができる．

保護機能対応カーネルにおいて，優先度データキュー管理領域は，カーネルの 用いるオブジェクト管理領域として扱われる．

送信待ち行列は，優先度データキューに対してデータが送信できるまで待って いる状態（優先度データキューへの送信待ち状態）のタスクが，データを送信 できる順序でつながれているキューである．また，受信待ち行列は，優先度デー タキューからデータが受信できるまで待っている状態（優先度データキューか らの受信待ち状態）のタスクが，データを受信できる順序でつながれている キューである．

優先度データキュー属性には，次の属性を指定することができる．

TA_TPRI を指定しない場合，送信待ち行列は FIFO 順になる．受信待ち行列は， FIFO 順に固定されている．

優先度データキュー機能に関連するカーネル構成マクロは次の通り．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは，データ優先度の最大値（ TMAX_D PRI ）は 16 に固定されている． ただし，タスク優先度拡張パッケージでは， TMAX_DPRI を 256 に拡張する．

【 TOPPERS/FMP カーネルにおける規定】

FMP カーネルでは，データ優先度の最大値（ TMAX_DPRI ）は 16 に固定されている．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは，データ優先度の最大値（ TMAX_DPRI ）は 16 に固定されている．

【使用上の注意】

データの優先度が使われるのは，データが優先度データキュー管理領域に格納 される場合のみであり，データを送信するタスクが送信待ち行列につながれて いる間には使われない．そのため，送信待ち行列につながれているタスクが， 優先度データキュー管理領 域に格納されているデータよりも高い優先度のデー タを送信しようとしている場合でも，最初に送信されるのは，優先度データ キュー管理領域に格納されているデータである．また， TA_TPRI 属性の優先度デー タキューにおいても，送信待ち行列はタスクの優先度順となり，タスクが送信 しようとしているデータの優先度順となるわけではない．

【μ ITRON4.0 仕様との関係】

μ ITRON4.0 仕様に規定されていない機能である．

【静的 API 】

【 C言語 API 】

【パラメータ】

＊優先度データキューの生成情報（パケットの内容）

【リターンパラメータ】

【エラーコード】

【機能】

各パラメータで指定した優先度データキュー生成情報に従って，優先度データ キューを生成する． pdqcnt と pdqmb から優先度データキュー管理領域が設定され， 格納されているデータがない状態に初期化される．また，送信待ち行列と受信 待ち行列は，空の状態に初期化される．

静的 API においては， pdqid はオブジェクト識別名， pdqcnt と maxdpri は整数定数 式パラメータ， pdqmb は一般定数式パラメータである．コンフィギュレータは， 静的 API のメモリ不足（ E_NOMEM ）エラーを検出することができない．

pdqmb を NULL とした場合， pdqcnt で指定した数のデータを格納できる優先度デー タキュー管理領域を，コンフィギュレータまたはカーネルが確保する．

maxdpri は， TMIN_DPRI 以上， TMAX_DPRI 以 下でなければならない．

〔 pdqmb に NULL 以外を指定した場合〕

pdqmb に NULL 以外を指定した場合， pdqmb を先頭番地とする優先度データキュー 管理領域は，アプリケーションで確保しておく必要がある．優先度データキュー 管理領域をアプリケーションで確保するために，次のマクロを用意している．

これらを用いて優先度データキュー管理領域を確保する方法は次の通り．

この時， pdqmb には <優先度データキュー管理領域の変数名 >を指定する．

この方法に従わず， pdqmb にターゲット定義の制約に合致しな い先頭番地を指定 した時には， E_PAR エラーとなる．また，保護機能対応カーネルにおいて， pdqmb で指定した優先度データキュー管理領域がカーネル専用のメモリオブジェ クトに含まれない場合， E_OBJ エラーとなる．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは， CRE_PDQ のみをサポートする．また， pdqmb には NULL のみを指 定することができる． NULL 以外を指定した場合には， E_NOSPT エラーとなる．た だし，動的生成機能拡張パッケージでは， acre_pdq もサポートする． acre_pdq に対しては， pdqmb に NULL 以外を指定できないという制限はない．

【 TOPPERS/FMP カーネルにおける規定】

FMP カーネルでは， CRE_PDQ のみをサポートする．また， pdqmb には NULL のみを 渡 すことができる． NULL 以外を指定した場合には， E_NOSPT エラーとなる．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは， CRE_PDQ のみをサポートする．また， pdqmb には NULL のみを 渡すことができる． NULL 以外を指定した場合には， E_NOSPT エラーとなる．

【静的 API 】

【パラメータ】

【エラーコード】

【機能】

nopdq で指定した数の優先度データキュー ID を，優先度データキューを生成する サービスコールによって割付け可能な優先度データキュー ID として確保する．

nopdq は整数定数式パラメータである．

【静的 API 】

【 C言語 API 】

【パラメータ】

＊アクセス許可ベクタ（パケットの内容）

【リターンパラメータ】

【エラーコード】

【機能】

pdqid で指定した優先度データキュー（対象優先度データキュー）のアクセス許 可ベクタ（ 4 つのアクセス許可パターンの組）を，各パラメータで指定した値 に設定する．

静的 API においては， pdqid はオブジェクト識別名， acptn1 ～ acptn4 は整数定数 式パラメータである．

SAC_PDQ は，対象優先度データキューが属する保護ドメインの囲みの 中に記述し なければならない．そうでない場合には， E_RSATR エラーとなる．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは， SAC_PDQ ， sac_pdq をサポートしない．

【 TOPPERS/FMP カーネルにおける規定】

FMP カーネルでは， SAC_PDQ ， sac_pdq をサポートしない．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは， SAC_PDQ のみをサポートする．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

pdqid で指定した優先度データキュー（対象優先度データキュー）を削除する． 具体的な振舞いは以下 の通り．

対象優先度データキューの登録が解除され，その優先度データキュー ID が未使 用の状態に戻される．また，対象優先度データキューの送信待ち行列と受信待 ち行列につながれたタスクは，それぞれの待ち行列の先頭のタスクから順に待 ち解除される．待ち解除されたタスクには，待ち状態となったサービスコール から E_DLT エラーが返る．

優先度データキューの生成時に，優先度データキュー管理領域がカーネルによっ て確保された場合は，そのメモリ領域が解放される．

【補足説明】

送信待ち行列と受信待ち行列の両方にタスクがつながれていることはないため， 別の待ち行列で待っていたタスクの間の待ち解除の順序は，規定する必要がな い．

【使用上の注意】

del_pdq により複数のタスクが待ち解除される場合，サービスコールの処理時間 およびカーネル内での割込み禁止時間が，待ち解除されるタスクの数に比例し て長くなる．特に，多くのタスクが待ち解除される場合，カーネル内での割込 み禁止時間が長くなるため，注意が必要である．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは， del_pdq をサポートしない．ただし，動的生成機能拡張パッ ケージでは， del_pdq をサポートする．

【 TOPPERS/FMP カーネルにおける規定】

FMP カーネルでは， del_pdq をサポートしない．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは， del_pdq をサポートしない．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

pdqid で指定した優先度データキュー（対象優先度データキュー）に， data で指 定したデータを， datapri で指定した優先度で送信する．具体的な振舞いは 以下 の通り．

対象優先度データキューの受信待ち行列にタスクが存在する場合には，受信待 ち行列の先頭のタスクが， data で指定したデータを受信し，待ち解除される． 待ち解除されたタスクには，待ち状態となったサービスコールから E_OK が返る．

対象優先度データキューの受信待ち行列にタスクが存在せず，優先度データ キュー管理領域にデータを格納するスペ ースがある場合には， data で指定した データが， datapri で指定したデータの優先度順で優先度データキュー管理領域 に格納される．

対象優先度データキューの受信待ち行列にタスクが存在せず，優先度データ キュー管理領域にデータを格納するスペースがない場合には，自タスクは優先 度データキューへの送信待ち状態となり，対象優先度データキューの送信待ち 行列につながれる．

datapri は， TMIN_DPRI 以上で，対象データキューに送信できるデータ優先度の 最大値以下でなければならない．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

pdqid で指定した優先度データキュー（対象優先度データキュー）からデータを 受信する．受信したデータは p_data で指定したメモリ領域に，その優先度は p_datapri で指定したメモリ領域に返される．具体的な振舞いは以下の通り．

対象優先度データキューの優先度データキュー管理領域にデータが格納されて いる場合には，優先度データキュー管理領域の先頭に格納されたデータが取り 出され， p_data で指定したメモリ領域に返される．また，その優先度が p_datapri で指定したメモリ領域に返され る．さらに，送信待ち行列にタスクが 存在する場合には，送信待ち行列の先頭のタスクの送信データが，データの優 先度順で優先度データキュー管理領域に格納され，そのタスクは待ち解除され る．待ち解除されたタスクには，待ち状態となったサービスコールから E_OK が 返る．

対象優先度データキューの優先度データキュー管理領域にデータが格納されて おらず，送信待ち行列にタスクが存在する場合には，送信待ち行列の先頭のタ スクの送信データが， p_data で指定したメモリ領域に返される．また，その優 先度が p_datapri で指定したメモリ領域に返される．送信待ち行列の先頭のタス クは，待ち解除される．待ち解除されたタスクには，待ち状態となったサービ スコールから E_OK が返る．

対象優先度データキューの優先度データ キュー管理領域にデータが格納されて おらず，送信待ち行列にタスクが存在しない場合には，自タスクは優先度デー タキューからの受信待ち状態となり，対象優先度データキューの受信待ち行列 につながれる．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

pdqid で指定した優先度データキュー（対象優先度データキュー）を再初期化す る．具体的な振舞いは以下の通り．

対象優先度データキューの優先度データキュ ー管理領域は，格納されているデー タがない状態に初期化される．また，対象優先度データキューの送信待ち行列 と受信待ち行列につながれたタスクは，それぞれの待ち行列の先頭のタスクか ら順に待ち解除される．待ち解除されたタスクには，待ち状態となったサービ スコールから E_DLT エラーが返る．

【補足説明】

送信待ち行列と受信待ち行列の両方にタスクがつな がれていることはないため， 別の待ち行列で待っていたタスクの間の待ち解除の順序は，規定する必要がな い．

【使用上の注意】

ini_pdq により複数のタスクが待ち解除される場合，サービスコールの処理時間 およびカーネル内での割込み禁止時間が，待ち解除されるタスクの数に比例し て長くなる．特に，多くのタスクが待ち解除される場合，カーネル内での割込 み禁止時間が長くなるため，注意が必要である．

優先度データキューを再初期化した場合に，アプリケーションとの整合性を保 つのは，アプリケーションの責任である．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

＊優先度データキューの現在状態（パケットの内容）

【エラーコード】

【機能】

pdqid で指定した優先度データキュー（対象優先度データキュー）の現在状態を 参照する．参照した現在状態は， pk_rpdq で指定したパケットに返される．

対象優先度データキューの送信待ち行列にタスクが存在しない場合， stskid に は TSK_NONE （＝ 0）が返る．また，受信待ち行列にタスクが存在しない場合， rtskid には TSK_NONE （＝ 0）が返る．

【使用上の注意】

ref_pdq はデバッグ 時向けの機能であり，その他の目的に使用することは推奨し ない．これは， ref_pdq を呼び出し，対象優先度データキューの現在状態を参照 した直後に割込みが発生した場合， ref_pdq から戻ってきた時には対象優先度デー タキューの状態が変化している可能性があるためである．

メールボックスは，共有メモリ上に置いたメッセージを， FIFO 順またはメッセー ジの優先度順で送受信するための同期・通信オブジェクトである．メールボッ クスは，メールボックス ID と呼ぶ ID 番号によって識別する．

各メールボックスが持つ情報は次の通り．

• ・メールボックス属性
• ・メッセージキュー
• ・待ち行列（メールボックスからの受信待ち状態のタスクのキュー）
• ・送信できるメッセージ優先度の最大値
• ・優先度別のメッセージキューヘッダ領域
• ・属するクラス（マルチプロセッサ対応カーネルの場合）

メッセージキューは，メールボックスに送信されたメッセージを， FIFO 順また はメッセージの優先度順につないでおくためのキュー である．

待ち行列は，メールボックスからメッセージが受信できるまで待っている状態 （メールボックスからの受信待ち状態）のタスクが，メッセージを受信できる 順序でつながれているキューである．

メールボックス属性には，次の属性を指定することができる．

TA_TPRI を指定しない場合，待ち行列は FIFO 順になる． TA_MPRI を指定しない場 合，メッセージキューは FIFO 順になる．

優先度別のメッセージキューヘッダ領域は， TA_MPRI 属性のメールボックスに対 して，メッセージキューを優先度別に設ける場合に使用する領域である．

カーネルは，メールボックスに送信されたメッセージをメッセージキューにつ なぐために，メッセージの先頭のメモリ領域を使用する．そのためアプリケー ションは，メールボックスに送信するメッセージの先頭に，カーネルが利用す るためのメッセージヘッダを置かなければならない．メッセージヘッダのデー タ型として，メールボックス属性に TA_MPRI が指定されているか否かにより，以 下のいずれかを用いる．

メッセージヘッダの領域は，メッセージがメッセージキューにつながれている 間（すなわち，メールボックスに送信してから受信するまでの間），カーネル によって使用される．そのため，メッセージキューにつながれているメッセー ジのメッセージヘッダの領域をアプリケーションが書き換えた場合や，メッセー ジキューにつながれているメッセージを再度メールボックスに送信した場合の 動作は保証されない．

TA_MPRI 属性のメールボックスにメッセージを送信する場合，アプリケーション は，メッセージの優先度を， T_MSG_PRI 型のメッセ ージヘッダ中の msgpri フィー ルドに設定する．

保護機能対応カーネルでは，メールボックス機能はサポートしない．

メールボックス機能に関連するカーネル構成マクロは次の通り．

【補足説明】

TOPPERS 新世代カーネルの現時点の実装では，優先度別のメッセージキューヘッ ダ領域は用いていない．

【使用上の注意】

メールボックス機能は，μ ITRON4.0 仕様との互換性のために残した機能であり， 保護機能対応カーネルではサポートしないため，使用することは推奨しない． メールボックス機能は，ほとんどの場合に，データキュー機能または優先度デー タキュー機能を用いて，メッセージを置いたメモリ領域へのポインタを送受信 する方法で置き換えることができる．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは，メールボックス機能をサポートする．メッセージ優先度の最 大値（ TMAX_MPRI ）は 16 に固定されている．ただし，タスク優先度拡張パッケー ジでは， TMAX_MPRI を 256 に拡張する．

【 TOPPERS/FMP カーネルにおける 規定】

FMP カーネルでは，メールボックス機能をサポートする．メッセージ優先度の最 大値（ TMAX_MPRI ）は 16 に固定されている．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは，メールボックス機能をサポートしない．

【μ ITRON4.0 仕様との関係】

TNUM_MBXID は，μ ITRON4.0 仕様に規定されていないカーネル構成マクロである．

【静的 API 】

【 C言語 API 】

【パラメータ】

＊メールボックスの生成情報（パケットの内容）

【リターンパラメータ】

【エラーコード】

【機能】

各パラメータで指定したメールボックス生成情報に従って，メールボックスを 生成する．メッセージキューはつながれているメッセージがない状態に初期化 され， mprihd と maxmpri から優先度別のメッセージキューヘッダ領域が設定され る．また，待ち行列は空の状態に初期化される．

静的 API においては， mbxid はオブジェクト識別名， maxmpri は整数定数式パラメー タ， mprihd は一般定数式パラメータである．コンフィギュレータは，静的 API の メモリ不足（ E_NOMEM ）エラーを検出することができない．

mprihd を NULL とした場合， maxmpri の指定に合致したサイズの優先度別のメッセー ジキューヘッダ領域を，コンフィギュレータまたはカーネルが確保する．

maxmpri は， TMIN_MPRI 以上， TMAX_MPRI 以下でなければならない．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは， CRE_MBX のみをサポートする．また，優先度別のメッセージ キューヘッダ領域は使用しておらず， mprihd には NULL のみを指定することがで きる． NULL 以外を指定した場合には， E_NOSPT エラーとなる．ただし，動的生成 機能拡張パッケージでは， acre_mbx もサポートする． acre_mbx に対しても， mprihd には NULL のみを指定することができる．

【 TOPPERS/FMP カーネルにおける規定】

FMP カーネルでは， CRE_MBX のみをサポートする．また，優先度別のメッセージ キューヘッダ領域は使用しておらず， mprihd には NULL のみを渡すことができる． NULL 以外を指定した場合には， E_NOSPT エラーとなる．

【静的 API 】

【パラメータ】

【エラーコード】

【機能】

nombx で指定した数のメールボックス ID を，メールボックスを生成するサービス コールによって割付け可能なメールボ ックス ID として確保する．

nombx は整数定数式パラメータである．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

mbxid で指定したメールボックス（対象メールボックス）を削除する．具体的な 振舞いは以下の通り．

対象メールボックスの登録が解除され，そのメールボックス ID が未使用の状態 に戻される．また，対象メールボックスの待ち行列につながれたタスクは，待 ち行列の先頭のタスクから順に待ち解除される．待ち解除されたタスクには， 待ち状態となったサービスコールから E_DLT エラーが返る．

メールボックスの生成時に，優先度別のメッセージキューヘッダ領域がカーネ ルによって確保された場合は，そのメモリ領域が解放される．

【使用上の注意】

del_mbx により複数のタスクが待ち解除される場合，サービスコールの処理時間 およびカーネル内での割込み禁止時間が，待ち解除されるタスクの数に比例し て長くなる．特に，多くのタスクが待ち解除される場合，カーネル内での割込 み禁止時間が長くなるため，注意が必要である．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは， del_mbx をサポートしない．ただし，動的生成機能拡張パッ ケージでは， del_mbx を サポートする．

【 TOPPERS/FMP カーネルにおける規定】

FMP カーネルでは， del_mbx をサポートしない．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

mbxid で指定したメールボックス（対象メールボックス）に， pk_msg で指定した メッセージを送信する．具体的な振舞いは以下の通り．

対象メールボックスの待ち行列 にタスクが存在する場合には，待ち行列の先頭 のタスクが， pk_msg で指定したメッセージを受信し，待ち解除される．待ち解 除されたタスクには，待ち状態となったサービスコールから E_OK が返る．

対象メールボックスの待ち行列にタスクが存在しない場合には， pk_msg で指定 したメッセージが，メールボックス属性の TA_MPRI 指定の有無によって指定され る順序で，メッセージキューにつなぐ．

対象メールボックスが TA_MPRI 属性である場合には， pk_msg で指定したメッセー ジの先頭のメッセージヘッダ中の msgpri フィールドの値が， TMIN_MPRI 以上で， 対象メールボックスに送信できるメッセージ優先度の最大値以下でなければな らない．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

mbxid で指定したメールボックス（対象メールボックス）からメッセージを受信 する．受信したメッセージの先頭番地は， ppk_msg で指定したメモリ領域に返さ れる．具体的な振舞いは以下の通り．

対象メールボックスのメッセージキューにメッセージがつながれている場合に は，メッセージキューの先頭につながれたメッセージが取り出され， ppk_msg で 指定したメモリ領域に返される．

対象メールボックスのメッセージキューにメッセージがつながれていない場合 には，自タスクはメールボックスからの受信待ち状態となり，対象メールボッ クスの待ち行列につながれる．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

mbxid で指定したメールボックス（対象メールボックス）を再初期化する．具体 的な振舞いは以下の通り．

対象メールボックスのメールボックス管理領域は，メッセージキューはつなが れているメッセージがない状態に初期化される．また，対象メールボックスの 待ち行列につながれたタスクは，待ち行列の先頭のタスクから順に待ち解除さ れる．待ち解除されたタスクには，待ち状態となったサ ービスコールから E_DLT エラーが返る．

【使用上の注意】

ini_mbx により複数のタスクが待ち解除される場合，サービスコールの処理時間 およびカーネル内での割込み禁止時間が，待ち解除されるタスクの数に比例し て長くなる．特に，多くのタスクが待ち解除される場合，カーネル内での割込 み禁止時間が長くなるため，注意が必要である．

メールボックスを再初期化した場合に，アプリケーションとの整合性を保つのは， アプリケーションの責任である．

【μ ITRON4.0 仕様との関係】

μ ITRON4.0 仕様に定義されていないサービスコールである．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

＊メールボックスの現在状態（パケットの内容）

【エラーコード】

【機能】

mbxid で指定したメールボックス（対象メールボックス）の現在状態を参照する． 参照した現在状態は， pk_rmbx で指定したパケットに返される．

対象メールボックスの待ち行列にタスクが存在しない場合， wtskid には TSK_NONE （＝ 0）が返る．また，メッセージキューにメッセージがつながれてい ない場合， pk_msg には NULL が返る．

【使用上の注意】

ref_mbx はデバッグ時向けの機能であり，その他の目的に使用することは推奨し ない．これは， ref_mbx を 呼び出し，対象メールボックスの現在状態を参照した 直後に割込みが発生した場合， ref_mbx から戻ってきた時には対象メールボック スの状態が変化している可能性があるためである．

ミューテックスは，タ スク間の排他制御を行うための同期・通信オブジェクト である．タスクは，排他制御区間に入る時にミューテックスをロックし，排他 制御区間を出る時にロック解除する．ミューテックスは，ミューテックス ID と 呼ぶ ID 番号によって識別する．

ミューテックスは，排他制御に伴う優先度逆転の時間を最小限に抑えるための 優先度上限プロトコル（ priority ceiling protocol ）をサポートする ．ミュー テックス属性により優先度上限ミューテックスであると指定することで，その ミューテックスの操作時に，優先度上限プロトコルに従った現在優先度の制御 が行われる．

各ミューテックスが持つ情報は次の通り．

• ・ミューテックス属性
• ・ロック状態（ロックされている状態とロック解除されている状態）
• ・ミューテックスをロックしているタスク
• ・待ち行列（ミューテックスのロック待ち状態のタスクのキュー）
• ・上限優先度（優先度上限ミューテックスの場合）
• ・アクセス許可ベクタ（保護機能対応カーネルの場合）
• ・属する保護ドメイン（保護機能対応カーネルの場合）
• ・属するクラス（マルチプロセッサ対応カーネルの場合）

待ち行列は，ミューテックスをロ ックできるまで待っている状態（ミューテッ クスのロック待ち状態）のタスクが，ミューテックスをロックできる順序でつ ながれているキューである．

上限優先度は，優先度上限ミューテックスに対してのみ有効で，ミューテック スの生成時に，そのミューテックスをロックする可能性のあるタスクのベース 優先度の中で最も高い優先度（または，それより高い優先度）に設定する．

ミューテックス属性には，次の属性を指定することができる．

TA_TPRI ， TA_CEILING のいずれも指定しない場合，待ち行列は FI FO 順になる．

ミューテックス機能に関連して，各タスクが持つ情報は次の通り．

• ・ロックしているミューテックスのリスト

ロックしているミューテックスのリストは，タスクの起動時に空に初期化され る．

タスクの現在優先度は，そのタスクのベース優先度と，そのタスクがロックし ている優先度上限ミューテックスの優先度上限の中で，最も高い優先度に設定 される．

ミューテックス機能によりタスクの現在優先度が変化する場合には，次の処理 が行われる．現在優先度を変化させるサービスコールの前後とも，当該タスク が実行できる状態である場合には，同じ優先度のタスクの中で最高優先順位と なる．そのサービスコールにより，当該タスクが実行できる状態に遷移する場 合には，同じ優先度のタスクの中で最低優先順位となる．そのサービスコール の後で，当該タスクが待ち状態で，タスクの優先度順の待ち行列につながれて いる場合には，当該タスクの変更後の現在優先度に従って，その待ち行列中で の順序が変更される．待ち行列中に同じ現在優先度のタスクがある場合には， 当該タスクの順序はそれらの中で最後になる．

ミューテックス機能に関連して，タスクの 終了時に行うべき処理として，タス クがロックしているミューテックスのロック解除がある．タスクの終了時にロッ クしているミューテックスが残っている場合，それらのミューテックスは，ロッ クしたのと逆の順序でロック解除される．

ミューテックス機能に関連するカーネル構成マクロは次の通り．

【使用上の注意】

優先度上限プロトコルには， (a) 優先度の低いタスクの排他制御区間に最大 1回 しかブロックされない， (b) タスクの実行が開始された以降は優先度の低いタ スクにブロックされないという利点があるが，これは，タスク間の同期に優先 度上限ミューテックスのみを用い，他の方法でタスクのスケジューリングに関 与しない場合に得られる利点である．

これらの利点を得るためには，タスクの優先順位の回転やディスパッチの禁止 を行ってはならないことに加えて，優先度上限ミューテックスをロックしたタ スクを待ち状態にしてはならない．特に，優先度上 限ミューテックスに対して， タスクがロック待ち状態になる状況に注意が必要である（優先度上限プロトコ ルでは，タスクがミューテックスのロック待ち状態になることはない）．

例えば，着目するタスク Aと，タスク Aよりベース優先度の低いタスク Bとタスク C ，タスク Aよりも高い上限優先度を持った優先度上限ミューテックスがある場 合を考える．タスク Aがミューテックスをロックし，タスク Bとタスク Cがミュ ー テックスを待っている状況で，タスク Aがミューテックスをロック解除すると， タスク Bがミューテックスをロックして優先度が上がり，タスク Bに切り換わる． さらにタスク Bがミューテックスをロック解除すると，タスク Cがミューテック スをロックして優先度が上がり，タスク Cに切り換わる．タスク Aが実行される のは，タスク Cがミューテックスをロック解除した後である．この例では，タス ク Aが実行開始後 に，タスク Bとタスク Cの排他制御区間にブロックされることに なる．

優先度上限ミューテックスに対してタスクがロック待ち状態になる状況を回避 するためには，優先度上限ミューテックスをロックする場合に，待ち状態にな らない ploc_mtx を用いるのが安全である．

【補足説明】

この仕様で優先度上限プロトコルと呼んでいる方式は，オリジナルの priority ceiling protocol とは異なるものである．この仕様の方式は， OSEK/VDX OS 仕様 でも priority ceiling protocol と呼ばれているが，学術論文や他の OS では， immediate ceiling priority protocol ， priority protection protocol ， p riority ceiling emulation ， highest locker protocol などと呼ばれている．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルでは，ミューテックス機能をサポートしない．ただし，ミューテッ クス機能拡張パッケージを用いると，ミューテックス機能を追加することがで きる．

【 TOPPERS/FM Pカーネルにおける規定】

FMP カーネルでは，ミューテックス機能をサポートしない．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは，ミューテックス機能をサポートする．

【未決定事項】

マルチプロセッサにおいては，タスク間の同期に優先度上限ミューテックスの み を用い，他の方法でタスクのスケジューリングに関与しない場合でも，優先 度上限ミューテックスに対してタスクがロック待ち状態になる．マルチプロセッ サ対応カーネルにおける優先度上限ミューテックスの扱いについては，今後の 課題である．

【μ ITRON4.0 仕様との関係】

μ ITRON4.0 仕様の厳密な優先度制御規則を採用し，簡略化した優先度制御規則 はサポートしていない．また，μ ITRON4.0 仕様でサポートしている優先度継承 プロトコル（ priority inheritance protocol ）は，現時点ではサポートしてい ない．

ミューテックス機能によりタスクの現在優先度が変化する場合の振舞いは， μ ITRON4.0 仕様では実装依存となっているが，この仕様では規定している．

TNUM_ MTXID は，μ ITRON4.0 仕様に規定されていないカーネル構成マクロであ る．

【静的 API 】

【 C言語 API 】

【パラメータ】

＊ミューテックスの生成情報（パケットの内容）

【リターンパラメータ】

【エラーコード】

【機能】

各パラメータで指定したミューテックス生成情報に従って，ミューテックスを 生成する．生成されたミューテックスのロック状態はロックされていない状態 に，待ち行列は空の状態に初期化される．

静的 API においては， mtxid はオブジェクト識別名， ceilpri は整数定数式パラメー タである．優先度上限ミューテックス以外の場合には， ceilpri の指定を省略す ることができる．

優先度上限ミューテックスを生成する場合， ceilpri は， TMIN_TPRI 以上， TMAX_TPRI 以下でなければならない．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルのミューテックス機能拡張パッケージでは， CRE_MTX のみをサポー トする．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは， CRE_MTX のみをサポートする．

【静的 API 】

【パラメータ】

【エラーコード】

【機能】

nomtx で指定した数のミューテックス ID を，ミューテックスを生成するサービス コールによって割付け可能なミューテックス ID として確保する．

nomtx は整数定数式パラメータである．

【静的 API 】

【 C言語 API 】

【パラメータ】

＊アクセス許可ベクタ（パケットの内容）

【リターンパラメータ】

【エラーコード】

【機能】

mtxid で指定したミューテックス（対象ミューテックス）のアク セス許可ベクタ （ 4つのアクセス許可パターンの組）を，各パラメータで指定した値に設定する．

静的 API においては， mtxid はオブジェクト識別名， acptn1 ～ acptn4 は整数定数 式パラメータである．

SAC_MTX は，対象ミューテックスが属する保護ドメインの囲みの中に記述しなけ ればならない．そうでない場合には， E_RSATR エラーとなる．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルのミューテックス機能拡張パッケージでは， SAC_MTX ， sac_mtx をサ ポートしない．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは， SAC_MTX のみをサポートする．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】

【機能】

mtxid で指定したミューテックス（対象ミューテックス）を削除する．具体的な 振舞いは以下の通り．

対象ミューテックスの登録が解除され，そのミューテックス ID が未使用の状態 に戻される．対象ミューテックスをロックしているタスクがある場合には，そ のタスクがロックしているミューテックスのリストから対象ミューテックスが 削除され，必要な場合にはそのタスクの現在優先度が変更される．また，対象 ミューテックスの待ち行列につながれたタスクは，待ち行列の先頭のタスクか ら順に待ち解除される．待ち解除されたタスクには，待ち状態となったサービ スコールから E_DLT エラーが返る．

【使用上の注意】

対象ミューテックスをロックしているタスクには，ミューテックスが削除され たことが通知されず，そのミューテックスをロック解除する時点でエラーとな る．これが不都合な場合には，ミューテックスをロックした状態で，ミューテッ クスを削除すればよい．

del_mtx により複数のタスクが待ち解除される場合，サービスコールの処理時間 およびカーネル内での割込み禁止時間が，待ち解除される タスクの数に比例し て長くなる．特に，多くのタスクが待ち解除される場合，カーネル内での割込 み禁止時間が長くなるため，注意が必要である．

【 TOPPERS/ASP カーネルにおける規定】

ASP カーネルのミューテックス機能拡張パッケージでは， del_mtx をサポートし ない．

【 TOPPERS/HRP2 カーネルにおける規定】

HRP2 カーネルでは， del_mtx をサポートしない．

【 C言語 API 】

【パラメータ】

【リターンパラメータ】

【エラーコード】