TOPPERS 新世代カーネル統合仕様書

バージョン : Release 1.4.0

最終更新 : 2012 年 5月 16 日

このドキュメントは, TOPPERS 新世代カーネルに属する一連のリアルタイムカー ネルの仕様を,統合的に記述するものである.現時点で, TOPPERS/ASP カーネル, TOPPERS/FMP カーネル, TOPPERS/HRP2 カーネル, TOPPERS/SSP カーネルの仕様に 関しては記述が完成しているが,未完成部分も残っている.特に動的生成対応 カーネルについては,仕様検 討が不十分なところが多い.なお,本文中から参 照している図は,ファイルの最後にまとめて掲載してある.

なお, TOPPERS/SSP カーネルは, Release 1.1.0 の時点では,この仕様に準拠し ていない.今後のリリースでは,この仕様に準拠するよう修正される予定であ る.


TOPPERS New Generation Kernel Specification

Copyright (C) 2006 -2012 by Embedded and Real -Time Systems Laboratory Graduate School of Information Science, Nagoya Univ., JAPAN

Copyright (C) 2006 -2012 by TOPPERS Project, Inc., JAPAN

上記著作権者は,以下の (1) ~ (3) の条件を満たす場合に限り,本ドキュメ ント(本ドキュメントを改変したものを含む.以下同じ)を使用・複製 ・改 変・再配布(以下,利用と呼ぶ)することを無償で許諾する.

本ドキュメントは,無保証で提供されているものである.上記著作権者およ び TOPPERS プロジェクトは,本ドキュメントに関して,特定の使用目的に対す る適合性も含めて,いかなる保証も行わない.また,本ドキュメントの利用 により直接的または間接的に生じたいかなる損害に関しても,その責任を負 わない.


○目次

第1章 TOPPERS 新世代カーネルの概要

1.1 TOPPERS 新世代カーネル仕様の位置付け

1.2 TOPPERS 新世代カーネル仕様の設計方針

1.3 TOPPERS/ASP カーネルの適用対象領域と仕様設計方針

1.4 TOPPERS/FMP カーネルの適用対象領域と仕様設計方針

1.5 TOPPERS/HRP2 カーネルの適用対象領域と仕様設計方針

1.6 TOPPERS/SSP カーネルの適用対象領域と仕様設計方針

1.7 TOPPERS/ASP Safety カーネルの適用対象領域と仕様設計方針

第2章 主要な概念と共通定義

2.1 仕様の位置付け

2.1.1 カーネルの機能セット

2.1.2 ターゲット非依存の規定とターゲット定義の規定

2.1.3 想定するソフトウェア構成

2.1.4 想定するハードウェア構成

2.1.5 想定するプログラミング言語

2.2 API の構成要素とコンベンション

2.2.1 API の構成要素

2.2.2 パラメータ とリターンパラメータ

2.2.3 返値とエラーコード

2.2.4 機能コード

2.2.5 ヘッダファイル

2.3 主な概念

2.3.1 オブジェクトと処理単位

2.3.2 サービスコールとパラメータ

2.3.3 保護機能

2.3.4 マルチプロセッサ対応

2.3.5 その他

2.4 処理単位の種類と実行

2.4.1 処理単位の種類

2.4.2 処理単位の実行順序

2.4.3 カーネル処理の不可分性

2.4.4 処理単位を実行するプロセッサ

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

2.5.1 カーネル動作状態と非動作状態

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

2.5.3 カーネルの振舞いに影響を与える状態

2.5.4 全割込みロック状態と全割込みロック解除状態

2.5.5 CPU ロック状態と CPU ロック解除状態

2.5.6 割込み優先度マスク

2.5.7 ディスパッチ禁止状態とディスパッチ許可状態

2.5.8 ディスパッチ保留状態

2.5.9 カーネル管理外の状態

2.5.10 処理単位の開始・終了とシステム状態

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

2.6.1 基本的なタスク状態

2.6.2 タスクの状態遷移

2.6.3 タスクのスケジューリング規則

2.6.4 待ち行列と待ち解除の順序

2.6.5 タスク例外処理マスク状態と待ち禁 止状態

2.6.6 ディスパッチ保留状態で実行中のタスクに対する強制待ち

2.6.7 制約タスク

2.7 割込み処理モデル

2.7.1 割込み処理の流れ

2.7.2 割込み優先度

2.7.3 割込み要求ラインの属性

2.7.4 割込みを受け付ける条件

2.7.5 割込み番号と割込みハンドラ番号

2.7.6 マルチプロセッサにおける割込み処理

2.7.7 カーネル管理外の割込み

2.7.8 カーネル管理外の割込みの設定方法

2.8 CPU 例外処理モデル

2.8.1 CPU 例外処理の流れ

2.8.2 CPU 例外ハンドラから呼び出せるサービスコール

2.8.3 エミュレートされた CPU 例外ハンドラ

2.8.4 カーネル管理外の CPU 例外

2.9 システムの初期化と終了

2.9.1 システム初期化手順

2.9.2 システム終了手順

2.10 オブジェクトの登録とその解除

2.10.1 ID 番号で識別するオブジェクト

2.10.2 オブジェクト番号で識別するオブジェクト

2.10.3 識別番号を持たないオブジェクト

2.10.4 オブジェクト生成に必要なメモリ領域

2.10.5 オブジェクトが属する保護ドメインの設定

2.10.6 オブジェクトが属するクラスの設定

2.10.7 オブジェクトの状態参照

2.11 オブジェクトのアクセス保護

2.11.1 オブジェクトのアクセス保護とアクセス違反の通知

2.11.2 メモリオブジェクトに対す るアクセス許可ベクタの制限

2.11.3 デフォルトのアクセス許可ベクタ

2.11.4 アクセス許可ベクタの設定

2.11.5 カーネルの管理領域のアクセス保護

2.11.6 ユーザタスクのユーザスタック領域

2.12 システムコンフィギュレーション手順

2.12.1 システムコンフィギュレーションファイル

2.12.2 静的 API の文法とパラメータ

2.12.3 保護ドメインの指定

2.12.4 クラスの指定

2.12.5 コンフィギュレータの処理モデル

2.12.6 静的 API のパラメータに関するエラー検出

2.12.7 オブジェクトの ID 番号の指定

2.13 TOPPERS ネーミングコンベンション

2.13.1 モジュール識別名

2.13.2 データ型名

2.13.3 関数名

2.13.4 変数名

2.13.5 定数名

2.13.6 マクロ名

2.13.7 静的 API 名

2.13.8 ファイル名

2.13.9 モジュール内部の名称の衝突回避

2.14 TO PPERS 共通定義

2.14.1 TOPPERS 共通ヘッダファイル

2.14.2 TOPPERS 共通データ型

2.14.3 TOPPERS 共通定数

2.14.4 TOPPERS 共通エラーコード

2.14.5 TOPPERS 共通マクロ

2.14.6 TOPPERS 共通構成マクロ

2.15 カーネル共通定義

2.15.1 カーネルヘッダファイル

2.15.2 カーネル共通定数

2.15.3 カーネル共通マクロ

2.15.4 カーネル共通構成マクロ

第3章 システムインタフェースレイヤ API 仕様

3.1 システムインタフェースレイヤの概要

3.2 SIL ヘッダファイル

3.3 全割込みロック状態の制御

3.4 SIL スピンロック

3.5 微少時間待ち

3.6 エンディアンの取得

3.7 メモリ空間アクセス関数

3.8 I/O 空間アクセス関数

3.9 プロセッサ ID の参照

第4章 カーネル API 仕様

4.1 タスク管理機能

4.2 タ スク付属同期機能

4.3 タスク例外処理機能

4.4 同期・通信機能

4.4.1 セマフォ

4.4.2 イベントフラグ

4.4.3 データキュー

4.4.4 優先度データキュー

4.4.5 メールボックス

4.4.6 ミューテックス

4.4.7 メッセージバッファ(☆未完成)

4.4.8 スピンロック

4.5 メモリプール管理機能

4.5.1 固定長メモリプール

4.6 時間管理機能

4.6.1 システム時刻管理

4.6.2 周期ハンドラ

4.6.3 アラームハンドラ

4.6.4 オーバランハンドラ

4.7 システム状態管理機能

4.8 メモリオブジェクト管理機能

4.9 割込み管理機能

4.10 CPU 例外管理機能

4.11 拡張サービスコール管理機能

4.12 システム構成管理機能

第5章 リファレンス

5.1 サービスコール一覧

5.2 静的 API 一覧

5.3 データ型

5.3.1 TOPPERS 共通データ型

5.3.2 カーネルの使用するデータ型

5.3.3 カーネルの使用するパケット形式

5.4 定数とマクロ

5.4.1 TOPPERS 共通定数

5.4.2 TOPPERS 共通マクロ

5.4.3 カーネル共通定数

5.4.4 カーネル共通マクロ

5.4.5 カーネルの 機能毎の定数

5.4.6 カーネルの機能毎のマクロ

5.5 構成マクロ

5.5.1 TOPPERS 共通構成マクロ

5.5.2 カーネル共通構成マクロ

5.5.3 カーネルの機能毎の構成マクロ

5.6 エラーコード一覧

5.7 機能コード一覧

5.8 カーネルオブジェクトに対するアクセスの種別

5.9 省略名の元になった英語

5.9.1 サービスコールと静的 API の名称の中の xxx の元になった英語

5.9.2 サービスコールと静的 API の名称の中の yyy の元になった英語

5.9.3 サービスコールの名称の中の zの元になった英語

5.10 バージョン履歴

第1章 TOPPERS 新世代カーネルの概要

TOPPERS 新世代カーネルとは, TOPPERS プロジェクトにおいて ITRON 仕様をベース として開発している一連のリアルタイムカーネルの総称である.この章では, TOPPERS 新世代カーネル仕様の位置付けと設計方針,それに属する各カーネルの 適用対象領域と設計方針について述べる.

1.1 TOPPERS 新世代カーネル仕様の位置付け

TOP PERS プロジェクトでは, 2000 年に公開した TOPPERS/JSP カーネルを始めとし て,μ ITRON4.0 仕様およびその保護機能拡張(μ ITRON4.0/PX 仕様)に準拠した リアルタイムカーネルを開発してきた.

μ ITRON4.0 仕様は 1999 年に,μ ITRON4.0/PX 仕様は 2002 年に公表されたが,それ 以降現在までの間に,大きな仕様改訂は実施されていない.その間に,組込み システムおよびソフトウェアのますますの大規模化・複雑化,これまで以上に 高い信頼性・安全性に対する要求,小さい消費エネルギー下での高い性能要求 など,組込みシステム開発を取り巻く状況は刻々変化している.リアルタイム カーネルに対しても,マルチプロセッサへの対応,発展的な保護機能のサポー ト,機能安全対応,省エネルギー制御機能のサポートなど,新しい要求が生じ ている.

TOPPERS プロジェクトでは,リアルタイムカーネルに対するこのような新しい要 求に対応するために,μ ITRON4.0 仕様を発展させる形で, TOPPERS 新世代カーネ ル仕様を策定することになった.

ただし, ITRON 仕様が,各社が開発するリアルタイムカーネルを標準化すること を目的に,リアルタイムカーネルの「標準仕様」を規定することを目指してい るのに対して, TOP PERS 新世代カーネル仕様は, TOPPERS プロジェクトにおいて 開発している一連のリアルタイムカーネルの「実装仕様」を記述するものであ り, ITRON 仕様とは異なる目的・位置付けを持つものである.

1.2 TOPPERS 新世代カーネル仕様の設計方針

TOPPERS 新世代カーネル仕様を設計するにあたり,次の方針を設定する.

  • (1) μ ITRON 4.0 仕様をベースに拡張・改良を加える

    TOPPERS 新世代カーネル仕様は,多くの技術者の尽力により作成され,多くの実 装・使用実績があるμ ITRON4.0 仕様をベースとする.ただし,μ ITRON4.0 仕様 の策定時以降の状況の変化を考慮し,μ ITRON4.0 仕様で不十分と考えられる点 については積極的に拡張・改良する.μ ITRON4.0 仕様への準拠性にはこだわら ない.

  • (2) ソフトウェアの再利用性を重視する

    μ ITRON4.0 仕様の策定時点と比べると,組込みソフトウェアの大規模化が進展 している一方で,ハードウェアの性能向上も著しい.そのため,ソフトウェア の再利用性を向上させるためには,少々のオーバヘッドは許容される状況にあ る.

    そこで, TOPPERS 新世代カーネル仕様では,μ ITRON4.0 仕様においてオーバヘッ ド削減のために実装定義または実装依存としていたような項目についても,ター ゲットシステムに依存する項目とするのではなく,強く規定する方針とする.

  • (3) 高信頼・安全なシステム構築を支援する

    TOPPERS 新世代カーネル仕様は,高信頼・安全な組込みシステム構築を支援する ものとする.

    安全性の面では,アプリケーションプログラムに問題がある場合でも,リーゾ ナブルなオーバヘッドでそれを救済できるなら,救済するような仕様とする. また,アプリケーションプログラムの誤動作を検出する機能や,システムの自 己診断のための機能についても,順次取り込んでいく.

  • (4) アプリケーションシステム構築に必要な機能は積極的に取り込む

    上記の方針を満たした上で,多くのアプリケーションシステムに共通に必要と なる機能については,積極的にカーネルに取り込む.

    カーネル単体の信頼性を向上させるためには,カーネルの機能は少なくした方 が楽である.しかし,アプリケーションシステム構築に必要となる機能は,カー ネルがサポートしていなければアプリケーションプログラムで実現しなければ ならず,システ ム全体の信頼性を考えると,多くのアプリケーションシステム に共通に必要となる機能については,カーネルに取り込んだ方が有利である.

1.3 TOPPERS/ASP カーネルの適用対象領域と仕様設計方針

TOPPERS/ASP カーネル( ASP は, Advanced Standard Profile の略.以下, ASP カー ネル)は, TOPPERS 新世代カーネルの出発点となるリアルタイムカーネルである. 保護機能を持ったカーネルやマルチプロセッサ対応のカーネルは, ASP カーネル を拡張する形で開発する.

ASP カーネルは, 20 年以上に渡る ITRON 仕様の技術開発成果をベースとして,完 成度の高いリアルタイムカーネルを実現するものである.完成度を高めるとい う観点から,カーネル本体の仕様に ついては,枯れた技術で実装できる範囲に 留める.

ASP カーネルの主な適用対象は,高い信頼性・安全性・リアルタイム性を要求さ れる組込みシステムとする.ソフトウェア規模の面では,プログラムサイズ (バイナリコード)が数十 KB ~ 1MB 程度のシステムを主な適用対象とする.それ より大規模なシステムには,保護機能を持ったリアルタイムカーネルを適用す べきと考えられる.

ASP カーネルの機能は,カーネル内で動的なメモリ管理が不要な範囲に留める. これは,高い信頼性・安全性・リアルタイム性を要求される組込みシステムで は,システム稼働中に発生するメモリ不足への対処が難しいためである.この 方針から,カーネルオブジェクトは静的に生成することとし,動的なオブジェ クト生成機能は設けない.ただし,アプリケーションプログラムが動的なメモ リ管理をす るためのカーネル機能である固定長メモリプール機能はサポートす る.

1.4 TOPPERS/FMP カーネルの適用対象領域と仕様設計方針

TOPPERS/FMP カーネル( FMP は, Flexible Multiprocessor Profile の略.以下, FMP カーネル)は, ASP カーネルを,マルチプロセッサ対応に拡張したリアルタ イムカーネルである.

FMP カーネルの適用対象となるターゲットハードウェアは,ホモジニアスなマル チプロセッサシステムである.各プロセッサが全く同一のものである必要はな いが,すべてのプロセッサでバイナリコードを共有することから,同じバイナ リコードを実行できることが必要である.

FMP カーネルでは,タスクを実行するプロセッサを静的に決定するのが基本であ り,カーネル は自動的に負荷分散する機能を持たないが,タスクをマイグレー ションさせるサービスコールを備えている.これを用いて,アプリケーション で動的な負荷分散を実現することが可能である.

FMP カーネルの機能は, ASP カーネルと同様に,カーネル内で動的なメモリ管理 が不要な範囲に留める.

1.5 TOPPERS/HRP2 カーネルの適用対象領域と仕様設計方針

TOPPERS/HRP2 カーネル( HRP は, High Reliable system Profile の略. 2はバー ジョン番号を示す.以下, HRP2 カーネル)は,さらに高い信頼性・安全性を要 求される組込みシステムや,より大規模な組込みシステム向けに適用できるよ うに, ASP カーネルを拡張したリアルタイムカーネルである.

HRP2 カーネルの適用対象となるターゲットハードウェアは,特権 モードと非特 権モードを備え,メモリ保護のために MMU ( Memory Management Unit )または MPU ( Memory Protection Unit )を持つプロセッサを用いたシステムである. HRP2 カーネルの主な適用対象は,ソフトウェア規模の面では,プログラムサイ ズ(バイナリコード)が数百 KB 以上のシステムである.

HRP2 カーネルの機能は, ASP カーネルと同様に,カーネル内で動的なメモリ管理 が不要な範囲に留める.具体的には, ASP カーネルに対して,メモリ保護機能と オブジェクトアクセス保護機能,拡張サービスコール機能,ミューテックス機 能,オーバランハンドラ機能を追加し,メールボックス機能を削除している.

1.6 TOPPERS/SSP カーネルの適用対象領域と仕様設計方針

TOPPERS/SSP カーネル( SSP は, Smallest Set Profile の略.以下, SSP カーネル) は,小規模システムに用いるために, ASP カーネルをベースに可能な限り機能を 絞り込んだリアルタイムカーネルである.

SSP カーネルの機能は,μ ITRON4.0 仕様の「仕様準拠の最低条件」の考え方を踏 襲し,メモリ使用量を最小化するように定めている.具体的には, SSP カーネル においては,タスクは待ち状態を持たない(言い換えると,制約タスクのみを サポートする)のが最大の特徴である.また, ASP カーネルに対して下位互換性 を持つように配慮しているが,システム全体のメモリ使用量を最小化するため に有用な機能は, ASP カーネルに対して追加している.

TOPPERS/SSP カーネルの主な適用対象は,プログラムサイズ(バイナリコード) が数 KB ~数 十 KB 程度の極めて小規模な組込みシステムである.

1.7 TOPPERS/ASP Safety カーネルの適用対象領域と仕様設計方針

TOPPERS/ASP Safety カーネル(以下, ASP Safety カーネル)は,小規模な安全 関連システムに用いるために, ASP カーネルの機能を徹底的な検証が可能な範囲 にサブセット化したものである.メールボックスのように安全性の観点から問 題のある機能や,タスク例外処理機能のように使用頻度に比べて検証にコスト のかかる機能はサポートしない.

ASP Safety カーネルの主な適用対象は,特に高い安全性を要求される組込みシ ステムとする.ソフトウェア規模の面では,プログラムサイズ(バイナリコー ド)が数十 KB ~ 1MB 程度のシステムを主な適用対象とする.それより大規模なシ ステムには,保護機能を持ったカーネルを適用すべきと考えられる.

第2章 主要な概念と共通定義

2.1 仕様の位置付け

この仕様は, TOPPERS 新世代カーネルに属する各カーネルの仕様を,統合的に記 述することを目標としている.また, TOPPERS 新世代カーネル上で動作する各種 のシステムサービスに共通に 適用される事項についても規定する.

2.1.1 カーネルの機能セット

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 仕様に対して保護機能を追加するための仕様であり,カー ネルオブジェクトの動的生成機能と保護機能を持っているが,マルチプロセッ サには対応していない.

2.1.2 ターゲット非依存の規定とターゲット定義の規定

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

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

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

2.1.3 想定するソフトウェア構成

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

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

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

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

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

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

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

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

2.1.4 想定するハードウェア構成

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

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

2.1.5 想定するプログラミング言語

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

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

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

2.2 API の構成要素とコンベンション

2.2.1 API の構成要素

  • (1) サービスコール

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

  • (2) コールバック

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

  • (3) 静的 API

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

  • (4) 構成マクロ

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

2.2.2 パラメータとリターンパラメータ

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

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

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

複数のパ ラメータまたはリターンパラメータを入れるための構造体を,パケッ ト( packet )と呼ぶ.

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

2.2.3 返値とエラーコード

一部の例外を除いて,サービスコールおよびコールバックの返値は,処理が正 常終了したかを表す符号付き整数とする.処理が正常終了した場合には, 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 のパラメータに関するエラー検出」の節を参照すること.

2.2.4 機能コード

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

2.2.5 ヘッダファイル

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

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

2.3 主な概念

2.3.1 オブジェクト と処理単位

  • (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 )と呼ぶ.

2.3.2 サービスコールとパラメータ

  • (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)を指定する ことによって行う.ノンブロッキングの指定を行えるサービスコールは,指定 した場合の振舞いをサービスコール毎に規定する.

    【補足説明】

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

2.3.3 保護機能

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

  • (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);

【補足説明】

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

