JP6462521B2 - 通常部の故障が安全部へ伝播することを防止するａｐｉ及びその処理部 - Google Patents

Description

本発明は、オペレーティングシステム(ＯＳ)におけるアプリケーションプログラミングインタフェース(ＡＰＩ)に関する。

コンピュータシステムのＯＳには、プログラムを並行に実行する機能を備えるものがある。並行実行のプログラムの単位は「タスク」と呼ばれる。タスクを並行に実行する機能を備えるオペレーティングシステムは、特定の動作後、あるいは、一定時間間隔で、次に実行するタスクを選択し、実行権を与える。次に実行するタスクを選択し、実行権を与える動作は、「スケジューリング」と呼ばれる。実行権を与えられたタスクは、次のスケジューリングが発生するまで、タスク毎にあらかじめ決められた処理を実行する。

いくつかのタスクは、リアルタイム性を必要とする。リアルタイム性とは、他のタスクに実行を妨げられずに、特定のイベントの後、すぐに処理を実行することを指す。例えば、車のブレーキを実行するタスクは、ブレーキペダルを踏むというイベント後、すぐにブレーキをかける必要があるため、リアルタイム性を必要とする。リアルタイム性を必要とするタスクは、他のタスクよりも優先的に実行される必要がある。特定のタスクを優先的に動作させるために、各タスクに優先度をつけ、優先度に応じてタスクをスケジューリングする方法がある。

特許文献１で開示されている方法は、起動されたタスクの優先度に応じてタスクの実行可能状態キューを制御する。起動されたタスクが実行中のタスクの優先度よりも低いか、もしくは等しければ起動されたタスクを実行可能状態キューの最後尾につなぎ、起動されたタスクの優先度が実行中のタスクの優先度よりも高ければ実行中のタスクを中断して起動されたタスクを実行可能状態キューの先頭につなぐ。

その際、中断されたタスクに巡回スケジュール抑止フラグが設定されていれば、実行中のタスクを実行可能状態キューの先頭につなぎ、設定されていなければ実行可能状態キューの最後尾につなぐ。スケジューラは実行可能状態キューの先頭にあるタスクをキューから取り外して実行させる。

特開平3-100831

タスクを安全タスクと通常タスクに分類する場合を考える。安全タスクは人命や環境、経済に係るような安全性を必要とする処理を実行する。このような処理を安全処理と呼ぶ。通常タスクはそれ以外の処理を実行する。この処理を通常処理と呼ぶ。安全処理は、安全性に関わるため、安全性を維持できないような通常処理からの時間的あるいは空間的な影響を受けてはならない。

特許文献１の方法は、タスクの優先度および特定のフラグで、実行可能状態キューを制御している。しかし、タスクの種別やそのタスクが操作するプログラムの種別によるスケジューリングの変更を考慮していない。そのため、安全タスクの能動的なプログラム操作により、通常タスクあるいは通常プログラムの故障が安全タスクに伝播する恐れがある。

例えば、タスクが操作するプログラムを安全部と通常部に分類する。安全タスクが通常部のプログラムを操作対象とするとき、そのプログラムを操作できるようになるまで安全タスクが待つならば、安全タスクが通常部のプログラムによって実行を妨げられることになる。タスクの起動時に実行可能状態キューを制御する特許文献１の方法では、タスク種別と、その操作対象プログラムの種別によって、スケジューリングを変更することは難しい。

各タスクを安全タスクと通常タスクのどちらかに分類する。ＯＳは、タスク種別ごとに異なるトラップ番号あるいは異なるライブラリを持つＡＰＩ、および、タスク種別ごとのＡＰＩ処理部を持つ。ここでトラップとは、プログラムの処理中に発生する例外を指す。トラップ番号とは、トラップに付けられた番号であり、発生したトラップの種別を識別するために使われる。トラップ番号あるいはライブラリがタスク種別ごとに異なるため、呼び出されるＡＰＩ処理部もタスク種別によって異なる。そのため、ＯＳはＡＰＩを呼び出したタスクを調べることなく、そのタスクのタスク種別を特定できる。各タスクはＡＰＩを介して、ＯＳが管理するプログラムを操作することができる。タスクが操作するプログラムは、プログラム種別を特定するためのフラグを持つ。各ＡＰＩ処理部は、呼び出し元タスクが操作しようとしているプログラムの種別を、そのフラグを見て特定する。その後、各ＡＰＩ処理部は、呼び出し元のタスク種別と操作対象となるプログラムの種別に応じたスケジューリングを行う。

