JPH10312294A - 情報処理装置、情報処理方法、及び、情報処理プログラムを記録した読み取り可能な記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 システム全体の処理効率を向上させるととも
に、ソフトウェア生産性、保守性を向上させることであ
る。 【解決手段】 ＯＳ４内部における特定条件の成立を保
持する状態フラグ１と、この状態フラグ１が保持する特
定条件に対応した動作を記述する動作記述部２と、この
動作記述部２に記述された動作を実行するためのデータ
を保持する動作キー記述部３と、を有し、動作記述部２
に記述された動作を、動作キー記述部３に記述されたデ
ータを用いて行うようにしてある。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、情報処理装置及び
情報処理プログラムを記録した読み取り可能な記録媒体
に関し、特に、特定の内部状態に対して従属する動作を
効率的に実行させることを可能とし、かつソフトウェア
生産性及び可搬性を向上させることを可能としたソフト
ウェアアーキテクチャを含む情報処理技術に関する。

【０００２】

【従来の技術】一般に、コンピュータシステムに用いら
れるオペレーティングシステム（ＯＳ）の構造は、ソフ
トウェアの可搬性を向上させるため、可能な限り汎用的
な内部ルーチンを持たせることが多い。近年は特に、処
理の効率化というよりはむしろ、システムコールインタ
フェースの統一、あるいは環境に依存した部分の隠蔽を
目的とした共通インタフェースの開発に注力されている
傾向がある。

【０００３】一方、最近のアプリケーションソフトウェ
アの傾向として、規模の巨大化、処理の複雑化がある。
このようにアプリケーションを従来の汎用的なＯＳで処
理する場合、そのままでは早急な応答を保証できなくな
ってきている。また、ＯＳの機能を使用するための手
順、ＯＳ内部状態の変化に伴う振舞いは一般に複雑であ
るため、アプリケーションの変更に柔軟に対応するのは
難しいのが現状である。

【０００４】たとえば、数百個のタスクが存在し、その
優先度がすべて同じ状況を考える。このような状況は、
時分割処理を主体としたプログラムにおいてはよく見ら
れるものである。従来のＯＳでは、これら数百個のタス
クをキュー構造で管理し、そのキューの先頭に繋がれて
いるタスクを実行させるように制御していた。ここで
は、キューの先頭を時分割に変更していくことによって
目的の処理を実現させることを考える。ここで、実行さ
せるタスクがキューの先頭であるということは、ＯＳの
仕様として静的に決められており、変更することは多く
の場合不可能となっている。

【０００５】図２に示すような状況において説明を行
う。図２は、ＬＡＮに接続された装置Ａ，装置Ｂ，装置
ＣがリアルタイムＯＳとその上で動作するタスク群によ
り制御されていることを表している。タスク群にはタス
クＡ，タスクＢ及び、タスクＣが含まれ、それぞれ装置
Ａ，装置Ｂ及び、装置Ｃを制御している。

【０００６】各装置はＬＡＮに接続されている他の装置
との通信で使用されるプロトコルを解釈し、他の装置と
の同期通信を成立させている。ハードウェアの仕様は全
装置で同一とし、それぞれ識別番号で識別されるとす
る。また、装置の接続順序によって装置間に従属関係が
生じると仮定する。すなわち、接続順序が早い装置がマ
スターとなり、その他の装置（スレーブ）に対しての初
期化処理を行う必要性を考慮に入れる。この例では、装
置Ａをマスターとし、装置Ｂ及び、装置Ｃをスレーブと
する。この従属関係は初期化時だけであるので、通常は
時分割で各装置を制御すればよい。このシステムが長期
にわたり稼働するものであれば、装置の電源投入を人間
系が行い、あとは自動制御する実現方法がよくとられ
る。

【０００７】ここで何らかの障害が発生し、各装置にリ
セットがかかったことを想定すると、上記初期化処理が
必要となるため、リアルタイムＯＳは最初の制御をタス
クＡに対して行うようにしなければならない。この場合
にとられる従来のＯＳの動作を図８に示す。まず、次に
行うべき処理を決定する。これにより、次に初期化処理
について行うと判断したものとする（ステップＳ８０
１）。続いて、マスターとなるべきタスクを検索する
（ステップＳ８０２）。これにより、タスクＡがマスタ
ーであると判明したことにする。続いて、今まで実行中
だったタスクをキューの先頭から外して（ステップＳ８
０３）、タスクＡをレディキューの先頭につなぐ（ステ
ップＳ８０４）。続いて、タスクＡ及び実行中のタスク
のコンテキスト格納領域を検索して（Ｓ８０５）、現在
実行中のタスクのコンテキストと、次に実行するタスク
Ａのコンテキストを交換する（ステップＳ８０６）。