2.3.4 マルチプロセッサ対応

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

  • (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 の扱いも未決定であるため,今後の課題とする.

2.3.5 その他

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

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

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

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

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

    【補足説明】

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

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

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

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

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

2.4 処理単位の種類と実行順序

2.4.1 処理単位の種類

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

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

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

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

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

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

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

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

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

2.4.2 処理単位の実行順序

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

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

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

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

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

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

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

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

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

【仕様決定の理由】

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

2.4.3 カーネル処理の不可分性

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

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

【補足説明】

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

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

2.4.4 処理単位を実行するプロセッサ

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

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

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

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

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

  初期割付けプロセッサ 割付け可能プロセッサ
タスク(タスク例外処理ルーチンを含む)
割込みハンドラ
割込みサービスルーチン
周期ハンドラ
アラームハンドラ
CPU 例外ハンドラ
ローカル初期化ルーチン
ローカル終了処理ルーチン

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

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

2.5.1 カーネル動作状態と非動作状態

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

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

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

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

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

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

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

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

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

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

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

2.5.3 カーネルの振舞いに影響を与える状態

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

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

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

2.5.4 全割込みロック状態と全割込みロ ック解除状態

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

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

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

2.5.5 CPU ロック状態と CPU ロック解除状態

プロセッサは,カーネル管理の割込み(「 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 ロック状態を使って他 のプロセッサで実行される処理単位との排他制御を実現することはできない.

2.5.6 割込み優先度マスク

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

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

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

2.5.7 ディスパッチ禁止状態とディスパッチ許可状態

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

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

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

【補足説明】

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

2.5.8 ディスパッチ保留状態

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

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

【補足説明】

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

2.5.9 カーネル管理外の状態

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

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

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

2.5.10 処理単位の開始・終了とシステム状態

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

  CPU ロックフラグ 割込み優先度マスク ディスパッチ禁止フラグ
【タスク】
実行開始条件 解除 全解除 許可
実行開始時処理 そのまま そのまま そのまま
終了前 原則解除 (*1) 原則全解除 (*1) 原則許可 (*1)
終了時処理 解除する 全解除する 許可する
【タスク例外処理ルーチン】
実行開始条件 解除 全解除 任意
実行開始時処理 そのまま そのまま そのまま
リターン前 原則解除 (*1) 原則全解除 (*1) 元に戻す
リターン時処理 解除する 全解除する 元に戻す (*4)
【カーネル管理の割込みハンドラ】
【割込みサービスルーチン】
【タイムイベントハンドラ】
実行開始条件 解除 自優先度より低い 任意
実行開始時処理 そのまま 自優先度に (*2) そのまま
リターン前 原則解除 (*1) 変更不可 (*3) 変更不可 (*3)
リターン時処理 解除する 元 に戻す (*5) そのまま
【 CPU 例外ハンドラ】
実行開始条件 任意 任意 任意
実行開始時処理 そのまま (*6) そのまま そのまま
リターン前 原則元に (*1) 変更不可 (*3) 変更不可 (*3)
リターン時処理 元に戻す 元に戻す (*5) そのまま
【拡張サービスコール】
実行開始条件 任意 任意 任意
実行開始時処理 そのまま そのまま そのまま
リターン前 任意 任意 任意
リターン時処理 そのまま そのまま そのまま

この表の中で「原則 (*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 タスクの状態遷移とスケジューリング規則

2.6.1 基本的なタスク状態

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

  • (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.6.2 タスクの状態遷移

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

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

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

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

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

【補足説明】

タスクの実行開始とは,タスクが起動された後に最初に実行される(実行状態 に遷移する)時のことをいう.

2.6.3 タスクのスケジューリング規則

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

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

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

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

2.6.4 待ち行列と待ち解除の順序

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

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

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

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

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

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

2.6.5 タスク例外処理マスク状態と待ち 禁止状態

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

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

待ち禁止状態とは,タスクが待ち状態に入ることが一時的に 禁止された状態で ある.待ち禁止状態にあるタスクが,サービスコールを呼び出して待ち状態に 遷移しようとした場合,サービスコールは 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.6.6 ディスパッチ保留状態で実行中のタスクに対する強制待ち

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

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

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

過渡的な状態も含めたタスクの状態遷移を図 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 カーネルでは,タスクが広義の待ち状態になることはないため,タスクが強 制待ち状態[実行継続中]になることもない.

2.6.7 制約タスク

制約タスク( 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 仕様の制約タスクよりも機 能制限が少なくなっている.

2.7 割込み処理モデル

TOPPERS 新世代カーネルにおける割込み処理のモデルは, TOPPERS 標準割込み処 理モデルに準拠している.

TOPPERS 標準割込み処理モデルの概念図を図 2-4に示す.この図は,割込み処理 モデルの持つすべての機能が,ハードウェア(プロセッサおよび割込みコント ローラ)で実現されているとして描いた概念図である.実際のハードウェアで 不足している機能については,カーネル内の割込み処理のソフトウェアで実現 される.

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

割込み処理モデルは,μ ITRON4.0 仕様から大幅に拡張している.

2.7.1 割込み処理の流れ

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

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

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

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

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

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

2.7.2 割込み優先度

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

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

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

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

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

【仕様決定の理由】

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

2.7.3 割込み要求ラインの属性

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

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

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

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

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

  • (2) 割込み優先度

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

  • (3) トリガモ ード

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

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

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

2.7.4 割込みを 受け付ける条件

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

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

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

2.7.5 割込み番号と割込みハンドラ番号

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

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

割 込みハンドラ番号は,割込み番号と 1対 1に対応するのが基本である(両者が 一致する場合が多い).

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

2.7.6 マルチプロセッサにおける割込み処理

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

マルチプロセッサ対応カーネルでは, 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 つのプロセッサのみに接続された割込み要求ラインに対して登録された割込み サービスルーチンは,そのプロセッサのみを割付け可能プロセッサとするクラ スに属していなければならない.

【使用上の注意】

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

2.7.7 カーネル管理外の割込み

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

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

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

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

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

2.7.8 カーネル管理外の割込みの設定方法

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

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

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

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

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

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

2.8 CPU 例外処理モデル

プロセッサが検出する CPU 例外の種類や, CPU 例外検出時のプロセッサの振舞い は,プロセッサによって大きく異なる.そのため, CPU 例外ハンドラをターゲッ トハードウェアに依存せずに記述することは,少なくとも現時点では困難であ る.そこでこの仕様では, CPU 例外の処理モデルを厳密に標準化するのではなく, ターゲットハードウェアに依存せずに決められる範囲で規定する.

2.8.1 CPU 例外処理の流れ

アプリケーションは,プロセッサが検出する 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 例外からのリカバリ処理の方法については,記述され ていない.

2.8.2 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 仕様を見直し,全面的に 修正した.

2.8.3 エミュレートされた CPU 例外ハンドラ

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

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

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

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

2.8.4 カーネル管理外の CPU 例外

カーネル内のクリティカルセクションの実行中(これを,カーネル実行中と呼 ぶ),全割込みロック状態, 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 例外が起こ る状況によって,カーネル管理となる場合とカーネル管理外となる場合がある.

2.9 システムの初期化と終了

2.9.1 システム初期化手順

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

標準のスタートアップモジュールは,プロセッサのモードとスタックポインタ 等の初期化, 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 の処理は, 初期化ルーチンを登録することのみを意味し,初期化ルーチンの実行は含まな いものとした.

2.9.2 システム終了手順

カーネルを終了させるサービスコール( 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 仕様には,システム終了に関する規定はない.

2.10 オブジェクトの登録とその解除

2.10.1 ID 番号で識別するオブジェクト

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 についても,サービスコールに整合するよう変更した.

2.10.2 オブジェ クト番号で識別するオブジェクト

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

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

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

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

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

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

2.10.3 識別番号を持たないオブジェクト

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

2.10.4 オブジェクト生成に必要なメモリ領域

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

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

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

【補足説明】

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

2.10.5 オブジェクトが属する保護ドメインの設定

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

カーネルオブジェクトを静的 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 エラー となる.

【補足説明】

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

【仕様決定の理由】

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

2.10.6 オブジェクトが属するクラスの設定

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

カーネルオブジェクトを静的 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 エラーとなる.

【補足説明】

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

【仕様決定の理由】

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

2.10.7 オブジェクトの状態参照

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

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

2.11 オブジェクトのアクセス保護

この節では,カーネ ルオブジェクトのアクセス保護について述べる.この節の 内容は,保護機能対応カーネルにのみ適用される.

2.11.1 オブジェクトのアクセス保護とアクセス違反の通知

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

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

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

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

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

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

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

【未決定事項】

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

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

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

【仕様決定の理由】

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

2.11.2 メモリオブジェクトに対するアクセス許可ベクタの制限

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

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

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

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

2.11.3 デフォルトのアクセス許可ベクタ

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

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

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

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

【未決定事項】

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

2.11.4 アクセス許可ベクタの設定

ア クセス許可ベクタをデフォルト以外の値に設定するために,カーネルオブジェ クトのアクセス許可ベクタを設定する静的 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 )により,オブジェクト に設定されたアクセス許可ベクタを参照する機能サポートしないこととした. これは,オブジェクトの登録時に指定し,その後に変化しない情報を参照する ための機能は用意しないという原則に合わせるための修正である.

2.11.5 カーネルの管理領域のアクセス保護

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

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

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

2.11.6 ユーザタスクのユーザスタック領域

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

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

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

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

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

2.12 システムコンフィギュレーション手順

2.12.1 システムコンフィギュレーションファイル

カーネルやシステムサービスが管理するオブジェクトの生成情報や初期状態な どを記述するファイルを,システムコンフィギュレーションファイ ル( 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 仕様における

ディレクティブの役割は,この仕様では INCLUDE ディレクティブに置き
換わる. 逆に,μ ITRON4.0 仕様における INCLUDE 静的 API の役割は,この仕様で は #include ディレクティブに置き換わる.

2.12.2 静的 API の文法とパラメータ

静的 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) としている.

2.12.3 保護ドメインの指定

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

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

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

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

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

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

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

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

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

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

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

【仕様決定の理由】

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

2.12.4 クラスの指定

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

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

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

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

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

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

【仕様決定の理由】

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

2.12.5 コンフィギュレータの処理モデル

コンフィギュレータは,次の 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 仕様との関係】

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

2.12.6 静的 API のパラメータに関するエラー検出

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

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

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

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

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

2.12.7 オブジェクトの ID 番号の指定

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

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

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

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

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

2.13 TOPPERS ネーミングコンベンション

この節では, TOPPERS ソフトウェアの API の構成要素の名称に関するネーミング コンベンションについて述べる.このネーミングコンベンションは,モジュー ル間のインタフェースに関わる名称に適用することを想定しているが,モジュー ル内部の名称に適用してもよい.

2.13.1 モジュール識別名

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

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

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

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

2.13.2 データ型名

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

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

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

  • (A) パケットのデータ型
T_CYYY acre _yyy に渡すパケットのデータ型
T_DYYY def_yyy に渡すパケットのデータ型
T_RYYY ref_yyy に渡すパケットのデータ型
T_WWW_CYYY www_acre_yyy に渡すパケットのデータ型
T_WWW_DYYY www_def_yyy に渡すパケットのデータ型
T_WWW_RYYY www_ref_yyy に渡すパケットのデータ型

2.13.3 関数名

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

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

  • (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) コールバック

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

2.13.4 変数名

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

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

~ id ~ ID (オブジェクトの ID 番号, ID 型)
~ no ~番号(オブジェクト番号)
~ atr ~属性(オブジェクト属性, ATR 型)
~ stat ~状態(オブジェクト状態, STAT 型)
~ mode ~モード(サービスコールの動作モード, MODE 型)
~ pri ~優先度(優先度, PRI 型)
~ sz ~サイズ(単位はバイト数, SIZE 型または uint_t 型)
~ cnt ~の個数(単位は個数, uint_t 型)
~ ptn ~パターン
~ tim ~時刻,~時間
~ cd ~コード
i ~ ~の初期値
max ~ ~の最大値
min ~ ~の最小値
left ~ ~の残り

また,ポインタ変数(関数ポインタを除く)の名称に関して,次のガイドライ ンを設ける.

p_ ~ ポインタ
pp_ ~ ポインタを入れる 領域へのポインタ
pk_ ~ パケットへのポインタ
ppk_ ~ パケットへのポインタを入れる領域へのポインタ

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

  • (A) パケットへのポインタ
pk_cyyy acre_yyy に渡すパケットへのポインタ
pk_dyyy def_yyy に渡すパケットへのポインタ
pk_ryyy ref_yyy に渡すパケットへのポインタ
pk_www_cyyy www_acre_yyy に渡すパケットへのポインタ
pk_www_dyyy www_def_yyy に渡すパケットへのポインタ
pk_www_ryyy www_ref_yyy に渡 すパケットへのポインタ

2.13.5 定数名

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

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

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

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

  • (B) 機能コード
TFN_XXX_YYY xxx_yyy の機能コード
TFN_WWW_XXX_YYY www_xxx_yyy の機能コード
  • (C) その他の定数

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

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

TA_ ~ オブジェクトの属性値
TSZ_ ~ ~のサイズ
TBIT_ ~ ~のビット数
TMAX_ ~ ~の最大値
TMIN_ ~ ~の最小値

2.13.6 マクロ名

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

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

  • (A) 構成マクロ

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

TSZ_ ~ ~のサイズ
TBIT_ ~ ~のビット数
TMAX_ ~ ~の最大値
TMIN_ ~ ~の最小値

2.13.7 静的 API 名

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

2.13.8 ファイル名

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

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

  • (A) ヘッダファイル

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

2.13.9 モジュール内部の名称の衝突回避

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

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

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

2. 14 TOPPERS 共通定義

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

2.14.1 TOPPERS 共通ヘッダファイル

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

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

2.14.2 TOPPERS 共通データ型

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

int8_t 符号付き 8ビット整数(オプション, C99 準拠)
uint8_t 符号無し 8ビット整数(オプション, C99 準拠)
int16_t 符号付き 16 ビット整数( C99 準拠)
uint16_t 符号無し 16 ビット整数( C99 準拠)
int32_t 符号付き 32 ビット整数( C99 準拠)
uint32_t 符号無し 32 ビット整数( C99 準拠)
int64_t 符号付き 64 ビット整数(オプション, C99 準拠)
uint64_t 符号無し 64 ビッ ト整数(オプション, C99 準拠)
int128_t 符号付き 128 ビット整数(オプション, C99 準拠)
uint128_t 符号無し 128 ビット整数(オプション, C99 準拠)
int_least8_t 8 ビット以上の符号付き整数( C99 準拠)
uint_least8_t int_least8_t 型と同じサイズの符号無し整数( C99 準拠)
float32_t IEEE754 準拠の 32 ビット単精度浮動小数点数(オプション)
double64_t IEEE754 準拠の 64 ビット倍精度浮動小数点数(オプション)
bool_t 真偽値( true または false )
int_t 16 ビット以上の符号付き整数
uint_t int_t 型と 同じサイズの符号無し整数
long_t 32 ビット以上かつ int_t 型以上のサイズの符号付き整数
ulong_t long_t 型と同じサイズの符号無し整数
intptr_t ポインタを格納できるサイズの符号付き整数( C99 準拠)
uintptr_t intptr_t 型と同じサイズの符号無し整数( C99 準拠)
FN 機能コード(符号付き整数, int_t に定義)
ER 正常終了( E_OK )またはエラーコード(符号付き整数, int_tに定義)
ID オブジェクトの ID 番号(符号付き整数, int_t に定義)
ATR オブジェクト属性(符号無し整数, uint_t に定義)
STAT オブジェクトの状態(符号無し整数, uint_t に定義)
MODE サービスコールの動作モード(符号無し整数, uint_t に定義)
PRI 優先度(符号付き整数, int_t に定義)
SIZE メモリ領域のサイズ(符号無し整数,ポインタを格納できるサイズの符号無し整数型に定義)
TMO タイムアウト指定(符号付き整数,単位はミリ秒, int_t に定義)
RELTIM 相対時間(符号無し整数,単位はミリ秒, uint_t に定義)
SYSTIM システム時刻(符号無し整数,単位はミリ秒, ulong_t に定義)
SYSUTM 性能評価用システム時刻(符号無し整数,単位はマイクロ秒,ulong_t に定 義)
FP プログラムの起動番地(型の定まらない関数ポインタ)
ER_BOOL エラーコードまたは真偽値(符号付き整数, int_t に定義)
ER_ID エラーコードまたは ID 番号(符号付き整数, int_t に定義,負の ID 番号は格納できない)
ER_UINT エラーコードまたは符号無し整数(符号付き整数, int_t に定義,符号無し整数を格納する場合の有効ビット数は uint_tより 1ビット短い)
MB_T オブジェクト管理領域を確保するためのデータ型
ACPTN アクセス許可パターン (符号無し 32 ビット整数, uint32_t に定義)
ACVCT アクセス許可ベクタ

ここで,データ型が「 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 を用意することにした

2.14.3 TOPPERS 共通定数

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

  • (1) 一般定数
  NULL 無効ポインタ
true 1
false 0
E_OK 0 正常終了

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

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

  • (2) 整数型に格納できる最大値と最小値
INT8_MAX int8_t に格納できる最大値(オプション, C99 準拠)
INT8_MIN int8_t に格納できる最小値(オプション, C99 準拠)
UINT8_MAX uint8_t に格納できる最大値(オプション, C99 準拠)
INT16_MAX int16_t に格納できる最大値( C99 準拠)
INT16_MIN int 16_t に格納できる最小値( C99 準拠)
UINT16_MAX uint16_t に格納できる最大値( C99 準拠)
INT32_MAX int32_t に格納できる最大値( C99 準拠)
INT32_MIN int32_t に格納できる最小値( C99 準拠)
UINT32_MAX uint32_t に格納できる最大値( C99 準拠)
INT64_MAX int64_t に格納できる最大値(オプション, C99 準拠)
INT64_MIN int64_t に格納できる最小値(オプション, C99 準拠)
UINT64_MAX uint64_t に格納できる最大値(オプション, C99 準拠)
INT128_MAX int128_t に格納できる最大値(オプション, C99 準拠)
INT128_MIN int128_t に格納できる最小値(オプション, C99 準拠)
UINT128_MAX uint128_t に格納できる最大値(オプション, C99 準拠)
INT_LEAST8_MAX int_least8_t に格納できる最大値( C99 準拠)
INT_LEAST8_MIN int_least8_t に格納できる最小値( C99 準拠)
UINT_LEAST8_MAX uint_least8_t に格納できる最大値( C99 準拠)
INT_MAX int_t に格納できる最大値( C90 準拠)
INT_MIN int_t に格納できる最小値( C90 準拠)
UIN T_MAX uint_t に格納できる最大値( C90 準拠)
LONG_MAX long_t に格納できる最大値( C90 準拠)
LONG_MIN long_t に格納できる最小値( C90 準拠)
ULONG_MAX ulong_t に格納できる最大値( C90 準拠)
FLOAT32_MIN float32_t に格納できる最小の正規化された正の浮動小数点数(オプション)
FLOAT32_MAX float32_t に格納できる表現可能な最大の有限浮動小数点数(オプション)
DOUBLE64_MIN double64_t に格納できる最小の正規化された正の浮動小数点数(オプション)
DOUBLE64_MAX double64_t に格納できる表現可能な最大の有限浮動小数点数(オプション)
  • (3) 整数型のビット数
CHAR_BIT char 型のビット数( C90 準拠)
  • (4) オブジェクト属性
TA_NULL 0U オブジェクト属性を指定しない
  • (5) タイムアウト指定
TMO_POL 0 ポーリング
TMO_FEVR -1 永久待ち
TMO_NBLK -2 ノンブロッキング
  • (6) アクセス許可パターン
TACP_KERNEL 0U カーネルドメインのみにアクセスを許可
TACP_SHARED ˜0U すべての保護ドメインにアクセスを許可

2.14.4 TOPPERS 共通エラーコード

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

  • (A) 内部エラークラス( EC_SYS , -5~ -8)
E_SYS -5 システムエラー
  • (B) 未サポートエラークラス( EC_NOSPT , -9~ -16 )
E_NOSPT -9 未サポート機能
E_RSFN -10 予約機能コード
E_RSATR -11 予約属性
  • (C) パラメータエラークラス( EC_PAR , -17 ~ -24 )
E_PAR -17 パラメータエラー
E_ID -18 不正 ID 番号
  • (D) 呼出しコンテキストエラークラス( EC_CTX , -25 ~ -32 )
E_CTX -25 コンテキストエラー
E_MACV -26 メモリアクセス違反
E_OACV -27 オブジェクトアクセス違反
E_ILUSE -28 サービスコール不正使用
  • (E) 資源不足エラー クラス( EC_NOMEM , -33 ~ -40 )
E_NOMEM -33 メモリ不足
E_NOID -34 ID 番号不足
E_NORES -35 資源不足
  • (F) オブジェクト状態エラークラス( EC_OBJ , -41 ~ -48 )
E_OBJ -41 オブ ジェクト状態エラー
E_NOEXS -42 オブジェクト未登録
E_QOVR -43 キューイングオーバフロー
  • (G) 待ち解除エラークラス( EC_RLWAI , -49 ~ -56 )
E_RLWAI -49 待ち禁止状態または待ち状態の強制解除
E_TMOUT -50 ポーリ ング失敗またはタイムアウト
E_DLT -51 待ちオブジェクトの削除または再初期化
E_CLS -52 待ちオブジェクトの状態変化
  • (H) 警告クラス( EC_WARN , -57 ~ -64 )
E_WBLK -57 ノンブロッキング受付け
E_BOVR -58 バッファオーバフロー

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

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

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

2.14.5 TOPPERS 共通マクロ

  • (1) 整数定数を作るマクロ
INT8_C(val) int_least8_t 型の定数を作るマクロ( C99 準拠)
UINT8_C(val) uint_least8_t 型の定数を作るマクロ( C99 準拠)
INT16_C(val) int16_t 型の定数を作るマクロ( C99 準拠)
UINT16_C(val) uint16_t 型の定数を作るマクロ( C99 準拠)
INT32_C(val) int32_t 型の定数を作るマクロ( C99 準拠)
UINT32_C(val) uint32_t 型の定数を作るマクロ( C99 準拠)
INT64_C(val) int64_t 型の定数を作るマ クロ(オプション, C99 準拠)
UINT64_C(val) uint64_t 型の定数を作るマクロ(オプション, C99 準拠)
INT128_C(val) int128_t 型の定数を作るマクロ(オプション, C99 準拠)
UINT128_C(val) uint128_t 型の定数を作るマクロ(オプション, C99 準拠)
UINT_C(val) uint_t 型の定数を作るマクロ
ULONG_C(val) ulong_t 型の定数を作るマクロ

【仕様決定の理由】

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

  • (2) 型に関する情報を取り出すためのマクロ
offsetof(structure, field) 構造体 structure 中のフィールド field のバイト位置を返すマクロ( C90 準拠)
alignof(type) 型 type のアラインメント単位を返すマクロ
ALIGN_TYPE(addr, type) 番地 addr が型 type に対してアラインしているかどうかを返すマクロ
  • (3) assert マクロ
assert(exp) exp が成立しているかを検査するマクロ( C90 準拠)
  • (4) コンパイラの拡張機能のためのマクロ
inline インライン関数
Inline ファイルローカルなインライン関数
asm インラインアセンブラ
Asm インラインアセンブラ(最適化抑止)
throw() 例外を発生しない関数
NoReturn リターンしない関数
  • (5) エラーコード構成・分解マクロ
ERCD(mercd, sercd) メインエラーコード mercd とサブエラーコード sercd から,エラーコードを構成するためのマクロ
MERCD(ercd) エラーコード ercd からメインエラーコードを抽出するためのマクロ
SERCD(ercd) エラーコード ercd からサブエラーコードを抽出するためのマクロ
  • (6) アクセス許可パターン構成マクロ
TACP(domid) domid で指定されるユーザドメインのみにアクセスを許可するアクセス許可パターンを構成するためのマクロ

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

2.14.6 TOPPERS 共通構成マクロ

  • (1) 相対時間の範囲
TMAX_RELTIM 相対時間に指定できる最大値

2.15 カーネル共通定義

カーネルの複数の機能で共通に用いる定義を,カーネル共 通定義と呼ぶ.

2.15.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 )に変更した.

2.15.2 カーネル共通定数

  • (1) オブジェクト属性
TA_TPRI 0x01U タスクの待ち行列をタスクの優先度順に

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

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

  • (2) 保護ドメイン ID
TDOM_SELF 0 自タスクの属する保護ドメイン
TDOM_KERNEL -1 カーネルドメイン
TDOM_NONE -2 無所属(保護ドメインに属さない)
  • (3) その他のカーネル共通定数
TCLS_SELF 0 自タスクの属するクラス
TPRC_NONE 0 割付けプロセッサの指定がない
TPRC_INI 0 初期割付けプロセッサ
TSK_SELF 0 自タスク指定
TSK_NONE 0 該当するタスクがない
TPRI_SELF 0 自タスクのベース優先度の指定
TPRI_INI 0 タスクの起動時優先度の指定
TIPM_ENAALL 0 割込み優先度マスク全解除
  • (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 は,コンフィギュレータによって検出される.

2.15.3 カーネル共通マクロ

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

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

STK_T スタック領域を確保するためのデータ型
COUNT_STK_T(sz) サイズ sz のスタック領域を確保するために必要なSTK_T 型の配列の要素数
ROUND_STK_T(sz) 要素数 COUNT_STK_T(sz) の STK_T 型の配列のサイズ( szを, STK_T 型のサイズの倍数になるように大きい方に丸めた値)

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

STK_T < スタック領域の変数名 >[COUNT_STK_T(< スタック領域のサイズ >)];

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

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

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

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

TA_DOM(domid) domid で指定される保護ドメインに属する

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

TA_CLS(clsid) clsid で指定されるクラスに属する
  • (3) サービスコールの呼出し方法を指定するマクロ

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

SVC_CALL(svc) svc で指定されるサ ービスコールを関数呼出しによって呼び出すための名称

2.15.4 カーネル共通構成マクロ

  • (1) サポートする機能
TOPPERS_SUPPORT_PROTECT 保護機能対応のカーネル
TOPPERS_SUPPORT_MULTI_PRC マルチプロセ ッサ対応のカーネル
TOPPERS_SUPPORT_DYNAMIC_CRE 動的生成対応のカーネル

【未決定事項】

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

  • (2) 優先度の範囲
TMIN_TPRI タスク優先度の最小値(= 1)
TMAX_TPRI タスク優先度の最大値

【 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) プロセッサの数

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

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

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

TOPPERS_MASTER_PRCID マスタプロセッサの ID 番号
TOPPERS_SYSTIM_PRCID システム時刻管理プロセッサの ID 番号(グローバルタイマ方式の場合のみ)
  • (5) タイマ方式

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

TOPPERS_SYSTIM_LOCAL ローカルタイマ方式の場合にマクロ定義
TOPPERS_SYSTIM_GLOBAL グローバルタイマ方式の場合にマクロ定義
  • (6) バージョン情報
TKERNEL_MAKER カーネルのメーカコード(= 0x0118 )
TKERNEL_PRID カーネルの識別番号
TKERNEL_SPVER カーネル仕様のバージョン番号
TKERNEL_PRVER カーネルのバージョン番号

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

カーネルの識別番号( TKERNEL_PRID )は, TOPPERS カーネルの種類を表す.

0x0001 TOPPERS/JSP カーネル
0x0002 予約( IIMP カーネル)
0x0003 予約( IDL カーネル)
0x0004 TOPPERS/FI4 カーネル
0x0005 TOPPERS/FDMP カーネル
0x0006 TOPPERS/HRP カーネル
0x0007 TOPPERS/ASP カーネル
0x0008 TOPPERS/FMP カーネル
0x0009 TOPPERS/SSP カーネル
0x000a TOPPERS/ASP Safety カーネル

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

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

第3章 システムインタフェースレイヤ API 仕様

3.1 システムインタフェースレイヤの概要

システムインタフェースレイヤ(この章では, SIL と略記する)は,デバイスを 直接操作するプログラムが用いるための機能である. ITRON デバイスドライバ設 計ガイドラインの一部分として検討されたものをベースに, TOPPERS プロジェク トにおいて修正を加えて用いている.

SIL の機能は,プロセッサの特権モードで実行されているプログラムが使用する ことを想定している.非特権モードで実行されているプログラムから SIL の機能 を呼び出した場合の動作は,次の例外を除いては保証されない.

  • ・微少時間待ちの機能を呼び出すこと
  • ・エンディアンの取得のためのマクロを参照すること
  • ・メモリ空間アクセス関数により,アクセスを許可されたメモリ領域にアクセ スすること
  • ・ I/O 空間アクセス関数により,アクセスを許可された I/O 領域にアクセスする こと

3.2 SIL ヘッダファイル

SIL を用いるために必要な定義は, SIL ヘッダファイル( sil.h )およびそこから インクルードされるファイルに含まれている. SIL を用いる場合には, SIL ヘッ ダファイルをインクルードする.

3.3 全割込みロック状態の制御

デバイスを扱うプログラムの中では,すべての割込み( NMI を除く,以下同じ) をマスクしたい場合がある.カーネルで制御できる CPU ロック状態は,カーネル 管理外の割込み( NMI 以外にカーネル管理外の割込みがあるかはターゲット定義) をマスクしないため,このような場合に用いることはできない.

そこで, SIL では,すべての割込みをマスクする全割込みロック状態を制御する ための以下の機能を用意している.

  • (1) SIL_PRE_ LOC

    全割込みロック状態の制御に必要な変数を宣言するマクロ.通常は,型と変数 名を並べたもので,最後に ";" を含まない.

    このマクロは, SIL_LOC_INT , SIL_UNL_INT を用いる関数またはブロックの先頭 の変数宣言部に記述しなければならない. SIL_LOC_INT , SIL_UNL_INT を 1つの関 数内でネストして用いることは可能であるが,その場合には ,ネストレベル毎 にブロックを作り,そのブロックの先頭の変数宣言部に SIL_PRE_LOC を記述しな ければならない.そのように記述しなかった場合の動作は保証されない.

  • (2) SIL_LOC_INT()

    全割込みロックフラグをセットすることで, NMI を除くすべての割込みをマスク し,全割込みロック状態に遷移する.

  • (3) SIL_UNL_INT()

    全割込みロックフラグを,対応する SIL_LOC_INT を実行する前の状態に戻す. SIL_LOC_INT を実行せずに SIL_UNL_INT を呼び出した場合の動作は保証されない.

    なお,全割込みロック状態で呼び出せるサービスコールなどの制限事項につい ては,「 2.5.4 全割込みロック状態と全割込みロック解除状態」の節を参照す ること.

    【補足説明】

    全割込みロック状態の制御機能の使用例は次の通り.

    { SIL_PRE_LOC;

    SIL_LOC_INT(); SIL_UNL_INT(); }

3.4 SIL スピンロック

マルチプロセッサシステムにおいて,カーネルの機能を用いずに,他のプロセッ サとの間でも排他制御を実現したい場合がある.そこで SIL では,割込みのマス クとプロセッサ間ロックの取得により排他制御を行うためのスピンロックの機 能を用意している.これを,カーネルのスピンロック機能と区別するために, SIL スピンロックと呼ぶ.

プロセッサ間ロックを取得している間は,全割込みロック状態にすることです べての割込み( NMI を除く)がマスクされる.ロックが他のプロセッサに取得さ れている場合には,ロックが取得できるまでループによって待つ.ロックの取 得を待つ間は,割込みはマスクされない(ロックの取得 を試みる前にマスクし ていた割込みは,マスク解除されない).プロセッサ間ロックを取得し割込み をマスクすることを, SIL スピンロックを取得するという.また,プロセッサ間 ロックを返却し割込みをマスク解除することを, SIL スピンロックを返却すると いう.

SIL で取得・返却するプロセッサ間ロックは,システムに唯一存在する.

  • (1) SIL_PRE_LOC

    全割込みロック状態の制御に必要な変数を宣言するマクロであるが, SIL スピン ロックの取得・解放にも兼用する.

    このマクロは, SIL_LOC_SPN , SIL_UNL_SPN を用いる関数またはブロックの先頭 の変数宣言部に記述しなければならない. SIL_LOC_SPN , SIL_UNL_SPN を,同じ 関数内の SIL_L OC_INT , SIL_UNL_INT とネストして用いることは可能であるが, その場合には,ネストレベル毎にブロックを作り,そのブロックの先頭の変数 宣言部に SIL_PRE_LOC を記述しなければならない.そのように記述しなかった場 合の動作は保証されない.

  • (2) SIL_LOC_SPN()

    SIL スピンロックが取得されていない状態である場合には,プロセッサ間ロック の取得を試みる.ロックが他のプロセッサに取得されている状態である場合や, 他のプロセッサがロックの取得に成功した場合には,ロックが返却されるまで ループによって待ち,返却されたらロックの取得を試みる.ロックの取得に成 功した場合には,全割込みロックフラグをセットし,全割込みロック状態に遷 移する.

  • (3) SIL_UNL_SPN()

    プロセッサ間ロックを返却し,全割込みロックフラグを対応する SIL_LOC_SPN を 実行する前の状態に戻す.

SIL スピンロックを取得している状態で SIL_LOC_SPN を呼び出した場合の動作は 保証されない.逆に, SIL スピンロックを取得していない状態で SIL_UNL_SPN を 呼び出した場合の動作も保証されない.

なお, SIL スピンロック取得 中は全割込みロック状態となっているため, SIL ス ピンロック取得中に呼び出せるサービスコールなどについては,「 2.5.4 全割 込みロック状態と全割込みロック解除状態」の節の制限事項が適用される.

なお,マルチプロセッサシステム以外では, SIL_LOC_SPN と SIL_UNL_SPN は用意 されていない.

【使用上の注意】

全割込ロック状態や CPU ロック状態で SIL_LOC_SPN を呼び出すことはできるが, 割込みがマスクされている時間が長くなるために,そのような使い方は避ける べきである.

【補足説明】

SIL スピンロック機能の使用例は次の通り.

{ SIL_PRE_LOC;

SIL_LOC_SPN(); SIL_UNL_SPN(); }

3.5 微少時間待ち

デバイスをアクセスする際に,微少な時間待ちを入れなければならない場合が ある.そのような場合に, NOP 命令をいくつか入れるなどの方法で対応すると, ポータビリティを損なうことになる.そこで, SIL では,微少な時間待ちを行う ための以下の機能を用意している.

  • (1) void sil_dly_nse(ulong_t dlytim)

    dlytim で指定された以上の時間(単位はナノ秒),ループなどによって待つ. 指定した値によっては,指定した時間よりもかなり長く待つ場合があるので注 意すること.

3.6 エンディアンの取得

プロセッサのバイトエンディアンを取得するためのマクロとして, SIL では,以 下のマクロを定義している.

  • (1) SIL_ENDI AN_BIG , SIL_ENDIAN_LITTLE

    ビッグエンディアンプロセッサでは SIL_ENDIAN_BIG を,リトルエンディアンプ ロセッサでは SIL_ENDIAL_LITTLE を,マクロ定義している.

3.7 メモリ空間アクセス関数

メモリ空間にマッピングされたデバイスレジスタや,デバイスとの共有メモリ をアクセスするために, SIL では,以下の関数を用意している.

  • (1) uint8_t sil_reb_mem(const uint8_t *mem)

    mem で指定されるアドレスから 8ビット単位で読み出した値を返す.

  • (2) void sil_wrb_mem(uint8_t *mem, uint8_t data)

    mem で指 定されるアドレスに data で指定される値を 8ビット単位で書き込む.

  • (3) uint16_t sil_reh_mem(const uint16_t *mem)

    mem で指定されるアドレスから 16 ビット単位で読み出した値を返す.

  • (4) void sil_wrh_mem(uint16_t *mem, uint16_t data)

    mem で指定さ れるアドレスに data で指定される値を 16 ビット単位で書き込む.

  • (5) uint16_t sil_reh_lem(const uint16_t *mem)

    mem で指定されるアドレスから 16 ビット単位でリトルエンディアンで読み出した 値を返す.リトルエンディアンプロセッサでは, sil_reh_mem と一致する.ビッ グエンディアンプロセッサでは, sil_reh_mem が返す値を,エン ディアン変換し た値を返す.

  • (6) void sil_wrh_lem(uint16_t *mem, uint16_t data)

    mem で指定されるアドレスに data で指定される値を 16 ビット単位でリトルエンディ アンで書き込む.リトルエンディアンプロセッサでは, sil_wrh_mem と一致する. ビッグエンディアンプロセッサでは, data をエンディアン変換した値を, sil_wrh_mem で書き込むのと同じ結果となる.

  • (7) uint16_t sil_reh_bem(const uint16_t *mem)

    mem で指定されるアドレスから 16 ビット単位でビッグエンディアンで読み出した 値を返す.ビッグエンディアンプロセッサでは, sil_reh_mem と一致 する.リト ルエンディアンプロセッサでは, sil_reh_mem が返す値を,エンディアン変換し た値を返す.

  • (8) void sil_wrh_bem(uint16_t *mem, uint16_t data)

    mem で指定されるアドレスに data で指定される値を 16 ビット単位でビッグエンディ アンで書き込む.ビッグエンディアンプロセッサでは, sil_wrh_mem と一致する. リトルエンディアンプロセッサでは, data をエンディアン変換した値を, sil_wrh_mem で書き込むのと同じ結果となる.

  • (9) uint32_t sil_rew_mem(const uint32_t *mem)

    mem で指定されるアドレスから 32 ビット単位で読み出した値を返す.

  • (10) void sil_wrw_mem(u int32_t *mem, uint32_t data)

    mem で指定されるアドレスに data で指定される値を 32 ビット単位で書き込む.

  • (11) uint32_t sil_rew_lem(const uint32_t *mem)

    mem で指定されるアドレスから 32 ビット単位でリトルエンディアンで読み出した 値を返す.リトルエンディアンプロセッサでは, sil_rew_mem と一致する.ビッ グエンディアンプロセッサでは, sil_rew_mem が返す値を,エンディアン変換し た値を返す.

  • (12) void sil_wrw_lem(uint32_t *mem, uint32_t data)

    mem で指定されるアドレスに data で指定される値を 32 ビット単位でリトルエンディ アンで書き込む.リトルエンディアンプロセッサでは, sil_wrw_mem と一致する. ビッグエンディアンプロセッサでは, data をエンディアン変換した値を, sil_wrw_mem で書き込むのと同じ結果となる.

  • (13) uint32_t sil_rew_bem(const uint32_t *mem)

    mem で指定されるアドレスから 32 ビット単位でビッグエンディ アンで読み出した 値を返す.ビッグエンディアンプロセッサでは, sil_rew_mem と一致する.リト ルエンディアンプロセッサでは, sil_rew_mem が返す値を,エンディアン変換し た値を返す.

  • (14) void sil_wrw_bem(uint32_t *mem, uint32_t data)

    mem で指定されるアドレスに data で指定される値を 32 ビット単 位でビッグエンディ アンで書き込む.ビッグエンディアンプロセッサでは, sil_wrw_mem と一致する. リトルエンディアンプロセッサでは, data をエンディアン変換した値を, sil_wrw_mem で書き込むのと同じ結果となる.

3.8 I/O 空間アクセス関数

メモリ空間とは別に I/O 空間を持つプロセッサでは, I/O 空間にあるデバイスレ ジスタをアクセスするために,メモリ空間アクセス関数と同等の以下の関数を 用意している.

  • (1) uint8_t sil_reb_iop(const uint8_t *iop)
  • (2) void sil_wrb_iop(uint8_t *iop, uint8_t data)
  • (3) uint16_t sil_reh_iop(const uint16_t *iop)
  • (4 ) void sil_wrh_iop(uint16_t *iop, uint16_t data)
  • (5) uint16_t sil_reh_lep(const uint16_t *iop)
  • (6) void sil_wrh_lep(uint16_t *iop, uint16_t data)
  • (7) uint16_t sil_reh_bep(const uint16_t *iop)
  • (8) void sil_wrh_bep(uin t16_t *iop, uint16_t data)
  • (9) uint32_t sil_rew_iop(const uint32_t *iop)
  • (10) void sil_wrw_iop(uint32_t *iop, uint32_t data)
  • (11) uint32_t sil_rew_lep(const uint32_t *iop)
  • (12) void sil_wrw_lep(uint32_t *iop, uint32_ t data)
  • (13) uint32_t sil_rew_bep(const uint32_t *iop)
  • (14) void sil_wrw_bep(uint32_t *iop, uint32_t data)

3.9 プロセッサ ID の参照

マルチプロセッサシステムにおいては,プログラムがどのプロセッサで実行さ れているかを参照するために,以下の関数を用意している .

  • (1) void sil_get_pid(ID *p_prcid)

    この関数を呼び出したプログラムを実行しているプロセッサの ID 番号を参照し, p_prcid で指定したメモリ領域に返す.

    【使用上の注意】

    タスクは, sil_get_pid を用いて,自タスクを実行しているプロセッサを正しく 参照できるとは限らない.これは, sil_get_pid を呼び出し,自タスクを実行し ているプロセッサの ID 番号を参照した直後に割込みが発生した場合, sil_get_pid から戻ってきた時には自タスクを実行しているプロセッサが変化し ている可能性があるためである.

第4章 カーネル API 仕様

この章では,カーネルの API 仕様 について規定する.

カーネルの API の種別と API をサポートするカーネルの種類を表すために,次の 記号を用いる.

〔 T〕はタスクコンテキスト専用のサービスコールを示す.非タスクコンテキス トから呼び出すと, E_CTX エラーとなる.

〔 I〕は非タスクコンテキスト専用のサービスコールを示す.タスクコンテキス トから呼び出すと, E_CTX エラーとなる.

〔 TI 〕はタスクコンテキストからも非タスクコンテキストからも呼び出すこと のできるサービスコールを示す.

〔 S〕は静的 API を示す.

〔 P〕は保護機能対応カーネルのみでサポートされている API を示す.保護機能 対応でないカーネルでは,この API はサポートされない.

〔 p〕は保護機能対応でないカーネルのみでサポートされている API を示す.保 護機能対応カーネルでは,この API はサポートされない.

〔 M〕はマルチプロセッサ対応カーネルのみでサポートされている API を示す. マルチプロセッサ対応でないカーネルでは,この API はサポートされない.

〔 D〕は動的生成対応カーネルのみでサポートされている API を示す.動的生成 対応でないカーネルでは,この API はサポートされない.

また,エラーコードが返る条件を表すために,次の記号を用いる.

〔 s〕はサービスコールのみで返るエラーコードを示す.静的 API では,この エラーコードは返らない.

〔 S〕は静的 API のみで返るエラーコードを示す.サービスコールでは,このエ ラーコードは返らない.

〔 P〕は保護機能対応カーネルのみで返るエラーコードを示す.保護機能対応で ないカーネルでは,このエラーコードは返らない.

〔 D〕は動的生成対応カーネルのみで返るエラーコードを示す.動的生成対応で ないカーネルでは,このエラーコードは返らない.

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

TOPPERS 共通データ型に従い,パラメータ のデータ型を次の通り変更した.これ らの変更については,個別の API 仕様では記述しない.

INT → int_t UINT → uint_t VP → void * VP_INT → intptr_t

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

ID 番号で識別するオブジェクトのアクセス許可ベクタをデフォルト以外に設定 する場合には,オブジェクトを生成した後に設定することとし,アクセス許可 ベクタを設定する静的 API ( SAC_YYY )を新設した.逆に,アクセス許可ベクタ を指定してオブジェクトを生成する機能( CRA_YYY , cra_yyy , acra_yyy )は廃 止した.これらの変更については,個別の API 仕様では記述しない.

4.1 タスク管理機能

タスクは,プログラムの並行実行の単位で,カーネルが実行を制御する処理単 位である.タスクは,タスク ID と呼ぶ ID 番号によって識別する.

タスク管理機能に関連して,各タスクが持つ情報は次の通り.

  • ・タスク属性
  • ・タスク状態
  • ・ベース優先度
  • ・現在優先度
  • ・起動要求キューイング数
  • ・割付けプロセッサ(マルチプロセッサ対応カーネルの場合)
  • ・次回起動時の割付けプロセッサ(マルチプロセッサ対応カーネルの場合)
  • ・拡張情報
  • ・メインルーチンの先頭番地
  • ・起動時優先度
  • ・実行時優先度( TOPPERS/SSP カーネルの場合)
  • ・スタック領域
  • ・システムスタック領域(保護機能対応カーネルの場合)
  • ・アクセス許可ベクタ(保護機能対応カーネルの場合)
  • ・属する保護ドメイン(保護機能対応カーネルの場合)
  • ・属するクラス(マルチプロセッサ対応カーネルの場合)

タスクのベース優先度は,タスクの現在優先度を決定するために使われる優先 度であり,タスクの起動時に起動時優先度に初期化される.

タスクの現在優先度は,タスクの実行順位を決定するために使われる優先度で ある.単にタスクの優先度と言った場合には,現在優先度のことを指す.タス クがミューテックスをロックしていない間は,タスクの現在優先度はベース優 先度に一致する.ミューテックスをロックしている間のタスクの現在優先度に ついては,「 4.4.6 ミューテックス」の節を参照すること.

タスクの起動要求キュ ーイング数は,処理されていないタスクの起動要求の数 であり,タスクの生成時に 0に初期化される.

割付けプロセッサは,マルチプロセッサ対応カーネルにおいて,タスクを実行 するプロセッサで,タスクの生成時に,タスクが属するクラスによって定まる 初期割付けプロセッサに初期化される.

次回起動時の割付けプロセッサは,マルチプロセッサ対応カーネルにおいて, タスクが次に起動される時に割り付けられるプロセッサで,タスクの生成時に 未設定の状態に初期化される.タスクの起動時に,次回起動時の割付けプロセッ サが設定されていれば,タスクの割付けプロセッサがそのプロセッサに変更さ れ,次回起動時の割付けプロセッサは未設定の状態に戻される.次回起動時の 割付けプロセッサが未設定の場合には,タスクの割付けプロセッサは変更され ない(つまり,タスクが前に実行されていたのと同じプロセッサで実行され る).

保護機能対応カーネルにおいては,スタック領域の扱いは,ユーザタスクとシ ステムタスクで異なる.ユーザタスクのスタック領域は,ユーザタスクが非特 権モードで実行する間に用いるスタック領域であり,ユーザスタック領域と呼 ぶ.その扱いについては,「 2.11.6 ユーザタスクのユーザスタック領域」の 節 を参照すること.システムタスクのスタック領域は,カーネルの用いるオブジェ クト管理領域と同様に扱われる.

システムスタック領域は,保護機能対応カーネルにおいて,ユーザタスクがサー ビスコール(拡張サービスコールを含む)を呼び出し,特権モードで実行する 間に用いるスタック領域である.システムスタック領域は,カーネルの用いる オブジェクト管理領域と同様に扱われる.

タスク属性には,次の属性を指定することができる.

TA_ACT 0x02U タスクの生成時にタスクを起動する
TA_RSTR 0x04U 生成するタスクを制約タスクとする

TA_ACT を指定しない場合,タスクの生成直後には,タスクは休止状態となる. また,ターゲットによっては,ターゲット定義のタスク属性を 指定できる場合 がある.ターゲット定義のタスク属性として,次の属性を予約している.

TA_FPU FPU レジスタをコンテキストに含める

C 言語によるタスクの記述形式は次の通り.

void task(intptr_t exinf)  
{  
     タスク本体  
    ext_tsk();  
}

exinf には,タスクの拡張情報が渡される. ext_tsk を呼び出さず,タスクのメ インルーチンからリターンした場合, ext_tsk を呼び出した場合と同じ動作をす る.

タスク管理機能に関連するカーネル構成マクロは次の通り.

TMAX_ACTCNT タスクの起動要求キューイング数の最大値
TNUM_TSKID 登録できるタスクの数(動的生成対応でないカーネルでは,静的 API によって登録されたタスクの数に一致)

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

ASP カーネルでは, TMAX_ACTCNT は 1に固定されている.また,制約タスクはサ ポー トしていない.ただし,制約タスク拡張パッケージを用いると,制約タスクの 機能を追加することができる.

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

FMP カーネルでは, TMAX_ACTCNT は 1に固定されている.また,制約タスクはサポー トしていない.

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

HRP2 カーネルでは, TMAX_ACTCNT は 1に固定されている.また,制約タスクはサ ポートしていない.

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

SSP カーネルでは,タスクの起動要求のキューイングはサポートしておらず,タ スクに対して起動要求キューイング数の情報を持たない.また, TMAX_ACTCNT を 定義してい ない.

また,制約タスクのみをサポートすることから,すべてのタスクでスタック領 域を共有しており,タスク毎にスタック領域の情報を持たない.

SSP カーネルにおける追加機能として,タスクに対して,実行時優先度の情報を 持つ. SSP カーネルにおいては,タスクが起動された後,最初に実行状態になる 時に,タスクのベース優先度が,タスクの実行時優先度に設定される.実行時 優先度の機能は,起動時優先度よりも高い優先度でタスクを実行することで, 同時期に共有スタック領域を使用している状態になるタスクの組み合わせを限 定し,スタック領域を節約するための機能である.

タスクの実行時優先度は,実行時優先度を定義する静的 API ( DEF_EPR )によっ て設定する.実行時優先度を定義しない場合,タスクの実行時優先度は,起動 時優先度と同じ値に設定される .

〔実行時優先度によるスタック領域の節約〕

いずれのタスクにも実行時優先度が設定されていない場合には,すべてのタス クが同時期に共有スタック領域を使用している状態になる可能性があるため, すべてのタスクのスタック領域のサイズの和に,非タスクコンテキスト用のス タック領域のサイズを加えたものが,共有スタック領域に必要なサイズとなる.

タスク Aに対して実行時優先度が設定されており,タスク Aの起動時優先度より も高く,タスク Aの実行時優先度と同じかそれよりも低い起動時優先度を持つタ スク Bがある場合,タスク Aとタスク Bは同時期に共有スタック領域を使用してい る状態にならない.そのため,タスク Aとタスク Bの内,サイズが小さい方のス タック領域のサイズは,共有スタック領域のサイズに加える必要がなくなり, スタック領域を節約でき ることになる.

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

この仕様では,自タスクの拡張情報の参照するサービスコール( get_inf )をサ ポートし,起動コードを指定してタスクを起動するサービスコール( sta_tsk ), タスクを終了と同時に削除するサービスコール( exd_tsk ),タスクの状態を参 照するサービスコールの簡易版( ref_tst )はサポートしないこととした.

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


CRE_TSK タスクの生成〔 S〕
acre_tsk タスクの生成〔 TD 〕

【静的 API 】

*保護機能対応でないカーネルの場合

CRE_TSK(ID tskid, { ATR tskatr, intptr_t exinf, TASK task, PRI itskpri, SIZE stksz, STK_T *stk })


*保護機能対応カーネルの場合

CRE_TSK(ID tskid, { ATR tskatr, intptr_t exinf, TASK task, PRI itskpri, SIZE stksz, STK_T *stk, SIZE sstksz, STK_T *sstk })

※ sstksz および sstk の記述は省略することができる.

【 C言語 API 】

ER_ID tskid = acre_tsk(const T_CTSK *pk_ctsk)

【パラメータ】

ID tskid 生成するタスクの ID 番号( CRE_TSK の場合)
T_CTSK * pk_ctsk タスクの生成情報を入れたパケットへのポインタ(静的 API を除く)

*タスクの生成情報(パケットの内容)

ATR tskatr タスク属性
intptr_t exinf タスクの拡張情報
TASK task タスクのメインルーチンの先頭番地
PRI itskpri タスクの起動時優先度
SIZE stksz タスクのスタック領域のサイズ(バイト数)
S TK_T * stk タスクのスタック領域の先頭番地
SIZE sstksz タスクのシステムスタック領域のサイズ(バイト数,保護機能対応カーネルの場合,静的 APIにおいては省略可)
STK_T * sstk タスクのシステムスタ ック領域の先頭番地(保護機能対応カーネルの場合,静的 API においては省略可)

【リターンパラメータ】

ER_ID tskid 生成されたタスクの ID 番号(正の値)またはエラーコード

【エラーコード】

E_CTX 〔 s〕 コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_RSATR 予約属性( tskatr が不正または使用できない,属する保護ドメインかクラスが不正)
E_PAR パラメータエラー( task , itskpri , stksz , stk , sstksz ,sstk が不正,その他の条件については機能の項を参照すること)
E_OACV 〔 sP 〕 オブジェクトアクセス違反(システム状態に対する管理操作が許可されてい ない)
E_MACV 〔 sP 〕 メモリアクセス違反( pk_ctsk が指すメモリ領域への読出しアクセスが許可されていない)
E_NOID 〔 sD 〕 ID 番号不足(割り付けられるタスク ID がない)
E_NOMEM メモリ不足(スタック領域やシステムスタック領域が確保できない)
E_OBJ オブジェクト状態エラー( tskid で指定したタスクが登録済み: CRE_TSK の場合,その他の条件については機能の項を参照すること)

【機能】

各パラメータで指定したタスク生成情報に従って,タスクを生成する.具体的 な振舞いは以下の 通り.

まず, stk と stksz からタスクが用いるスタック領域が設定される. stksz に 0を 指定した時や,ターゲット定義の最小値よりも小さい値を指定した時には, E_PAR エラーとなる.また,保護機能対応カーネルで,生成するタスクがユーザ タスクの場合には, sstk と sstksz からシステムスタック領域が設定される.こ の場合, sstksz に 0を指定した時や,ターゲット定義の最小値より も小さい値を 指定した時には, E_PAR エラーとなる.

次に,生成されたタスクに対してタスク生成時に行うべき初期化処理が行われ, 生成されたタスクは休止状態になる.さらに, tskatr に TA_ACT を指定した場合 には,タスク起動時に行うべき初期化処理が行われ,生成されたタスクは実行 できる状態になる.

静的 API においては, tskid はオブジェクト識別名, tskatr , itskpri , stksz は 整数定数式パラメータ, exinf , task , stk は一般定数式パラメータである.コ ンフィギュレータは,静的 API のメモリ不足( E_NOMEM )エラーを検出すること ができない.

itskpri は, TMIN_TPRI 以上, TMAX_TPRI 以下でなければならない.

〔 stk に NULL を指定した場合〕

stk を NULL とした場合, stksz で指定したサイズのスタック領域が,コンフィギュ レータまたはカーネルにより確保される. stksz にターゲット定義の制約に合致 しないサイズを指定した時には,ターゲット定義の制約に合致するように大き い方に丸めたサイズで確保される.

保護機能対応カーネルにおいて,生成するタスクが ユーザタスクの場合,コン フィギュレータまたはカーネルにより確保されるスタック領域(ユーザスタッ ク領域)は,「 2.11.6 ユーザタスクのユーザスタック領域」の節の規定に従っ て,メモリオブジェクトとしてカーネルに登録される.

静的 API において,生成するタスクが制約タスクの場合( tskatr に TA_RSTR を指 定した場合),コンフィギュレータは,生成する制約タスクの起動時優先度毎 にスタック領域を確保し,同じ起動時優先度を持つ制約タスクにそのスタック 領域を共有させる.確保するスタック領域のサイズは,コンフィギュレータが スタック領域を確保し( stk に NULL を指定して生成され),同じ起動時優先度を 持つ制約タスクのスタック領域のサイズ( stksz )の最大値となる.マルチプロ セッサ対応カーネルでは,以上のスタック領域の確保処理を,制約タスクの初 期割付けプロセッサ毎に行う.

〔 stk に NULL 以外を指定した場合〕

stk に NULL 以外を指定した場合, stk と stksz で指定したスタック領域は,アプリ ケーションで確保しておく必要がある.スタック領域をアプリケーションで確 保する方法については,「 2.15.3 カーネル共通マクロ」の節を参照すること. その方法に従わず, stk や stksz に ターゲット定義の制約に合致しない先頭番地 やサイズを指定した時には, E_PAR エラーとなる.

保護機能対応カーネルにおいて,生成するタスクがシステムタスクの場合に, stk と stksz で指定したスタック領域がカーネル専用のメモリオブジェクトに含 まれない場合, E_OBJ エラーとなる.

保護機能対応カーネルにおいて,生成するタスクがユーザタスクの場合, stk と stksz で指定したスタック領域(ユーザスタック領域)は,「 2.11.6 ユーザタ スクのユーザスタック領域」の節の規定に従って,メモリオブジェクトとして カーネルに登録される.そのため,上の方法を用いてスタック領域を確保して も,ターゲット定義の制約に合致する先頭番地とサイズとなるとは限らず,ス タック領域をアプリケーションで確保する方法は,ターゲット定義である.ま た, stk と stksz で指 定したスタック領域が,登録済みのメモリオブジェクトと メモリ領域が重なる場合には, E_OBJ エラーとなる.

〔 sstk と sstksz の扱い〕

保護機能対応カーネルにおける sstk と sstksz の扱いは,生成するタスクがユー ザタスクの場合とシステムタスクの場合で異なる.

生成するタスクがユーザタスクの場合の扱いは次の通り.

sstk の記述を省略するか, sstk を NULL とした場合, sstksz で指定したサイズの システムスタック領域が,コンフィギュレータまたはカーネルにより確保され る. sstksz にターゲット定義の制約に合致しないサイズを指定した時には,ター ゲット定義の制約に合致するように大きい方に丸めたサイズで確保される. sstksz の記述も省略した場合には,ターゲット定義のデフォルトのサイズで確 保される.

sstk に NULL 以外を指定した場合, sstk と sstksz で指定したスタック領域は,ア プリケーションで確保しておく必要がある.スタック領域をアプリケーション で確保する方法については,「 2.15.3 カーネル共通マクロ」の節を参照するこ と.その方法に従わず, sstk や sstksz にターゲット定義の制約に合致しない先 頭番地やサイズを指定した時には, E_PAR エラーとなる.また, stk と stksz で指 定したシステムスタック領域がカーネル専用のメモリオブジェクトに含まれな い場合, E_OBJ エラーとなる.

生成するタスクがシステムタスクの場合の扱いは次の通り.

sstk に指定することができるのは, NULL のみである. sstk に NULL 以外を指定し た場合には, E_PAR エラーとなる.

sstksz に 0以外の値を指定した場合で, stk が NULL の場合には,コンフィギュレー タまたはカーネルにより確保されるスタック領域のサイズに, sstksz が加えら れる. stksz に sstksz を加えた値が,ターゲット定義の制約に合致しないサイズ になる時には,ターゲット定義の制約に合致するように大きい方に丸めたサイ ズで確保される.

sstksz に 0以外の値を指定した場合で, stk が NULL でない場合には, E_PAR エラー となる.

sstksz に 0を指定した場合,これらの処理は行わず, E_PAR エラーにもならない.

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

ASP カーネルでは, CRE_TSK のみをサポートする.ただし,動的生成機能拡張パッ ケージ では, acre_tsk もサポートする.

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

FMP カーネルでは, CRE_TSK のみをサポートする.

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

HRP2 カーネルでは, CRE_TSK のみをサポートする.

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

SSP カーネルでは, CRE_TSK のみをサポートする.

SSP カーネルでは,複数のタスクに対して,同じ起動時優先度を設定することは できない.設定した場合には,コンフィギュレータが E_PAR エラーを報告する.

SSP カーネルでは,制約タスクのみをサポートするため,タスク属性に TA_RSTR を指定しない場合でも,生成されるタスクは制約タスクとなる .

SSP カーネルでは, stk には NULL を指定しなくてはならず,その場合でも,コン フィギュレータはタスクのスタック領域を確保しない.これは, SSP カーネルで は,すべての処理単位が共有スタック領域を使用し,タスク毎にスタック領域 を持たないためである. stk に NULL 以外を指定した場合には, E_PAR エラーとな る.

共有スタック領域の設定方法については, DEF_STK の項を参照すること.

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

task のデータ型を TASK に, stk のデータ型を STK_T * に変更した. COUNT_STK_T と ROUND_STK_T を新設し,スタック領域をアプリケーションで確保する方法を規定 した.

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

sstk のデータ型を STK_T * に変更した.システムスタック領域をアプリケーショ ンで確保する方法を規定した.

【未決定事項】

サービスコール( acre_tsk )により, stk に NULL を指定して制約タスクを生成し た場合のスタック領域の確保方法については,今後の課題である.

【仕 様決定の理由】

保護機能対応カーネルにおいて, sstksz および sstk の記述は省略することがで きることとしたのは,保護機能対応でないカーネル用のシステムコンフィギュ レーションファイルを,保護機能対応カーネルにも変更なしに使えるようにす るためである.


AID_TSK 割付け可能なタスク ID の数の指定〔 SD 〕

【静的 API 】

AID_TSK(uint_t notsk)

【パラメータ】

uint_t notsk 割付け可能なタスク ID の数

【エラーコード】

E_RSATR 予約属性(属する保護ドメインまたはクラスが不正)

【機能】

notsk で指定した数のタスク ID を,タスクを生成するサービスコールによって割 付け可能なタスク ID として確保する.

notsk は整数定数式パラメータである.


SAC_TSK タスクのアクセス許可ベクタの設定〔 SP 〕
sac_tsk タスクのアクセス許可ベクタの設定〔 TPD 〕

【静的 API 】

SAC_TSK(ID tskid, { ACPTN acptn1, ACPTN acpt n2, ACPTN acptn3, ACPTN acptn4 })

【 C言語 API 】

ER ercd = sac_tsk(ID tskid, const ACVCT *p_acvct)

【パラメータ】

ID tskid 対象タスクの ID 番号
ACVCT * p_acvct アクセス許可ベクタを入れたパケットへのポインタ(静的 API を除く)

*アクセス許可ベクタ(パケットの内容)

ACPTN acptn1 通常操作 1のアクセス許可パターン
ACPTN acptn2 通常操作 2のアクセス 許可パターン
ACPTN acptn3 管理操作のアクセス許可パターン
ACPTN acptn4 参照操作のアクセス許可パターン

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX 〔 s〕 コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( tskid が不正)
E_RSATR 予約属性(属する保護ドメインかクラスが不正: SAC_TSKの場合)
E_NOEXS 〔 D〕 オブジェ クト未登録(対象タスクが未登録)
E_OACV 〔 sP 〕 オブジェクトアクセス違反(対象タスクに対する管理操作が許可されていない)
E_MACV 〔 sP 〕 メモリアクセス違反( p_acvct が指すメモリ領域への読出しアクセスが許可されていない)
E_OBJ オブジェクト状態エ ラー(対象タスクは静的 API で生成された: sac_tsk の場合,対象タスクに対してアクセス許可ベクタが設定済み: SAC_TSK の場合)

【機能】

tskid で指定したタスク(対象タスク)のアクセス許可ベクタ( 4つのアクセス 許可パターンの組)を,各パラメータで指定した値に設定する.

静的 API においては, tskid はオブジェクト識別名, acptn1 ~ acptn4 は整数定数 式パラメータである.

SAC_TSK は,対象タスクが属する保護ドメインの囲みの中に記述しなければなら ない.そうでない場合には, E_RSATR エラーとなる.

sac_tsk において tskid に TSK_SELF (= 0)を指定すると,自タスクが対象タスク となる.

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

ASP カーネルでは, SAC_TSK , sac_tsk をサポートしない.

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

FMP カーネルでは, SAC_TSK , sac_tsk をサポートしない.

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

HRP2 カーネルでは, SAC_TSK のみをサポートする.

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

SSP カーネルでは, SAC_TSK , sac_tsk をサポートしない.


DEF_EPR タスクの実行時優先度の定義〔 S〕

【静的 API 】

DEF_EPR(ID tskid, { PRI exepri })

【パラメータ】

ID tskid 対象タスクの ID 番号
PRI exepri タスクの実行時優先度

【エラーコード】

E_ID 不正 ID 番号( tskid が不正)
E_PAR パラメータエラー( exepri が不正)
E_ILUSE サービスコール不正使用( exepri が,自タスクの起動時優先度よりも低い場合)
E_OBJ オブジェクト状態エラー (対象タスクに対して実行優先度が設定済み)

【サポートするカーネル】

DEF_EPR は, TOPPERS/SSP カーネルのみがサポートする静的 API である.他のカー ネルは, DEF_EPR をサポートしない.

【機能】

tskid で指定したタスク(対象タスク)の実行 時優先度を, exepri で指定した優 先度に設定する.

tskid はオブジェクト識別名, exepri は整数定数式パラメータである.

exepri は, TMIN_TPRI 以上, TMAX_TPRI 以下でなければならない.また, exepri は,対象タスクの起動時優先度と同じかそれよりも高くなければならない.

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

μ ITRON4.0 仕様に定義されていない静的 API である.


del_tsk タスクの削除〔 TD 〕

【 C言語 API 】

ER ercd = del_tsk(ID tskid)

【パラメータ】

ID tskid 対象タスクの ID 番号

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( tskid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象タスクが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象タスクに対する管理操作が許可されていない)
E_OBJ オブジェクト 状態エラー(対象タスクが休止状態でない,対象タスクは静的 API で生成された)

【機能】

tskid で指定したタスク(対象タスク)を削除する.具体的な振舞いは以下の通 り.

対象タスクが休止状態である場合には,対象タスクの登録が解除され,そのタ スク ID が未使用の状態に戻される.また,タスクの生成時にタスクのスタック 領域およびシステムスタック領域がカーネルによって確保された場合は,それ らのメモリ領域が解放される.

対象タスクが休止状態でない場合には, E_OBJ エラーとなる.

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

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

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

FMP カーネルでは, del_tsk をサポートしない.

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

HRP2 カーネルでは, del_tsk をサポートしない.

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

SSP カーネルでは, del_tsk をサポートしない.


act_tsk タスクの起動〔 T〕
iact_tsk タスクの起動〔 I〕

【 C言語 API 】

ER ercd = act_tsk(ID tskid)

ER ercd = iact_tsk(ID tskid)

【パラメータ】

ID tskid 対象タスクの ID 番号

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し: act_tsk の場合,タスクコンテキストからの呼出し:iact_tsk の場合, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( tskid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象タスクが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象タスクに対する通常操作 1が許可されていない: act_tsk の場合)
E_QOVR キューイングオーバフロー(起動要求キューイング数がTMAX_ACTCNT に一致)

【機能】

tskid で指定したタスク(対象タスク)に対して起動要求を行う.具体的な振舞 いは以下の通り.

対象タスクが休止状態である場合には,対象タスクに対してタスク起動時に行 うべき初期化処理が行われ,対象タスクは実行できる状態になる.

対象タスクが休止状態でない場合には,対象タスクの起動要求キューイング数 に 1が加えられる.起動要求キューイング数に 1を加えると TMAX_ACTCNT を超える 場合には, E_QOVR エラーとなる.

act_tsk において tskid に TSK_SELF (= 0)を指定すると,自タスクが対象タスク となる.

【補足説明】

マルチプロセッサ対応カーネルでは, act_tsk / iact_tsk は,対象タスクの次回 起動時の割付けプロセッサを変更しない.


mact_tsk 割付けプロセッサ指定でのタスクの起動〔 TM 〕
imact_tsk 割付けプロセッサ指定でのタスクの起動〔 IM 〕

【 C言語 API 】

ER ercd = mact_tsk(ID tskid, ID prcid)

ER ercd = imact_tsk(ID tskid, ID prcid)

【パラメータ】

ID tskid 対象タスクの ID 番号
ID prcid タスクの 割付け対象のプロセッサの ID 番号

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し: mact_tsk の場合,タスクコンテキストからの呼出し: imact_tsk の場合, CPU ロック状態からの呼出し)
E_NOSPT 未サポート機能(対象タスクが制約タスク)
E_ID 不正 ID 番号( tskid , prcid が不正)
E_PAR パラメータエラー(対象タスクは prcid で指定したプロセッサに 割り付けられない)
E_NOEXS 〔 D〕 オブジェクト未登録(対象タスクが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象タスクに対する通常操作 1が許可されていない: mact_tsk の場合)
E_QOVR キューイングオーバフロー(起動要求キューイング数がTM AX_ACTCNT に一致)

【機能】

prcid で指定したプロセッサを割付けプロセッサとして, tskid で指定したタス ク(対象タスク)に対して起動要求を行う.具体的な振舞いは以下の通り.

対象タスクが休止状態である場合には,対象タスクの割付けプロセッサが prcid で指定したプロセッサに変更された後,対象タスクに対してタスク起動時 に行うべき初期化処理が行われ,対象タスクは実行できる状態になる.

対象タスクが休止状態でない場合には,対象タスクの起動要求キューイング数 に 1が加えられ,次回起動時の割付けプロセッサが prcid で指定したプロセッサ に変更される.起動要求キューイング数に 1を加えると TMAX_ACTCNT を超える場 合には, E_QOVR エラーとなる.

mact_tsk において tskid に TSK_SELF (= 0)を指定すると,自タスクが対象タス クとなる.

対象タスクの属するクラスの割付け可能プロセッサが, prcid で指定したプロセッ サを含んでいない場合には, E_PAR エラーとなる.

prcid に TPRC_INI (= 0)を指定すると,対象タスクの割付けプロセッサを,そ れが属するクラスの初期割 付けプロセッサとする.

【補足説明】

TMAX_ACTCNT が 2以上の場合でも,対象タスクが次に起動される時の割付けプロ セッサは,キューイングされない.すなわち,プロセッサ Aに割り付けられた休 止状態でないタスクを対象として,プロセッサ Bを割付けプロセッサとして mact_tsk を呼び出し,さらにプロセッサ Cを割付けプロセッサとして mact_tsk を 呼び出すと,対象タスクの次回起動時の割付けプロセッサがプロセッサ Cに変更 され,対象タスクがプロセッサ Bで実行されることはない.なお, TMAX_ACTCNT が 1の場合には,プロセッサ Cを割付けプロセッサとした 2回目の mact_tsk が E_QOVR エラーとなるため,次回起動時の割付けプロセッサはプロセッサ Bのまま 変更されない.

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

ASP カーネルでは, mact_tsk , imact_tsk をサポートしない.

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

HRP2 カーネルでは, mact_tsk , imact_tsk をサポートしない.

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

SSP カーネルでは, mact_tsk , imact_tsk をサポートしない.

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

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


can_act タスク起動要求のキャンセル 〔 T〕

【 C言語 API 】

ER_UINT actcnt = can_act(ID tskid)

【パラメータ】

ID tskid 対象タスクの ID 番号

【リターンパラメータ】

ER_UINT actcnt キューイングされていた起動要求の数(正の値または 0)またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( tskid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象タスクが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象タスクに対する通常操作 1が許可されていない)

【機能】

tskid で指定したタスク(対象タスク)に対する処理されていない起動要求をす べてキャンセルし,キャンセルした起動要求の数を返す.具体的な振舞いは以 下の通り.

対象タスクの起動要求キューイング数が 0に設定され, 0に設定する前の起動要 求キューイング数が,サービスコールの返値として返される.また,マルチプ ロセッサ対応カーネルにおいては,対象タスクの次回起動時の割付けプロセッ サが未設定状態に戻される.

tskid に TSK_SELF (= 0)を指定すると,自タスクが対象タスクとなる.

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

SSP カーネルでは, can_act をサポートしない.


mig_tsk タスクの割付けプロセッサの変更〔 TM 〕

【 C言語 API 】

E R ercd = mig_tsk(ID tskid, ID prcid)

【パラメータ】

ID tskid 対象タスクの ID 番号
ID prcid タスクの割付けプロセッサの ID 番号

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエ ラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し,対象タスクが自タスクでディスパッチ保留状態からの呼出し)
E_NOSPT 未サポート機能(対象タスクが制約タスク)
E_ID 不正 ID 番号( tskid , prcid が不正)
E_PAR パラメータエラー(対象タスクは prcid で指定したプロセッサに割り付けられない)
E_NOEXS 〔 D〕 オブジェクト未登録(対象タスクが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象タスクに対する通常 操作 1が許可されていない)
E_OBJ オブジェクト状態エラー(対象タスクが自タスクと異なるプロセッサに割り付けられている)

【機能】

tskid で指定したタスクの割付けプロセッサを, prcid で指定したプロセッサに 変更する.具体的な 振舞いは以下の通り.

対象タスクが,自タスクが割り付けられたプロセッサに割り付けられている場 合には,対象タスクを prcid で指定したプロセッサに割り付ける.対象タスクが 実行できる状態の場合には, prcid で指定したプロセッサに割り付けられた同じ 優先度のタスクの中で,最も優先順位が低い状態となる.

対象タスクが,自タスクが割付けられたプロセッサと異なるプロセッサ に割り 付けられている場合には, E_OBJ エラーとなる.

tskid に TSK_SELF (= 0)を指定すると,自タスクが対象タスクとなる.

ディスパッチ保留状態で,対象タスクを自タスクとして mig_tsk を呼び出すと, E_CTX エラーとなる.

prcid に TPRC_INI (= 0)を指定すると,対象タスクの割付けプロセッサを,そ れが属するクラスの初期割付けプロセッサに変更する.

【補足説明】

この仕様では,タスクをマイグレーションさせることができるのは,そのタス クと同じプロセッサに割り付けられたタスクのみである.そのため, CPU ロック 状態やディスパッチ禁止状態を用いて,他のタスクへのディスパッチが起こら ないようにすることで,自タスクが他のプロセッサへマイグレーショ ンされる のを防ぐことができる.

対象タスクが,最初から prcid で指定したプロセッサに割り付けられている場合 には,割付けプロセッサの変更は起こらないが,優先順位が同一優先度のタス クの中で最低となる.

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

ASP カーネルでは, mig_tsk をサポートしない.

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

HRP2 カーネルでは, mig_tsk をサポートしない.

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

SSP カーネルでは, mig_tsk をサポートしない.

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

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


ext_tsk 自タスクの終了〔 T〕

【 C言語 API 】

ER ercd = ext_tsk()

【パラメータ】

なし

【リターンパラメータ】

ER ercd エラーコード

【エラーコード】

E_SYS システムエラー(カーネルの誤動作)
E_CTX コンテキストエラー(非タスクコンテキストからの呼出し)

【機能】

自タスクを終了させる.具体的な振舞いは以下の通り.

自タスクに対してタスク終了時に行うべき処理が行われ,自タスクは休止状態 になる.さらに,自タスクの起動要求キューイング数が 0でない場合には,自タ スクに対してタスク起動時に行うべき処理が行われ,自タスクは実行できる状 態になる.またこの時,起動要求キューイング数から 1が減ぜられる.

ext_tsk は, CPU ロック解除状態,割込み優先度マスク全解除状態,ディスパッ チ許可状態で呼び出すのが原則であるが,そうでない状態で呼び出された場合 には, CPU ロック解除状態,割込み優先度マスク全解除状態,ディスパッチ許可 状態に遷移させた後,自タスクを終了させる.

ext_tsk が正常に処理された場合, ext_tsk からはリターンしない.

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

SSP カーネルでは, ext_tsk をサポートしない.自タスクを終了させる場合には, タスクのメインルーチンからリターンする.

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

ext_tsk を非タスクコンテキストから呼び出した場合に, E_CTX エラーが返るこ ととした. μ ITRON4.0 仕様においては, ext_tsk からはリターンしないと規定さ れている.


ter_tsk タスクの強制終了〔 T〕

【 C言語 API 】

ER ercd = ter_tsk(ID tskid)

【パラメータ】

ID tskid 対象タスクの ID 番号

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( tskid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象タスクが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象タスクに対する通常操作 2が許可されていない)
E _ILUSE サービスコール不正使用(対象タスクが自タスク)
E_OBJ オブジェクト状態エラー(対象タスクが休止状態,対象タスクが自タスクと異なるプロセッサに割り付けられている)

【機能】

tskid で指定したタスク(対象タスク)を終了さ せる.具体的な振舞いは以下の 通り.

対象タスクが休止状態でない場合には,対象タスクに対してタスク終了時に行 うべき処理が行われ,対象タスクは休止状態になる.さらに,対象タスクの起 動要求キューイング数が 0でない場合には,対象タスクに対してタスク起動時に 行うべき処理が行われ,対象タスクは実行できる状態になる.またこの時,起 動要求キューイング数から 1が減ぜられる.

対象タスクが休止状態である場合には, E_OBJ エラーとなる.また,対象タスク が自タスクの場合には, E_ILUSE エラーとなる.

マルチプロセッサ対応カーネルでは,対象タスクは,自タスクと同じプロセッ サに割り付けられているタスクに限られる.対象タスクが自タスクと異なるプ ロセッサに割り付けられている場合には, E_OBJ エラーとなる.

【 TOPPERS/FMP カーネルにおける使用上の注意】

現時点の FMP カーネルの実装では,デッドロック回避のためのリトライ処理によ り,サービスコールの処理時間に上限がないため,注意が必要である(ロック 方式にも依存する).

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

SSP カーネルでは, ter_tsk をサポートしない.


chg_pri タスクのベース優先度の変更〔 T〕

【 C言語 API 】

ER ercd = chg_pri(ID tskid, PRI tskpri)

【パラメータ】

ID tskid 対象タスクの ID 番号
PRI tskpri ベース優先度

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_NOSPT 未サポート機能(対象タスクが制約タスク)
E_ID 不正 ID 番号( tskid が不正)
E_PAR パラメータエラー( tskpri が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象タスクが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象タスクに対する通常操作 2が許可されていない)
E_ILUSE サービスコール不正使用( tskpri が,対象タスクがロックしているかロックを待っている優先度上限ミューテックスの上限優先度よりも高い場 合)
E_OBJ オブジェクト状態エラー(対象タスクが休止状態)

【機能】

tskid で指定したタスク(対象タスク)のベース優先度を, tskpri で指定した優 先度に変更する.具体的な振舞いは以下の通り.

対象タスクが休止状態でない場合には,対象タスクのベース優先度が, tskpri で指定した優先 度に変更される.それに伴って,対象タスクの現在優先度も変 更される.

対象タスクが,優先度上限ミューテックスをロックしていない場合には,次の 処理が行われる.対象タスクが実行できる状態の場合には,同じ優先度のタス クの中で最低優先順位となる.対象タスクが待ち状態で,タスクの優先度順の 待ち行列につながれている場合には,対象タスクの変更後の現在優先度に従っ て,その待ち 行列中での順序が変更される.待ち行列中に同じ現在優先度のタ スクがある場合には,対象タスクの順序はそれらの中で最後になる.

対象タスクが,優先度上限ミューテックスをロックしている場合には,対象タ スクの現在優先度が変更されることはなく,優先順位も変更されない.

対象タスクが休止状態である場合には, E_OBJ エラーとなる.

tskid に TSK_SELF (= 0)を指定すると,自タスクが対象タスクとなる.また, tskpri に TPRI_INI (= 0)を指定すると,対象タスクのベース優先度が,起動時 優先度に変更される.

tskpri は, TPRI_INI であるか, TMIN_TPRI 以上, TMAX_TPRI 以下でなければなら ない.また,対象タスクが優先度上限ミューテックスをロックしているかロッ クを待っている場合, tskpri は,それらのミューテックスの上限優先度と同じ かそれより低くなければならない.

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

SSP カーネルでは, chg_pri をサポートしない.

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

対象タスクが,同じ優先度のタスクの中で最低の優先順位となる(対象タスク が待ち状態で,タスクの優先度順の待ち行列につながれている場合には,同じ 優先度のタスクの中での順序が最後になる)条件を変更した.


get_pri タスク優先度の参照〔 T〕

【 C言語 API 】

ER ercd = g et_pri(ID tskid, PRI *p_tskpri)

【パラメータ】

ID tskid 対象タスクの ID 番号
PRI * p_tskpri 現在優先度を入れるメモリ領域へのポインタ

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード
PRI tskpri 現在優先度

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( tskid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象タスクが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象タスクに対する参照操作が許可されていない)
E_MACV 〔 P〕 メモリアクセス違反( p_tskpri が指すメモリ領域への書込みアクセスが許可されていない)
E_OBJ オブジェクト状態エラー(対象タスクが休止状態)

【機能】

tskid で指定したタスク(対象タスク)の現在優先度を参照する.具体的な振舞 いは以下の通り.

対象タスクが休止状態でない場合には,対象タスクの現在優先度が, p_tskpri で指定した メモリ領域に返される.対象タスクが休止状態である場合には, E_OBJ エラーとなる.

tskid に TSK_SELF (= 0)を指定すると,自タスクが対象タスクとなる.

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

SSP カーネルでは, get_pri をサポートしない.


get_inf 自タスクの拡張情報の参照〔 T〕

【 C言語 API 】

ER ercd = get_inf(intptr_t *p_exinf)

【パラメータ】

intptr_t * p_exinf 拡張情報を入れるメモリ領域へのポインタ

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード
intptr_t exinf 拡張情報

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_MACV 〔 P〕 メモリアクセス違反( p_exinf が指すメモリ領域への書込みアクセスが許可されていない)

【機能】

自タスクの拡張情報を参照する.参照した拡張情報は, p_exinf で指定したメモ リ領域に返される.

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

SSP カーネルでは, get_inf をサポートしない.

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

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


ref_tsk タスクの状態参照〔 T〕

【 C言語 API 】

ER ercd = ref_tsk(ID tskid, T_RTSK *pk_rtsk)

【パラメータ】

ID tskid 対象タスクの ID 番号
T_RTSK * pk_rtsk タスクの現在状態を入れるパケットへのポインタ

【リターンパラ メータ】

ER ercd 正常終了( E_OK )またはエラーコード

*タスクの現在状態(パケットの内容)

STAT tskstat タスク状態
PRI tskpri タスクの現在優先度
PRI tskbpri タスクのベース優先度
STAT tskwait タスクの待ち要因
ID wobjid タスクの待ち対象のオブジェクトの ID
TMO lefttmo タスクがタイムアウトするまでの時間
uint_t actcnt タスクの起動要求キューイング数
uint_t wupcnt タスクの起床要求キューイング数
bool_t texmsk タスクがタスク例外処理マスク状態か否か(保護機能対応カーネルの場合)
bool_t waifbd タスクが待ち禁止状態か否か(保護機能対応カーネルの場合)
uint_t svclevel タスクの拡張サービスコールのネストレベル(保護機能対応カーネルの場合)
ID prcid タスクの割付けプロセッサの ID (マルチプロセッサ対応カーネルの場合)
ID actprc タスクの次回起動時の割付けプロセッサの ID (マルチプロセッサ対応カーネルの場合)

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( tskid が不正)
E_NOE XS 〔 D〕 オブジェクト未登録(対象タスクが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象タスクに対する参照操作が許可されていない)
E_MACV 〔 P〕 メモリアクセス違反( pk_rtsk が指すメモリ領域への書込みアクセスが許可されていない)

【機能】

tskid で指定したタスク(対象タスク)の現在状態を参照する.参照した現在状 態は, pk_rtsk で指定したメモリ領域に返される.

tskstat には,対象タスクの現在のタスク状態を表す次のいずれかの値が返され る.

TTS_RUN 0x01U 実行状態
TTS_RDY 0x02U 実行可能状態
TTS_WAI 0x04U 待ち状態
TTS_SUS 0x08U 強制待ち状態
TTS_WAS 0x0cU 二重待ち状態
TTS_DMT 0x10U 休止状態

マルチプロセッサ対応カーネルでは,対象タスクが自タスクの場合にも, tskstat が TTS_SUS となる場合がある.この状況は,自タスクに対して ref_tsk を 発行するのと同じタイミングで,他のプロセッサで実行されているタスクから 同じタスクに対して sus_tsk が発行された場合に発生する可能性がある.

対象タスクが休止状態でない場合には, tskpri には対象タスクの現在優先度が, tskbpri には対象タスクのベース優先度が返される.対象タスクが休止 状態であ る場合には, tskpri と tskbpri の値は保証されない.

対象タスクが待ち状態である場合には, tskwait には,対象タスクが何を待って いる状態であるかを表す次のいずれかの値が返される.

TTW_SLP 0x0001U 起床待ち
TTW_DLY 0x0002U 時間経過待ち
TTW_SEM 0x0004U セマフォの資源獲得待ち
TTW_FLG 0x0008U イベントフラグ待ち
TTW_SDTQ 0x0010U データキューへの送信待ち
TTW_RDTQ 0x0020U データキューからの受信待ち
TTW_SPDQ 0x0100U 優先度データキューへの送信待ち
T TW_RPDQ 0x0200U 優先度データキューからの受信待ち
TTW_MBX 0x0040U メールボックスからの受信待ち
TTW_MTX 0x0080U ミューテックスのロック待ち状態
TTW_MPF 0x2000U 固定長メモリブロックの獲得待ち

対象タスクが待ち状態でない場合には, tskwait の値は保証されない .

対象タスクが起床待ち状態および時間経過待ち状態以外の待ち状態である場合 には, wobjid に,対象タスクが待っているオブジェクトの ID 番号が返される. 対象タスクが待ち状態でない場合や,起床待ち状態または時間経過待ち状態で ある場合には, wobjid の値は保証されない.

対象タスクが時間経過待ち状態以外の待ち状態である場合には, lefttmo に,タ スクがタイムアウトを起こすまでの相対時間が返される.タスクがタイムアウ トを起こさない場合には, TMO_FEVR (= -1)が返される.

対象タスクが時間経過待ち状態である場合には, lefttmo に,タスクの遅延時間 が経過して待ち解除されるまでの相対時間が返される.ただし,返されるべき 相対時間が TMO 型に格納することができない場合がありうる.この場合には,相 対時間 ( RELTIM 型, uint_t 型に定義される)を TMO 型( int_t 型に定義される) に型キャストした値が返される.

対象タスクが待ち状態でない場合には, lefttmo の値は保証されない.

actcnt には,対象タスクの起動要求キューイング数が返される.

対象タスクが休止状態でない場合には, wupcnt に,タスクの起床要求キューイ ング数が返さ れる.対象タスクが休止状態である場合には, wupcnt の値は保証 されない.

保護機能対応カーネルで,対象タスクが休止状態でない場合には, texmsk に, 対象タスクがタスク例外処理マスク状態の場合に true ,そうでない場合に false が返される. waifbd には,対象タスクが待ち禁止状態の場合に true ,そう でない場合に false が返される.また svclevel には,対象タスクが拡 張サービス コールを呼び出していない場合には 0,呼び出している場合には,実行中の拡張 サービスコールがネスト段数が返される.対象タスクが休止状態である場合に は, texmsk , waifbd , svclevel の値は保証されない.

マルチプロセッサ対応カーネルでは, prcid に,対象タスクの割付けプロセッサ の ID 番号が返される.また actprc には,対象タスクの次回起動時の割付けプロ セッサの ID 番号が返される.次回起動時の割付けプロセッサが未設定の場合に は, actprc に TPRC_NONE (= 0)が返される.

tskid に TSK_SELF (= 0)を指定すると,自タスクが対象タスクとなる.

【補足説明】

対象タスクが時間経過待ち状態である場合に, lefttmo ( TMO 型)に返される値 を RELTIM 型に型キャストすることで,タスクが待ち解除されるまでの相対時間 を正しく得ることができる.

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

ASP カーネルでは, tskwait に TTW_MTX が返ることはない.ただし,ミューテック ス機能拡張パッケージを用いると, tskwait に TTW_MTX が返る場合がある.

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

FMP カーネルでは, tskwait に TTW_MTX が返ることはない.

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

HRP2 カーネルでは, tskwait に TTW_MBX が返ることはない.

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

SSP カーネル では, ref_tsk をサポートしない.

【使用上の注意】

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

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

対象タスクが時間経過待ち状態の時に lefttmo に返される値について規定した. また,参照できるタスクの状態から,強制待ち要求ネスト数( suscnt )を除外 した.

マルチプロセッサ対応カーネルで参照できる情報として,割付けプロセッサの ID ( prcid )と次回起動時の割付けプロセッサの ID ( actprc )を追 加した.

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

保護機能対応カーネルで参照できる情報として,タスク例外処理マスク状態か 否か( texmsk ),待ち禁止状態か否か( waifbd ),拡張サービスコールのネス トレベル( svclevel )を追加した.


4.2 タスク付属同期機能

タスク付属同期機能は,タスクとタスクの間,または非タスクコンテキストの 処理とタスクの間で同期を取るために,タスク単独で持っている機能である.

タスク付属同期機能に関連して,各タスクが持つ情報は次の通り.

  • ・起床要求キューイング数

タスクの起床要求キューイング数は,処理されていないタスクの起床要求の数 であり,タスクの起動時に 0に初期化される.

タスク付属同期機能に関連するカーネル構成マクロは次の通り.

TMAX_WUPCNT タスクの起床要求キューイング数の最大値

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

ASP カーネルでは, TMAX_WUPCNT は 1に固定されている.

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

FMP カーネルでは, TMAX_WUPCNT は 1に固定されている.

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

HRP2 カーネルでは, TMAX_WUPCNT は 1に固定されている.

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

SSP カーネルでは,タスク付属同期機能をサポートしない.

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

この仕様では,強制待ち要求をネストする機能をサポートしないこととした. 言い換えると,強制待ち要求ネスト数の最大値を 1に固定する.これに伴い,強 制待ち状態から強制再開するサービスコール( frsm_tsk )とタスクの強制待ち 要求ネスト数の最大値を表すカーネル構成マクロ( TMAX_SUSCNT )は廃止した. また, ref_tsk で参照できる情報( T_RTSK のフィールド)から,強制待ち要求ネ スト数( suscnt )を除外した.


slp_tsk 起床待ち〔 T〕
tslp_tsk 起床待ち(タイムアウト付き)〔 T〕

【 C言語 API 】

ER ercd = slp_tsk()

ER ercd = tslp_tsk(TMO tmout)

【パラメータ】

TMO tmout タイム アウト時間( tslp_tsk の場合)

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(ディスパッチ保留状態からの呼出し)
E_NOSPT 未サポート機能(制約タスクからの呼出し)
E_PAR パラメータエラー( tmout が不正: tslp_tsk の場合)
E_TMOUT ポーリング失敗またはタイムアウト( slp_tsk を除く)
E_RLWAI 待ち禁止状態または待ち状態の強制解除

【機能】

自タスクを起床待ちさせる.具体的な振舞いは以下の通り.

自タスクの起床要求キューイング数が 0でない場合には,起床要求キューイング 数から 1が減ぜられる.起床要求キューイング数が 0の場合には,自タスクは起 床待ち状態となる.

【補足説明】

自タスクの起床要求キューイング数が 0でない場合には,自タスクは実行できる 状態を維持し,自タスクの優先順位は変化しない.


wup_tsk タスクの起床〔 T〕
iwup_tsk タスクの起床〔 I〕

【 C言語 API 】

ER ercd = wup_tsk(ID tskid)

ER ercd = iwup_tsk(ID tskid)

【パラメータ】

ID tskid 対象タスクの ID 番号

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し: wup_tsk の場合,タスクコンテキストからの呼出し:iwup_tsk の場合, CPU ロック状態からの呼出し)
E_NOSPT 未サポート機能(対象タスクが制約タスク)
E_ID 不正 ID 番号( tskid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象タスクが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象タスクに対する通常操作 1が許可されていない: wup_tsk の場合)
E_OBJ オブジェクト状態エラー(対象タスクが休止状態 )
E_QOVR キューイングオーバフロー(起床要求キューイング数がTMAX_WUPCNT に一致)

【機能】

tskid で指定したタスク(対象タスク)を起床する.具体的な振舞いは以下の通 り.

対象タスクが起床待ち状態である場合には,対象タスクが待ち解除され る.待 ち解除されたタスクには,待ち状態となったサービスコールから E_OK が返る.

対象タスクが起床待ち状態でなく,休止状態でもない場合には,対象タスクの 起床要求キューイング数に 1が加えられる.起床要求キューイング数に 1を加え ると TMAX_WUPCNT を超える場合には, E_QOVR エラーとなる.

対象タスクが休止状態である場合には, E_OBJ エラーとなる.

wup_tsk において tskid に TSK_SELF (= 0)を指定すると,自タスクが対象タスク となる.


can_wup タスク起床要求のキャンセル〔 T〕

【 C言語 API 】

ER_UINT wupcnt = can_wup(ID tskid)

【パラメータ】

ID tskid 対象タスクの ID 番号

【リターンパラメータ】

ER_UINT wupcnt キューイングされていた起床要求の数(正の値または 0)またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_NOSPT 未サポート機能(対象タスクが制約タスク)
E_ID 不正 ID 番号( tskid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象タスクが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象タスクに対する通常操作 1が許可されていない)
E_OBJ オブジェクト状態エラー(対象タスクが休止状態)

【機能】

tskid で指定したタスク(対象 タスク)に対する処理されていない起床要求をす べてキャンセルし,キャンセルした起床要求の数を返す.具体的な振舞いは以 下の通り.

対象タスクが休止状態でない場合には,対象タスクの起床要求キューイング数 が 0に設定され, 0に設定する前の起床要求キューイング数が,サービスコール の返値として返される.

対象タスクが休止状態である場合には, E_OBJ エラーとなる.

tskid に TSK_SELF (= 0)を指定すると,自タスクが対象タスクとなる.


rel_wai 強制的な待ち解除〔 T〕
irel_wai 強制的な待ち解除〔 I〕

【 C言語 API 】

ER ercd = rel_wai(ID tskid)

ER ercd = irel_wai(ID tskid)

【パラメータ】

ID tskid 対象タスクの ID 番号

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し: rel_wai の場合,タスクコンテキストからの呼出し:irel_wai の場合, CPU ロック状態からの呼出し)
E_NOSPT 未サポート機能(対象タスクが制約タスク)
E_ID 不正 ID 番号( tskid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象タスクが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象タスクに対する通常操作 2が許可されていない: rel_wai の場合)
E_OBJ オブジェクト状態エラー(対象タスクが待ち状態でない)