タスク種別と操作対象プログラムの種別に応じてスケジューリングを変更することにより、安全タスクの能動的なプログラム操作による、通常タスク故障あるいは通常プログラム故障の安全タスクへの伝播を防ぐことができる

本発明の代表的な実施形態の特徴を示すソフトウェアモジュール図。 本発明のハードウェア構成の一例を示すブロック図。 実施例１における安全ＡＰＩ処理部１１１の一例を示すソフトウェアモジュール図。 実施例１における通常ＡＰＩ処理部１１２の一例を示すソフトウェアモジュール図。 実施例１における、ＯＳ１１０が取り扱うプログラムの一種であるセマフォの、カーネルオブジェクトコントロールブロック１２１の一例を示す図。 実施例１における安全ＡＰＩ処理部１１１の処理の一例を示すフローチャート図。 実施例１における通常ＡＰＩ処理部１１２の処理の一例を示すフローチャート図。 実施例１において、安全処理が安全部のカーネルオブジェクトを操作する場合の図６のステップ６０８の処理の一例を示すフローチャート図。 実施例１において、安全処理が通常部のカーネルオブジェクトを操作する場合の図６のステップ６０８の処理の一例を示すフローチャート図。 実施例１において、通常処理が通常部のカーネルオブジェクトを操作する場合の図８のステップ７０５の処理の一例を示すフローチャート図。 実施例２における安全ＡＰＩ処理部１１１の一例を示すソフトウェアモジュール図。 実施例２における通常ＡＰＩ処理部１１２の一例を示すソフトウェアモジュール図。 実施例２におけるＯＳ１１０が取り扱うプログラムの一種であるメールボックスのカーネルオブジェクトコントロールブロック１２１の一例を示す図。 実施例２において、安全処理が安全部のカーネルオブジェクトを操作する場合の図６のステップ６０８の処理の一例を示すフローチャート図。 実施例２において、安全処理が通常部のカーネルオブジェクトを操作する場合の図７のステップ６０８の処理の一例を示すフローチャート図。 実施例２において、通常処理が通常部のカーネルオブジェクトを操作する場合の図７のステップ７０５の処理の一例を示すフローチャート図。

以下、図面を用いて本発明の実施例を説明する。

図１は、本発明の代表的な実施形態の特徴を示すソフトウェアモジュール図であり、アプリケーション１００とＯＳ１１０とコントロールブロック１２０から構成される。アプリケーション１００は少なくとも１つの安全ドメイン１０１と、少なくとも１つの通常ドメインを持つ。安全ドメイン１０１は少なくとも１つの安全タスク１０３を持つ。通常ドメイン１０２は少なくとも１つの通常タスク１０４を持つ。安全ドメイン１０１および安全タスク１０３は、安全ＡＰＩの呼び出し１０５によって、ＯＳ１１０の機能を呼び出し、安全処理を行う。通常ドメイン１０２および通常タスク１０４は、通常ＡＰＩの呼び出し１０６によってＯＳ１１０の機能を呼び出し、通常処理を行う。

安全ＡＰＩと通常ＡＰＩは、異なるトラップ番号あるいは異なるライブラリによって実現する。トラップ番号あるいはライブラリが異なるため、ＯＳ１１０は、ＡＰＩが呼び出された時点で、そのＡＰＩ処理が安全処理か通常処理かを判定できる。安全タスクが通常処理を実行するのを防止するため、安全タスクは安全ＡＰＩのみ呼び出せ、通常ＡＰＩを呼び出せないように実装する。通常タスクが安全処理を実行するのを防止するため、通常タスクは通常ＡＰＩのみ呼び出せ、安全ＡＰＩを呼び出せないように実装する。この実装の実現方法の一例は、コンパイル時に誤ったＡＰＩ呼び出しを検出すること、である。

ＯＳ１１０は安全ＡＰＩを処理する安全ＡＰＩ処理部１１１と、通常ＡＰＩを処理する通常ＡＰＩ処理部１１２と、ユーザ定義基本処理部１１３と基本処理部１１４と、実行可能状態キュー１１５と、タイマイベントキュー１１６を持つ。安全ＡＰＩ処理部１１１は、安全ＡＰＩに関連する安全処理を行う。通常ＡＰＩ処理部１１２は、通常ＡＰＩに関連する通常処理を行う。安全ＡＰＩ処理部１１１と通常ＡＰＩ処理部１１２は、ＡＰＩを呼び出したタスクが操作するプログラムの種別に応じて、スケジューリングを変更する。基本処理部１１４はハードウェアやコントロールブロック１２０から得られるデータを処理する。ユーザ定義基本処理部１１３はＯＳ１１０のユーザが定義したＯＳの追加機能を処理する。基本処理部１１４やユーザ定義基本処理部１１３が上記以外の処理を行うことも可能である。