【０００８】また、従来のＯＳにおける処理では、実行
するタスクはレディキューの最高優先度部分に繋がって
いるタスクのうち、最初のタスクを見つけだして制御を
移していた。したがって、目的のタスクがキューの先頭
にない場合には、そのタスクを先頭に移動させる必要が
あり、そのために必要以上の処理時間をとられることが
少なくない。この状況を図９に示す。図９は、同一優先
度に３つのタスクが繋がっており、タスクＡを起動させ
るために、キューの順番の変更を最悪２回行う必要が生
じる。すなわち、タスクＡを起動させる場合、キューの
先頭のタスクＡをタスクＢからタスクＣにする変更と、
タスクＣからタスクＡに変更が必要になる。この処理を
図１０に示す。まず、レディキューの先頭のタスクは、
目的のタスクか否かを判断する（ステップＳ１００
１）。目的のタスクが先頭であれば、この処理は終了す
るが、先頭ではない場合には、続いて、キューの最初の
タスクをキューから外し（ステップＳ１００２）、外し
たタスクをキューの最後につなげる（ステップＳ１００
３）。更に、次のタスクをキューにつなぎ替えて（ステ
ップＳ１００４）、これにより先頭になったタスクが目
的のタスクか否かを判断する（ステップＳ１００１）。
以上のような処理を目的のタスクが先頭になるまで続け
る。

【０００９】図１０の処理において、仮にタスクの数が
さらに多いときには、かかる時間もその数に比例して大
きくなる。応答性が要求されるアプリケーションにおい
ては、応答時間の見込みがたたないシステムの適用は困
難であり、ハードウェア、ソフトウェアを機能拡張して
対応する必要が生じてくる。このことはシステム規模の
肥大化を招き保守性を著しく損なうことにつながる。

【００１０】以上のように、発生する複数のイベントの
発生に従ってタスク制御方法を変更する必要が生じた場
合、対応する方法は複雑なものになった。すなわち、数
百個のタスクのつながりをアプリケーション側で起動、
停止しながら、自ら順序を作って制御する必要があり、
数百個分のタスクにおけるソフトウェアの改編が必要と
されるため、作業量が膨大であるばかりでなく、保守
性、信頼性の低下を招く可能性があった。また、この場
合、余計な処理時間が要求されるため、応答性能も低下
してまった。更に、タスクの起動時間の見積もりについ
ても、そのタスクのキュー上の位置で変化するため、設
計時において正確に予測することができないという問題
点があった。

【００１１】次に、アプリケーションに何らかの機能を
追加する必要が生じた際の従来例について説明する。従
来技術では、ＯＳの機能の制限により簡単な拡張では実
現できない場合がある。たとえば、タスクの内容は変更
せず、ある特定の条件下でキューの最後尾にあるタスク
を実行させたいというような場合である。このようなキ
ューの順序を無視してタスクを実行することは従来のＯ
Ｓでは不可能なものがほとんどであったため、別のＯＳ
を使用し、アプリケーションを開発し直すしか方法がな
かった。

【００１２】別の例として、たとえば、バイナリセマフ
ォで管理していた資源を計数型セマフォで管理したいと
いうような状況を考える。一般に、管理すべき資源の数
が増加するというような時に、このような状況が生じ
る。バイナリセマフォを計数型セマフォに変更するため
には、一般に、ＯＳそのものの内部構造を修正する必要
があるため容易ではない。したがって、アプリケーショ
ンプログラムを改造し、対応するのが一般的となってい
る。この場合は資源の数だけセマフォを使用し管理する
ことになるが、セマフォ用の管理領域が大きくなるほ
か、セマフォと資源の対応づけが複雑になるため、プロ
グラムの正当性を保証することが非常に難しくなる。ま
た上述したように、ＯＳの目的の一つとして汎用性を高
めることもあるため、特定のアプリケーションに特化し
た形にＯＳの仕様を変更することも、事実上不可能であ
った。したがって計数型セマフォを持つ別のＯＳを導入
する方法もしばしばとられる。ただし、この場合、ＯＳ
とアプリケーション間のインタフェースも異なってくる
ため、アプリケーション修正に必要な作業量は膨大なも
のとなっていた。

【００１３】次に、ＯＳが提供していない機能をアプリ
ケーションプログラムが使用することになった場合につ
いて、別の例に従って説明する。ここではアプリケーシ
ョンの構成図を図１１のように考える。図１１におい
て、タスク１はリアルタイムＯＳ１上で動作するプログ
ラムであり、実行のためには資源１を必要とすることを
示している。そのためタスク１は、実行の前に資源１を
獲得し、終了すると資源１を解放する処理を行う。ここ
で、資源１の獲得、解放はリアルタイムＯＳ１の機能を
使用することになる。すなわち、タスク１から資源獲得
／解放要求をリアルタイムＯＳ１に対して発行し、リア
ルタイムＯＳからその許可をタスクに与える。また、タ
スク１から発行する資源獲得／解放要求はＯＳの「セマ
フォ」という機能を使用する。