【機能】

tskid で指定したタスク(対象タスク)を,強制的に待ち解除する.具体的な振 舞いは以下の通り.

対象タスクが待ち状態である場合には,対象タスクが待ち解除される.待ち解 除されたタスクには,待ち状態となったサービスコールから E_RLWAI が返る.

対象タスクが待ち状態でない場合には, E_OBJ エラーとなる.


sus_tsk 強制待ち状態への遷移〔 T〕

【 C言語 API 】

ER ercd = sus_tsk(ID tskid)

【パラメー タ】

ID tskid 対象タスクの ID 番号

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し,対象タスクが自タスクでディスパッチ保留状態からの呼出し)
E_NOSPT 未サポート機能(対象タスクが制約タスク)
E_ID 不正 ID 番号( tskid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象タスクが未登録)
E_OACV 〔 P〕 オ ブジェクトアクセス違反(対象タスクに対する通常操作 2が許可されていない)
E_OBJ オブジェクト状態エラー(対象タスクが休止状態)
E_QOVR キューイングオーバフロー(対象タスクが強制待ち状態)

【機能】

tskid で指定したタスク(対象タスク)を強制待ちにする.具体的な振舞いは以 下の通り.

対象タスクが実行できる状態である場合には,対象タスクは強制待ち状態とな る.また,待ち状態(二重待ち状態を除く)である場合には,二重待ち状態と なる.