実行可能状態キュー１１５は、実行可能状態のタスクが実行予定順に並んだキューである。実行可能状態とは、タスクの状態の１つであり、実行権を与えられればいつでも実行できる状態である。本実施例のスケジューリングでは、実行可能状態キュー１１５の先頭のタスクに、実行権を与える。タイマイベントキュー１１６は、指定された時間後に起動するタスクが時間順に並んだキューである。

コントロールブロック１２０は０個あるいは１個以上のカーネルオブジェクトコントロールブロック１２１を持つ。カーネルオブジェクトコントロールブロック１２１は、ＯＳ１１０の取り扱うプログラムに関する情報を格納する。タスクは、これらのプログラムを安全ＡＰＩあるいは通常ＡＰＩを介して操作する。ＯＳ１１０の取り扱うプログラムの実行時の単位をカーネルオブジェクトと呼ぶ。本実施例では、各カーネルオブジェクトは、安全部と通常部のどちらかに分類する。

本実施例では、安全ＡＰＩ処理部１１１および通常ＡＰＩ処理部１１２は、タスクが操作するカーネルオブジェクトの種別に応じてスケジューリングを変更する。本実施例における、安全処理部１１１が実施するスケジューリングは、次のようなスケジューリングである。安全タスク１０３が操作するカーネルオブジェクトが安全部の場合、安全ＡＰＩを呼び出した安全タスク１０３は、カーネルオブジェクトを操作可能なときは操作し、操作不可能なときは時間制限付きの待ち状態に移行する。操作するカーネルオブジェクトが通常部の場合、安全ＡＰＩを呼び出した安全タスク１０３は、操作するカーネルオブジェクトをすぐに操作可能な場合は操作し、すぐに操作不可能な場合はＡＰＩ処理を終了する。これにより、ＡＰＩを呼び出した安全タスク１０３は、通常部のカーネルオブジェクトを操作するとき、待ち状態にならないため、通常部による時間的侵害を受けない。

本実施例における、通常ＡＰＩ処理部１１２が実施するスケジューリングは、次のようなスケジューリングである。通常タスク１０４が操作するカーネルオブジェクトが通常部であれば、通常ＡＰＩを呼び出した通常タスク１０４は、カーネルオブジェクトを操作可能なときは操作し、操作不可能なときは待ち状態に移行する。カーネルオブジェクトが安全部であれば、ＡＰＩ処理を実行しない。これにより、呼び出した通常タスク１０４は、安全部のカーネルオブジェクトを操作しないため、安全部を時間的に侵害しない。

図２は、本発明のハードウェア構成の一例を示す図である。処理装置２００は、少なくとも１つのＲＡＭ２１０と、少なくとも１つのＲＯＭ２２０と、少なくとも１つのＣＰＵ２３０と、少なくとも１つの割込みコントローラ２４０と、少なくとも１つのＩ／Ｏ２５０と、０個あるいは１個以上の外部記憶装置２６０から構成される。

アプリケーションプログラム２２１は、アプリケーション１００のプログラムである。ＯＳプログラム２２２はＯＳ１１０のプログラムである。アプリケーションプログラム２２１とＯＳプログラム２２２は、起動時にＲＡＭ２１０に展開される。アプリケーションプログラム２２１とＯＳプログラム２２２の機能は、ＣＰＵ２３０によってプログラムが解釈実行されることにより実現する。

各機能を実現するプログラム等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、ＤＶＤ（Digital Versatile Disc）等の記録媒体に格納されてもよい。

図３は、図１の安全ＡＰＩ処理部１１１の一例を示すソフトウェアモジュール図である。安全ＡＰＩ処理部１１１は、引数確認部３０１と、ＡＰＩ種別確認部３０２と、安全判定部３０３と、待ち行列確認部３０４と、ＡＰＩ処理部３０５から構成される。引数確認部３０１は、ＡＰＩの引数に、処理範囲外の値が指定されていないか確認を行う。ＡＰＩ種別確認部３０２は、呼び出されたＡＰＩが、呼び出し元タスクを待ち状態にするようなＡＰＩかどうかを判定する。安全判定部３０３は、タスクが操作するカーネルオブジェクトが安全部かを判定する。待ち行列確認部３０４は、ＡＰＩを呼び出したタスクが操作する予定のカーネルオブジェクトを、他のタスクが待っているかどうかを判定する。ＡＰＩ処理部３０５は、ＯＳ１１０のカーネルオブジェクトを操作するカーネルオブジェクト操作部３１０を持つ。本実施例において、ＯＳ１１０のカーネルオブジェクトは、セマフォのみである。セマフォは排他制御を実現するためのカーネルオブジェクトである。セマフォは有限の資源を持つ。資源の初期数および最大値は、セマフォが生成されたときに決定する。タスクがセマフォの獲得を試みたとき、セマフォの持つ資源数が、タスクが希望する資源数より多ければ、タスクはセマフォを獲得できる。セマフォの持つ資源数が、タスクが希望する資源数より少なければ、タスクはセマフォを獲得できない。カーネルオブジェクト操作部３１０は、セマフォを操作するためのセマフォ操作部３１１を持つ。セマフォに関するＡＰＩ処理はセマフォ操作部３１１が行う。