【００１４】一般に、セマフォはバイナリセマフォ、計
数型セマフォの二つに大別される。バイナリセマフォは
資源一つだけに対して排他制御でき、計数型セマフォは
複数の資源を排他制御できる。図１１の例では、ＯＳは
バイナリセマフォを有するとする。資源の数は一つだけ
であるため、システムの動作上、問題は無いことにな
る。図１１におけるタスク１のプログラムを図１２に示
した。

【００１５】ここで、管理する資源の数が増えたことを
想定する。図１３は、管理する資源が１００あり、この
１００の資源に対してタスク１から各資源を管理するも
のとする。複数の資源は、直接、バイナリセマフォでは
管理できないため、従来はアプリケーションプログラム
の変更が必要となった。すなわち、資源の数だけセマフ
ォを用意し、資源の一つ一つに対応づけることになる。
このときのタスク１のプログラムを図１４に示した。図
１４に示すように、資源の数が増えた分、セマフォ獲得
／解放のための処理が必要となる。このことは、プログ
ラムサイズが増大するだけでなく、セマフォ管理領域も
また増大することを示している。処理時間に関しても、
セマフォの数が増えた分、長くなってしまう。この例で
はタスクの数は一つであったが、仮に複数のタスクが同
じ資源にアクセスしようとした場合には、タスクの数だ
けプログラムの修正範囲はさらに広くなる。このこと
は、セマフォ機能に関するアプリケーションプログラム
の修正には、膨大な作業量を伴うことを示している。同
時に、修正後のプログラム実行効率は、資源の数、タス
クの数にしたがって、低下してしまうという問題点もあ
る。

【００１６】上述したことは言い方を替えると、アプリ
ケーションをまったく変更せずに、アプリケーションの
仕様変更要求を満たすことは、従来のＯＳを使用したシ
ステムでは不可能であったといえる。このことは、近
年、爆発的に増大しているソフトウェア資産の活用とい
う観点からみると、非常に非効率的であるといえる。

【００１７】

【発明が解決しようとする課題】上述のごとく、従来の
情報処理装置では、ＯＳの内部処理手順を変更すること
ができないため、例外的なイベントに対応する処理を行
うことが困難であった。また、ＯＳの内部処理に依存し
た部分の処理時間はアプリケーション設計時に見積もる
ことが不可能であった。更に、アプリケーションをまっ
たく変更せずに、アプリケーションの仕様変更を行うこ
とは不可能であった。

【００１８】本発明は、上記事情に鑑みてなされたもの
であり、その目的とするところは、システム内部の状況
に依存する特定の通常のＯＳの処理とは独立に効率よく
実行させ、アプリケーションに依存した処理を容易に記
述する手段をプログラムに提供することによって、シス
テム全体の処理効率を向上させるとともに、ソフトウェ
ア生産性、保守性を向上させることができる情報処理装
置及び情報処理プログラムを記録した読み取り可能な記
録媒体を提供することにある。

【００１９】

【課題を解決するための手段】上記目的を達成するた
め、請求項１の発明は、オペレーティングシステム（Ｏ
Ｓ）の制御に基づいて処理動作を行う情報処理装置にお
いて、前記ＯＳ内部における特定条件の成立を保持する
状態フラグと、この状態フラグが保持する特定条件に対
応した動作を記述する動作記述部と、を有し、前記動作
記述部に記述された動作を行うことを特徴とする。

【００２０】請求項２の発明は、オペレーティングシス
テム（ＯＳ）の制御に基づいて処理動作を行う情報処理
装置において、前記ＯＳ内部における特定条件の成立を
保持する状態フラグと、この状態フラグが保持する特定
条件に対応した動作を記述する動作記述部と、この動作
記述部に記述された動作を実行するためのデータを保持
する動作キー記述部と、を有し、動作記述部に記述され
た動作を、前記動作キー記述部に記述されたデータを用
いて行うことを特徴とする。

【００２１】請求項３の発明は、前記請求項１又は２に
おける前記状態フラグは、前記ＯＳ内部における特定条
件の成立をビットパターンを用いて保持することを特徴
とする。

【００２２】請求項４の発明は、前記請求項１又は２に
おける前記動作記述部は、前記状態フラグが保持する特
定条件に対応した動作を前記ＯＳの内部ルーチンとは異
なったプログラムにより記述することを特徴とする。