対象タスクが強制待ち状態または二重待ち状態である場合は E_QOVR エラー,休 止状態で ある場合には E_OBJ エラーとなる.

マルチプロセッサ対応カーネルでは,対象タスクが自タスクの場合にも, E_QOVR エラーとなる場合がある.この状況は,自タスクに対して sus_tsk を発行 するのと同じタイミングで,他のプロセッサで実行されているタスクから同じ タスクに対して sus_tsk が発行された場合に発生する可能性がある.

tskid に TSK_SELF (= 0)を指定すると,自タスクが対象タスクとなる.

ディスパッチ保留状態で,対象タスクを自タスクとして sus_tsk を呼び出すと, E_CTX エラーとなる.


rsm_tsk 強制待ち状態からの再開〔 T〕

【 C言語 API 】

ER ercd = rsm_tsk(ID tskid)

【パラメータ】

ID tskid 対象タスクの ID 番号

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_NOSPT 未サポート機能(対象タスクが制約タスク)
E_ID 不正 ID 番号( tskid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象タスクが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象タスクに対する通常操作 2が許可されていない)
E_OBJ オブジェクト状態エラー(対象タスクが強制待ち状態でない)

【機能】

tskid で指定したタスク(対象タスク)を,強制待ちか ら再開する.具体的な振 舞いは以下の通り.