図４は、図１の通常ＡＰＩ処理部１１２の一例を示すソフトウェアモジュール図である。通常ＡＰＩ処理部１１２は、通常判定部４０１とＡＰＩ処理部４０２を持つ。通常判定部４０１は、ＡＰＩが取り扱うカーネルオブジェクトが通常部のプログラムかを判定する。ＡＰＩ処理部４０２は、ＯＳ１１０のカーネルオブジェクトを操作するカーネルオブジェクト操作部４１０を持つ。カーネルオブジェクト操作部４１０は、通常ＡＰＩのためのセマフォ操作部４１１を持つ。

図５は、セマフォのカーネルオブジェクトコントロールブロック１２１の一例を示す図である。安全ＡＰＩ処理部１１１および通常ＡＰＩ処理部１１２は、待ち行列先頭アドレス５０１を調べることで、セマフォの待ち行列に並んでいるタスクの有無を判別する。セマフォを獲得できなかったタスクは、セマフォを獲得できるようになるまで、待つことができる。このような一定の条件が成立するまで待つ状態を、待ち状態と呼ぶ。セマフォを獲得するために待ち状態になったタスクは、対象のセマフォの待ち行列に並ぶ。セマフォを獲得しているタスクが資源を返却すると、待ち状態に並んでいるタスクが一つ選択され、セマフォの獲得を試みる。

カーネルオブジェクトコントロールブロック１２１は、カーネルオブジェクトを一意に識別するためのＩＤ５０２を持つ。安全フラグ５０３は、カーネルオブジェクトが安全部か通常部かを示す。安全フラグ５０３は、カーネルオブジェクト生成時にセットする。拡張情報５０４には、カーネルオブジェクトに関する任意の情報をセットできる。属性１０５は、カーネルオブジェクトの属性を表す情報である。セマフォカウント５０６はセマフォが持つ資源の数量を表す。タスクが希望する資源の数量がセマフォカウント５０６より小さい場合のみ、タスクはセマフォを獲得することができる。タスクがセマフォを獲得すると、タスクが希望した数量だけ、セマフォカウント５０６が減少する。セマフォカウント最大値５０７はセマフォカウント５０６の取りうる最大値である。

図６は、実施例１における安全ＡＰＩ処理部１１１の処理の一例を示すフローチャート図である。タスクが安全ＡＰＩを呼び出すと(Ｓ６０２)、安全ＡＰＩ処理部１１１が安全処理を開始する。

まず、実行中のタスクが使用していたレジスタの内容をＲＡＭ２１０に退避する(Ｓ６０３)。次に、引数確認部３０１が、呼び出された安全ＡＰＩの引数に処理対象外の値が指定されていないかを確認する(Ｓ６０４)。処理対象外の値が指定されている場合は、エラー処理のためにＳ６１０へ進む。引数が全て処理対象の値であれば、安全処理を続行する。

前述したように、安全タスク１０３は、安全部のカーネルオブジェクトを操作する場合は待ち状態になれるが、通常部のカーネルオブジェクトを操作する場合は待ち状態になれない。これを達成するために、まず、ＡＰＩ種別確認部３０２が、呼び出された安全ＡＰＩがタスクを待ち状態にするような処理を含むＡＰＩかを判定する(Ｓ６０５)。呼び出された安全ＡＰＩがタスクを待ち状態にしないＡＰＩならば、スケジューリングは必要ないため、ＡＰＩ処理を続行する。呼び出された安全ＡＰＩがタスクを待ち状態にするＡＰＩならば、安全判定部３０３が、操作するカーネルオブジェクトが安全部かを判定するために、カーネルオブジェクトの安全フラグ５０３を確認する(Ｓ６０６)。安全部のカーネルオブジェクトであれば、ＡＰＩ処理を続行する。通常部のカーネルオブジェクトであれば、カーネルオブジェクトの操作権を待っている他のタスクの有無を調べるために、待ち行列確認部３０４がカーネルオブジェクトの待ち行列が空か確認する(Ｓ６０７)。他のタスクが待ち行列に並んでいる場合、すぐにカーネルオブジェクトを操作できないためＡＰＩ処理を終了し、エラー処理へと進む。他のタスクが待ち行列にいない場合、すぐにカーネルオブジェクトを操作できる可能性があるため、ＡＰＩ処理を続行する。