【００２３】請求項５の発明は、リアルタイムＯＳとそ
のリアルタイムＯＳ上で動作する複数のタスクとにより
複数の装置の動作を制御する情報処理装置において、前
記リアルタイムＯＳが障害が起きたことを保持する第１
のフラグ、及び、スケジューリングの操作を開始するこ
とを保持する第２のフラグを有する状態フラグと、前記
第１及び第２のフラグが保持する条件に基づいて、対応
する動作を記述する動作記述部と、を有し、前記動作記
述部に記述された動作を行うことを特徴とする。 請求
項６の発明は、リアルタイムＯＳとそのリアルタイムＯ
Ｓ上で動作する複数のタスクとにより複数の資源の排他
制御を行う情報処理装置において、前記複数の資源の排
他制御を行う計数セマフォへ変更可能とする状態を保持
するセマフォ変更フラグを有する状態フラグと、前記セ
マフォ変更フラグが保持する計数セマフォへ変更可能と
する状態に対応した動作を記述する動作記述部と、この
動作記述部に記述された計数セマフォへ変更するための
パラメータを保持する動作キー記述部と、を有し、動作
記述部に記述された動作を、前記動作キー記述部に記述
されたデータを用いて行うことを特徴とする。

【００２４】上記目的を達成するため、請求項７の発明
は、オペレーティングシステム（ＯＳ）の制御に基づい
て処理動作を行う情報処理方法において、前記ＯＳ内部
における特定条件の成立を保持し、この保持した特定条
件に対応した動作を記述しておき、この記述された動作
を行うことを特徴とする。

【００２５】請求項８の発明は、オペレーティングシス
テム（ＯＳ）の制御に基づいて処理動作を行う情報処理
方法において、前記ＯＳ内部における特定条件の成立を
保持し、この保持した特定条件に対応した動作を記述し
ておき、この記述された動作を実行するために保持され
たデータを用いて、前記記述された動作を行うことを特
徴とする。

【００２６】上記目的を達成するため、請求項９の発明
は、オペレーティングシステム（ＯＳ）の制御に基づい
て処理動作を行うコンピュータに用いられる情報処理プ
ログラムを記録した読み取り可能な記録媒体において、
前記ＯＳ内部における特定条件の成立を保持させるステ
ップと、この保持させた特定条件に対応した動作を記述
させるステップと、を有し、前記コンピュータに、前記
動作を記述させるステップにて記述された動作を実行さ
せることを特徴とする。

【００２７】請求項１０の発明は、オペレーティングシ
ステム（ＯＳ）の制御に基づいて処理動作を行うコンピ
ュータに用いられる情報処理プログラムを記録した読み
取り可能な記録媒体において、前記ＯＳ内部における特
定条件の成立を保持させるステップと、この保持させた
特定条件に対応した動作を記述させるステップと、この
記述された動作を実行するためのデータを保持させるス
テップと、を有し、前記コンピュータに、前記動作を記
述させるステップに記述された動作を、前記保持された
動作を実行するためのデータを用いて実行させることを
特徴とする。

【００２８】請求項１１の発明は、前記請求項９又は１
０における前記特定条件の成立を保持させるステップ
は、前記ＯＳ内部における特定条件の成立をビットパタ
ーンを用いて保持することを特徴とする。

【００２９】請求項１２の発明は、前記請求項９又は１
０における前記動作を記述させるステップは、前記保持
された特定条件に対応した動作を前記ＯＳの内部ルーチ
ンとは異なったプログラムにより記述することを特徴と
する。

【００３０】請求項１３の発明は、リアルタイムＯＳと
そのリアルタイムＯＳ上で動作する複数のタスクとによ
り複数の装置の動作を制御するコンピュータシステムに
用いられる情報処理プログラムを記録した読み取り可能
な記録媒体において、前記リアルタイムＯＳが障害が起
きたことを第１のフラグに保持させ、及び、スケジュー
リングの操作を開始することを第２のフラグに保持させ
るステップと、前記第１及び第２のフラグに保持させる
条件に基づいて、対応する動作を記述させるステップ
と、を有し、前記コンピュータに前記記述された動作を
実行させることを特徴とする。

【００３１】請求項１４の発明は、リアルタイムＯＳと
そのリアルタイムＯＳ上で動作する複数のタスクとによ
り複数の資源の排他制御をコンピュータにより実行させ
る情報処理プログラムを記録した読み取り可能な記録媒
体において、前記複数の資源の排他制御を行う計数セマ
フォへ変更可能とする状態をセマフォ変更フラグに保持
させるステップと、前記保持させた計数セマフォへ変更
可能とする状態に対応した動作を記述させるステップ
と、この記述させた計数セマフォへ変更するためのパラ
メータを動作キー記述部に保持させるステップと、を有
し、前記動作記述部に記述された動作を、前記動作キー
記述部に記述されたデータを用いてコンピュータに実行
させることを特徴とする。

【００３２】

【発明の実施の形態】以下、本発明に係る情報処理装置
及び情報処理プログラムを記録した読み取り可能な記録
媒体の実施形態について、図面を参照しながら詳細に説
明する。