対象タスクが強制待ち状態である場合には,対象タスクは強制待ちから再開さ れる.強制待ち状態でない場合には, E_OBJ エラーとなる.


dis_wai 待ち禁止状態への遷移〔 TP 〕
idis_wai 待ち禁止状態への遷移〔 IP 〕

【 C言語 API 】

ER ercd = dis_wai(ID tskid)

ER ercd = idis_wai(ID tskid)

【パラメータ】

ID tskid 対象タスクの ID 番号

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し: dis_wai の場合,タスクコンテキストからの呼出し:idis_wai の場合, CPU ロック状態から の呼出し)
E_NOSPT 未サポート機能(対象タスクが制約タスク)
E_ID 不正 ID 番号( tskid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象タスクが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象タスクに対する通常操作 2が許可されていない: dis_wai の場合)
E_OBJ オブジェクト状態エラー(対象タスクが休止状態,対象タスクがタスク例外処理マスク状態でない)
E_QOVR キューイングオーバフロー(対象タスクが待ち禁止状態)

【機能】

tskid で指定したタスク(対象タスク)を待ち禁止状態にする.具体的な振舞い は以下の通り.

対象タスクがタスク例外処理マスク状態であり,待ち禁止状態でない場合には, 対象タスクは待ち禁止状態になる.

対象タスクが休止状態である場合には, E_OBJ エラーとなる.また,対象タスク がタスク例外処理マスク状態でない場合には E_OBJ エラー,待ち禁止状態の場合 には E_QOVR エラーとなる.

dis_wai において tskid に TSK_SELF (= 0)を指定すると,自タスクが対象タスク となる.

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

ASP カーネルでは, dis_wai をサポートしない.

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

FMP カーネルでは, dis_wai をサポートしない .

【補足説明】

dis_wai は,対象タスクの待ち解除は行わない.対象タスクを待ち禁止状態にす ることに加えて待ち解除したい場合には, dis_wai を呼び出した後に, rel_wai を呼び出せばよい.

【未決定事項】

マルチプロセッサ対応カーネルでは,対象タスクを,自タスクと同じプロセッ サに割り付けられているタスクに限るなどの制限を導入する可能性があるが, 現時点では未決定である.

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

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


ena_wai 待ち禁止状態の解除〔 TP 〕
iena_wai 待ち禁止状態の解除〔 IP 〕

【 C言語 API 】

ER ercd = ena_wai(ID tskid)

ER ercd = iena_wai(ID tskid)

【パラメータ】

ID tskid 対象 タスクの ID 番号

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し: ena_wai の場合,タスクコンテキストからの呼出し:iena_wai の場合, CPU ロック状態からの呼出し)
E_NOSPT 未サポート機能(対象タスクが制約タスク)
E_ID 不正 ID 番号( tskid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象タスクが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象タスクに対する通常操作 2が許可されていない: ena_wai の場合)
E_OBJ オブジェクト状態エラー(対象タスクが休止状態,対象タスクが待ち禁止状態でない)

【機能】

tskid で指定したタスク(対象タスク)の待ち禁止状態を解除する.具体的な振 舞いは以下の通り.

対象タスクが待ち禁止状態である場合には,待ち禁止状態は解除される.対象 タスクが休止状態である場合や,待ち禁止状態でない場合には, E_OBJ エラーと なる.

ena_wai において tskid に TSK_SELF (= 0)を指定すると,自タスクが対象タスク となる.

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

ASP カーネルでは, ena_wai をサポートしない.

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

FMP カーネルでは, ena_wai をサポートしない.

【未決定事項】

マルチプロセッサ対応カーネルでは,対象タスクを,自タスクと同じプロセッ サに割り付けられているタスクに限るなどの制限を導入する 可能性があるが, 現時点では未決定である.

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

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


dly_tsk 自タスクの遅延〔 T〕

【 C言語 API 】

ER ercd = dly_tsk(RELTIM dlytim)

【パラメータ】

RELTIM dlytim 遅延時間

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコー ド】

E_CTX コンテキストエラー(ディスパッチ保留状態からの呼出し)
E_NOSPT 未サポート機能(制約タスクからの呼出し)
E_PAR パラメータエラー( dlytim が不正)
E_RLWAI 待ち禁止状態または待ち状態の強制解除

【機能】

dlytim で指定した時間,自タスクを遅延させる.具体的な振舞いは以下の通り.

自タスクは, dlytim で指定した時間が経過するまでの間,時間経過待ち状態と なる. dly_tsk を呼び出してから dlytim で指定した相対時間後に,自タスクは待 ち解除され, dly_tsk から E_OK が返る.

dlytim は, TMAX_RE LTIM 以下でなければならない.


4.3 タスク例外処理機能

タスク例外処理ルーチンは,カーネルが実行を制御する処理単位で,タスクと 同一のコンテキスト内で実行される.タスク例外処理ルーチンは,各タスクに 1 つのみ登録できるため,タスク ID によって識別する.

タスク例外処理機能に関連して,各タスクが持つ情報は次の通り.

  • ・タスク例外処理ルーチン属性
  • ・タスク例外処理禁止フラグ
  • ・保留例外要因
  • ・タスク例外処理ルーチンの先頭番地

タスク例外処理ルーチン属性に指定できる属性はない.そのため,タスク例外 処理ルーチン属性には, TA_NULL を指定しなければならない.