操作するカーネルオブジェクトの待ち行列が空であった場合、ＡＰＩ処理部３０５がＡＰＩ処理を実行する(Ｓ９００)。ＡＰＩ処理で、Ｓ６０６で判定した結果に基づいたスケジューリングを実施する。

その後、ＡＰＩの返り値が処理対象外の値でないかを判定する(Ｓ６０８)。返り値が処理対象外の場合は、ＡＰＩ処理に不具合があると考えられるため、処理内容を破棄し(Ｓ６０９)、エラー処理を実行する(Ｓ６１０)。引数が不正であった場合や操作するカーネルオブジェクトの待ち行列が残っていた場合も、エラー処理を実行する(Ｓ６１２)。

以上の処理の後、Ｓ６０３でＲＡＭ２１０に退避したレジスタの内容をレジスタに戻す(Ｓ６１１)。安全ＡＰＩ処理部１１１が、安全ＡＰＩ処理を終了する(Ｓ６１２)。

図７は、実施例１における通常ＡＰＩ処理部１１２の処理の一例を示すフローチャート図である。タスクが通常ＡＰＩを呼び出すと(Ｓ７０２)、通常ＡＰＩ処理部１１２が通常処理を開始する。

まず、実行中のタスクの使用していたレジスタの内容をＲＡＭ２１０に退避する(Ｓ７０３)。

前述したように、通常タスク１０４は、通常部のカーネルオブジェクトを操作する場合は待ち状態になれるが、安全部のカーネルオブジェクトを操作することはできない。以上を達成するために、まず、通常判定部４０１が、操作するカーネルオブジェクトが通常部のプログラムかどうかを判定するために、カーネルオブジェクトの安全フラグ５０３を確認する(Ｓ７０４)。通常部のプログラムであれば、ＡＰＩ処理部４０２がＡＰＩ処理を実行する(Ｓ１１００)。安全部のプログラムであれば、エラー処理を実行する(Ｓ７０７)。

以上の処理のあと、Ｓ７０３でＲＡＭ２１０に退避したレジスタの内容をレジスタに戻す(Ｓ７０５)。通常ＡＰＩ処理部１１２が通常ＡＰＩ処理を終了する(Ｓ７０６)。

図８は、実施例１において、安全処理が、安全部のカーネルオブジェクトを操作する場合の、図６のＳ９００の内部処理の一例を示すフローチャート図である。同図は、安全ＡＰＩ処理部１１１のセマフォ操作部３１１が、安全部のセマフォを獲得する処理を行う例を示す。

まず、排他的なセマフォ操作を実現するために、割込みをマスクする(Ｓ９０１)。次に、セマフォカウント最大値５０７が、ＡＰＩの引数で指定されたセマフォ獲得希望数より多いかどうか判定する(Ｓ９０２)。少ない場合には、ＡＰＩを呼び出したタスクは、セマフォを獲得できず、エラー処理を実行する(Ｓ９１２)。

Ｓ９０２でセマフォカウント最大値５０７が、ＡＰＩの引数で指定されたセマフォ獲得希望数より、多いあるいは同数の場合には、セマフォカウント５０６が、ＡＰＩの引数で指定されたセマフォ獲得希望数より多いかどうかを判定する(Ｓ９０３)。セマフォカウント５０６が、ＡＰＩの引数で指定されたセマフォ獲得希望数より、多いあるいは同数の場合には、セマフォの獲得処理を行う(Ｓ９０４)。セマフォ獲得処理では、セマフォカウント５０６から、ＡＰＩの引数で指定されたセマフォ獲得希望数を引いたものを、セマフォカウント５０６に格納する。

Ｓ９０３でセマフォカウント５０６が、ＡＰＩの引数で指定されたセマフォ獲得希望数より少ないと判定された場合、ＡＰＩを呼び出したタスクは時間制限付きの待ち状態に移行する(Ｓ９０７〜Ｓ９１１)。まず、待ち状態の時間制限を指定しているかを確認する(Ｓ９０７)。待ち状態の時間制限の指定方法の例として、ＡＰＩの引数で指定する方法や、カーネルオブジェクトにあらかじめ設定しておく方法がある。待ち状態の時間制限が指定されていない場合は、エラー処理を行う(Ｓ９１２)。