【００３３】本実施形態で用いる情報処理装置は、各種
処理を行うための中央処理部と、キーボード、マウス、
ライトペン、又はフレキシブルディスク装置等の入力装
置と、メモリ装置やディスク装置等の記憶装置と、ディ
スプレイ装置、プリンタ装置等の出力装置等とを備えた
通常のコンピュータシステムを用いる。

【００３４】図１は、本実施形態の情報処理装置を概念
的に示した機能ブロック図である。この情報処理装置
は、ＯＳ内部における特定条件の成立を保持する状態フ
ラグ１と、状態フラグ１が保持する特定条件に対応した
動作を記述する動作記述部２と、動作記述部２に記述さ
れた動作を効率的に実行するためのデータを保持する動
作キー記述部３と、を有する。なお、図中の実線で示す
矢印はデータの流れを示している。

【００３５】状態フラグ１は、リアルタイムＯＳ４の内
部状態についてメモリ中のビットパターンを使用して表
している。ビットパターンごとに一つの状態を表現する
ため、例えば、４ビットであれば１６通りの内部状態を
表すことが可能となる。この状態フラグ１のセットは、
リアルタイムＯＳ４がその内部において状態の変化をと
らえて行われる。

【００３６】動作記述部２は、状態フラグ１の各パター
ンに対応したリアルタイムＯＳ４の動作を通常のＯＳの
内部ルーチンとは異なったプログラムにより記述する。
例えば、状態フラグ１のフラグパターンＢに対応する動
作については、動作記述部２の動作プラグパターンＢに
対応した動作２に記述するようにする。

【００３７】動作キー記述部３は、動作記述部２に記述
される各動作に対応したキー項目を保持する。このキー
項目は各動作を効率的に実行するためのヒントとなるも
ので、タスクのアドレス、メッセージ等、アプリケーシ
ョンプログラムに依存したデータが格納される。

【００３８】リアルタイムＯＳ４は、状態フラグ１で表
されるＯＳの内部状態になった場合、動作記述部２の内
容に従ってプログラム実行を行う。

【００３９】次に、本実施形態における第１の具体例を
説明する。図２は、ＬＡＮに接続された装置Ａ，装置Ｂ
及び、装置ＣがリアルタイムＯＳとその上で動作するタ
スク群により制御されていることを表している。タスク
群にはタスクＡ，タスクＢ及び、タスクＣが含まれ、そ
れぞれ装置Ａ，装置Ｂ及び、装置Ｃを制御している。

【００４０】各装置Ａ，Ｂ及び、Ｃは、ＬＡＮに接続さ
れている他の装置との通信で使用されるプロトコルを解
釈し、他の装置との同期通信を成立させている。ハード
ウェアの仕様は全装置で同一とし、それぞれ識別番号で
識別されるとする。また、装置の接続順序によって装置
間に従属関係が生じると仮定する。すなわち、接続順序
が早い装置がマスターとなり、その他の装置（スレー
ブ）に対しての初期化処理を行う必要性を考慮に入れ
る。この例では、装置Ａをマスターとし、装置Ｂ及び、
装置Ｃをスレーブとする。この従属関係は初期化時だけ
であるので、通常は時分割で各装置を制御すればよい。
このシステムが長期にわたり稼働するものであれば、装
置の電源投入を人間系が行い、あとは自動制御する実現
方法がよくとられる。具体的にはリアルタイムＯＳ上の
各タスクは時間的に均等に実行され、各装置のための制
御を行う。タスクの構造はほとんど同一でよいため、こ
のシステムの開発に必要な工数は少なくて済む。この場
合のリアルタイムＯＳの内部動作のフローチャートを図
３に示す。まず、レディーキューの最初につながってい
るタスクを検索し（ステップＳ３０１）、そのタスクの
コンテキスト格納領域を検索して（ステップＳ３０
２）、現在続行中のタスクのコンテキストと、次のタス
クのコンテキストを交換する（ステップＳ３０３）。こ
のように、本実施形態におけるリアルタイムＯＳの処理
は、従来例で同様の処理を説明した図８に比較して、よ
り少ない処理で実現が可能となるため、システム全体の
処理効率を向上させるとともに、ソフトウェア生産性、
保守性を向上させることができる。

【００４１】次に、図３のようなリアルタイムＯＳが実
行するための本実施形態の具体例を説明する。まず、何
らかの障害が起きたというイベントおよびＯＳがこれか
らスケジューリングの操作をするというフラグをＯＳが
セットする機構を用意する。この具体例における状態フ
ラグの例を図４に示す。この具体例で必要なフラグは、
障害が発生したか否かの状態を表すフラグ（１ビット）
と、スケジューリング開始を表すフラグ（１ビット）で
ある。障害が発生したか否かの状態を表すフラグは、障
害発生の割込みハンドラ実行の時点で、また、スケジュ
ーリング開始を表すフラグは、初期化処理が必要だと判
定できた時点で、それぞれフラグがセットされる。