タスクは,タスク例外処理ルーチンの実行を保留するためのタスク例外処理禁 止フラグを持つ.タスク例外処理禁止フラグがセットされた状態をタスク例外 処理禁止状態,クリアされた状態をタスク例外処理許可状態と呼ぶ.タスク例 外処理禁止フラグは,タスクの起動時に,セットした状態に初期化される.

タスクの保留例外要因は,タスクに対して要求された例外要因を蓄積するため のビットマップであり,タスクの起動時に 0に初期化される.

タスク例外処理ルーチンは,「タスク例外処理許可状態である」「保留例外要 因が 0でない」「タスクが実行状態である」「タスクコンテキストが実行されて いる」「割込み優先度マスク全解除状態である」「 CPU ロック状態でない」の 6 つの条件が揃った場 合に実行が開始される.保護機能対応カーネルにおいては, さらに,「タスク例外処理マスク状態でない」という条件が追加される.タス ク例外処理マスク状態については,「 2.6.5 タスク例外処理マスク状態と待ち 禁止状態」の節を参照すること.

タスク例外処理ルーチンの実行が開始される時,タスク例外処理禁止フラグは セットされ,保留例外要因は 0にクリアされる.また,タスク例外処理ルーチン からのリターン時には,タスク例外処理禁止フラグはクリアされる.

保護機能対応カーネルでは,ユーザタスクのタスク例外処理ルーチンの実行開 始時に,リターン先の番地やシステム状態等が,ユーザスタック上に保存され る.ここで,ユーザスタック領域に十分な空きがない場合や,ユーザスタック ポインタがユーザスタック領域以外を指している場合,カーネルは,エミュレー トされた CPU 例 外を発生させる.これを,タスク例外実行開始時スタック不正例 外と呼ぶ.

逆に,タスク例外処理ルーチンからのリターン時には,リターン先の番地やシ ステム状態等が,ユーザスタック上から取り出される.ここで,ユーザスタッ ク領域に積まれている情報が足りない場合や,ユーザスタックポインタがユー ザスタック領域以外を指している場合,カーネルは,エミュレートされた CPU 例 外を発 生させる.これを,タスク例外リターン時スタック不正例外と呼ぶ.

タスク例外実行開始時スタック不正例外またはタスク例外リターン時スタック 不正例外を起こしたタスクの実行を継続した場合の動作は保証されないため, アプリケーションは,これらの CPU 例外を処理する CPU 例外ハンドラで, 「 2.8.1 CPU 例外処理の流れ」の節の (b) または (d) の方法でリカバリ処理を行う 必要がある.

保護機能対応カーネルにおいて,タスク例外処理ルーチンは,タスクと同じ保 護ドメインに属する.

タスク例外処理機能に用いるデータ型は次の通り.

TEXPTN タスク例外要因のビットパターン(符号無し整数, uint_t に定義)

C 言語によるタスク例外処理ルーチンの記述形式は次の通り.

void task_exception_routine(TEXPTN texptn, intptr_t exinf)  
{  
     タスク例外処理ルーチン本体  
}

texptn にはタスク例外処理ルーチン起動時の保留例外要因が, exinf にはタスク の拡張情報が,それぞれ渡される.

タスク例外処理機能に関連するカーネル構成マクロは次の通り.

TBIT_TEXPTN タスク例外要因のビット数( TEXPTN の有効ビット数)

【補足説明】

保護機能対応でないカーネルでは,タスク例外処理ルーチンの実行開始条件の 内,「 CPU ロック状態でない」は省いても 同じ結果になる.これは, CPU ロック 状態で他の条件が揃うことはないためである.一方,保護機能対応カーネルで は, CPU ロック状態で拡張サービスコールからリターンした場合(より厳密には, タスク例外処理マスク状態が解除された場合)に, CPU ロック状態で他の条件が 揃うことになる.

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

ASP カーネルでは,タスク例外要因のビット数( TBIT_TEXPTN )は 16 以上である.

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

FMP カーネルでは,タスク例外要因のビット数( TBIT_TEXPTN )は 16 以上である.

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

HRP2 カーネルでは,タスク例外要因のビット数 ( TBIT_TEXPTN )は 16 以上である.

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

SSP カーネルでは,タスク例外処理機能をサポートしない.

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

割込み優先度マスク全解除状態でない場合には,タスク例外処理ルーチンの実 行が開始されないという仕様に変更した.

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

ユーザタスクのタスク例外処理ルーチンの実行開始時とリターン時にユーザス タックが不正となる問題に関して,μ ITRON4.0/PX 仕様では考慮されていない.

【仕様変更の経緯】

この仕様の Release 1.2 以前では,タスク例外処理ルーチンの実行開始条件に 「割込み優先度マスク全解除状態である」の条件がなかったが, Release1.3 以 降で追加した.これは,マルチプロセッサ対応カーネルにおいて,他プロセッ サで実行中のタスクに対してタスク例外処理を要求した場合に,割込み優先度 マスクが全解除でないと,タスク例外処理ルーチンをただちに実行開始するこ とができないためである.なお, ASP カーネル Release 1.6 以前と, FMP カーネ ル Release 1.1.1 以前のバージョンは,古い仕様に従って実装されている.


DEF_TEX タスク例外処理ルーチンの定義〔 S〕
def_tex タスク例外処理ルーチンの定義〔 TD 〕

【静的 API 】

DEF_TEX(ID t skid, { ATR texatr, TEXRTN texrtn })

【 C言語 API 】

ER ercd = def_tex(ID tskid, const T_DTEX *pk_dtex)

【パラメータ】

ID tskid 対象タスクの ID 番号
T_DTEX * pk_dtex タスク例外処理ル ーチンの定義情報を入れたパケットへのポインタ(静的 API を除く)

*タスク例外処理ルーチンの定義情報(パケットの内容)

ATR texatr タスク例外処理ルーチン属性
TEXRTN texrtn タスク例外処理ルーチンの先頭番地

【リターンパラ メータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX 〔 s〕 コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( tskid が不正)
E_RSATR 予約属性( texatr が不正または使用できない,属する保護ドメインかクラスが不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象タスクが未登録)
E_OACV 〔 sP 〕 オブジェクトアクセス違反(対象タスクに対する管理操作が許可されていない)
E_MACV 〔 sP 〕 メモリアクセス違反( pk_dtex が指すメモリ領域への読出しアクセスが許可されていない)
E_PAR パラメータエラー( texrtn が不正)
E_OBJ オブジェクト状態エラー(タスク例外処理ルーチンを定義済みのタスクに対する定義,タスク例外処理ルーチ ンを未定義のタスクに対する解除,対象タスクは静的 API で生成された: def_tex の場合)

【機能】

tskid で指定したタスク(対象タスク)に対して,各パラメータで指定したタス ク例外処理ルーチン定義情報に従って,タスク例外処理ルーチンを定義する.

ただし, def_tex において pk_dtex を NULL にした場合には,対象タスクに対する タスク例外処理ルーチンの定義を解除する.また,対象タスクのタスク例外処 理禁止フラグをセットし,保留例外要因を 0に初期化する.

静的 API においては, tskid はオブジェクト識別名, texatr は整数定数式パラメー タ, texrtn は一般定数式パラメータである.

静的 API によって生成したタスクに対しては,タスク例外処理ルーチンの登録は DEF_TEX によって行わねばならず, def_tex によってタスク例外処理ルーチンを 登録/登録解除することはできない. def_tex において,対象タスクが静的 API で生成したタスクである場合には, E_OBJ エラーとなる.

タスク例外処理ルーチンを定義する場合( DEF_TEX の場合および def_tex におい て pk_dtex を NULL 以外にした場合)で,対象タスクに対してすでにタスク例外処 理ルーチンが定義されている場合には, E_OBJ エラーとなる.

保護機能対応カーネルにおいて, DEF_TEX は,対象タスクが属する保護ドメイン の囲みの中に記述しなければならない.そうでない場合には, E_RSATR エラーと なる.また, def_tex でタスク例外処理ルーチンを定義する場合には,タスク例 外処理ルーチンの属する保護ドメインを設定する必要はなく,タスク例外処理 ルーチン属性に TA_DOM(domid) を指定した場合には E_RSATR エラーとなる.ただ し, TA_DOM(TDOM_SELF) を指定した場合には,指定が無視され, E_RSATR エラー は検出されない.

タスク例外処理ルーチンの定義を解除する場合( def_tex において pk_dtex を NULL にし た場合)で,対象タスクに対してタスク例外処理ルーチンが定義され ていない場合には, E_OBJ エラーとなる.

def_tex において tskid に TSK_SELF (= 0)を指定すると,自タスクが対象タスク となる.

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

ASP カーネルでは, DEF_TEX のみをサポートする.ただし,動的生成機能拡張パッ ケージでは, def_tex もサポートする.

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

FMP カーネルでは, DEF_TEX のみをサポートする.

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

HRP2 カーネルでは, DEF_TEX のみをサポートする.

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

texrtn のデータ型を TEXRTN に変更した.

def_tex によって,定義済みのタスク例外処理ルーチンを再定義しようとした場 合に, E_OBJ エラーとすることにした.


ras_tex タスク例外処理の要求〔 T〕
iras_tex タスク例外処理の要求〔 I〕

【 C言語 API 】

ER ercd = ras_tex(ID tskid, TEXPTN rasptn)

ER ercd = iras_tex(ID tskid, TEXPTN rasptn)

【パラメータ】

ID tskid 対象タスクの ID 番号
TEXPTN rasptn 要求するタスク例外処理のタスク例外要因

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し: ras_tex の場合,タスクコンテキストからの呼出し:iras_tex の場合, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( tskid が不正)
E_NOEXS 〔 D〕 オブジェクト未 登録(対象タスクが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象タスクに対する通常操作 2が許可されていない: ras_tex の場合)
E_PAR パラメータエラー( rasptn が不正)
E_OBJ オブジェクト状態エラー(対象タスクが休止状態,対象タスクに対してタスク例外処理ルーチンが定義されていない)

【機能】

tskid で指定したタスク(対象タスク)に対して, rasptn で指定したタスク例外 要因のタスク例外処理を要求する.対象タスクの保留例外要因が,それまでの 値と rasptn で指定した値のビット毎論理和( C言語の "|" )に更新される.

対象タスクが休止状態である場合と,対象タスクに対してタスク例外処理ルー チンが定義されていない場合には, E_OBJ エラーとなる.

ras_tex において tskid に TSK_SELF (= 0)を指定すると,自タスクが対象タスク となる.

rasptn が 0の場合には, E_PAR エラーとなる.


dis_tex タスク例外処理の禁止〔 T〕

【 C言語 API 】

ER ercd = dis_tex()

【パラメータ】

なし

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_OBJ オブジェクト状態エラー(自タスクに対してタスク例外処理ルーチンが定義されていない)

【機能】

自タスクのタスク例外処理禁止フラグをセットする.すなわち,自タスクをタ スク例外処理禁止状態に遷移させる.


ena_tex タスク 例外処理の許可〔 T〕

【 C言語 API 】

ER ercd = ena_tex()

【パラメータ】

なし

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_OBJ オブジェクト状態エラー(自タスクに対してタスク例外処理ルーチンが定義されていない)

【機能】

自タ スクのタスク例外処理禁止フラグをクリアする.すなわち,自タスクをタ スク例外処理許可状態に遷移させる.

【補足説明】

タスク例外処理ルーチン中で ena_tex を呼び出すことにより,タスク例外処理ルー チンの多重起動を行うことができる.ただし,多重起動の最大段数を制限する のは,アプリケーションの責任である.


sns_tex タスク例外処理禁止状態の参照〔 TI 〕

【 C言語 API 】

bool_t state = sns_tex()

【パラメータ】

なし

【リターンパラメータ】

b ool_t state タスク例外処理禁止状態

【機能】

実行状態のタスクのタスク例外処理禁止フラグを参照する.具体的な振舞いは 以下の通り.

実行状態のタスクが,タスク例外処理禁止状態の場合に true ,タスク例外処理 許可状態の場合に false が返る. sns_tex を非タスクコンテキストから呼び出し た場合で,実行状態のタスクがない場合には, true が返る.

マルチプロセッサ対応カーネルにおいては,サービスコールを呼び出した処理 単位を実行しているプロセッサにおいて実行状態のタスクのタスク例外処理禁 止フラグを参照する.

【補足説明】

sns_tex をタスクコンテキストから呼び出した場合,実行状態のタスクは自タス クに一致する.


ref_tex タスク例外処理の状態参照〔 T〕

【 C言語 API 】

ER ercd = ref_tex(ID tskid, T_RTEX *pk_rtex)

【パラメータ】

ID tskid 対象タスクの ID 番号
T_RTEX * pk_rtex タスク例外処理の現在状態を入れるパケットへのポインタ

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

*タスク例外処理の現在状態(パケットの内容)

STAT texstat タスク例外処理の状態
TEXPTN pndptn タスクの保留例外要因

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック 状態からの呼出し)
E_ID 不正 ID 番号( tskid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象タスクが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象タスクに対する参照操作が許可されていない)
E_MACV 〔 P〕 メモリアクセス違反( pk_rtex が指すメモリ領域へ の書込みアクセスが許可されていない)
E_OBJ オブジェクト状態エラー(対象タスクが休止状態,対象タスクに対してタスク例外処理ルーチンが定義されていない)

【機能】

tskid で指定したタスク(対象タスク)のタスク例外処理に関する現在状態を参 照する.参照した現在状態は, pk_rtex で指定したパケットに返される.

texstat には,対象タスクの現在のタスク例外処理禁止フラグを表す次のいずれ かの値が返される.

TTEX_ENA 0x01U タスク例外処理許可状態
TTEX _DIS 0x02U タスク例外処理禁止状態

pndptn には,対象タスクの現在の保留例外要因が返される.

tskid に TSK_SELF (= 0)を指定すると,自タスクが対象タスクとなる.


4.4 同期・通信機能

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

SSP カーネルでは,同期・通信機能をサポートしない..

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

この仕様では,ランデブ機能はサポートしていない.今後の検討により,ラン デブ機能をサポートすることに変更する可能性もある.

4.4.1 セマフォ

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

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

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

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

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

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

TA_TPRI 0x01U 待ち行列をタスクの優先度順にする

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

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

TMAX_MAXSEM セマフォの最大資源数の最大値(= UINT_MAX )
TNUM_SEMID 登録できるセマフォの数(動的生成対応でないカーネルでは,静的 API によって登録されたセマフォの数に一致)

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

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


CRE_SEM セマフォの生成〔 S〕
acre_sem セマフォの生成〔 TD 〕

【静的 API 】

CRE_SEM(I D semid, { ATR sematr, uint_t isemcnt, uint_t maxsem })

【 C言語 API 】

ER_ID semid = acre_sem(const T_CSEM *pk_csem)

【パラメータ】

ID semid 生成するセマフォの ID 番号( CRE_SEM の場合)
T_C SEM * pk_csem セマフォの生成情報を入れたパケットへのポインタ(静的 API を除く)

*セマフォの生成情報(パケットの内容)

ATR sematr セマフォ属性
uint_t isemcnt セマフォの初期資源数
uint_t maxsem セマフォの最大資源数

【リターンパラメータ】

ER_ID semid 生成されたセマフォの ID 番号(正の値)またはエラーコード

【エラーコード】

E_CTX 〔 s〕 コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_RSATR 予約属性( sematr が不正または使用できない,属する保護ドメインかクラスが不正)
E_PAR パラメータエラー( isemcnt , maxsem が不正)
E_OACV 〔 sP 〕 オブジェクトアクセス違反(システム状態に対する管理操作が許可されていない)
E_MACV 〔 sP 〕 メモリアクセス違反( pk_csem が指すメモリ領域への読出しアクセスが許可されていない)
E_NOID 〔 sD 〕 ID 番号不足(割り付けられるセマフォ ID がない)
E_OBJ オブジェクト状態エラー( semid で指定したセマフォ が登録済み: CRE_SEM の場合)

【機能】

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

静的 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 のみをサポートする.


AID_SEM 割付け可能なセマフォ ID の数の指定〔 SD 〕

【静的 API 】

AID_SEM(uint_t nosem)

【パラメータ】

uint_t nosem 割付け可能なセマフォ ID の数

【エラーコード】

E_RSATR 予約属性(属する保護ドメインまたはクラスが不正)

【機能】

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

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


SAC_SEM セマフォのアクセス許可ベクタの設定〔 SP 〕
sac_sem セマフォのアクセス許可ベクタの設定〔 TPD 〕

【静的 API 】

SAC_SEM(ID semid, { ACPTN acptn1, ACPTN acptn2, ACPTN acptn3, ACPTN acptn4 })

【 C言語 API 】

ER ercd = sac_sem(ID semid, const ACVCT *p_acvct)

【パラメータ】

ID semid 対象セマフォの ID 番号
ACVCT * p_acvct アクセス許可ベクタを入れたパケットへのポインタ(静的 API を除く)

*アクセス許可ベクタ(パケットの内容)

ACPTN acptn1 通常操作 1の アクセス許可パターン
ACPTN acptn2 通常操作 2のアクセス許可パターン
ACPTN acptn3 管理操作のアクセス許可パターン
ACPTN acptn4 参照操作のアクセス許可パターン

【リターンパラメータ】

ER ercd 正常終了( E_OK )ま たはエラーコード

【エラーコード】

E_CTX 〔 s〕 コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( semid が不正)
E_RSATR 予約属性(属する保護ドメインかクラスが不正: SAC_SEMの場合)
E_NOEXS 〔 D〕 オブジェクト未登録(対象セマフォが未登録)
E_OACV 〔 sP 〕 オブジェクトアクセス違反(対象セマフォに対する管理操作が許可されていない)
E_MACV 〔 sP 〕 メモリアクセス違反( p_acvct が指すメモリ領域への読出しアクセスが許可されていない)
E_OBJ オブジェクト状態エラー(対象セマフォは静的 API で生成された: sac_sem の場合,対象セマフォに対してアクセス許可ベクタが設定済み: SAC_SEM の場合)

【機能】

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 のみをサポートする.


del_sem セマフォの削除〔 TD 〕

【 C言語 API 】

ER ercd = del_sem(ID semid)

【パラメータ】

ID semid 対象セマフォの ID 番号

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( semid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象セマフォが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象セマフォに対する管理操作が許可されていない)
E_OBJ オブジェクト状態エラー(対象セマフォは静的 API で生成された)

【機能】

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

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

【使用上の注意】

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

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

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

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

FMP カーネルでは, del_sem をサポートしない.

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

HRP2 カーネルでは, del_sem をサポートしない.


sig_sem セマフ ォの資源の返却〔 T〕
isig_sem セマフォの資源の返却〔 I〕

【 C言語 API 】

ER ercd = sig_sem(ID semid)

ER ercd = isig_sem(ID semid)

【パラメータ】

ID semid 対象セマフォの ID 番号

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し: sig_sem の場合,タスクコンテキストからの呼出し:isig_sem の場合, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( semid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象セマフォが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象セマフォに対する通常操作 1が許可されていない: sig_sem の場合)
E_QOVR キューイングオーバフロー(資源数が最大資源数に一致)

【機能】

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

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

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


wai_sem セマフォの資源の獲得〔 T〕
pol_sem セマフォの資源の獲得(ポーリング)〔 T〕
twai_sem セマフォの資源の獲得(タイムアウト付き)〔 T〕

【 C言語 API 】

ER erc d = wai_sem(ID semid)

ER ercd = pol_sem(ID semid)

ER ercd = twai_sem(ID semid, TMO tmout)

【パラメータ】

ID semid 対象セマフォの ID 番号
TMO tmout タイムアウト時間( twai_sem の場合)

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し,ディスパッチ保留状態からの呼出し: pol_sem を除く)
E_NOSPT 未サポート機能(制約タスクからの呼出し: pol_sem を除く)
E_ID 不正 ID 番号( semid が不正)
E_PAR パラメータエラー( tmout が不正: twai_sem の場合)
E_NOEXS 〔 D〕 オブジェクト未登録(対象セマフォが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象セマフォに対する通常操作 2が許可されていない)
E_TMOUT ポーリング失敗またはタイムアウト( wai_sem を除く)
E_RLWAI 待ち禁止状態または待ち状態の強制解除( pol_sem を除く)
E_DLT 待ちオブジェクトの削除または再初期化( pol_sem を除く)

【機能】

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

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


ini_sem セマフォの再初期化〔 T〕

【 C言語 API 】

ER ercd = ini_sem(ID semid)

【パラメータ】

ID semid 対象セマフォの ID 番号

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( semid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象セマフォが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象セマフォに対する管理操作が許可されていない)

【機能】

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

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

【使用上の注意】

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

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

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

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


ref_sem セマフォの状態参照〔 T〕

【 C言語 API 】

ER ercd = ref_sem(ID semid, T_RSEM *pk_rsem)

【パラメータ】

ID semid 対象セマフォの ID 番号
T_RSEM * pk_rsem セマフォの現在状態を入れるパケットへのポインタ

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

*セマフォの現在状態(パケットの内容)

ID wtskid セマフォの待ち行列の先頭のタスクの ID 番号
uint_t semcnt セマフォの資源数

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( semid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象セマフォが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象セマフォに対する参照操作が許可されていない)
E_MACV 〔 P〕 メモリアクセス違反( pk_rsem が指すメモリ領域への書込みアクセスが許可されて いない)

【機能】

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

対象セマフォの待ち行列にタスクが存在しない場合, wtskid には TSK_NONE (= 0 )が返る.

【使用上の注意】

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


4.4.2 イベントフラグ

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

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

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

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

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

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

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

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

TA_TPRI 0x01U 待ち行列をタスクの優先度順にする
TA_WMUL 0x02U 複数のタスクが待つのを許す
TA_CLR 0x04U タスクの待ち解除時にイベントフラグをクリアする

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

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

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

FLGPTN イベントフラグのビットパターン(符号無し整数, uint_t に定義)

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

TBIT_FLGPTN イベントフラグのビット数( FLGPTN の有効ビット数)
TNUM_FLGID 登録できるイベントフラグの数(動的生成対応でないカーネルでは,静的 API によって登録されたイベントフラグの数に一致)

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

ASP カーネルでは,イベントフラグのビット数( TBIT_FLGPTN )は 16 以上である.

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

FMP カーネルでは,イベントフラグのビット数( TBIT_FLGPTN )は 16 以上である.

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

HRP2 カーネルでは,イベントフラグのビット数( TBIT_FLGPTN )は 16 以上である.

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

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


CRE_FLG イベントフラグの生成〔 S〕
acre_flg イベントフラグの生成〔 TD 〕

【静的 API 】

CRE_FLG(ID flgid, { ATR flgatr, FLGPTN iflgptn })

【 C言語 API 】

ER_ID flgid = acre_flg(const T_CFLG *pk_cflg)

【パラメータ】

ID flgid 生成するイベントフラグの ID 番号( CRE_FLG の場合)
T_CFLG * pk_cflg イベントフラグの生成情報を入れたパケットへのポインタ(静的 API を除く)

*イベントフラグの生成情報(パケットの内容)

ATR flgatr イベントフラグ属性
FLGPTN iflgptn イベントフラグの初期ビットパターン

【リターンパラメータ】

ER_ID flgid 生成されたイベントフラグの ID 番号(正の値)またはエラーコード

【エラーコード】

E_CTX 〔 s〕 コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_RSATR 予約属性( flgatr が不正または使用できない,属する保護ドメインかクラスが不正)
E_OACV 〔 sP 〕 オブジェクトアクセス違反(システム状態に対する管理操作が許可されていない)
E_MACV 〔 sP 〕 メモリアクセス違反( pk_cflg が指すメモリ領域への読出しアクセスが許可されていない)
E_NOID 〔 sD 〕 ID 番号不足(割り付けられるイベントフラグ ID がない)
E_OBJ オブジェクト状態エラー( flgid で指定したイベントフラグが登録済み: CRE_FLG の場合)

【機能】

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

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

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

ASP カーネルでは, CRE_FLG のみをサポートする.ただし,動的生成機能拡張パッ ケージでは, acre_flg もサポートする.

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

FMP カーネルでは, CRE_FLG のみをサポートする.

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

HRP2 カーネルでは, CRE_FLG のみをサポートする.


AID_FLG 割付け可能なイベントフラグ ID の数の指定〔 SD 〕

【静的 API 】

AID_FLG(uint_t noflg)

【パラメータ】

uint_t noflg 割付け可能なイベントフラグ ID の数

【エラーコード】

E_RSATR 予約属性(属する保護ドメインまたはクラスが不正)

【機能】

noflg で指定した数のイベントフラグ ID を,イベントフラグを生成するサービス コールによって割付け可能なイベントフラグ ID として確保する.

noflg は整数定数式パラメータである.