待ち状態の時間制限が指定されている場合、ＡＰＩを呼び出したタスクは実行可能状態から待ち状態に遷移する(Ｓ９０８〜Ｓ９１１)。まず、実行可能状態キュー１１５から、ＡＰＩを呼び出したタスクを取り外す(Ｓ９０８)。次に、ＡＰＩを呼び出したタスクの状態を実行可能状態から待ち状態に変更する(Ｓ９０９)。待ち状態の時間制限経過後に起動できるように、ＡＰＩを呼び出したタスクをタイマイベントキュー１１６につなぐ(Ｓ９１０)。ＡＰＩを呼び出したタスクを待ち対象となるカーネルオブジェクトの待ち行列５０１につなぐ(Ｓ９１１)。

セマフォ獲得処理(Ｓ９０４)あるいは待ち状態への移行(Ｓ９０８〜Ｓ９１１)あるいはエラー処理(Ｓ９１２)が終了したら、Ｓ９０１で実行した割込みマスクを解除する(Ｓ９０５)。安全ＡＰＩ処理部１１１のＡＰＩ処理部３０５は、処理を終了する(Ｓ９０６)。

図９は、実施例１において、安全処理が通常部のカーネルオブジェクトを操作する場合の図７のＳ９００の内部処理の一例を示すフローチャート図である。本図は、安全ＡＰＩ処理部１１１のセマフォ操作部３１１が通常部のセマフォを獲得する処理を行う例を示す。

セマフォカウント５０６が、ＡＰＩの引数で指定されたセマフォ獲得希望数より少ない場合の動作は図９と異なり、エラー処理を行う(Ｓ９１２)。これは、本実施例の安全処理において通常部のカーネルオブジェクトを取得する際、待ち状態に移行できないためである。

図１０は、実施例１において、通常処理が通常部のカーネルオブジェクトを操作する場合の図８のＳ１１０５の内部処理の一例を示すフローチャート図である。本図は、通常ＡＰＩ処理部１１２のセマフォ操作部４１１が通常部のセマフォを獲得する処理を行う例を示す。

Ｓ１１０１〜Ｓ１１０２の処理は、図９のＳ９０１〜Ｓ９０２と同様である。セマフォカウント５０６が、ＡＰＩの引数で指定されたセマフォ獲得希望数より多いあるいは同数の場合の処理(Ｓ１１０３〜Ｓ１１０６)は、図９のＳ９０３〜Ｓ９０６と同様である。

セマフォカウント５０６が、ＡＰＩの引数で指定されたセマフォ獲得希望数より少ないと判定された場合の処理(Ｓ１１０８〜Ｓ１１１２)は図９と異なる。本実施例では、通常処理において、通常部のカーネルオブジェクトを取得する際、待ち状態に時間制限をつける必要はない。そのため、時間制限の指定の有無をチェックせずに、実行可能状態キュー１１５からＡＰＩを呼び出したタスクを取り外し(Ｓ１１０８)、ＡＰＩを呼び出したタスクの状態を実行可能状態から待ち状態に変更する(Ｓ１１０９)。

待ち状態の時間制限が指定されている場合には(Ｓ１１１０)、待ち状態の時間制限経過後に起動できるように、ＡＰＩを呼び出したタスクをタイマイベントキュー１１６につなぐ(Ｓ１１１２)。待ち状態の時間制限の指定の有無に関わらず、ＡＰＩを呼び出したタスクをカーネルオブジェクトの待ち行列５０１につなぐ(Ｓ１１１２)。

その後の処理(Ｓ１１０５〜Ｓ１１０６)は図９のＳ９０６〜Ｓ９０７と同様である。

以上の処理により、安全タスクは、操作対象のカーネルオブジェクトが安全部ならば時間制限付きの待ち状態に移行でき、通常部ならば待ち状態に移行できず、通常タスクは、操作対象のカーネルオブジェクトが安全部ならば操作できず、通常部ならば時間制限を問わない待ち状態に移行できる。よって、タスクの種別とカーネルオブジェクトの種別に応じたスケジューリングの制御が可能となり、通常部の故障が安全タスクに伝播するような時間的侵害を防ぐことができる。

本発明の第二の実施例は、図３、および、図４において、カーネルオブジェクトの種別を一種類から七種類に変更したものである。追加されたカーネルオブジェクトはタスク、イベントフラグ、メールボックス、ミューテックス、ランデブポート、メッセージボックスである。本実施例には、それぞれのカーネルオブジェクトを操作するための、カーネルコントロールブロック１２１、安全ＡＰＩ、通常ＡＰＩ、安全ＡＰＩ処理部１１１の操作部、通常ＡＰＩ処理部１１２の操作部を追加する。以下、本実施例において、実施例１と同じ構成には同じ番号を付与して説明を省略する。