【００４２】この具体例の動作記述部２及び動作キー記
述部３を図５に示す。また、本実施形態の処理の流れを
図６に示す。まず、想定しているフラグパターンはセッ
トされているか否かを判定する（ステップＳ６０１）。
このフラグパターンのチェックは、リアルタイムＯＳ内
部に設けられたチェックポイントにて行う。このチェッ
クポイントは、比較的長い間処理を中断することができ
ない場所、例えば、ＯＳ内部のクリティカルセクション
及び割込み禁止区域等の前に静的に設けられる。この具
体例では、スケジューラを実行する直前において状態フ
ラグのチェックが行われる。

【００４３】状態フラグ１のチェック終了後、リアルタ
イムＯＳ４は、この状態フラグ１に対応した動作記述部
の内容に従って動作する。この際、動作キーにかかれて
いる項目を利用する（ステップＳ６０２）。この具体例
では、フラグパターン“１１００００００”に対応した
動作記述部の内容を読み込み、実行する。すなわち、フ
ラグがセットされていると判断した時点で実行中のタス
クを停止させ、タスクＡに制御を移すことを行う。

【００４４】以上のように、本実施形態では、動作記述
部２に特定タスクを起動する命令を記述することによっ
て、特定の状況下での応答性を高める。この例では、動
作記述部２に対応した動作キー記述部３から、タスクＡ
のコンテキストを格納してある領域のアドレスを読み出
し、そのアドレスから実行させるように動作記述部２に
記述する。これにより、状態フラグで想定するイベント
に関して、その後の処理を効率よく行うことができる。
またその処理時間には不確定要素がないため、厳しい時
間制約を課せられたアプリケーションの構築指針を容易
に立てることが可能となる。

【００４５】次に、本実施形態の第２の具体例につい
て、図面を参照しながら詳細に説明する。この実施形態
では、リアルタイムＯＳが提供していない機能をアプリ
ケーションプログラムが使用することになった場合に、
アプリケーションプログラムにまったく手を入れずに、
仕様変更に対応することができる実施形態について説明
する。

【００４６】この具体例を従来例で説明を行った図１１
を用いて説明する。同図において、タスク１はリアルタ
イムＯＳ１上で動作するプログラムであり、実行のため
には資源１を必要とすることを示している。この場合に
は、状態フラグ１にセマフォ変更フラグを設ける。セマ
フォ変更フラグに対して、セマフォ機能に変更ありとい
うフラグをセットする。このセットは、あらかじめシス
テムのコンフィグレーション時に静的に行ってもよい
し、システムの中のタスクにセットさせてもよい。ま
た、リアルタイムＯＳは、すでに状態フラグによって処
理を分岐できる構造で実装されているものとする。

【００４７】状態フラグ１がセットされた後、タスクを
実行し、セマフォへのアクセスのための命令をＯＳに対
して行った場合、その処理は動作記述部２における対応
した場所に記述されている動作になる。この場合、動作
記述部２には計数型セマフォを実現するためのプログラ
ムが記述される。動作記述部２に渡されるパラメータを
動作キー記述部３に格納することによって、動作記述部
２の内容に汎用性を持たせることもできる。このこと
は、動作キー記述部３は、アプリケーションと動作記述
部２間におけるインタフェースの役割を担うこともでき
ることを示している。

【００４８】図７に、この場合の処理のフローチャート
を示す。まず、リアルタイムＯＳ４は、タスクからセマ
フォ獲得要求受付を行う（ステップＳ７０１）。ここ
で、セマフォへ変更フラグが立っているか否かを判定す
る（ステップＳ７０２）。セマフォ変更フラグが立って
いる場合には、動作記述部２に記述された動作記述の実
行を行う（ステップＳ７０４）。セマフォ変更フラグが
立っていない場合には、通常のセマフォ処理を行う（ス
テップＳ７０３）。

【００４９】以上のように、アプリケーションプログラ
ムの変更はまったく必要ないため、ソフトウェア資産を
有効に活用することができる。一方で、動作記述部２に
ＯＳの動作を決定するプログラムを記述することによっ
て、ＯＳのオプション動作を明確に部品化することもで
きる。ここでは、計数型セマフォを実現する効率的なコ
ードを記述することによって、プログラムの実行効率、
メモリ効率を向上させることも可能となる。

【００５０】なお、上述した情報処理を実現するための
プログラムは記録媒体に保存することができる。この記
録媒体をコンピュータシステムによって読み込ませ、前
記プログラムを実行してコンピュータを制御しながら上
述した情報処理を実現することができる。ここで、前記
記録媒体とは、メモリ装置、磁気ディスク装置、光ディ
スク装置等、プログラムを記録することができるような
装置が含まれる。