SAC_FLG イベントフラグのアクセス許可ベクタの設定〔 SP 〕
sac_flg イベントフラグのアクセス許可ベクタの設定〔 TPD 〕

【静的 API 】

SAC_FLG(ID flgid , { ACPTN acptn1, ACPTN acptn2, ACPTN acptn3, ACPTN acptn4 })

【 C言語 API 】

ER ercd = sac_flg(ID flgid, const ACVCT *p_acvct)

【パラメータ】

ID flgid 対象イベントフラグの ID 番号
ACVCT * p_acvct アクセス許可ベクタを入れたパケットへのポインタ(静的 API を除く)

*アクセス許可ベクタ(パケットの内容)

ACPTN acptn1 通常操作 1のアクセス許可 パターン
ACPTN acptn2 通常操作 2のアクセス許可パターン
ACPTN acptn3 管理操作のアクセス許可パターン
ACPTN acptn4 参照操作のアクセス許可パターン

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコ ード

【エラーコード】

E_CTX 〔 s〕 コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( flgid が不正)
E_RSATR 予約属性(属する保護ドメインかクラスが不正: SAC_FLGの場合)
E_NOEXS 〔 D〕 オブジェクト未登録(対象イベントフラグが未登録)
E_OACV 〔 sP 〕 オブジェクトアクセス違反(対象イベントフラグに対する管理操作が許可されていない)
E_MACV 〔 sP 〕 メモリアクセス違反( p_acvct が指すメモリ領域への読出しアクセスが許可されていない)
E_OBJ オブジェクト状態エラー(対象イベントフラグは静的 APIで生成された: sac_flg の場合,対象イベントフラグに対してアクセス許可ベクタが設定済み: SAC_FLG の場合)

【機能】

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 のみをサポートする.


del_flg イベントフラグの削除〔 TD 〕

【 C言語 API 】

ER ercd = del_flg(ID flgid)

【パラメータ】

ID flgid 対象イベントフラグの ID 番号

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( flgid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象イベントフラグが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象イベントフラグに対する管理操作が許可されていない)
E_OBJ オブジェクト状態エラー(対象イベントフラグは静的 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 をサポートしない.


set_flg イベントフラグのセット〔 T〕
iset_flg イベントフラグのセット〔 I〕

【 C言語 API 】

ER ercd = set_flg(ID flgid, FLGPTN setptn)

ER ercd = iset_flg(ID flgid, FLGPTN setptn)

【パラメータ】

ID flgid 対象イベントフラグの ID 番号
FLGPTN setptn セットするビットパターン

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し: set_flg の場合,タスクコンテキストからの呼出し:iset_flg の場合, CPU ロック状態から の呼出し)
E_ID 不正 ID 番号( flgid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象イベントフラグが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象イベントフラグに対する通常操作 1が許可されていない: set_flg の場合)

【機能】

flgid で指定したイベントフラグ(対象イベントフラグ)の setptn で指定したビッ トをセットする.具体的な振舞いは以下の通り.

対象イベントフラグのビットパターンは,それまでの値と setptn で指定した値 のビット毎論理和( C言語の "|" )に更新される.対象イベントフラグの待ち行 列にタスクが存在する場合には,待ち解除の条件を満たしたタスクが,待ち行 列の前方につな がれたものから順に待ち解除される.待ち解除されたタスクに は,待ち状態となったサービスコールから E_OK が返る.

ただし,対象イベントフラグが TA_CLR 属性である場合には,待ち解除の条件を 満たしたタスクを 1つ待ち解除した時点で,対象イベントフラグのビットパター ンが 0にクリアされるため,他のタスクが待ち解除されることはない.

【使用上の注意】

対象イベントフラグが, TA_WMUL 属性であり, TA_CLR 属性でない場合, set_flg または iset_flg により複数のタスクが待ち解除される場合がある.この場合, サービスコールの処理時間およびカーネル内での割込み禁止時間が,待ち解除 されるタスクの数に比例して長くなる.特に,多くのタスクが待ち解除される 場合,カーネル内での割込み禁止時間が長くなるため,注意が必要である.


clr_flg イベントフラグのクリア〔 T〕

【 C言語 API 】

ER ercd = clr_flg(ID flgid, FLGPTN clrptn)

【パラメータ】

ID flgid 対象イベントフラグの ID 番号
FLGPTN clrptn クリアするビットパターン(クリアしないビットを 1,クリアするビットを 0とする)

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( flgid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象イベントフラグが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反( 対象イベントフラグに対する通常操作 1が許可されていない: clr_flg の場合)

【機能】

flgid で指定したイベントフラグ(対象イベントフラグ)の clrptn で指定したビッ トをクリアする.対象イベントフラグのビットパターンは,それまでの値と clrptn で指定した値のビット毎論理積( C言語の "&" )に更新される.


wai_flg イベントフラグ待ち〔 T〕
pol_flg イベントフラグ待ち(ポーリング)〔 T〕
twai_flg イベントフラグ待ち(タイムアウト付き)〔 T〕

【 C言語 API 】

ER ercd = wai_flg(ID flgid, FLGPTN waiptn, MODE wfmode, FLGPTN *p_flgptn)

ER ercd = pol_flg(ID flgid, FLGPTN waiptn, MODE wfmode, FLGPTN *p_flgptn)

ER ercd = twai_flg(ID flgid, FLGPTN waiptn, MODE wfmode, FLGPTN *p_flgptn, TMO tmout)

【パラメータ】

ID flgid 対象イベントフラグの ID 番号
FLGPTN waiptn 待ちビットパターン
MODE wfmode 待ちモード
FLGPTN * p_flgptn 待 ち解除時のビットパターンを入れるメモリ領域へのポインタ
TMO tmout タイムアウト時間( twai_flg の場合)

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード
FLGPTN flgptn 待ち解除時のビットパターン

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し,ディスパッチ保留状態からの呼出し: pol_flg を除く)
E_NOSPT 未サポート機能(制約タスクからの呼出し: pol_flg を除く)
E_ID 不正 ID 番号( flgid が不正)
E_PAR パラメータエラー( waiptn , wfmode が不正, tmout が不正:twai_flg の場合)
E_NOEXS 〔 D〕 オブジェクト未登録(対象イベントフラグが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象イベントフラグに対する通常操作 2が許可されていない)
E_MACV 〔 P〕 メモリアクセス違反( p_flgptn が指すメモリ領域への書込みアクセスが許可されていない)
E_ILUSE サービスコール不正使用( TA_WMUL 属性でないイベントフラグで待ちタスクあり)
E_TMOUT ポーリング失敗またはタイムアウト( wai_flg を除く)
E_RLWAI 待ち禁止状態または待ち状態の強制解除( pol_flg を除く)
E_DLT 待ちオブジェクト の削除または再初期化( pol_flg を除く)

【機能】

flgid で指定したイベントフラグ(対象イベントフラグ)が, waiptn と wfmode で 指定した待ち解除の条件を満たすのを待つ.具体的な振舞いは以下の通り.

対象イベントフラグが, waiptn と wfmode で指定した待ち解除の条件を満たして いる場合には,対象イベントフラグのビットパター ンの現在値が flgptn に返さ れる.対象イベントフラグが TA_CLR 属性である場合には,対象イベントフラグ のビットパターンが 0にクリアされる.

待ち解除の条件を満たしていない場合には,自タスクはイベントフラグ待ち状 態となり,対象イベントフラグの待ち行列につながれる.


ini_flg イベントフラグの再初期化〔 T〕

【 C言語 API 】

ER ercd = ini_flg(ID flgid)

【パラメータ】

ID flgid 対象イベントフラグの ID 番号

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( flgid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象イベントフラグが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象イベントフラグに対する管理操作が許可されていない)

【機能】

flgid で指定したイベントフラグ(対象イベントフラグ)を再初期化する.具体 的な振舞いは以下の通り.

対象イベントフラグのビットパターンは,初期ビットパターンに初期化される. また,対象イベントフラグの待ち行列につながれたタスクは,待ち行列の先頭 のタスクから順に待ち解除される.待ち解除されたタスクには,待ち状態となっ たサービスコールから E_DLT エラーが返る.

【使用上の注意】

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

イベントフラグを再初期化した場合に,ア プリケーションとの整合性を保つの は,アプリケーションの責任である.

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

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


ref_flg イベントフラグの状態参照〔 T〕

【 C言語 API 】

ER ercd = ref_flg(ID flgid, T_RFLG *pk_rflg)

【パラメータ】

ID flgid 対象イベントフラグの ID 番号
T_RFLG * pk_rflg イベントフラグの現在状態を入れるパケットへのポインタ

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

*イベントフラグの現在状態(パケットの内容)

ID wtskid イベントフラグの待ち行列の先頭のタスクの ID番号
uint_t flgptn イベントフラグのビットパターン

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( flgid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象イベントフラグが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象イベントフラグに対する参照操作が許可されていない)
E_MACV 〔 P〕 メモリアクセス違反( pk_rflg が指すメモリ領域への書込みアクセスが許可されていない)

【機能】

flgid で指定したイベントフラグ(対象イベントフラグ)の現在状態を参照する. 参照した現在状態は, pk_rflg で指定したパケットに返される.

対象イベントフラグの待ち行列にタスクが存在しない場合, wtskid には TSK_NONE (= 0)が返る.

【使用上の注意】

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


4.4.3 データキュー

データキューは, 1ワードのデータをメッセージとして, FIFO 順で送受信するた めの同期・通信オブジェクトである.より大きいサイズのメッセージを送受信 したい場合には,メッセージを置いたメモリ領域へのポ インタを 1ワードのデー タとして送受信する方法がある.データキューは,データキュー ID と呼ぶ ID 番 号によって識別する.

各データキューが持つ情報は次の通り.

  • ・データキュー属性
  • ・データキュー管理領域
  • ・送信待ち行列(データキューへの送信待ち状態のタスクのキュー)
  • ・受信待ち行列(データキューからの受信待ち状態のタス クのキュー)
  • ・アクセス許可ベクタ(保護機能対応カーネルの場合)
  • ・属する保護ドメイン(保護機能対応カーネルの場合)
  • ・属するクラス(マルチプロセッサ対応カーネルの場合)

データキュー管理領域は,データキューに送信されたデータを,送信された順 に格納しておくためのメモリ領域である.データキュー生成時に,データキュー 管理領域に格納できるデータ数を 0とすることで, データキュー管理領域のサイ ズを 0とすることができる.

保護機能対応カーネルにおいて,データキュー管理領域は,カーネルの用いる オブジェクト管理領域として扱われる.

送信待ち行列は,データキューに対してデータが送信できるまで待っている状 態(データキューへの送信待ち状態)のタスクが,データを送信できる順序で つながれているキューである.また,受信待ち行列は,データキューからデー タが受信できるまで待っている状態(データキューからの受信待ち状態)のタ スクが,データを受信できる順序でつながれているキューである.

データキュー属性には,次の属性を指定することができる.

TA_TPRI 0x01U 送信待ち行列をタスクの優先度順にする

TA_TPRI を指定しない場合,送信待ち行列は FIFO 順になる.受信待ち行列は, FIFO 順に固定されている.

データキュー機能に関連するカーネル構成マクロは次の通り.

TNUM_DTQID 登録できるデータキューの数(動的生成対応でないカーネルでは,静的 API によって登録されたデータキューの数に一致)

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

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


CRE_DTQ データキューの生成〔 S〕
acre_dtq データキューの生成〔 TD 〕

【静的 API 】

CRE_DTQ(ID dtqid, { ATR dtqatr, uint_t dtqcnt, void *dtqmb })

【 C言語 API 】

ER_ID dtqid = acre_dtq(const T_CDTQ *pk_cdtq)

【パラメータ】

ID dtqid 生成するデータキューの ID 番号( CRE_DTQ の場合)
T_CDTQ * pk_cdtq データキューの生成情報を入れたパケットへのポインタ(静的 API を除く)

*データキューの生成情報(パケットの内容)

A TR dtqatr データキュー属性
uint_t dtqcnt データキュー管理領域に格納できるデータ数
void * dtqmb データキュー管理領域の先頭番地

【リターンパラメータ】

ER_ID dtqid 生成されたデータキューの ID 番号(正の値)またはエラーコード

【エラーコード】

E_CTX 〔 s〕 コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_RSATR 予約属性( dtqatr が不正または使用できない,属する保護ドメイン かクラスが不正)
E_NOSPT 未サポート機能( dtqmb がサポートされていない値)
E_PAR パラメータエラー( dtqmb が不正)
E_OACV 〔 sP 〕 オブジェクトアクセス違反(システム状態に対する管理操作が許可されていない)
E_MACV 〔 sP 〕 メモリアクセス違反( pk_cdt qが指すメモリ領域への読出しアクセスが許可されていない)
E_NOID 〔 sD 〕 ID 番号不足(割り付けられるデータキュー ID がない)
E_NOMEM メモリ不足(データキュー管理領域が確保できない)
E_OBJ オブジェクト状態エラー( dtqid で指定したデータキューが登録済み: CRE_DTQ の場合,その他の条件については機能の項を参照すること)

【機能】

各パラメータで指定したデータキュー生成情報に従って,データキューを生成 する. dtqcnt と dtqmb からデータキュー管理領域が設定され,格納されているデー タがない状態に初 期化される.また,送信待ち行列と受信待ち行列は,空の状 態に初期化される.

静的 API においては, dtqid はオブジェクト識別名, dtqcnt は整数定数式パラメー タ, dtqmb は一般定数式パラメータである.コンフィギュレータは,静的 API の メモリ不足( E_NOMEM )エラーを検出することができない.

dtqmb を NULL とした場合, dtqcnt で指定した数のデー タを格納できるデータキュー 管理領域を,コンフィギュレータまたはカーネルが確保する.

〔 dtqmb に NULL 以外を指定した場合〕

dtqmb に NULL 以外を指定した場合, dtqmb を先頭番地とするデータキュー管理領 域は,アプリケーションで確保しておく必要がある.データキュー管理領域を アプリケーションで確保するために,次のマクロを用意している.

TSZ_DTQMB(dtqcnt) dtqcnt で指定した数のデータを格納できるデータキュー管理領域のサイズ(バイト数)
TCNT_DTQMB(dtqcnt) dtqcnt で指定した数のデータを格納できるデータキュー管理領域を確保するために必要な MB_T 型の配列の要素数

これらを用いてデータキュー管理領域を確保する方法は次の通り.

MB_T < データキュー管理領域の変数名 >[TCNT_DTQMB(dtqcnt)];

この時, 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 を新設し,データキュー管理領域をアプリケーションで確 保する方 法を規定した.


AID_DTQ 割付け可能なデータキュー ID の数の指定〔 SD 〕

【静的 API 】

AID_DTQ(uint_t nodtq)

【パラメータ】

uint_t nodtq 割付け可能なデータキュー ID の数

【エラーコード】

E_RSATR 予約属性(属する保護ドメインまたはクラスが不正)

【機能】

nodtq で指定した数のデータキュー ID を,データキューを生成するサービスコー ルによって割付け可能なデータキュー ID として確保する.

nodtq は整数定数式パラメータである.


SAC_DTQ データキューのアクセス許可ベクタの設定〔 SP 〕
sac_dtq データキューのアクセス許可ベクタの設定〔 TPD 〕

【静的 API 】

SAC_DTQ(ID dtqid, { ACPTN acptn1, ACPTN acptn2, ACPTN acptn3, ACPTN acptn4 })

【 C言語 API 】

ER ercd = sac_dtq(ID dtqid, const ACVCT *p_acvct)

【パラメータ】

ID dtqid 対象データキューの ID 番号
ACVCT * p_acvct アクセス許可ベクタを入れたパケットへのポインタ(静的 API を除く)

*アクセス許可ベクタ(パケットの内容)

ACPTN acptn1 通常操作 1のアクセス許可パターン
ACPTN acptn2 通常操作 2のアクセス許可パターン
ACPTN acptn3 管理操作のアクセス許可パターン
ACPTN acptn4 参照操作のアクセス許可パターン

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX 〔 s〕 コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( dtqid が不正)
E_RSATR 予約属性(属する保護ドメインかクラスが不正: SAC_DTQの場合)
E_NOEXS 〔 D〕 オブジェクト未登録(対象データキューが未登録)
E_OACV 〔 sP 〕 オブジェクトアクセス違反(対象データキューに対する管理操作が許可されていない)
E_MACV 〔 sP 〕 メモリアクセス違反( p_acvct が指すメモリ領域への読出しアクセスが許可されていない)
E_OBJ オブジェクト状態エラー(対象データキューは静的 API で生成された: sac_dtq の場合,対象データキューに対してアクセス許可ベクタが設定済み: SAC_DTQ の場合)

【機能】

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 のみをサポートする.


del_dtq データキューの削除〔 TD 〕

【 C言語 API 】

ER ercd = del_dtq(ID dtqid)

【パラメータ】

ID dtqid 対象データキューの ID 番号

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( dtqid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象データキューが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象データキューに対する管理操作が許可されていない)
E_OBJ オブジェクト状態エラー(対象データキューは静的 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 をサポートしない.


snd_dtq データキューへの送信〔 T〕
psnd_dtq データキューへの送信(ポーリング)〔 T〕
ipsnd_dtq データキューへの送信(ポーリング)〔 I〕
tsnd_dtq データキューへの送信(タイムアウト付き)〔 T〕

【 C言語 API 】

ER ercd = snd_dtq(ID dtqid, intptr_t data)

ER ercd = psnd_dtq(ID dtqid, intptr_t data)

ER ercd = ipsnd_dtq(ID dtqid, intptr_t data)

ER ercd = tsnd_dtq(ID dtqid, intptr_t data, T MO tmout)

【パラメータ】

ID dtqid 対象データキューの ID 番号
intptr_t data 送信データ
TMO tmout タイムアウト時間( tsnd_dtq の場合)

【リターンパラメータ】

ER er cd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し: ipsnd_dtq を除く,タスクコンテキストからの呼出し:ipsnd_dtq の場合, CPU ロック状態からの呼出し,ディスパッチ保留状態からの呼出し: snd_dtq と tsnd_dtq の場合)
E_NOSPT 未サポート機能(制約タスクからの呼出し: snd_dtq とtsnd_dtq の場合)
E_ID 不正 ID 番号( dtqid が不正)
E_PAR パラメータエラー( tmo ut が不正: tsnd_dtq の場合)
E_NOEXS 〔 D〕 オブジェクト未登録(対象データキューが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象データキューに対する通常操作 1が許可されていない: ipsnd_dtq を除く)
E_TMOUT ポーリング失敗またはタイムアウト( snd_dtq を除く)
E_RLWAI 待ち禁止状態または待ち状態の強制解除( snd_dtq とtsnd_dtq の場合)
E_DLT 待ちオブジェクトの削除または再初期化( snd_dtq とtsnd_dtq の場合)

【機能】

dtqid で指定したデータキュー(対象デ ータキュー)に, data で指定したデータ を送信する.具体的な振舞いは以下の通り.

対象データキューの受信待ち行列にタスクが存在する場合には,受信待ち行列 の先頭のタスクが, data で指定したデータを受信し,待ち解除される.待ち解 除されたタスクには,待ち状態となったサービスコールから E_OK が返る.

対象データキューの受信待ち行列にタスクが存在せず,データキュー管 理領域 にデータを格納するスペースがある場合には, data で指定したデータが, FIFO 順でデータキュー管理領域に格納される.

対象データキューの受信待ち行列にタスクが存在せず,データキュー管理領域 にデータを格納するスペースがない場合には,自タスクはデータキューへの送 信待ち状態となり,対象データキューの送信待ち行列につながれる.


fsnd_dtq データキューへの強制送信〔 T〕
ifsnd_dtq データキューへの強制送信〔 I〕

【 C言語 API 】

ER ercd = fsnd_dtq(ID dtqid, intptr_t data)

ER ercd = ifsnd_dtq(ID dtqid, intptr_t data)

【パラメータ】

ID dtqid 対象データキューの ID 番号
intptr_t data 送信データ

【リターンパラメータ】

ER ercd 正常終了( E_OK )また はエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し: fsnd_dtq の場合,タスクコンテキストからの呼出し:ifsnd_dtq の場合, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( dtqid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象データキューが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象データキューに対する通常操作 1が許可されていない: fsnd_dtq の場合)
E_ILUSE サービスコール不正使用(対象データキューのデータキュー管理領域のサイズが 0)

【機能】

dtqid で指定したデータキュー(対象データキュー)に, data で指定したデータ を強制送信する.具体的な振舞いは以下の通り.

対象データキューの受信待ち行列にタスクが存在する場合には,受信待ち行列 の先頭のタスクが, data で指定したデータを受信し,待ち解除される.待ち解 除されたタスクには,待ち状態となったサービスコールから E_OK が返る.

対象データキューの受信待ち行列にタスクが存在せず,データキュー管理領域 にデータを格納するスペースがある場合には, data で指定したデータが, FIFO 順でデータキュー管理領域に格納される.

対象データキューの受信待ち行列にタスクが存在せず,データキュー管理領域 にデータを格 納するスペースがない場合には,データキュー管理領域の先頭に 格納されたデータを削除し,空いたスペースを用いて, data で指定したデータ が, FIFO 順でデータキュー管理領域に格納される.

対象データキューのデータキュー管理領域のサイズが 0の場合には, E_ILUSE エ ラーとなる.


rcv_dtq データキューからの受信〔 T〕
prcv_dtq データキューからの受信(ポーリング)〔 T〕
trcv_dtq データキューからの受信(タイムアウト付き)〔 T〕

【 C言語 API 】

ER ercd = rcv_dtq(ID dtqid, intptr_t *p_data)

ER ercd = prcv_dtq(ID dtqid, intptr_t *p_data)

ER ercd = trcv_dtq(ID dtqid, intptr_t *p_data, TMO tmout)

【パラメータ】

ID dtqid 対象データキューの ID 番号
intptr_t * p_data 受信データを入れるメモリ領域へのポインタ
TMO tmout タイムアウト時間( trcv_dtq の場合)

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード
intptr_t data 受信データ

【エラーコード】

E_CTX コ ンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し,ディスパッチ保留状態からの呼出し: prcv_dtq を除く)
E_NOSPT 未サポート機能(制約タスクからの呼出し: prcv_dtq を除く)
E_ID 不正 ID 番号( dtqid が不正)
E_PAR パラメータエラー( tmout が不正: trcv_dtq の場合)
E_NOEXS 〔 D〕 オブジェクト未登録(対象データキューが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象データキューに対する通常操作 2が許可されていない)
E_MACV 〔 P〕 メモリアクセス違反( p_data が指すメモリ領域への書込みアクセスが許可されていない)
E_TMOUT ポーリング失敗またはタイムアウト( rcv_dtq を除く)
E_RLWAI 待ち禁止状態または待ち状態の強制解除( prcv_dtq を除く)
E_DLT 待ちオブジェクトの削除または再初期化( prcv_dtq を除く)

【機能】

dtqid で指定したデータキュー(対象データキュー)からデータを受信する.受 信したデータは, p_data で指定したメモリ領域に返される.具体的な振舞いは 以下の通り.

対象データキューのデータキュー管理領域にデータが格納されている場合には, データキュー管理領域の先頭に格納されたデータが取り出され, p_data で指定 したメモリ領域に返される.また,送信待ち行列にタスクが存在する場合には, 送信待ち行列の先頭のタスクの送信データが, FIFO 順でデータキュー管理領域 に格納され,そのタスクは待ち解除される.待ち解除されたタスクには,待ち 状態となったサービスコールから E_OK が返る.

対象データキューのデー タキュー管理領域にデータが格納されておらず,送信 待ち行列にタスクが存在する場合には,送信待ち行列の先頭のタスクの送信デー タが, p_data で指定したメモリ領域に返される.送信待ち行列の先頭のタスク は,待ち解除される.待ち解除されたタスクには,待ち状態となったサービス コールから E_OK が返る.

対象データキューのデータキュー管理領域にデータが格納されておらず,送信 待ち行列にタスクが存在しない場合には,自タスクはデータキューからの受信 待ち状態となり,対象データキューの受信待ち行列につながれる.


ini_dtq データキューの再初期化〔 T〕

【 C言語 API 】

ER ercd = ini_d tq(ID dtqid)

【パラメータ】

ID dtqid 対象データキューの ID 番号

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( dtqid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象データキューが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象データキューに対する管理操作が許可されていない)

【機能】

dtqid で指定したデータキュー(対象データキュー)を再初期化する.具体的な 振舞いは以下の通り.

対象データキューのデータキュー管理領域は,格納されているデータがない状 態に初期化される.また,対象データキューの送信待ち行列と受信待ち行列に つながれたタスクは,それぞれの待ち行列の先頭のタスクから順に待ち解除さ れる.待ち解除されたタスクには,待ち状態となったサービスコールから E_DLT エラーが返る.