図１１は、本実施例における安全ＡＰＩ処理部１１１の一例を示すソフトウェアモジュール図である。追加されたカーネルオブジェクトを操作するために、カーネルオブジェクト操作部３１０にタスク操作部１２０１、イベントフラグ操作部１２０２、メールボックス操作部１２０３、ミューテックス操作部１２０４、ランデブポート操作部１２０５を追加する。それぞれのカーネルオブジェクトに関するＡＰＩ処理を、それぞれの操作部が行う。

図１２は、本実施例における通常ＡＰＩ処理部１１２の一例を示すソフトウェアモジュール図である。追加されたカーネルオブジェクトを操作するために、カーネルオブジェクト操作部４１０にタスク操作部１３０１、イベントフラグ操作部１３０２、メールボックス操作部１３０３、ミューテックス操作部１３０４、メッセージバッファ操作部１３０５、ランデブポート操作部１３０６を追加する。それぞれのカーネルオブジェクトに関するＡＰＩ処理を、それぞれの操作部が行う。

図１３は、本実施例において、カーネルオブジェクトの一種であるメールボックスのカーネルオブジェクトコントロールブロック１２１の一例を示す図である。

メッセージキューとは、送信されたメッセージを入れるためのキューである。タスクが送信ＡＰＩを呼ぶと、安全ＡＰＩ処理部１１１のメールボックス操作部１２０３あるいは通常ＡＰＩ処理部１１２のメールボックス操作部１３０３が、メッセージキューにメッセージを入れる。タスクが受信ＡＰＩを呼ぶと、安全ＡＰＩ処理部１１１のメールボックス操作部１２０３あるいは通常ＡＰＩ処理部１１２のメールボックス操作部１３０３が、メッセージキュー内のメッセージを、ＡＰＩを呼んだタスクに渡す。メッセージキューの先頭メッセージ１４０１はメッセージキューの先頭メッセージのアドレスを格納する。メッセージキューの最後尾メッセージ１４０２はメッセージキューの最後尾メッセージのアドレスを格納する。

図１４は、本実施例において、安全処理が安全部のカーネルオブジェクトを操作する場合の図７のＳ９００の処理の一例を示すフローチャート図である。本図は、安全ＡＰＩ処理部１１１のメールボックス操作部１２０３が安全部のメールボックスからメッセージを受信する処理を行う例を示す。

メールボックス操作部１２０３は、メールボックスのメッセージキューの先頭メッセージ１４０１あるいはメッセージキューの最後尾メッセージ１４０２を確認し、メールボックスにメッセージが存在するかを判定する(Ｓ９３１)。

メールボックスにメッセージが存在する場合には、メッセージ受信処理を行う(Ｓ９３２)。メッセージ受信処理では、メッセージキューの先頭メッセージ１４０１をメッセージキューから取り外し、ＡＰＩを呼び出したタスクへ返すための処理を行う。

メールボックスにメッセージが存在しない場合には、ＡＰＩを呼び出したタスクは待ち状態に移行する(Ｓ９０７〜Ｓ９１２)。待ち状態の時間制限が指定されていない場合には(Ｓ９０７)、エラー処理を行う(Ｓ９１２)。

図１５は、本実施例において、安全処理が通常部のカーネルオブジェクトを操作する場合の図６のＳ９００の処理の一例を示すフローチャートである。本図は、安全ＡＰＩ処理部１１１のメールボックス操作部１２０３が通常部のメールボックスからメッセージを受信する処理を行う例を示す。

メールボックス操作部１２０３は、メールボックスのメッセージキューの先頭メッセージ１４０１あるいはメッセージキューの最後尾メッセージ１４０２を確認し、メールボックスにメッセージが存在するかを判定する(Ｓ９５１)。メールボックスにメッセージが存在する場合の処理(Ｓ９３２)は、図１５と同様である。

メールボックスにメッセージが存在しない場合、エラー処理を行う(Ｓ９１２)。これは、安全ＡＰＩを呼び出したタスクは、通常部のカーネルオブジェクトを取得する際、待ち状態に移行できないためである。

図１６は、本実施例において、通常処理が通常部のカーネルオブジェクトを操作する場合の図７のＳ１１００の処理の一例を示すフローチャート図である。本図は、通常ＡＰＩ処理部１１２のメールボックス操作部１３０３が通常部のメールボックスからメッセージを受信する処理を行う例を示す。