【００５１】

【発明の効果】以上説明したように、本発明に係る情報
処理装置及び情報処理プログラムを記録した読み取り可
能な記録媒体によれば、以下の点においての効果が見込
まれる。

【００５２】まず、従来、システム内部の状態に依存し
ていた特定の処理を、内部状態とは独立に効率よく実行
することが可能となる。したがって、システム全体のパ
フォーマンスが向上するだけでなく、アプリケーション
設計時に予測することの困難な、可変的頻度の事象に対
して、簡単に対策を用意することが可能となる。これ
は、ソフトウェア生産性の向上が可能であることにも通
ずる。

【００５３】また、アプリケーションの処理時間をアプ
ケーション設計時に見積もることが可能となるため、従
来よりも合理的なシステム開発を行うことが可能とな
る。

【００５４】また、従来、ＯＳが提供する機能の制限に
より、実現することのできなかった処理をアプリケーシ
ョン側で容易に実現することが可能となる。このことに
より、一つのＯＳを適用できる範囲が多くなることが見
込まれる。このことは、従来異なったシステムごとに、
その都度習得しなければならなかったＯＳの数を減らす
ことが可能となることを指し、開発工程の短縮だけでな
く技術者教育等にかかるコストの削減をも実現すること
が可能であることを示している。

【００５５】更に、従来、アプリケーションプログラム
を変更することで対応していた、アプリケーションプロ
グラムの仕様変更を、アプリケーションプログラムの変
更無しに対応することができる。

【図面の簡単な説明】

【図１】本実施形態の情報処理装置を示すブロック図で
ある。

【図２】本実施形態の情報処理装置の第１の具体例を示
す図である。

【図３】図２に示す具体例における処理のフローチャー
トを示す図である。

【図４】状態フラグの例を示す図である。

【図５】動作記述部及び動作キー記述部の例を示す図で
ある。

【図６】本実施形態の情報処理装置の動作を示すフロー
チャートである。

【図７】本実施形態の情報処理装置の第２の具体例を示
す図である。

【図８】図２に示す具体例の従来例による処理のフロー
チャートを示す図である。

【図９】レディキューを説明するための図である。

【図１０】レディキューに繋がれているタスクの順番を
変更する処理のフローチャートを示す図である。

【図１１】タスク１が単数の資源を獲得、解放する場合
を説明するための図である。

【図１２】図１１のタスク１のプログラムの抜粋を示す
図である。

【図１３】タスク１が複数の資源を獲得、解放する場合
を説明するための図である。

【図１４】図１３のタスク１のプログラムの抜粋を示す
図である。

【符号の説明】

１ 状態フラグ ２ 動作記述部 ３ 動作したキー記述部 ４ リアルタイムＯＳ

Claims (14)

【特許請求の範囲】
1. 【請求項１】 オペレーティングシステム（ＯＳ）の制
   御に基づいて処理動作を行う情報処理装置において、 前記ＯＳ内部における特定条件の成立を保持する状態フ
   ラグと、 この状態フラグが保持する特定条件に対応した動作を記
   述する動作記述部と、 を有し、前記動作記述部に記述された動作を行うことを
   特徴とする情報処理装置。
2. 【請求項２】 オペレーティングシステム（ＯＳ）の制
   御に基づいて処理動作を行う情報処理装置において、 前記ＯＳ内部における特定条件の成立を保持する状態フ
   ラグと、 この状態フラグが保持する特定条件に対応した動作を記
   述する動作記述部と、 この動作記述部に記述された動作を実行するためのデー
   タを保持する動作キー記述部と、 を有し、動作記述部に記述された動作を、前記動作キー
   記述部に記述されたデータを用いて行うことを特徴とす
   る情報処理装置。
3. 【請求項３】 前記状態フラグは、 前記ＯＳ内部における特定条件の成立をビットパターン
   を用いて保持することを特徴とする請求項１又は２記載
   の情報処理装置。
4. 【請求項４】 前記動作記述部は、 前記状態フラグが保持する特定条件に対応した動作を前
   記ＯＳの内部ルーチンとは異なったプログラムにより記
   述することを特徴とする請求項１又は２記載の情報処理
   装置。
5. 【請求項５】 リアルタイムＯＳとそのリアルタイムＯ
   Ｓ上で動作する複数のタスクとにより複数の装置の動作
   を制御する情報処理装置において、 前記リアルタイムＯＳが障害が起きたことを保持する第
   １のフラグ、及び、スケジューリングの操作を開始する
   ことを保持する第２のフラグを有する状態フラグと、 前記第１及び第２のフラグが保持する条件に基づいて、
   対応する動作を記述する動作記述部と、 を有し、前記動作記述部に記述された動作を行うことを
   特徴とする情報処理装置。