【補足説明】

送信待ち行列と受信待ち行列の両方にタスクがつながれていることはないため, 別の待ち行列で待っていたタスクの間の待ち解除の順序は,規定する必要がな い.

【使用上の注意】

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

データキューを再初期化した場合に,アプリケーションとの整合性を保つのは, アプリケーションの責任である.

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

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


ref_dtq データキューの状態参照〔 T〕

【 C言語 API 】

ER ercd = ref_dtq(ID dtqid, T_RDTQ *pk_rdtq)

【パラメータ】

ID dtqid 対象データキューの ID 番号
T_RDTQ * pk_rdtq データキューの現在状態を入れるパケットへのポインタ

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

*データキューの現在状態(パケットの内容)

ID stskid データキューの送信待ち行列の先頭のタスクのID 番号
ID rtskid データキューの受信待ち行列の先頭のタスクのID 番号
uint_t sdtqcnt データキュー管理領域に格納されているデータの数

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( dtqid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象データキューが未登録)
E_OACV 〔 P〕 オブジェクト アクセス違反(対象データキューに対する参照操作が許可されていない)
E_MACV 〔 P〕 メモリアクセス違反( pk_rdtq が指すメモリ領域への書込みアクセスが許可されていない)

【機能】

dtqid で指定したデータキュー(対象データキュー)の現在状態を参照する.参 照した現在状態は, pk_rdtq で指定したパケットに返される.

対象データキューの送信待ち行列にタスクが存在しない場合, stskid には TSK_NONE (= 0)が返る.また,受信待ち行列にタスクが存在しない場合, rtskid には TSK_NONE (= 0)が返る.

【使用上の注意】

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


4.4.4 優先度データキュー

優先度データキューは, 1ワードのデータをメッセージとして,データの優先度 順で送受信するための同期・通信カーネルオブジェクトである.より大きいサ イズのメッセージを送受信したい場合には,メッセージを置いたメモリ領域へ のポインタを 1ワードのデータとして送受信する方法がある.優先度データキュー は,優先度データキュー ID と呼ぶ ID 番号によ って識別する.

各優先度データキューが持つ情報は次の通り.

  • ・優先度データキュー属性
  • ・優先度データキュー管理領域
  • ・送信待ち行列(優先度データキューへの送信待ち状態のタスクのキュー)
  • ・受信待ち行列(優先度データキューからの受信待ち状態のタスクのキュー)
  • ・送信できるデータ優先度の最大値
  • ・アクセス許可ベクタ(保 護機能対応カーネルの場合)
  • ・属する保護ドメイン(保護機能対応カーネルの場合)
  • ・属するクラス(マルチプロセッサ対応カーネルの場合)

優先度データキュー管理領域は,優先度データキューに送信されたデータを, データの優先度順に格納しておくためのメモリ領域である.優先度データキュー 生成時に,優先度データキュー管理領域に格納できるデータ数を 0とすることで, 優先度デー タキュー管理領域のサイズを 0とすることができる.

保護機能対応カーネルにおいて,優先度データキュー管理領域は,カーネルの 用いるオブジェクト管理領域として扱われる.

送信待ち行列は,優先度データキューに対してデータが送信できるまで待って いる状態(優先度データキューへの送信待ち状態)のタスクが,データを送信 できる順序でつながれているキューである.また,受信待ち行列は,優先度デー タキューからデータが受信できるまで待っている状態(優先度データキューか らの受信待ち状態)のタスクが,データを受信できる順序でつながれている キューである.

優先度データキュー属性には,次の属性を指定することができる.

TA_TPRI 0x01U 送信待 ち行列をタスクの優先度順にする

TA_TPRI を指定しない場合,送信待ち行列は FIFO 順になる.受信待ち行列は, FIFO 順に固定されている.

優先度データキュー機能に関連するカーネル構成マクロは次の通り.

TMIN_DPRI データ優先度の最小値(= 1)
TMAX_DPRI データ優先度の最大値
TNUM_PDQID 登録できる優先度データキューの数(動的生成対応でないカーネルでは,静的 API によって登録された優先度データキューの数に一致)

【 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 仕様に規定されていない機能である.


CRE_PDQ 優先度データキューの生成〔 S〕
acre_pdq 優先度データキューの生成〔 TD 〕

【静的 API 】

CRE_PDQ(ID pdqid, { A TR pdqatr, uint_t pdqcnt, PRI maxdpri, void *pdqmb })

【 C言語 API 】

ER_ID pdqid = acre_pdq(const T_CPDQ *pk_cpdq)

【パラメータ】

ID pdqid 生成する優先度データキューの ID 番号( CRE_PDQの場合)
T_CPDQ * pk_cpdq 優先度データキューの生成情報を入れたパケットへのポインタ(静的 API を除く)

*優先度データキューの生成情報(パケットの内容)

ATR pdqatr 優先度データキュー属性
uint_t pdqcnt 優先度データキュー管理領域に格納できるデータ数
PRI maxdpri 優先度データキューに送信できるデータ優先度の最大値
void * pdqmb 優先度データキュー管理領域の 先頭番地

【リターンパラメータ】

ER_ID pdqid 生成された優先度データキューの ID 番号(正の値)またはエラーコード

【エラーコード】

E_CTX 〔 s〕 コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_RSATR 予約属性( pdqatr が不正または使用できない,属する保護ドメインかクラスが不正)
E_NOSPT 未サポート機能( pdqmb がサポートされていない値)
E_PAR パラメータエラー( pdqmb , maxdpri が不正)
E_OACV 〔 sP 〕 オブジェクトアクセス違反(システム状態に対する管理操作が許可されていない)
E_MACV 〔 sP 〕 メモリアクセス違反( pk_cpdq が指すメモリ領域への読出しアクセスが許可されていない)
E_NOID 〔 sD 〕 ID 番号不足(割り付けられる優先度データキュー ID がない)
E_NOMEM メモリ不足(優先度データキュー管理領域が確保できない)
E_OBJ オブジェクト状態エラー( pdqid で指定した優先度データキューが登録済み: CRE_PDQ の場合,その他の条件については機能の項を参照すること)

【機能】

各パラメータで指定した優先度データキュー生成情報に従って,優先度データ キューを生成する. pdqcnt と pdqmb から優先度データキュー管理領域が設定され, 格納されているデータがない状態に初期化される.また,送信待ち行列と受信 待ち行列は,空の状態に初期化される.

静的 API においては, pdqid はオブジェクト識別名, pdqcnt と maxdpri は整数定数 式パラメータ, pdqmb は一般定数式パラメータである.コンフィギュレータは, 静的 API のメモリ不足( E_NOMEM )エラーを検出することができない.

pdqmb を NULL とした場合, pdqcnt で指定した数のデータを格納できる優先度デー タキュー管理領域を,コンフィギュレータまたはカーネルが確保する.

maxdpri は, TMIN_DPRI 以上, TMAX_DPRI 以 下でなければならない.

〔 pdqmb に NULL 以外を指定した場合〕

pdqmb に NULL 以外を指定した場合, pdqmb を先頭番地とする優先度データキュー 管理領域は,アプリケーションで確保しておく必要がある.優先度データキュー 管理領域をアプリケーションで確保するために,次のマクロを用意している.

TSZ_PDQMB(pdqcnt) pdqcnt で指定した数のデータを格納できる優先度データキュー管理領域のサイズ(バイト数)
TCNT_PDQMB(pdqcnt) pdqcnt で指定した数のデータを格納できる優先度データキュー管理領域を確保するために必要な MB_T 型の配列の要素数

これらを用いて優先度データキュー管理領域を確保する方法は次の通り.

MB_T < 優先度データキュー管理領域の変数名 >[TCNT_PDQMB(pdqcnt)];

この時, 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 エラーとなる.


AID_PDQ 割付け可能な優先度データキュー ID の数の指定〔 SD 〕

【静的 API 】

AID_PDQ(uint_t nopdq)

【パラメータ】

uint_t nopdq 割付け可能な優先度データキュー ID の数

【エラーコード】

E_RSATR 予約属性(属する保護ドメインまたはクラスが不正)

【機能】

nopdq で指定した数の優先度データキュー ID を,優先度データキューを生成する サービスコールによって割付け可能な優先度データキュー ID として確保する.

nopdq は整数定数式パラメータである.


SAC_PDQ 優先度データキューのアクセス許可ベクタの設定〔 SP 〕
sac_pdq 優先度データキューのアクセス許可ベクタの設定〔 TPD 〕

【静的 API 】

SA C_PDQ(ID pdqid, { ACPTN acptn1, ACPTN acptn2, ACPTN acptn3, ACPTN acptn4 })

【 C言語 API 】

ER ercd = sac_pdq(ID pdqid, const ACVCT *p_acvct)

【パラメータ】

ID pdqid 対象優先度データキューの ID 番号
ACVCT * p_acvct アクセス許可ベクタを入れたパケットへのポインタ(静的 API を除く)

*アクセス許可ベクタ(パケットの内容)

ACPTN acptn1 通常操作 1のアクセス 許可パターン
ACPTN acptn2 通常操作 2のアクセス許可パターン
ACPTN acptn3 管理操作のアクセス許可パターン
ACPTN acptn4 参照操作のアクセス許可パターン

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラ ーコード

【エラーコード】

E_CTX 〔 s〕 コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( pdqid が不正)
E_RSATR 予約属性(属する保護ドメインかクラスが不正: SAC_PDQの場合)
E_NOEXS 〔 D〕 オブジェクト未登録(対象優先度データキューが未登録)
E_OACV 〔 sP 〕 オブジェクトアクセス違反(対象優先度データキューに対する管理操作が許可されていない)
E_MACV 〔 sP 〕 メモリアクセス違反( p_acvct が指すメモリ領域への読出しアクセスが許可されていない)
E_OBJ オブジェクト状態エラー(対象優先度データキューは静的API で生成された: sac_pdq の場合,対象優先度データキューに対してアクセス許可ベクタが設定済み: SAC_PDQ の場合)

【機能】

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 のみをサポートする.


del_pdq 優先度データキューの削除〔 TD 〕

【 C言語 API 】

ER ercd = del_pdq(ID pdqid)

【パラメータ】

ID pdqid 対象優先度データキューの ID 番号

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( pdqid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象優先度データキューが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象優先度データキ ューに対する管理操作が許可されていない)
E_OBJ オブジェクト状態エラー(対象優先度データキューは静的API で生成された)

【機能】

pdqid で指定した優先度データキュー(対象優先度データキュー)を削除する. 具体的な振舞いは以下 の通り.

対象優先度データキューの登録が解除され,その優先度データキュー ID が未使 用の状態に戻される.また,対象優先度データキューの送信待ち行列と受信待 ち行列につながれたタスクは,それぞれの待ち行列の先頭のタスクから順に待 ち解除される.待ち解除されたタスクには,待ち状態となったサービスコール から E_DLT エラーが返る.

優先度データキューの生成時に,優先度データキュー管理領域がカーネルによっ て確保された場合は,そのメモリ領域が解放される.

【補足説明】

送信待ち行列と受信待ち行列の両方にタスクがつながれていることはないため, 別の待ち行列で待っていたタスクの間の待ち解除の順序は,規定する必要がな い.

【使用上の注意】

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

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

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

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

FMP カーネルでは, del_pdq をサポートしない.

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

HRP2 カーネルでは, del_pdq をサポートしない.


snd_pdq 優先度データキューへの送信〔 T〕
psnd_pdq 優先度データキューへの送信(ポーリング)〔 T〕
ipsnd_pdq 優先度データキューへの送信(ポーリング)〔 I〕
tsnd_pdq 優先度データキューへの送信(タイムアウト付き)〔 T〕

【 C言語 API 】

ER ercd = snd_pdq(ID pdqid, intptr_t data, PRI datapri)

ER ercd = psnd_pdq(ID pdqid, intptr_t data, PRI datapri)

ER ercd = ipsnd_pdq(ID pdqid , intptr_t data, PRI datapri)

ER ercd = tsnd_pdq(ID pdqid, intptr_t data, PRI datapri, TMO tmout)

【パラメータ】

ID pdqid 対象優先度データキューの ID 番号
intptr_t data 送信データ
PR I datapri 送信データの優先度
TMO tmout タイムアウト時間( tsnd_pdq の場合)

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タス クコンテキストからの呼出し: ipsnd_pdq を除く,タスクコンテキストからの呼出し:ipsnd_pdq の場合, CPU ロック状態からの呼出し,ディスパッチ保留状態からの呼出し: snd_pdq と tsnd_pdq の場合)
E_NOSPT 未サポート機能(制約タスクからの呼出し: snd_ pdq とtsnd_pdq の場合)
E_ID 不正 ID 番号( pdqid が不正)
E_PAR パラメータエラー( datapri が不正, tmout が不正:tsnd_pdq のみ)
E_NOEXS 〔 D〕 オブジェクト未登録(対象優先度データキューが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象優先度データキューに対する通常操作 1が許可されていない: ipsnd_pdq を除く)
E_TMOUT ポーリング失敗またはタイムアウト( snd_pdq を除く)
E_RLWAI 待ち禁止状態または待ち状態の強制解除( snd_pdq とtsnd_pdq の場合)
E_DLT 待ちオブジェクトの削除または再初期化( snd_pdq とtsnd_pdq の場合)

【機能】

pdqid で指定した優先度データキュー(対象優先度データキュー)に, data で指 定したデータを, datapri で指定した優先度で送信する.具体的な振舞いは 以下 の通り.

対象優先度データキューの受信待ち行列にタスクが存在する場合には,受信待 ち行列の先頭のタスクが, data で指定したデータを受信し,待ち解除される. 待ち解除されたタスクには,待ち状態となったサービスコールから E_OK が返る.

対象優先度データキューの受信待ち行列にタスクが存在せず,優先度データ キュー管理領域にデータを格納するスペ ースがある場合には, data で指定した データが, datapri で指定したデータの優先度順で優先度データキュー管理領域 に格納される.

対象優先度データキューの受信待ち行列にタスクが存在せず,優先度データ キュー管理領域にデータを格納するスペースがない場合には,自タスクは優先 度データキューへの送信待ち状態となり,対象優先度データキューの送信待ち 行列につながれる.

datapri は, TMIN_DPRI 以上で,対象データキューに送信できるデータ優先度の 最大値以下でなければならない.


rcv_pdq 優先度データキューからの受信〔 T〕
prcv_pdq 優先度データキューからの受信(ポーリング)〔 T〕
trcv_pdq 優先度データキューからの受信(タイムアウト付き)〔 T〕

【 C言語 API 】

ER ercd = rcv_pdq(ID pdqid, intptr_t *p_data, PRI *p_datapri)

ER ercd = prcv_pdq(ID pdqid, intptr_t *p_data, PRI *p_datapri)

ER erc d = trcv_pdq(ID pdqid, intptr_t *p_data, PRI *p_datapri, TMO tmout)

【パラメータ】

ID pdqid 対象優先度データキューの ID 番号
intptr_t * p_data 受信データを入れるメモリ領域へのポインタ
PRI * p_datapri 受信データの優 先度を入れるメモリ領域へのポインタ
TMO tmout タイムアウト時間( trcv_pdq の場合)

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード
intptr_t data 受信データ
PRI datapri 受信データの優先度

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し,ディスパッチ保留状態からの呼出し: prcv_pdq を除く)
E_NOSPT 未サポート機能(制約タスクからの呼出し: prcv_pdq を除く)
E_ID 不正 ID 番号( pdqid が不正)
E_PAR パラメータエラー( tmout が不正: trcv_pdq の場合)
E_NOEXS 〔 D〕 オブジェクト未登録(対象優先度データキューが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象優先度データキューに対する通常操作 2が許可されていない)
E_MACV 〔 P〕 メモリアクセス違反( p_data または p_datapri が指すメモリ領域への書込みアクセスが許可されていない)
E_TMOUT ポーリング失敗 またはタイムアウト( rcv_pdq を除く)
E_RLWAI 待ち禁止状態または待ち状態の強制解除( prcv_pdq を除く)
E_DLT 待ちオブジェクトの削除または再初期化( prcv_pdq を除く)

【機能】

pdqid で指定した優先度データキュー(対象優先度データキュー)からデータを 受信する.受信したデータは p_data で指定したメモリ領域に,その優先度は p_datapri で指定したメモリ領域に返される.具体的な振舞いは以下の通り.

対象優先度データキューの優先度データキュー管理領域にデータが格納されて いる場合には,優先度データキュー管理領域の先頭に格納されたデータが取り 出され, p_data で指定したメモリ領域に返される.また,その優先度が p_datapri で指定したメモリ領域に返され る.さらに,送信待ち行列にタスクが 存在する場合には,送信待ち行列の先頭のタスクの送信データが,データの優 先度順で優先度データキュー管理領域に格納され,そのタスクは待ち解除され る.待ち解除されたタスクには,待ち状態となったサービスコールから E_OK が 返る.

対象優先度データキューの優先度データキュー管理領域にデータが格納されて おらず,送信待ち行列にタスクが存在する場合には,送信待ち行列の先頭のタ スクの送信データが, p_data で指定したメモリ領域に返される.また,その優 先度が p_datapri で指定したメモリ領域に返される.送信待ち行列の先頭のタス クは,待ち解除される.待ち解除されたタスクには,待ち状態となったサービ スコールから E_OK が返る.

対象優先度データキューの優先度データ キュー管理領域にデータが格納されて おらず,送信待ち行列にタスクが存在しない場合には,自タスクは優先度デー タキューからの受信待ち状態となり,対象優先度データキューの受信待ち行列 につながれる.


ini_pdq 優先度データキューの再初期化〔 T〕

【 C言語 API 】

ER ercd = ini_pdq(ID pdqid)

【パラメータ】

ID pdqid 対象優先度データキューの ID 番号

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

【エラーコード】

E_CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( pdqid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象優先度データキューが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象優先度データキューに対する管理操作が許可されていない)

【機能】

pdqid で指定した優先度データキュー(対象優先度データキュー)を再初期化す る.具体的な振舞いは以下の通り.

対象優先度データキューの優先度データキュ ー管理領域は,格納されているデー タがない状態に初期化される.また,対象優先度データキューの送信待ち行列 と受信待ち行列につながれたタスクは,それぞれの待ち行列の先頭のタスクか ら順に待ち解除される.待ち解除されたタスクには,待ち状態となったサービ スコールから E_DLT エラーが返る.

【補足説明】

送信待ち行列と受信待ち行列の両方にタスクがつな がれていることはないため, 別の待ち行列で待っていたタスクの間の待ち解除の順序は,規定する必要がな い.

【使用上の注意】

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

優先度データキューを再初期化した場合に,アプリケーションとの整合性を保 つのは,アプリケーションの責任である.


ref_pdq 優先度データキューの状態参照〔 T〕

【 C言語 API 】

ER ercd = ref_pdq(ID pdqid, T_RPDQ *pk_rpdq)

【パラメータ】

ID pdqid 対象優先度データキューの ID 番号
T_RPDQ * pk_rpdq 優先度データキューの現在状態を入れるパケットへのポインタ

【リターンパラメータ】

ER ercd 正常終了( E_OK )またはエラーコード

*優先度データキューの現在状態(パケットの内容)

ID stskid 優先度データキューの送信待ち行列の先頭のタスクの ID 番号
ID rtskid 優先度データキューの受信待ち行列の先頭のタスクの ID 番号
uint_t spdqcnt 優先度データキュー管理領域に格納されているデータの数

【エラーコード】

E_ CTX コンテキストエラー(非タスクコンテキストからの呼出し, CPU ロック状態からの呼出し)
E_ID 不正 ID 番号( pdqid が不正)
E_NOEXS 〔 D〕 オブジェクト未登録(対象優先度データキューが未登録)
E_OACV 〔 P〕 オブジェクトアクセス違反(対象優先度データキューに対する参照操作が許可されていない)
E_MACV 〔 P〕 メモリアクセス違反( pk_rpdq が指すメモリ領域への書込みアクセスが許可されていない)

【機能】

pdqid で指定した優先度データキュー(対象優先度データキュー)の現在状態を 参照する.参照した現在状態は, pk_rpdq で指定したパケットに返される.

対象優先度データキューの送信待ち行列にタスクが存在しない場合, stskid に は TSK_NONE (= 0)が返る.また,受信待ち行列にタスクが存在しない場合, rtskid には TSK_NONE (= 0)が返る.

【使用上の注意】

ref_pdq はデバッグ 時向けの機能であり,その他の目的に使用することは推奨し ない.これは, ref_pdq を呼び出し,対象優先度データキューの現在状態を参照 した直後に割込みが発生した場合, ref_pdq から戻ってきた時には対象優先度デー タキューの状態が変化している可能性があるためである.


4.4.5 メールボックス

メールボックスは,共有メモリ上に置いたメッセージを, FIFO 順またはメッセー ジの優先度順で送受信するための同期・通信オブジェクトである.メールボッ クスは,メールボックス ID と呼ぶ ID 番号によって識別する.

各メールボックスが持つ情報は次の通り.

  • ・メールボックス属性
  • ・メッセージキュー
  • ・待ち行列(メールボックスからの受信待ち状態のタスクのキュー)
  • ・送信できるメッセージ優先度の最大値
  • ・優先度別のメッセージキューヘッダ領域
  • ・属するクラス(マルチプロセッサ対応カーネルの場合)

メッセージキューは,メールボックスに送信されたメッセージを, FIFO 順また はメッセージの優先度順につないでおくためのキュー である.

待ち行列は,メールボックスからメッセージが受信できるまで待っている状態 (メールボックスからの受信待ち状態)のタスクが,メッセージを受信できる 順序でつながれているキューである.

メールボックス属性には,次の属性を指定することができる.

TA_TPRI 0x01U 待ち行列をタスクの優先度順にする
TA_MPRI 0x02U メッセージキューをメッセージの優先度順にする

TA_TPRI を指定しない場合,待ち行列は FIFO 順になる. TA_MPRI を指定しない場 合,メッセージキューは FIFO 順になる.

優先度別のメッセージキューヘッダ領域は, TA_MPRI 属性のメールボックスに対 して,メッセージキューを優先度別に設ける場合に使用する領域である.

カーネルは,メールボックスに送信されたメッセージをメッセージキューにつ なぐために,メッセージの先頭のメモリ領域を使用する.そのためアプリケー ションは,メールボックスに送信するメッセージの先頭に,カーネルが利用す るためのメッセージヘッダを置かなければならない.メッセージヘッダのデー タ型として,メールボックス属性に TA_MPRI が指定されているか否かにより,以 下のいずれかを用いる.

T_MSG TA_MPRI 属性でないメールボックス用のメッセージヘッダ
T_MSG_PRI TA_MPRI 属性のメールボックス用のメッセージヘッダ

メッセージヘッダの領域は,メッセージがメッセージキューにつながれている 間(すなわち,メールボックスに送信してから受信するまでの間),カーネル によって使用される.そのため,メッセージキューにつながれているメッセー ジのメッセージヘッダの領域をアプリケーションが書き換えた場合や,メッセー ジキューにつながれているメッセージを再度メールボックスに送信した場合の 動作は保証されない.

TA_MPRI 属性のメールボックスにメッセージを送信する場合,アプリケーション は,メッセージの優先度を, T_MSG_PRI 型のメッセ ージヘッダ中の msgpri フィー ルドに設定する.

保護機能対応カーネルでは,メールボックス機能はサポートしない.

メールボックス機能に関連するカーネル構成マクロは次の通り.

TMIN_MPRI メッセージ優先度の最小値(= 1)
TMAX_MPRI メッセージ優先度の最大値
TNUM_MBXID 登録できるメールボックスの数(動的生成対応でないカーネルでは,静的 API によって登録されたメールボックスの数に一致)

【補足説明】

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 仕様に規定されていないカーネル構成マクロである.


CRE_MBX メールボックスの生成〔 Sp 〕
acre_mbx メールボックスの生成〔 TpD 〕

【静的 API 】

CRE_MBX(ID mbxid, { ATR mbxatr, PRI maxmpri, void *mprihd })

【 C言語 API 】

ER_ID mbxid = acre_mbx(const T_CMBX *pk_cmbx)

【パラメータ】

ID mbxid 生成するメールボックスの ID 番号( CRE_MBX の場合)
T_CMBX * pk_cmbx メールボックスの生成情報を入れたパケットへのポインタ(静的 API を除く)

*メールボックスの生成情報(パケットの内容)

ATR mbxatr メールボックス属性
PRI maxmpri 優先度メールボックスに送信できるメッセージ優先度の最大値
void * mprihd 優先度別のメッセージキ