メールボックスのメッセージキューの先頭メッセージ１４０１あるいはメッセージキューの最後尾メッセージ１４０２を確認し、メールボックスにメッセージが存在するかを判定する(Ｓ１１２２)。メールボックスにメッセージが存在する場合は、メッセージ受信処理を行う(Ｓ１１２３)。メッセージ受信処理では、メッセージキューの先頭メッセージ１４０１をメッセージキューから取り外し、ＡＰＩを呼び出したタスクへ返すための処理を行う。

以上の処理により、カーネルオブジェクトの種類が複数存在していても、カーネルオブジェクトの種類に応じて、タスクの種別とカーネルオブジェクトの種別に依存したスケジューリングの制御が可能となる。これにより、カーネルオブジェクトの種類ごとに、時間的侵害による安全タスクへの、通常部故障の伝播を防ぐスケジューリングを実現することができる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例を含む。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

１００…アプリケーション、１０３…安全タスク、１０４…通常タスク、１１０…OS、１１１…安全ＡＰＩ処理部、１１２…通常ＡＰＩ処理部、１２０…コントロールブロック、１２１…カーネルオブジェクトコントロールブロック、１１５…実行可能状態キュー、１１６…タイマイベントキュー、５０１…待ち行列先頭アドレス、５０３…安全フラグ

Claims (8)

1. アプリケーション処理を実行する計算機システムであって、
   実行要求のあったプログラムが他のプログラムの実行が完了したときに実行するプログラムであった場合、
   実行要求のあったプログラムが安全アプリケーションのプログラムであることを判定する安全判定部と、
   前記安全判定部が実行要求のあったプログラムが安全アプリケーションのプログラムであると判定したとき要求されたプログラムを実行し、
   前記安全判定部が実行要求のあったプログラムが安全アプリケーションのプログラムでないと判定したとき、プログラムの実行待ち行列キューが空であれば要求されたプログラムを実行する安全アプリケーション処理部を備えることを特徴とする計算機システム。
2. 実行要求のあったプログラムが他のプログラムの実行完了を待たないプログラムであった場合、
   前記安全アプリケーション処理部は実行要求のあったプログラムを実行することを特徴とする請求項１に記載の計算機システム。
3. 安全アプリケーション処理部が要求されたプログラムを実行したとき処理結果が正しくなければ処理内容を破棄してプログラムを終了し、処理結果が正しいとき処理内容を破棄せずプログラムを終了することを特徴とする請求項２に記載の計算機システム。
4. 実行要求されたプログラムが通常アプリケーションであることを判定する通常判定部をさらに備え、
   前記通常判定部が実行要求のあったプログラムが通常アプリケーションのプログラムと判定したとき要求されたプログラムを実行し、
   前記通常判定部が実行要求のあったプログラムが通常アプリケーションのプログラムでないと判定したとき、要求されたプログラムを実行しない通常アプリケーション処理部を備えることを特徴とする請求項２に記載の計算機システム。
5. アプリケーション処理を実行する計算機システムの処理方法であって、
   安全判定部は実行要求のあったプログラムが他のプログラムの実行が完了したときに実行するプログラムであった場合、実行要求のあったプログラムが安全アプリケーションのプログラムであると判定し、
   安全アプリケーション処理部は前記安全判定部が実行要求のあったプログラムが安全アプリケーションのプログラムであると判定したとき要求されたプログラムを実行し、
   前記安全判定部が実行要求のあったプログラムが安全アプリケーションのプログラムでないと判定したとき、プログラムの実行待ち行列キューが空であれば要求されたプログラムを実行することを特徴とする計算機システムの処理方法。
6. 実行要求のあったプログラムが他のプログラムの実行完了を待たないプログラムであった場合、前記安全アプリケーション処理部は実行要求のあったプログラムを実行することを特徴とする請求項５に記載の計算機システムの処理方法。
7. 安全アプリケーション処理部が要求されたプログラムを実行したとき処理結果が正しくなければ処理内容を破棄してプログラムを終了し、処理結果が正しいとき処理内容を破棄せずプログラムを終了することを特徴とする請求項６に記載の計算機システムの処理方法。
8. 通常判定部が実行要求されたプログラムが通常アプリケーションであるかどうかを判定し、通常アプリケーション処理部は前記通常判定部が実行要求のあったプログラムが通常アプリケーションのプログラムと判定したとき要求されたプログラムを実行し、
   前記通常判定部が実行要求のあったプログラムが通常アプリケーションのプログラムでないと判定したとき、要求されたプログラムを実行しないことを特徴とする請求項５に記載の計算機システムの処理方法。

Images