6. 【請求項６】 リアルタイムＯＳとそのリアルタイムＯ
   Ｓ上で動作する複数のタスクとにより複数の資源の排他
   制御を行う情報処理装置において、 前記複数の資源の排他制御を行う計数セマフォへ変更可
   能とする状態を保持するセマフォ変更フラグを有する状
   態フラグと、 前記セマフォ変更フラグが保持する計数セマフォへ変更
   可能とする状態に対応した動作を記述する動作記述部
   と、 この動作記述部に記述された計数セマフォへ変更するた
   めのパラメータを保持する動作キー記述部と、 を有し、動作記述部に記述された動作を、前記動作キー
   記述部に記述されたデータを用いて行うことを特徴とす
   る情報処理装置。
7. 【請求項７】 オペレーティングシステム（ＯＳ）の制
   御に基づいて処理動作を行う情報処理方法において、 前記ＯＳ内部における特定条件の成立を保持し、 この保持した特定条件に対応した動作を記述しておき、
   この記述された動作を行うことを特徴とする情報処理方
   法。
8. 【請求項８】 オペレーティングシステム（ＯＳ）の制
   御に基づいて処理動作を行う情報処理方法において、 前記ＯＳ内部における特定条件の成立を保持し、 この保持した特定条件に対応した動作を記述しておき、
   この記述された動作を実行するために保持されたデータ
   を用いて、前記記述された動作を行うことを特徴とする
   情報処理方法。
9. 【請求項９】 オペレーティングシステム（ＯＳ）の制
   御に基づいて処理動作を行うコンピュータに用いられる
   情報処理プログラムを記録した読み取り可能な記録媒体
   において、 前記ＯＳ内部における特定条件の成立を保持させるステ
   ップと、 この保持させた特定条件に対応した動作を記述させるス
   テップと、 を有し、前記コンピュータに、前記動作を記述させるス
   テップにて記述された動作を実行させることを特徴とす
   る情報処理プログラムを記録した読み取り可能な記録媒
   体。
10. 【請求項１０】 オペレーティングシステム（ＯＳ）の
    制御に基づいて処理動作を行うコンピュータに用いられ
    る情報処理プログラムを記録した読み取り可能な記録媒
    体において、 前記ＯＳ内部における特定条件の成立を保持させるステ
    ップと、 この保持させた特定条件に対応した動作を記述させるス
    テップと、 この記述された動作を実行するためのデータを保持させ
    るステップと、 を有し、前記コンピュータに、前記動作を記述させるス
    テップに記述された動作を、前記保持された動作を実行
    するためのデータを用いて実行させることを特徴とする
    情報処理プログラムを記録した読み取り可能な記録媒
    体。
11. 【請求項１１】 前記特定条件の成立を保持させるステ
    ップは、 前記ＯＳ内部における特定条件の成立をビットパターン
    を用いて保持することを特徴とする請求項９又は１０記
    載の情報処理プログラムを記録した読み取り可能な記録
    媒体。
12. 【請求項１２】 前記動作を記述させるステップは、 前記保持された特定条件に対応した動作を前記ＯＳの内
    部ルーチンとは異なったプログラムにより記述すること
    を特徴とする請求項９又は１０記載の情報処理プログラ
    ムを記録した読み取り可能な記録媒体。
13. 【請求項１３】 リアルタイムＯＳとそのリアルタイム
    ＯＳ上で動作する複数のタスクとにより複数の装置の動
    作を制御するコンピュータシステムに用いられる情報処
    理プログラムを記録した読み取り可能な記録媒体におい
    て、 前記リアルタイムＯＳが障害が起きたことを第１のフラ
    グに保持させ、及び、スケジューリングの操作を開始す
    ることを第２のフラグに保持させるステップと、 前記
    第１及び第２のフラグに保持させる条件に基づいて、対
    応する動作を記述させるステップと、 を有し、前記コンピュータに前記記述された動作を実行
    させることを特徴とする情報処理プログラムを記録した
    読み取り可能な記録媒体。
14. 【請求項１４】 リアルタイムＯＳとそのリアルタイム
    ＯＳ上で動作する複数のタスクとにより複数の資源の排
    他制御をコンピュータにより実行させる情報処理プログ
    ラムを記録した読み取り可能な記録媒体において、 前記複数の資源の排他制御を行う計数セマフォへ変更可
    能とする状態をセマフォ変更フラグに保持させるステッ
    プと、 前記保持させた計数セマフォへ変更可能とする状態に対
    応した動作を記述させるステップと、 この記述させた計数セマフォへ変更するためのパラメー
    タを動作キー記述部に保持させるステップと、 を有し、前記動作記述部に記述された動作を、前記動作
    キー記述部に記述されたデータを用いてコンピュータに
    実行させることを特徴とする情報処理プログラムを記録
    した読み取り可能な記録媒体。