JPH10502473A - リアルタイム非同期ソフトウェア・アプリケーションにおいて階層呼び出し構造を実施する方法 - Google Patents

Abstract

(57)【要約】 別のコード単位による、アプリケーションのコード単位の各呼び出しの間に、カーネル操作を実行することによって、上方向のコールを防止する階層呼び出し構造を強制するカーネル。カーネル操作は前記階層的な呼び出し構造に基づいて、呼び出しを行っているコード単位の優先順位を判定する。より低い優先順位の単位、又はその単位自身による呼び出しだけが許可される。一旦呼び出されると、カーネルは、呼び出されたタスクに関して優先順位を確立するよう動作する。カーネルは様々なイベント・メカニズムを提供し、強制された呼び出し構造と一致する強制排除に基づいた優先順位を提供する。従って、カーネルはマルチタスキング環境で、非同期イベントの処理を可能とする。イベント・メカニズムは、コード単位が条件の発生を通知できるようにし、これは、他のコード単位によって把握されうる。カーネルはその条件に応答するのにふさわしいコード単位を判定し、処理操作を更に定義するために、範囲ルールを使用する。スケジューリング、及びタスキング・メカニズムは、条件の処理をスケジュールし、優先付けられた基準でイベントの処理をタスク指名する。

Description

【発明の詳細な説明】 リアルタイム非同期ソフトウエア・アプリケーションにおいて 階層呼び出し構造を実施する方法 発明の背景 発明の技術分野 本発明は一般にソフトウエア・アーキテクチャに関し、より詳しくは、ソフト ウエア・アプリケーションにおいてリアルタイムの会話を制御するカーネルを使 用する方法に関する。 背景技術の説明 ソフトウエア・アプリケーションは伝統的にリアルタイム・アプリケーション と非リアルタイム・アプリケーションに分けられてきた。非リアルタイム・アプ リケーションは、スプレッドシート、ワープロ、グラフィック設計プログラム等 のような、従来の単一ユーザ・プログラムに含まれる。一定の時間に依存する性 能基準を満足させなければならない物理装置を制御するソフトウエア・アプリケ ーションは伝統的にリアルタイム・アプリケーションであると考えられており、 それは飛行制御システム、工業処理制御プログラム等のアプリケーションを含む ものである。 ソフトウエア・アプリケーションをリアルタイムと非リアルタイムのカテゴリ に分割することは、通常そのアプリケーションによって要求される動作が、制御 の単一スレッドの中で実行されるべきか どうかに基づいている。従来より、制御の様々なスレッドに関して別のローカル 記億域を提供するために、リアルタイム・アプリケーションのクラスに関してマ ルチタスキングが用いられている。マルチタスキング・カーネルは、複数の制御 のスレッドの生成、及び同期のためのメカニズムを提供し、それ以外はタスク、 又はプロセスとして知られている。制御のスレッドのそれぞれに関するローカル 記憶域は通常、スタックの形態をとる。スタックは、通常ほとんどのコンピュー タの命令セットに提供されるメカニズムである。スタックによって、複数のコー ド・シーケンスからのサブルーチン呼び出しが可能になる。呼び出しコード・シ ーケンスの戻りアドレスがスタック上にプッシュされ、即ち記憶される。サブル ーチンが完了すると、そのアドレスがスタックからポップされ、即ち除去され、 呼び出しコード・シーケンスからのコードの実行が続けられる。リアルタイム・ アプリケーションを作成するために使用されるマルチタスキング・プログラミン グ環境は複数のスタックを提供する一方、従来のプログラミング環境は単一スタ ックを提供する。マルチタスキングは通常、リアルタイム・プログラミングに必 要と考えられているが、ソフトウエアは各タイプのプログラミング環境内でリア ルタイム・イベントに応答するよう構築されうる。 より洗練されたソフトウエア・アプリケーションを作成することは、リアルタ イム・アプリケーションと非リアルタイム・アプリケーションの間の従来の制限 を不鮮明にする。洗練された単一ユーザ・アプリケーションは、ユーザ入力を待 つ間バックグラウンド・プ ロセシング（スプレッドシートの再計算のような）を実行するかもしれない。こ こで、マルチタスキング、及び非マルチタスキング環境両方におけるソフトウエ ア開発において、解決が必要な一般的問題は、いかにして、ユーザ入力、外部イ ベント、又はデータ・アクセスのようなある条件を、他の目的のための処理命令 が続けられている間で「待機する」ことができるソフトウエア命令を書くか、つ まり、いかにソフトウエア・アプリケーションによって実行されている様々な処 理やタスクに関して複数の、制御のスレッドを提供するかということである。 最も単純な待機の問題に対する解決策は、一時点で１つの条件に関してのみ待 機するようなプログラムを構築することである。例として、単純な抵当償却プロ グラムが、利率、支払額等の入力をユーザに促し、そのそれぞれの値の入力を待 って次の値の入力を促す、制御の単一スレッドで書かれうる。この単純なプログ ラム構造は、現存のソフトウエア・アプリケーションの多くの部分に対し十分な ものである。しかし、アプリケーションの性質が、複数で非同期に発生する条件 を処理する必要のある場合には、この構造では十分でない。 単一スタック環境用に書かれたプログラムは、何度も起こるリアルタイム・イ ベントをいくつかの異なる方法で処理することができる。リアルタイムの条件を 処理するための一つの可能な単一スタック・プログラム構造は、イベントのある 種のソート、またはメッセージ・ベースのカーネルの使用を必要とし、非同期条 件に応答して コードのタスク指名(dispatch)を処理する。こうしたアプリケーションに関して は、アプリケーションの主要部は、様々なメッセージやイベントを再入可能に処 理できなければならないイベント、又はメッセージ・ハンドラからなる。マイク ロソフトのウインドウズ、またはアップルのマッキントッシュのオペレーティン グ・システムが、このタイプのプログラミング環境を提供しているので、このプ ログラム構造は、グラフィカル・ユーザ・インタフェース・ベースの多くのアプ リケーションでは代表的なものである。様々なカーネルのアーキテクチャは、メ ッセージの待ち行列化、及び／又はメッセージ処理の優先順位付けを含むことが できる。 アプリケーションとオペレーティング・システムの間でのメッセージングに基 づく、現在使用されている全てのカーネル・アーキテクチャは、２つの顕著な問 題点を有する傾向が強い。図1Aは、システム・カーネル93からのメッセージを介 してそのカーネルと対話しているアプリケーション91と、そのアプリケーション 91からコールするアプリケーション・プログラミング・インタフェース97との間 の基本的な関係を概略的に示す図である。第１の顕著な問題は無制限の再帰の問 題である。カーネル93からのメッセージＭが、アプリケーション91のカーネル機 能Ｆのコールの結果生成され、カーネル機能Ｆが別のメッセージＭを生成する場 合、このシーケンスがそれ自身を無限に繰り返す可能性があり、最終的にスタッ クを物理制限まで使い果たすことになる。 第２の問題は非再入コードとして知られ、通常は無制限の再帰よ り大きく関係する。前述の例において、カーネル機能Ｆは、その機能の最初の呼 び出しが終了する前に、アプリケーション91から２度コールされうる。その機能 が再入するようコード化されていない場合、これはプログラミング・エラーとな る可能性がある。更に、アプリケーション91内のメッセージ・ハンドラ機能も、 この再入の影響を受ける。無制限の再帰の問題と非再入コードの問題はまた、コ ードの個々の単位が実行プロセスの間で互いに呼び出しを行うアプリケーション の内部構造に関連して発生する。現在、アプリケーション内、またはアプリケー ションとオペレーティング・システムの間で、こうした問題が発生しないことを 保証する唯一の方法は、アプリケーション開発者による細心のプログラミングで ある。 従って、プログラマから無制限の再帰の問題と非再入コードの問題を避けるた めの負担を取り除く、これらの問題を抑止するためのメカニズムを提供すること が望ましい。 問題の第２のクラスは、リアルタイム・イベントを処理するために、複数の非 同期プロセスを処理する必要がある場合に発生する。単一スタック環境における アプリケーションは、他の全てのイベント及びメッセージ処理を遅延させる好ま しくない影響を有することなく、単に特定のイベント、又はメッセージを待つよ うに構築することができない。非同期で発生する条件を確実に処理しようとする 、全ての単一スタック実施に共通の一つの好ましくない結果は、これらのアプリ ケーションが状態駆動型でなければならないことである。状態駆動型アプリケー ションは、変数を設定することによって現在 のプログラム状態を記憶し、メッセージを受信した際に、これらの変数の状態が アプリケーションによって取られる動作を判定する。状態駆動型アプリケーショ ンにおける問題は、条件の待機を処理するように適切に書くことが非常に困難で あり、それによって無制限の再帰と非再入コードの発生する可能性が高くなるこ とである。従って、条件の待機を処理する面での大きな利便性から、マルチタス キングが使われる。 マルチタスキングによって、コードは多数でバラバラの待機操作で構成できる が、この柔軟性は複雑さが増すという代償を備えている。再帰及び再入という２ 重の問題に加えて、マルチタスキングの実例は、危険地域(critical section)の 複雑さを増加させ、デッドロックを招く。デッドロックは、２つのプロセスが実 行を継続するために、互いに他方のプロセスによる動作を待つ場合に起きる。危 険地域は、複数のスレッドによって現在実行されればエラーとなる可能性のある 、コードの個別セグメントである。これらの問題は当業者には周知であり、こう した問題を回避する技法は、多くの研究の対象となってきた。しかし、再入と再 帰の問題のために、こうした問題の最終的な検出及び訂正は、プログラマによる 注意深いコーディングに依存する。 ソフトウエア・バグという用語は、プログラミングの問題とエラーのある実行 時条件の発生の両方を示すためによく使用される。正しくないコード・シーケン スに対する、より正確な用語はプログラム障害(program fault)である。プログ ラム不良(program failure) は、コードの実行中のプログラム障害を表現するものである。 無制限の再帰、非再入、デッドロック、及び危険地域の問題は、一時的な不良 を引き起こす。これらの問題は、それらがアプリケーションの単一実行の際、又 は複数の実行の際でさえ、必ずしも発生するものではなく、むしろ、典型的には 繰り返された実行の後で、アプリケーションの単位の間での会話が特定の方法で 行われる場合にのみ発生する。 これらの４つのタイプのプログラミング・エラーは、周期的エラーと呼ばれる プログラミング・エラーのクラスに属する。これらの周期的エラーは、ソフトウ エア・アプリケーションの呼び出し構造に対しトレースされうる。呼び出し構造 は、アプリケーションの単位の間の関係を順序づけ、コールするものである。呼 び出し構造は有向グラフによって示される。図1Bは、６つのコード単位Ａないし Ｆを含むソフトウエア・アプリケーション91の呼び出し構造の、有向グラフを示 す。ある単位から別の単位に向かう矢印は、実行中に発信単位が受信単位に１つ 以上の手順コールを呼び出したことを示す。ここで、図1Bにおいて、単位Ａから 単位Ｂ、更に単位Ｅに命令実行が進みうるが、単位Ｄから単位Ｃへの命令の進行 は明らかにない。 伝統的設計のソフトウエア・アプリケーションは、下向きの矢印によって示さ れている手順の呼び出しを有する、純粋に階層的なアプリケーションに非常に近 いことが多い。しかし、非同期イベントを処理する必要性の高まりによって、こ の階層的な呼び出し構造は 徐々に移動され、単位間のコールが次第に非階層的になってきた。これは、単位 Ｅから単位Ａへのコール103のような上方向コールによって示される。この上方 向コールは、有向グラフ内で周期(コール101、109、103)を作り出す。あるノー ドからそれ自身に戻る、矢印の方向に従う経路がある場合、有向グラフ内には周 期が存在する。図1Bの有向グラフに示された呼び出し構造においては、上方向コ ール103が経路、または単位Ａがそれ自身を呼び出すことのできる手順コールの 組を生成するので、周期が存在する。コールI01、109、及び103の間の図1B内の 周期は、非再入と無制限の再帰に２重に関連する。同様に、デッドロックの可能 性を検出することもでき、ここでは単位Ｄ及び単位Ｅの間のコール115及び117を 有する周期によって示され、各単位は一方を実行中にコールする。単位Ｂ及び単 位Ｃは、それらが論理的には同時に単位Ｅをコールできないので、危険地域とな りうる。周期を生成するのは、主として呼び出し構造内の上方向コールの存在で ある。呼び出し構造内にある周期は、周期的エラーが存在することを例示するも のではなく、こうしたバグがアプリケーションの実行の間に起こりうることを示 している。 周期のない、有向グラフが、非周期有向グラフとして知られており、それは純 粋な階層化グラフを示す。純粋な階層化呼び出し構造は周期エラーの可能性を除 去するが、リアルタイム性能に関して必要な非同期イベントを処理するための伝 統的な技法の使用を妨げる。それは、これらのイベントが現在、単一スタック環 境の上方向コールで、又はマルチタスク環境の優先順位ベースの強制排除(preem pt ion)によって処理されているためである。こうしたタイプのプログラミング方法 は純粋に階層的な構造を強制せず、従って、周期エラーの可能性を許容すること になる。現在、リアルタイム・アプリケーションのアプリケーション開発に適用 可能で、一時的な不良を防止する、共用プログラミング方法論はない。更に今日 、使用時にこうしたプログラミング方法論を強いるメカニズムはない。 前述のことから、アプリケーション・プログラミングに非同期イベントをリア ルタイムに処理するための動作を可能にしつつ、そのプログラムの呼び出し構造 において純粋な階層を作成する方法を使用して、ソフトウエア・アプリケーショ ンが開発されることは、そのソフトウエア・アプリケーションの動作にとって有 利なことである。階層構造でソフトウエア・アプリケーションを単に開発するこ とは、周期的なエラーの発生を防止するには十分であるが、実行時にその構造を 強いる外部メカニズムがない場合、その階層呼び出し構造から導かれる利点を保 証する道はない。 従って、実際の実行時操作で階層呼び出し構造を強要し、それによって周期的 なエラーを除去するという形で階層呼び出し構造の利点を保証する、単一スタッ ク、または複数スタック・プログラミング開発環境のどちらにおいても使用でき るソフトウエア・カーネルを提供することが望ましい。 更に、呼び出し階層の強制は、強制排除コードを処理するための従来のメカニ ズムを妨げるので、強制階層呼び出し構造と共存しながら、強制排除と並行処理 を提供するカーネルを提供することが好 ましい。こうしたメカニズムは、アプリケーション内で単一の制御のスレッドを 保持する機能を備えることが好ましい。 本発明の概要 本発明は、アプリケーションを含む構成要素（コンテキスト）の間の階層呼び 出し構造を強制する方法、アプリケーション内で制御の単一スレッドを保証する 方法、及びイベント・ルーチンを含むコンテキストの優先順位に基づいてイベン ト・ルーチンの優先順位付けされた実行を提供する方法からなる。階層呼び出し 構造を強制する方法の実施例は、呼び出しコンテキストによる呼び出されたコン テキストの呼び出しを示すステップ、呼び出しコンテキストの実行優先順位を判 定するステップ、及び呼び出されたコンテキストの実行優先順位が呼び出しコン テキストの実行優先順位より高い場合に、その呼び出しを許可するステップを含 んでいる。各コンテキストが、関連する実行優先順位を有しているので、より低 い実行優先順位を有するコンテキストだけが、より高い実行優先順位を有するコ ンテキストを呼び出すことができる。このことは、上述のような、様々な周期的 エラーにつながる上方向コールを防止する。この方法は、複数スタック、または 単一スタック・プログラミング環境のどちらでも実施可能で、またマイクロプロ セッサの命令セットに含むこともできる。 更に本発明の方法を洗練するために、呼び出しコンテキストの実行優先順位を 判定するステップは、コンテキストがそれ自身を呼び出しているかどうかを判定 し、呼び出されたコンテキストの優先順 位が呼び出しコンテキストの優先順位より高いかどうかを判定するステップを含 む。これらのステップは、呼び出しコンテキストの性質に基づいて、その呼び出 しの代替的な処理を提供する。更に本発明の方法を洗練するために、制御の戻り を呼び出しコンテキストに対して許容するために、呼び出しコンテキストのイン ジケータを記憶し、呼び出されたコンテキストの実行優先順位に基づいて呼び出 されたコンテキスト内のイベント・ルーチンに関する実行優先順位を確立し、及 び呼び出されたコンテキストの実行レベルを上げるステップを更に含む、呼び出 しを許可するステップが提供される。これらのステップは、再帰レベルの制御、 及び現在活動している様々なコンテキストの実行優先順位を確立するためのメカ ニズムを提供する。 本発明はまた、アプリケーションが多くのコンテンツを含む場合、コンテキス ト内に制御の単一スレッドを強制する方法も提供する。その方法は、ルーチンを 実行するためのコンテキストを判定し、ルーチンを実行するためのコンテキスト 内に制御の活動スレッドが存在するかどうか判定し、次に、そのコンテキストが 制御の活動スレッドをもはや持たなくなるまで、そのコンテキストによってルー チンの実行を遅らせる。そのコンテキストが制御の活動スレッドをもはや持たな くなったとき、そのルーチンの実行は続けられる。 本発明はまた、アプリケーション内の多くのコンテキスト内のスケジュールさ れたイベント・ルーチンの実行を、コンテキスト内のイベント・ルーチンをスケ ジューリングすることによって優先順位 付け、次に、そのコンテキスト内に制御の活動スレッドがあるかどうかを判定す る。そのコンテキスト内に制御の活動スレッドがない場合、本発明の方法は、コ ンテキストの実行優先順位と同じ実行優先順位を、スケジュールされたイベント ・ルーチンを実行するためのタスクに割り当てる。次に、スケジュールされたイ ベント・ルーチンを実行するためのタスクが起動される。本発明の方法を洗練す るために、イベント・ルーチンは、イベントの発生とそのイベントをコンテキス トによって処理する要求を示すことによってスケジュールされる。次にこの方法 は、そのイベントを処理するためのコンテキストを判定し、処理するためのコン テキスト内にイベント・ルーチンがある場合、方法はタスクによる実行に関し、 そのイベント・ルーチンを指定する。そのタスクは、処理するためのコンテキス トの実行優先順位に基づいて実行優先順位が割り当てられるので、そのタスクに 関連づけられスケジュールされた全てのイベント・ルーチンは、その実行優先順 位のレベルで実行される。 図面の簡単な説明 図1Aは、ソフトウエア・アプリケーションとメッセージング・システム・カーネ ルの間の関係を示す図である。 図1Bは、多くのコンテキストを含むソフトウエア・アプリケーションの呼び出し 構造を示す図である。 図２は、本発明のシステムのブロック図である。 図３は、アプリケーションの呼び出し構造を示す図である。 図4A、及び4Bは、プリエンプティブ複数スタック環境におけるEnte r ContextとExit Contextルーチンのフローチャートである。 図5A、及び5Bは、ポーリング単一スタック環境におけるEnter ContextとExit Co ntextルーチンのフローチャートである。 図６は、ソフトウエア・アプリケーションの呼び出し構造を示す図である。 図7A、及び7Bは、Single EventとRaise Eventルーチンのフローチャートである 。 図7C、7D、及び7Eは、内部起動(Internal Raise)、及び処理配置ルーチンのフロ ーチャートである。 図８は、複数スタック及び単一スタック・カーネルの両方におけるCapture Even tルーチンのフローチャートである。 図９は、複数スタック及び単一スタック・カーネルの両方におけるCapture As E ventルーチンのフローチャートである。 図10は、複数スタック及び単一スタック・カーネルの両方におけるUncapture Ev entルーチンのフローチャートである。 図11A、及び11Bは、プリエンプティブ複数スタック環境におけるWait Event、及 びCheck Eventルーチンのフローチャートである。 図12A、及び12Bは、ポーリング単一スタック環境におけるWait Event、及びChec k Eventルーチンのフローチャートである。 図13は、本発明のカーネルの内部Check Eventルーチンのフローチャートである 。 図14A、及び14Bは、複数スタック及び単一スタック・カーネルの両方におけるSc hedule Eventルーチンのフローチャートである。 図15A、及び15Bは、プリエンプティブ、及びポーリング・カーネル両方のTask t o Dispatch Events、及びPolling to Dispatch Eventルーチンのフローチャート である。 図15Cは、プリエンプティブ複数スタック・カーネルのDispatch All Eventsルー チンのフローチャートである。 図16は、プリエンプティブ、及び複数スタック・カーネル両方のDispatch Event ルーチンのフローチャートである。 図17は、アプリケーションの呼び出し構造を示す図である。 発明の好適実施例の説明 本発明の様々な実施例を説明する前に、本発明の特徴と動作を理解する上で類 似が有用である。 コンピュータ・プログラムは抽象的な問題を解決するための命令の集合として 見ることができる。同様に人は、組織化された問題を解決するために、様々な職 種に分割される。ファースト・フード事業の店舗を管理する問題を考えると、組 織化された問題の要件は言葉で指定される。例えば、ドライブスルーの窓のサー ビスは、中の顧客のサービスより優先すべきである、顧客サービスの平均時間は ３分を越えてはならない、フレンチフライは30秒計が時間切れになる間に熱油か ら取り出さなければならないなどである。 組織化された問題の要件を満たす、多くの異なる方法の様々な組織化のタスク がある。この店舗の効率は、いかに効果的にこれらのタスクが雇用者に分割され るかにかかっている。ビジネスは通常、要件を満たすタスクの組織化のためにい くつかのシステムを判定し、 各雇用者に、それらのタスクに関して彼らの特定の義務を定義した書かれた命令 を提供する。これらの書かれた命令は、コンピュータ・プログラムにおける書か れた命令と類似する。雇用者は互いにあるタスクを実行するよう要求することを 含む、様々な仕事を実行するのに必要な情報を交換するために、互いの間で通信 することができる。同様に、コンピュータ・プログラムは、互いに通信してある 機能（例えば、リアルタイム制御、スプレッドシート計算等）を実行するコード ・エンティティ（例えば、オブジェクト、モジュール、タスク）の集合として見 ることができる。 人間の通信とコンピュータの命令実行の間の１つの大きな違いは、個々のコー ド・エンティティが与えられた全ての命令を実行しようとすることである。ファ ースト・フードの類似例では、店員がマネジャが処理の空くのを待つとすると、 マネジャはどれだけのバーガー・パティをフリーザから取り出すかをコックに尋 ねて待ち、コックは店員が特別の注文を受けるのを待つ。各人は別の人間の動作 を、それらが割り当てられていた命令から少しだけずらされて、デッドロックを 解消するよう実行されるまで待つので、人間はすぐ、この周期的なデッドロック 条件に気づく。しかし、コンピュータ・プログラムは、この待機状態の周期の中 に永久に居座る可能性がある。 ここで、ファースト・フード店の効率と信頼性を、以下のシステムを実装する ことによって向上させるように決定された事業管理を仮定する。 ・全ての雇用者は数字のランクに割り当てられる。 ・同じランクの雇用者は、互いに話すことはできない。 ・ランクの高い雇用者がランクの低い雇用者にタスクを実行するよう命令でき る。 ・ランクの低い雇用者はランクの高い雇用者との通信を起動できないが、高い ランクの雇用者によって持ち出された特定の質問には答えることができる。 ・ランクの低い雇用者は、彼らが高いランクの雇用者への値の情報を有してい ると思う場合に、手を挙げることによって高いランクの雇用者に信号を送ること ができる。 これらの条件は、雇用者に階層呼び出し構造を強いるものであり、彼らが他の 雇用者の情報やサービスを使用できる場合、及び時を制御する。このシステムと 一致する命令セットが書かれうることは明白であるが、人間に適用する場合に、 こうしたシステムが非効率的で非生産的となることにはほとんど疑いの余地はな い。 しかし、ソフトウエア・アプリケーション内のコード・エンティティに適用し た場合、こうしたシステムはコード・エンティティに関して階層呼び出し構造を 強要し、それによって上述の周期的なエラーを効果的に取り除く。本発明はこう した階層呼び出し構造を強いるためのメカニズムを提供する。このことは、コン テキストが別のコンテキストを呼び出す毎に、呼び出されたコンテキストが、呼 び出しコンテキストより高い実行優先順位（即ちランク）を有するかどうかを判 定することによって行われる。より高い実行優先順位を有している場合、呼び出 されたコンテキストはその手順を実行す ることを許され、それによって制御の活動スレッドを得る。呼び出されたコンテ キストがより低い実行優先順位であった場合、試みられた呼び出しは禁止された 上方向コールであり、その呼び出しは成功しない。 呼び出しレベルにおけるコード・エンティティ間に階層を適用し、強制するこ とによって、プログラマはコードを開発する間、再入、再帰、デッドロック、及 び危険地域に関する考慮から解放され、それによって開発プロセスがスピードア ップされる。本発明は、カーネル操作の使用によってこの呼び出し階層を強制す る。カーネルは通常、ソフトウエア・システムの最下層に属する。本発明は、既 存のオペレーティング・システム・カーネルと非常に類似した１組のメカニズム を提供するものなので、カーネルとして記述されうる。しかし、現存のオペレー ティング・システム・カーネルとは異なり、本発明のカーネルは、呼び出し構造 が階層的な、厳正な内部コード構造に適合するためにそのカーネルを使用するア プリケーションを要求する。更に、カーネルは、この階層フレームワーク内で非 同期イベントを処理するためのイベント・メカニズムを提供し、制御の単一スレ ッドを強制し、及び操作のプリエンプティブ処理を提供する。 ここで、図２を参照すると、本発明の一実施例の環境のブロック図が示されて いる。本発明は、マイクロプロセッサ201、キーボード207、ディスプレイ203、 プリンタ209、及びアプリケーション開発と実行時実行の間の両方でソフトウエ ア・アプリケーション215を記憶 するためのメモリ211を含むコンピュータ・システムで実施される。ソフトウエ ア・アプリケーション215は、単一スタックまたは複数スタック環境のどちらか の操作であることができ、非同期イベントのリアルタイム処理に関して設計され る。メモリ211は、本発明を実施するカーネル213も記億する。プロセッサ201は バス229を介してこのメモリ211と通信する。 メモリ211内に記憶されたソフトウエア・アプリケーション215は、それぞれが 選択された他のコンテキストからのコール又は呼び出しに応答して、任意の数の 操作または手順を実行する、多くのコンテキスト、又はコードの単位からなる。 より詳しくは、コンテキストは、本発明の階層強制メカニズムを実行させるコー ド・ステートメント内に含まれているコードの単位である。操作の間に、新しい コンテキストが必要に応じて追加され、破棄される。各コンテキストは、そのコ ンテキストが手順を実行するためにコールされているかを示すためのフラグとし て機能する入れ子カウンタを有する。各コンテキストはまた、他のコンテキスト から伝えられた条件に応答するためのイベント・ルーチンも含む。そのイベント ・ルーチンの制御、及び順序づけは、以下で図７ないし図16に関連して説明する 。 アプリケーション215の呼び出し構造は、アプリケーション215のコンテキスト 間の関係をコールする手順の組である。アプリケーション215では、本発明で使 用するよう最適に開発された呼び出し構造は、常に階層的である。このことは、 呼び出し構造の有向グラフの中に周期がないことを意味している。階層呼び出し 構造301の例が図 ３に示されている。図３は、有向グラフで、図２のソフトウエア・アプリケーシ ョン215に関する階層呼び出し構造301を示している。図３では、各コンテキスト は、より低レベル（つまり高優先順位）またはそれ自身にのみ手順コールを行う (303)。呼び出し構造301が階層であるため、より高い優先順位を持つ、より低い レベルのコンテキスト（図の底部近くに示されている）から、より低い優先順位 を有する、より高いレベルのコンテキストへの手順呼び出しである、上方向コー ルは存在しない。上方向コールを禁止することによって、有向グラフ内に周期を 持たない呼び出し構造301が得られ、従って、デッドロック、無制限の再帰、危 険地域、または非再入の周期的なエラーの可能性が除去される。 概念のレベルでは、各コンテキストは、非同期イベントを処理するリアルタイ ム・アプリケーション内の実行の別のスレッドとして考えられる。ここで、コン テキスト呼び出しは、ある手順から他の手順への要求として考えられる。本発明 で使用されるプログラミング方法論は、制御の１つのスレッドだけが任意の所与 の時間におけるコンテキストの範囲内において活動中であることを必要とし、本 発明がこの要件を強制するためのメカニズムを提供する。コンテキストの範囲は 、コンテキストで定義された手順全てを含む。これらの条件が破られない限り、 実際のコンテキスト間の呼び出しは、現在使用されているいくつかの形態のうち １つを取ることができる。従って、本発明はアプリケーション215の階層呼び出 し構造301を強制する様々な実施例を有する。 開始コンテキスト(Enter Context)、及び終了コンテキスト(Exit Context)操 作 階層呼び出し構造の実行時チェックを強制するために、カーネル213は、Enter ContextとExit Context操作に関係のある、２つのタイプの呼び出しを実行し、 これらの操作はコンテキストの呼び出しと戻りの間にプロセッサ201によって実 行される。これらの操作は、より高い優先順位、即ち低レベルのコンテキストが より低い優先順位、即ち高いレベルのコンテキストを直接呼び出すのを防止する ことによって、階層的な呼び出しをカーネル213が強制することを可能にする。 ここで、図4A、及び4Bを参照すると、プリエンプティブ・複数スタック環境で実 施されるEnter ContextとExit Context操作のフローチャートが示されている。 図4AはEnter Context操作400を示す。このEnter Context操作400はカーネル21 3内に常駐し、コンテキストが別のコンテキストを呼び出す場合、プロセッサ201 によって実行される。最初に、プロセッサ201は、そのコンテキストがそれ自身 を呼び出しているかどうかを判定する(401)。コンテキスト内のコールは許可さ れ、再帰をもたらす。無制限の再帰は、それがコード自体の中で簡単に識別可能 で、再帰コール数の制限を備える入れ子カウンタで容易に処理することができる ので、コンテキスト内のコールにとっては重要な問題ではない。従って、コンテ キストがそれ自体を呼び出している場合、コンテキストの入れ子カウンタがイン クリメントされる(413)。このフラグは更に、そのコンテキストが制御の活動ス レッドを有することを示す。 そのコンテキストが自身を呼び出さないが、別のコンテキストを呼び出す場合、 プロセッサ201は、呼び出されたコンテキストの優先順位が呼び出しているコン テキストの優先順位より高いかどうかを判定する(403)。このステップは、それ が上方向コールが試みられているかどうか、即ち、図1Bに示すように、高い優先 順位の低レベル・コンテキストが低い優先順位の高レベル・コンテキストを呼び 出そうとしているかどうかをチェックするので、呼び出し構造の階層を維持する 。上方向コールが試みられている場合、プロセッサ201はそのコールをエラーと し、アプリケーション215に伝える(409)。 呼び出しが順当に、低優先順位コンテキストから高優先順位コンテキストへの ものである場合、プロセッサ201はスタック上にある呼び出しコンテキストに対 するポインタをメモリ211内に記憶し、プロセッサ201が制御のスレッドを後で呼 び出しコンテキストに戻すことができるようにする。次にプロセッサ201は、コ ールされた手順の優先順位を、呼び出されたコンテキストの優先順位にセットす る(407)。このことによって、プロセッサ201は、図７、及び図15ないし図16に関 連して更に説明されるように、異なる優先順位のコンテキスト内で、コールされ ている様々な手順をスケジュールすることができる。 プロセッサ201は次に、コンテキストが入力され、タスクを実行するよう活動 中であることを示すセマフォ、またはそれと同様のものを、呼び出されたコンテ キストから待つ(411)。コンテキストによるタスクの実行は更に、図15Aに関連し て以下で説明される。 最後に、プロセッサ201はその呼び出されたコンテキストの入れ子 カウンタをインクリメントし(413)、それはコンテキストが制御の活動スレッド を有することを示す。そのコンテキストが最も高い優先順位を有しているとする と、呼び出されたタスク、又は手順は、呼び出されたコンテキストによって実行 される。そのコンテキストの実行が終了すると、Exit Context操作417がプロセ ッサ201によって実行される。 要するに、Enter Context操作が、コンテキストの各呼び出しで発生し、呼び 出されたコンテキストが呼び出しコンテキストより高い実行優先順位を有する場 合に、呼び出しの許可だけがされる。呼び出しが許可されると、追加ステップが 、実行をコンテキストに戻す間、呼び出しコンテキストに関する情報を維持し、 また呼び出されたコンテキストが再帰、又は再入を記録する間に呼び出された回 数も記録する。更に、更なる呼び出しが許可される前に、呼び出されたコンテキ ストからセマフォ、又はそれと同等のものを待つことによって、操作が制御の単 一のスレッドのみを保証する援助を行う。 図4BはExit Context操作のフローチャートである。この操作は、各コンテキス トの操作の終了の際に実行される。最初に、プロセッサ201が、呼び出されたコ ンテキストの入れ子カウンタをデクリメントし(419)、これは１つのレベルの実 行が終了したことを示している。プロセッサ201は、その入れ子カウンタが０に 達したかどうかをテストし(421)、これはそのコンテキストが全ての呼び出しを 完了したことを示す。０でない場合、プロセッサ201は制御を呼び出されたコン テキストに戻し(429)、実行を続けるよう許可する。呼び出されたコ ンテキストの入れ子フラグが０である場合、プロセッサ201はそのコンテキスト のイベント・ルーチンをタスク指名する(422)。このステップは、そのコンテキ ストに関連づけられたイベント・ルーチンの全てが、現在の呼び出しの完了前に 終了することを保証する。このステップは図16に示すルーチンに従って実行され る。プロセッサ201は次に、コンテキストのエントリ・セマフォを開放し(423)、 このことはそのコンテキストがもはや制御の活動スレッドでないことを示してい る。プロセッサ201は、記憶されたスタックに関するポインタを用いて、呼び出 しコンテキストを復元し(425)、現在実行中のタスクの優先順位レベルを現在の コンテキスト、即ち呼び出しコンテキストの優先順位レベルにセットする(427) 。 Enter Context400、及びExit Context417操作はまた、ポーリング、単一スタ ック環境のカーネル213で実施されうる。このような操作のフローチャートが図5 A、及び5Bに示されている。これらの操作の使用は、機能的にはプリエンプティ ブな実施と同じであり、基本的な差は、カーネル213が、呼び出されたコンテキ ストが呼び出しコンテキストより高い優先順位を有するかどうかを判定した(507 )後に、イベントにポーリングを行う(505)ことである。ポーリングとプリエンプ ティブ環境の間の差は、更に以下で説明する。ポーリング操作は、図15Bに関し て以下で説明される。 実行時に階層呼び出し構造を強制するためのカーネル213は、本発明で使用さ れるシステムの実施要件に従って、様々な形態で実施可能である。Enter Contex t、及びExit Context操作は、コンテキスト の呼び出しと戻りのそれぞれについて実行されなければならず、カーネル213の 好適実施例は、アプリケーション215を実行するプロセッサ201の命令セットにこ うした操作を提供するものである。この実施例において、アプリケーションが終 了すると、コンパイラがこれらの操作を実行するために必要なコードを完成する 。代替案として、コンテキスト操作はプロセッサ201によって使用されるオペレ ーティング・システム内に含むことができ、ソフトウエア、又はファームウエア のどちらかで提供される。どちらにしても、プログラマは、アプリケーション開 発において手でコンテキスト操作をコード化する必要はない。 本発明のカーネル213はまた、ここで記述されたプログラミング方法論に基づ いて開発されたコードからコールされうるルーチンのライブラリとして見ること もできる。カーネル213はここで、図２に示すように、アプリケーション215のア ドレス空間のどれかにリンクされうる。別の代替実施例では、本発明で使用され るプログラミング方法論を直接支援するプログラミング言語によって、及びカー ネル213の操作を達成するためのプログラミング言語の構文を使用することによ って、カーネル213を容易に使用することができる。こうした言語の疑似コード が、本発明のカーネル操作に関連して以下で例示される。 最後に、プロセッサ201、オペレーティング・システム、又は新しいプログラ ミング言語の命令セットのどれにも直接的な組み込みがなされない場合、本発明 はコード・プロセッサ227を使用して既存の コンピュータ・システムに実装されうる。コード・プロセッサ227は、既存のcfr ontプロセッサと同様に動作し、例えば、C++のコードをＣプログラミング言語に 変換する。この実施例では、コード・プロセッサ227はプログラミング言語抽象 化(abstractions)を既存のプログラミング言語、好適にはC++に統合する。本発 明はC++言語の使用を必要としないが、C++は、コードの簡潔さとプログラミング ・エラーに対する保護のために、好適なプログラミング言語である。カーネル21 3、及びコード・プロセッサ227としての本発明の実施は、常にコンテキスト操作 をアプリケーション手順コールに統合することによって、Enter Context、及びE xit Context操作の省略を防ぎ、それによってプログラマが手でこれらの操作を 提供しなくてもいいようにする。 コード・プロセッサ227によって、プログラマは、プロセッサ227によって処理 される時に、Enter Context、及びExit Context操作をアプリケーション・コー ドにリンクさせる、様々なプログラミング言語の拡張を使用することができる。 これらの操作の関数プロトタイプが資料Ａに示されている。疑似コードの例は以 下に示す。 この疑似コードにおけるキーワードContextは、C++のクラス・キーワードと同 様である。キーワードServiceは、New Messageメソッドが他のコンテキストに呼 び出されようとしていることを示すものである。キーワードServiceがないと、 プロセッサ227はそのメソッド宣言を、クラス定義のセクション：private内に移 動する。コード・プロセッサ227は先行するコードを得て、以下のC++出力を生成 する。 includeステートメントは通常、言語抽象化によって参照される望ましいコー ド表現を完成させるために、コード・プロセッサ227によって使用されるべきコ ード・ライブラリ内のヘダー・ファイルを識別する。コード・プロセッサ227は 、K の抽象化が定義されることを保証するように、事前コンパイルされたコード 内にkernel.hxxヘダー・ファイルを含む。キーワードContextは、Message Boxオ ブジェクトに関するクラスがK Contextクラスから導出されるべきであることを 示すものであり、カーネル・ヘダーに定義されている。K Context Protector変 数、dummyはそのコンストラクタ内の現在のthisポインタを取る。dummy変数のコ ンストラクタは単に、K Enter Contextカーネル操作を実行し、そのデストラク タはK Exit Context操作を実行する。そのコードは、両方の操作がコンテキスト の開始とコンテキストの終了で実行されることを保証する。 イベント これまで、本発明の一態様として、カーネル213を使用した階層呼び出し構造 の強制が記述されてきた。本発明の更なる態様は、こうした階層呼び出し構造に プリエンプティブな性質を提供することである。 図1Bに関して前述したように、より低レベルのコード単位から、より高レベル の単位への上方向コールが周期的なエラーの可能性を作り出す。本発明で使用さ れるプログラミング方法論は、こうしたクラスのプログラム不良を排除するため に上方向コールを禁止する。 しかし、プリエンプティブ、またはポーリング環境のどちらかで非同期イベント のリアルタイム処理を提供するために、より低レベルのコンテキストがより高レ ベルのコンテキスト実行を起動できるメカニズムを提供することが依然として必 要とされている。 従って、本発明によって、重要性のあると思われるより低レベルのコンテキス トからの条件の発生を、より低レベルのコンテキストに伝えるための、イベント ・メカニズムが提供される。呼び出し構造でイベントを使用すると、コンテキス ト間で送信されるパラメータが常に、より高レベルのコンテキストによって起動 される、要求時駆動型プログラム構造となる。イベント・メカニズムは、より高 レベルのコンテキストの中のコードの実行をスケジューリングする方法を提供す る。このコードの実行は、高レベルのコンテキストが、低レベル、即ちより高い 優先順位のコンテキストの完了に続いてイベントを処理することによって、その 要求を処理できるまで延期される。イベント・メカニズムの様々な要素に関する 関数プロトタイプは、資料Ａに示されている。 好適実施例では、イベントは、Eventステートメントの使用によって定義され うる。コンテキストの範囲内に定義されたイベントは、そのコンテキストに対し てはローカルであると考えられ、コンテキストの範囲外に定義されたイベントは 、グローバルな範囲を有すると考えられる。 この疑似コード・プログラミングの例は、イベントを参照するためにC++構文 を使用して、イベントoopsの定義を例示する。 イベントの最も単純な実装は、Deviceコンテキストで割り当てられる構造内に イベントに関する変数を割り当てることである。変数のアドレスは、カーネル21 3によって実行されるイベント操作に関するハンドルを提供する。この実装は、 アプリケーション215内にリンクされるよう意図したカーネル実装にとっては十 分である。 プログラミング・イディオムという用語は、プログラミング言語の特徴を使用 する技法について述べるために使用されてきた。本発明の一実施例に有用なプロ グラミング・イディオムの１つは、Event Hand1eの使用である。コンテキストは イベントを定義し、そのイベントを把握し、そしてそのイベントを後で伝える(s ignal)１つ以上のコンテキストにハンドルを送信する。あるカーネル実装では、 Event Handleは単に、イベント変数のアドレスである。より複雑なカーネル実装 では、イベントの生成がカーネル自身のアドレス空間内の記憶域の割り当てにつ ながることがあり、Event Handleが単に、カーネル213が適切な操作を判定する ために解釈する抽象キーとなる。イベントのハンドルを得るための疑似コードの 例を以下に示す。 カーネル213は、操作が直接そのイベントに関して行われるように、構文的にE vent Handlesに関して操作を行う。 イベントの通知(signaling)と起動(raising) 本発明は、その様々な実施例において、イベントを「通知(signal)」し、及び 「把握(capture)」するためのメカニズムを提供する。通知は通常、コンテキス トが、他のコンテキストに対して重要である可能性のある条件を、別のコンテキ ストに伝えていることを示すためのメカニズムを指す。把握は通常、通知された 条件が伝えられるべきことを示すコンテキストによるメカニズムを指す。ファー スト・フードの店舗に話を戻すと、通知メカニズムは個々の高いランクの雇用者 に、より低いランクの雇用者が、ある高いランクの雇用者との通信を要している ことを知らせる。把握メカニズムは、高いランクの雇用者が、店員が通知を行っ たときにマネジャに伝達を行うといった、マネジャに対する伝達の条件をセット できるようにする。異なるランクの多くの異なる雇用者が、他の雇用者からの通 信を受信しようとしている場合、雇用者間の通信をスケジュールする必要がでて くる。高いランクの雇用者は彼らの要求をタスク指名するので、より低いランク の雇用者は彼らの義務を実行できる。本発明はこの通信を強制し、アプリケーシ ョン215のコンテキストに関する構造を実行するメカニズムを提供する。 本発明は所与の時間において、コンテキストの範囲内の制御の活 動スレッドを１つだけ要求するので、通知、及び把握メカニズムは、カーネル21 3が、制御の活動スレッドを管理し、タスクのスケジューリングを遅らせること ができるようにし、従って、プリエンプティブ、又はポーリング・マルチタスキ ングを可能にする。こうしたメカニズムは、本発明で用いられるプログラミング 方法論でコンパイルを行うソース・コードの開発を可能にするのに十分な表現力 を有する。一般に、イベント・メカニズム内の複雑さの増大と、イベントを処理 するためのソース・コード内での余分な要求はトレード・オフの関係にある。 より詳しくは、カーネル213によって、イベントの発生を通知するための２つ のメカニズム、Signal EventとRaise Event関数が提供される。この実施例では 、イベントを把握するための２つのメカニズム、Capture EventとSeize Event関 数も提供される。 イベントは、次のどちらかの方法で通知される。 Signal()関数は、コンテキスト・クラスに関して定義されたC++メソッドであ り、コード・プロセッサ227によってSignal Event関数に変換される。同様に、R aise()関数は、コード・プロセッサ227によってカーネル関数Raise Eventへのコ ールに変換されるメソッドであり、それは、イベントを起動するコンテキストを 識別する余分なパラメータをとる。これらの関数は、範囲の判定の際においての み異なり、カーネル213によって使用され、通知されたイベントを処理す るための把握コンテキストを見つけだす。Signal Event関数はグローバルな範囲 を有する。アプリケーション215内の任意のコンテキストはそのイベントを把握 できる。Raise Event関数は、以下に示すように、より制限された範囲を有する 。 １．上位の（高レベル、低優先順位の）コンテキストだけが、別のコンテキスト によって起動されたイベントを把握できる。 ２．そのイベントを起動しているコンテキスト内に制御の活動スレッドが存在す る場合、「コール連鎖」の一部であるコンテキストだけがそのイベントを把握で きる。 ３．そのイベントが活動呼び出しを有していないコンテキストによって起動され た場合、イベントの範囲は、そのイベントを起動したコンテキストより低い優先 順位のコンテキスト全てに制限される。 コール連鎖は、現在のスタックに関する戻りアドレスを有するコンテキストか らなると考えられる。図６は、多くのコンテキストからなるソフトウエア・アプ リケーション215に関する呼び出し構造601を示す。図６では、経路〈Ａ、Ｂ、Ｅ 、Ｇ〉を含むコール連鎖603が示されており、これは、コンテキストＡ、Ｂ、Ｅ 、及びＧを結合する太い矢印によって示されている。コンテキストＧが、Ａから Ｇまでの活動コール連鎖がある間にイベントを起動した場合、このコール連鎖内 のコンテキストだけがイベントを把握する資格がある。コンテキストＧが同じイ ベントを通知する場合、アプリケーション215内の任意のコンテキストがイベン トを把握できる。上述の範囲のルールは、以下に示す図7Dに関連して記述される Locate Contextルー チン内で使用される。把握コンテキストの範囲を洗練するためのコール連鎖の使 用は、既存の例外メカニズムと同様である。 ここで図7A、及び7Bを参照すると、コンテキストによる通知と起動に関する、 ルーチンの実施例のフローチャートが示されている。 Signal Event操作700によって、コンテキストは、アプリケーション215のある コンテキスト内で特定の条件が発生したことを示すことができる。一旦通知が行 われると、その条件の伝達（把握）に関して以前に登録されているコンテキスト の１つが、イベントを処理するものとして指名され、そのイベントは、その実行 優先順位に従う処理コンテキストによって実行される。図7Aでは、Signal Event 操作700の一実施例が、その操作のパラメータとして渡されたイベント・ハンド ルが、カーネル213のアドレス空間に対してローカルかどうかを判定する(701)こ とから実行を開始する。ローカルであれば、そのイベント・ハンドルがローカル ・イベントへのポインタに変換される(705)。ローカルでなければ、そのイベン トはアプリケーション215の外部のルーチンに依存し、そのイベント・ハンドル が、オペレーティング・システム、及びネットワーク上の他のアプリケーション で利用できるようにする待ち行列内に配置される(703)。従って、あるリモート ・イベントが通知されていることを示す内部イベントに対するポインタが、ロー カル・イベントに対するポインタの代わりに使用される(707)。イベント・レコ ードが、イベント・ポインタの１つ、及びそのイベントの優先順位が最も高い優 先順位にセットされる設定を行うフラグを使用して生成される(709)。イベント ・レ コードは、通知、又は起動されているイベントに対するポインタ、通知、又は起 動するコンテキストの優先順位、及び範囲のルールに使用するためのフラグを含 む。通知されたイベントがグローバルなコンテキストであるため、範囲のフラグ は、通知されたイベントに対して「偽」と設定される。これは、そのイベントに グローバルな範囲を与え、アプリケーション内のどのコンテキストによっても把 握が可能となる。イベントの優先順位が最も高い値にセットされるので、イベン トは、それを処理することができるコンテキストで最も優先順位の高いものによ って処理される。次にイベント・レコードは、通知コンテキストの優先順位に基 づいてイベントを処理するための適当なコンテキストを判定する、カーネル213 の内部操作に渡される(711)。このルーチンは更に、図7Cに関連して以下で記述 される。 図7Bでは、プリエンプティブ、及びポーリング環境の両方で使用されるRaise Event操作713の一実施例のフローチャートが示されている。Signal Event同様、 Raise Eventは起動コンテキストのコール連鎖内の把握コンテキストに優先を与 えるために使用される。イベント・レコードは渡されたイベントからのポインタ を使用して生成される(717)。しかし、そのイベントにSignal Event操作700内で 最も高い優先順位を割り当てる代わりに、そのイベントを起動するコンテキスト の優先順位に、そのイベントが割り当てられる。このことは、起動コンテキスト より低い優先順位のコンテキストだけがそのイベントを処理することを保証する 。このステップは、上述の第 １の範囲のルールの実装を助ける。次にカーネル213は、そのイベントを起動し たコンテキスト内で活動中のEnter Context操作があるかを、そのコンテキスト の入れ子カウンタの状態に基づいて判定する(719)。コンテキストが活動中のEnt er Contextを有し、従って制御の活動スレッドを有する場合、範囲のルールが使 用中で、従って、コール連鎖内のコンテキストだけがそのイベントを処理できる ことを示すようにフラグがセットされる(721)。このことは第２の範囲のルール の実装を助ける。制御の活動スレッドがない場合、フラグは偽にセットされる(7 23)。次に、イベント・レコードは、イベント内部起動ルーチンに渡され(725)、 そのルーチンから戻り値を得た際(745)に、その値が通知／起動コンテキストに 戻される(727)。この戻り値は、イベントを処理するコンテキストが見つかった かどうかを示す。 図7Cは、イベント内部起動ルーチン731の実施例のフローチャートを示す。こ こで、そのルーチンは、そのデフォルトの戻り値に偽をセットし(733)、次に、 通知された／起動されたイベントを処理する適当なコンテキストを上述の範囲の ルールに従って判定するために、カーネル213の内部のLocate Handling Context ルーチンにイベント・レコードを渡す(735)。その後続のルーチンが完了すると 、カーネル213は、イベントを処理するためのコンテキストが識別されているか どうかを判定する(737)。識別されている場合、その戻り値は真にセットされ(73 9)、見つけられたコンテキストのアドレス空間内のイベント・カウンタがインク リメントされる(741)。このカウンタはコ ンテキストがイベントを把握した場合に、以下に述べるようにして確立される。 このカウンタは、イベントの発生数を記録する。 イベント・カウンタは、そのイベントが処理された回数を判定するためにテス トされる(743)。そのカウンタが丁度１にインクリメントされた場合、そのイベ ントは現在の呼び出しの間において、以前に処理されたことがなく、それは、そ のイベントを処理するためのイベント・ルーチンをスケジュールするのに必要で ある。カウンタが１より大きい場合、そのイベントを処理するためのイベント・ ルーチンは既にスケジュールされ、そのメソッドはそのイベント・ルーチンの実 行回数の記録だけを必要とする。 そのイベントに関するイベント・ルーチンをスケジュールするために、カーネ ル213は、通知された／起動されたイベントに関連づけられたイベント・ルーチ ンがあるかどうかを判定する(751)。イベント・ルーチンがある場合、内部スケ ジューリング・ルーチンをコールすることによって、カーネル213はそのイベン ト・ルーチンをスケジュールする(753)。このスケジューリング・ルーチンは、 図14Aに関して以下で更に記述される。イベント・ルーチンがない場合、カーネ ル213は、通知されたイベントに関するエイリアス・イベントがあるかどうか判 定し(755)、そのエイリアスを参照するようイベント・レコードを修正する(757) 。イベント・レコードは再び、Locate Handling Contextに渡され、そのエイリ アス・イベントを処理するためのコンテキストを更に見つけだす。イベントを処 理するためのコンテキストが見つからない場合(739)、戻り値（偽にセットされ て いる）が戻される(745)。 図7Dは、Locate Handling Contextルーチンの一実施例のフローチャートを示 す。このルーチンはカーネル213の内部で動作し、イベントが起動されていると きに、上述の範囲のルールを使用して、イベントを処理するのに適したコンテキ ストを判定するのに使用される。第１に、カーネル213は、範囲のルールを使用 するための範囲のフラグが真にセットされるかどうかを判定する(763)。真にセ ットされている場合、範囲のルールは以下のように使用される。 テスト・コンテキストは起動コンテキストにセットされる(765)。範囲のルー ルは、テスト・コンテキストがコールの連鎖の頂部にあるかどうか判定する(769 )ことによって適用される。頂部にない場合、テスト・コンテキストはテスト・ コンテキストを呼び出したコンテキストにセットされ(771)、ここでテスト・コ ンテキストは、テスト・コンテキストが所有(seizing)コンテキストのリスト上 にあるかどうかを判定するテストを行う(773)。リスト上にない場合、ステップ7 69は繰り返される。テスト・コンテキストが所有コンテキストである場合、それ はコールしているルーチンに戻される(783)。テスト・コンテキストがコールの 連鎖の頂部であった場合、カーネル213はそのテスト・コンテキストが依然、起 動コンテキストにセットされているかどうか判定し(775)、セットされている場 合は、そのコールの連鎖内には１つのコンテキストだけが存在するので、ルーチ ンは空(null)コンテキストを返す(781)。テスト・コンテキストが別のコンテキ ストにセットされている(771)場合、そして、そのコンテキスト が把握コンテキストのリスト上にある(777)場合、それはコーリング・ルーチン に戻される(783)。そうでない場合、テスト・コンテキストは、コール連鎖内で 次に呼び出されたコンテキストにセットされる(779)。このループは、そのイベ ントを把握するようセットされた最も低い優先順位、即ち最も高いレベルのコン テキストが見つけられるまで繰り返される。 範囲のルールを使用する例が示されている。図６に示されるコール連鎖が現在 活動中であり、コンテキストＧがイベントを起動していると仮定する。更に、コ ンテキストＢだけがイベントを把握しており、即ちコンテキストＧからの通知の 伝達を要求すると仮定する。コール連鎖が活動中で、イベントが起動されている ので、範囲フラグがRaise Eventルーチン内にセットされる(721)。Locate Handl ing Contextルーチンでは次に、テスト・コンテキストがコンテキストＧにセッ トされる(765)。これには、コール連鎖の頂部であるかのテストがなされる(769) 。コンテキストＡがコール連鎖の頂部であるため、テスト・コンテキストはコン テキストＥにリセットされ(771)、それはコンテキストＧの呼び出し者となる。 テスト・コンテキストは、それが所有コンテキストのリスト上にあるかどうか判 定するためにテストされる(773)。コンテキストＡがイベントの所有を示す場合 、それは処理コンテキストとして戻される(783)。この例の目的のために、そう でないと仮定すると、ステップ769でテストが繰り返され、今はコンテキストＥ であるテスト・コンテキストが再び、コール連鎖の頂部にない。従って、テスト ・コンテキストがコンテキス トＢにセットされる(771)。コンテキストＢは同様に、所有コンテキストのリス トに含まれるかに関するテストがなされる。コンテキストＢがイベントの把握を 示すので、ループは、コール連鎖内の各コンテキストがテストされるまで繰り返 される。従って、テスト769のループ、セットを行う771、及びテストを行う773 は、イベントを処理するための起動コンテキストより上の、最も高い優先順位、 即ち最も低いレベルのコンテキストを見つけるために使用される。 起動されたイベントを所有するコール連鎖内にコンテキストがない場合、テス ト775からセット779へのループは、そのイベントを処理するコンテキストが見つ けられるまで、コール連鎖を下方向に横断する。従って、コンテキストＡから始 めて、カーネル213は、コンテキストＡがイベントの把握のためにリストされた かどうか判定する(777)。この例において、コンテキストＡがリストされず、コ ンテキストＢがリストされている場合、コール連鎖内で次に呼び出されるコンテ キストは、テスト・コンテキストとしてセットされる。ここで、コンテキストＢ がイベントを把握するよう示されていると仮定すると、それは戻されることにな る(783)。コンテキストＢは、たとえコンテキストＥもまたそのイベントを把握 するよう示されていても、コンテキストＢがより低い優先順位、即ちより高いレ ベルのコンテキストであるため、処理コンテキストとして選択される。 ここで図7Dを参照すると、イベントが通知される（フラグがステップ709で偽 にセットされる）か又は、カーネルが起動コンテキスト内に制御の活動スレッド がないことを判定する(719)ので、範囲のル ールのアプリケーションに関するフラグが、ステップ763で偽にセットされる。 どちらにしても、カーネル213は、最初に最も高い優先順位の所有コンテキスト を見つけようとし、次に最も低い優先順位の把握コンテキストを見つけようとす る、前と意味的に同じステップに基本的に従うことによって、適当な処理コンテ キストを判定する。 従って、カーネル213は、起動されたイベントを所有するよう示されたコンテ キストのリストを横断し(785)、起動コンテキストの優先順位より低いもので、 最も高い優先順位を有するコンテキストを判定する。このようなコンテキストが 見つかった場合(787)、処理コンテキストがこのコンテキストにセットされ(789) 、この識別されたコンテキストが所有コンテキストのリストから除去され(791) 、全ての同じレベルの優先順位のエントリの後ろに再インサートされる。次にコ ンテキストがコールしているルーチンに処理コンテキストとして戻される(800) 。適当なコンテキストが見つからない場合(787)、カーネル213は起動されたイベ ントを把握するようセットされたコンテキストのリストを横断し(793)、起動コ ンテキストの優先順位より低いもので、最も低い優先順位を有するコンテキスト を見つけようとする。こうしたコンテキストが見つかった場合(799)、処理コン テキストとしてこのコンテキストにセットされ(797)、このコンテキストが同様 に把握コンテキストのリストから除去され(799)、全ての同じ優先順位のコンテ キストの後ろのリストの端部に再インサートされる。次にその処理コンテキスト がコールしているルーチンに戻される(800)。適当な処理コンテキストが見つか らない場合、空コンテ キストがまたコールしているルーチンに戻される(781)。 上述のイベント・メカニズムは、これらがイベントの発生以外の情報を提供し ないという点で、現存の同様の有名なメカニズムと異なっている。結果として、 イベントを「把握」するより高いレベルのコンテキストが、そのイベントを処理 するのにふさわしい動作を実行できる。 把握(caDturing)、及び所有(seizing) Signal Event、及びRaise Event関数は、処理コンテキストを判定するための 更なる考察の対象である。これらの考察は、イベントが「把握」される方法に依 存する。イベントの把握は、コンテキストがイベントの発生を伝達されるべきで あることを、カーネル213に登録する方法である。通知されるか又は、起動され ることによってイベントが発生すると、把握コンテキスト全てが判定され、その イベントに関連づけられたカウンタが、各把握コンテキストのアドレス空間内で インクリメントされる。 イベントは把握されるか又は、所有されうる。イベントの把握に関する構文は 、以下の形態のうち１つを取る。 イベント把握の意味論は、把握コンテキストのアドレス空間内のカウンタのイ ンクリメントを含む。このインクリメント操作は、極めて小さいものであるとい う保証がなされる。イベントを把握する各コンテキストによって、イベントに対 して割り当てられた個別の カウンタがあり、イベントの把握に関する目標コンテキストが、コンテキスト構 造に関して課せられた階層の範囲のルールを使用することによって解決されうる 。把握コンテキストによって続けて取られる動作は、その把握コンテキスト内に 関連するイベント・ルーチンがあるかどうかに依存する。この把握コンテキスト がイベントを起動するコンテキストより低い優先順位のものである場合、カーネ ルによって、このイベント・ルーチンの実行が遅延される。 本発明の好適実施例において、イベントの把握に関するデフォルト・ルールは 、そのイベントを最も高い意味レベルで把握するようにできるものである。例え ば、ホストのオペレーティング・システムの一部としてカーネルが実施される場 合、アプリケーション・プログラムがオペレーティング・システム・シェルによ って支援されうる。プログラム・エラー条件が論理的にグローバルなイベントと して表現される。カーネルによって定義されたDIVISION BY ZEROイベントがアプ リケーション・プログラムによって把握される場合、そのアプリケーション・プ ログラムは、この条件を適切に処理できる。しかし、アプリケーション・プログ ラムとオペレーティング・システム・シェルが両方、DIVISION BY ZEROイベント を把握する場合、より高いレベルのコンテキスト（そのアプリケーション）が実 際にそのイベントを処理する。イベント把握に関してカーネル内に定義されたル ールが２つの同等のレベルの（同じ優先順位の）コンテキストの間で解決されな い場合、カーネルはイベントのラウンドロビン分配を提供する。 Seize()メソッドは意味的には、Capture()メソッドと同じである。しかし、こ れは、デフォルトの最も高い意味レベルの把握ルールを却下する。O/SシェルがD IVISION BY ZEROイベントを所有することになる場合、イベントはアプリケーシ ョンによって見られることはない。所有と把握は両者とも、Capture Eventカー ネル関数を呼び出すコンテキスト・クラスに関して定義されるC++メソッドとし て実装される。この関数に対するパラメータは、イベントが所有されるかどうか 、又は把握されるかどうかを判定するために使用される。把握停止(Uncapture) メソッドは、イベントの把握を停止するために使用される。 ここで図８を参照すると、プリエンプティブ、及びポーリング・マルチタスキ ング・カーネルの両方でイベントの把握と所有をするためのフローチャートが示 されている。Capture Eventルーチンは、コンテキストが別のコンテキスト内の 条件を通知されるべきであることを示すアプリケーション215のコンテキストの うちの１つによってコールされる(801)。オプションで、イベント・ルーチンに 対するハンドル、及びコンテキストがそのイベントを所有、又は把握するもので あるかどうかを示すフラグを含むパラメータは、そのルーチンに渡される。新し い把握レコードは、コンテキストのアドレス空間内に割り当てられ(803)、ここ で、カウンタはそのイベントに関して初期化され、把握コンテキストはスタック 上に記憶される。カーネル213は次に、イベント・ルーチンが把握されるべきイ ベントに関して指定されているかどうかを判定する(805)。指定されている場合 、 その把握コンテキスト内のそのイベント・ルーチンに対するポインタは、把握レ コード内に記憶される(807)。一旦ポインタが記憶されると、あるいは、１つも イベント・ルーチンが指定されていない場合、カーネル213は、そのコンテキス トが既にそのイベントを把握、または所有しているかどうか判定する(809)。コ ンテキストがそのイベントを把握、又は所有している場合、そのコンテキストは 把握されたイベントの把握コンテキストのリストから除去され(811)、前の把握 レコードが削除される。このことは、１時点で所与のイベントに対して１つの把 握レコードだけが存在することを保証する。どちらの場合にしても、カーネルは 次に、その所有フラグが、イベントが所有されていることを示すようセットされ ているかどうかを判定する(813)。そのイベントが所有されている場合、所有さ れたイベントのカーネルのリストは、そのイベントを把握することができる最も 高い優先順位の、即ち最も低いレベルのコンテキストを識別するために横断され る。新しい把握レコードは、所有されたイベントのカーネルのリストの先頭に挿 入され(821)、このイベントが最も高い優先順位の処理を受ける。このイベント が所有されておらず、むしろ把握されている場合、把握レコードのリストは、そ のイベントを処理することができる最も低い優先順位で、最も高いレベルのコン テキストを判定するために横断され(815)、そして再び、新しい把握レコードが 把握レコード・リストの先頭に挿入される(817)。このことによって、最も低い 優先順位のコンテキストが、そのイベントを処理することができる。一旦、その イベントが把握、又は所有され ると、制御がカーネル213に戻る(823)。 図９はCapture As Eventルーチンのフローチャートを示している。このルーチ ンは、イベント・ルーチンがパラメータとして渡されているかどうか判定し(805 )、次に、このイベントに対するポインタを記憶する(807)代わりに、エイリアス ・イベントに対するハンドルが把握レコードに記憶される(905)ことを除いて、 基本的にCapture Eventルーチンと同じである。このルーチンは次に、Capture E ventルーチンと同様の方法で処理を続ける。 コード・プロセッサ227は、いくつかの異なるイベントの把握を、ローカル・ コンテキストの範囲内に定義された単一イベントとして支援する。例えば、アテ ンション(attention)イベントを定義する３つの変数ｘ、ｙ、及びｚがあるとす ると、これらのイベントは以下のように共通のイベントとして把握され、処理さ れうる。 Attentionが、把握コンテキストに対してローカルに定義されたイベントであ るとすると、後続のC++コードがプリプロセッサによって生成される。 カーネル213はまた、制御のスレッドを、イベントの把握を停止することによ ってコールしているコンテキストに戻すために、イベン トの把握停止も提供する。図10はUncapture Eventルーチンのフローチャートを 示す。カーネル213は最初に、把握停止イベント・ルーチンを呼び出し(1001)、 把握コンテキストの把握レコードが、コンテキスト及び、最も直近に処理された イベント、又はイベントのエイリアスを含む把握レコードを見つけるために横断 される(1003)。把握レコードが見つかった場合(1005)、それは削除され(1007)、 コンテキストが把握コンテキストのリストから除去される。上記以外の場合、所 有コンテキストのリストが、コンテキスト及びイベントに一致する把握レコード を見つけるために横断される(1009)。そのレコードが見つかった場合(1011)、コ ンテキストが所有コンテキストのリストから除去され(1013)、把握レコードが削 除される。制御は次に、カーネル213に戻される(1015)。 処理(Hand1ing)イベント コンテキストによって把握されたイベントは多くの異なる方法で処理されうる 。イベントの通知、又は把握に加え、コンテキストはイベントのチェックも待つ 可能性がある。最初に、コンテキストは、イベントが発生し（かつ把握され）た かどうか「チェック」しうる。図11Bはイベントのチェックのフローチャートを 示す。コンテキストはカーネル213によってチェック・ルーチンを呼び出す(1113 )。カーネル213は、任意の数のイベントの状態を判定するための、所望のイベン トに対するポインタをパラメータとして使用する内部チェック・ルーチンを実行 し(1115)、そのフロー・チャートは図13に示されている。カーネル213は次に、 そのイベントのチェックの状態を示す 値を戻す(1117)。 内部チェック・ルーチンは図13に示されている。ここで、カーネル213はそこ に渡されたイベントの数をカウントし(1301)、各イベントが適当なカーネル・イ ベント記号を持つことを確認する。カーネルは、パラメータ全てが満足なもので あり、イベントの数が０より大きいかどうか判定する(1303)。これらの条件のど れかが偽である場合、カーネルはエラーで戻る(1305)。そうでない場合、カーネ ル213は、渡されたイベントの数が１であるかどうか判定する。１である場合、 テストは、イベントに関連づけられたカウンタが０にセットされているかどうか 判定し(1313)、それが０である場合、その値を返す(1319)。カウンタが１にセッ トされている場合、その値は返され(1321)、そのイベント・パラメータに関連づ けられたイベント・ルーチンがタスク指名され(1323)、そこで、制御がカーネル に戻る。イベントの数がステップ1307において１より大きい場合、コールしてい るコンテキストのイベント・リストは、非ゼロのカウンタを有してカーネルに渡 されたイベントを見つけるために横断される(1309)。こうしたイベントが見つか った場合(1311)、そのイベントはイベントのリストの先頭から除去され、最後に 置かれる。戻り値がパラメータのインデックス番号にセットされ(1317)、そのイ ベントのイベント・ルーチンが実行される(1323)。 チェック・イベント・ルーチンは以下のCheck節を使用することによって呼び 出される。 前述の疑似コードの例において、oopsイベントの発生が把握されていない場合 、Check節は０で戻る。これが非ゼロで戻る場合、イベントの把握に関連づけら れたカウンタがデクリメントされる。Check節はまた、コード・プロセッサ227に よって以下のように複数のイベントをテストするよう支援されたプログラミング 環境でも使用されうる。 この構文は、C++、及びCで用いられるswitchステートメントの構文に似ている 。switchステートメントと異なり、caseはイベント・ タイプ（例えばx.attention）の評価を行う表現で構成されうる。これは、コー ド・プロセッサ227が以下のC++コードをCheck節の処理後に生成するので可能と なる。 Check節のcaseの使用は、Check Eventルーチンから戻るイベントに関連づけら れたカウンタのデクリメントも行う。Check節のcaseの使用は、以下のプログラ ミング例と対照的である。 case節の結果は前述のコード例と同じものになる。しかし、Check Eventカー ネル関数は、複数の重要なイベント間のラウンドロビン選択を提供するよう保証 される。対照的に、前述のコードの例は常に、x.attentionイベントより、oops イベントの発生のチェックに優先を与え、従って、複数の非同期イベントのテス トにおける使用には不適格である。 イベントをチェックすることが、コンテキストがイベントの発生を処理する唯 一の方法ではない。wait節は意味的にCheck節と同じであり、Wait Eventカーネ ル・ルーチンに対するコールを生成する。図11Aは、Wait Eventルーチンのフロ ーチャートを示す。Wait EventルーチンとCheck Eventルーチンの唯一の違いは 、カーネル213が、Wait Eventルーチンに渡されたイベントが発生していない(11 05) （戻り値が０）かどうか判定する場合に、Wait Eventルーチンが、指定されたイ ベント（１つ又は複数）が発生するまで、更なる実行によるコンテキストをブロ ックする(1107)ことである。コンテキストの実行をブロックした結果はカーネル の実装のタイプに依存し、本発明のカーネルの単一スタック実装と、複数スタッ ク実装の間の違いに関連して以下で更に説明される。 図12A及び12Bは、ポーリング単一スタック環境におけるWait EventとCheck Ev entルーチンの実装を示している。Check Eventルーチンは機能的には同じで、Wa it Eventルーチンはイベントに対してポーリングを行い(1207)、その待たされた イベントが把握されていないときに、最も高い優先順位のコンテキスト内でイベ ント・ルーチンをコールする(1205)。 イベント・ルーチン、プリエンプティブでかつ優先付けされたコードの実行 コンテキストの範囲内に定義されたイベントは、関連するイベント・ルーチン を有する可能性がある。このイベント・ルーチンは、本発明のカーネルを使用し てプリエンプティブで優先付けされた、コードの実行のための手段を提供し、そ れによって、プリエンプティブ・マルチタスキング環境で必要とされる非同期イ ベントのリアルタイム処理が可能となる。イベント・ルーチンの宣言は以下の疑 似コードで例示される。 イベント・ルーチンの優先付けされた実行は、そのルーチンが定義されるコン テキストの優先順位レベルに基づいている。全てのコンテキストは、それらに関 連づけられた実行優先順位を有し、全ての呼び出しは、より低い優先順位のコン テキストからより高い優先順位のコンテキストに対してでなければならない。イ ベントが、現在実行しているコンテキストより高い優先順位のコンテキストによ って把握されている場合、カーネル213は、そのコンテキストに関して定義され たイベント・ルーチンを実行するために、より低い優先順位のコンテキストの実 行を強制排除することができる。 イベント・ルーチンの実行は同期であることも、また非同期であることも可能 である。コンテキストの範囲内の制御の活動スレッドがなく、ルーチンがカーネ ルによる実行に関してタスク指名される 場合、そのイベント・ルーチンの非同期の実行が発生する。複数スタック環境で は、このタスク指名プロセスは、イベント・ルーチンを実行するタスク（制御の 個別スレッド）の選択を含むことができる。単一スタック環境では、カーネルは ルーチンの単一コールを行うことができる。コンテキスト内に制御の活動スレッ ドがある場合、イベント・ルーチンの実行はWait節、またはCheck節のどちらか が続くまで、又は現在活動中のスレッドがコンテキストの範囲を終了するまで遅 延される。 イベント・ルーチンの同期実行は、コンテキストの中の活動スレッドが明白に イベントに関するCheck節、又はWait節を実行する場合、発生する。この場合、 前に議論した節の意味論に加えて、関連するイベント・ルーチンが、Check節、 又はWait節から戻る前に実行される。イベント・ルーチンの実行は、コンテキス トに関する制御の現在スレッド内で発生しうる（即ち、同期的に）。 イベント・ルーチンはパラメータなしでなければならず、戻り値を持たない（ 空の戻り値を持つ）。カーネル213は、Capture Event関数に対し、パラメータと して任意の関数ポインタの指定を可能にするが、それは、イベントの宣言と実行 されるべきルーチンの間の言語レベルの結合を強いるために、カーネル213によ って支援されるプログラミング方法論を意図するものである。このため、コード ・プロセッサ227は、イベント・ルーチンで宣言されているイベントが把握され た場合に、適切なルーチンの自動割り当てを支援する。別のコンテキスト内で定 義されたイベントが発生した場合に、イベン ト・ルーチンを実行することが、時として好ましい場合がある。任意のルーチン をこの外部で宣言されたイベントの把握に割り当てることができるが、好ましい プロセスは、関連するルーチンで、把握しているコンテキストに対してローカル に新しいイベントを宣言し、その外部イベントをこの新しく定義されたイベント として把握することである。これは、以下の疑似コードの例で示される。 一般的に上述したようなイベント・メカニズムの実施例は、図14ないし図16の フローチャートに示されている。ここで、図14Aを参照すると、本発明に従うプ リエンプティブ複数スタック・カーネル213においてイベントをスケジュールす るルーチンの一実施例のフローチャートが示されている。Schedule Eventルーチ ンは、イベントを処理するためのコンテキストがカーネル213によって見つけら れた後に、内部イベント起動ルーチンからコールされる(753)。一旦コールされ ると、カーネル213はイベント・ルーチンに対するポインタを含む、スケジュー ルされているイベント・ルーチンに関する要素をコ ンテキスト・ルーチン・リストに追加する(1403)。コンテキストによるイベント ・ルーチンの非同期実行を提供するためには、そのイベント・ルーチンが実行さ れる場合に、コンテキスト内に制御の活動スレッドが存在できない。従って、カ ーネル213は、コンテキストの入れ子フラグが０より大きいかどうか、又は制御 の活動スレッドが既にそのコンテキストに割り当てられているかどうかを判定す る(1405)。どちらの場合でも、Schedule Eventルーチンは内部イベント起動ルー チンに制御を戻し、そのイベントはそのスケジュール・リストの最後に追加され る。それ以外の場合、コンテキストが現在活動中でない場合、カーネル213はタ スク・プールからタスクを選択し(1407)、利用可能な空でないタスクがあるか判 定する(1409)。タスクが利用可能である場合、それには、そのイベントを処理し ているコンテキストの実行優先順位と等しいタスク実行順位が割り当てられ(141 3)、そのコンテキストには制御の活動スレッドが割り当てられる。この、タスク にコンテキストの実行優先順位を割り当てることは、処理しているコンテキスト の優先順位に従う、優先付けられたタスクの処理に関するメカニズムを提供する 。従って、低レベル、即ち高い優先順位のコンテキストがイベントを処理するよ う指定された場合、カーネルはそのコンテキストの優先順位を使用して、より低 い実行優先順位のタスク、即ちより高いレベルのコンテキストによって把握され たタスクの実行を強制排除する。そのコンテキストに対するポインタは、そのタ スクのアドレス空間内に記憶され、wakeupセマフォがそのタスクに関して通知さ れる(1415)。 図14Bは、ポーリング単一スタック実施例におけるSchedule Eventルーチンの 実施例を示している。ここでカーネル213は、把握しているコンテキストに対す るポインタを有するリスト要素を生成する(1421)ことだけが必要であり、スケジ ュールされたイベントのカーネルのリスト内のその要素を配置し(1423)、それは 次に、処理しているコンテキストの優先順位に従って先入れ先出し法(first in first out)に基づいて処理される。 図15Aは、コンテキストによって処理されたイベント・ルーチンを、実行の優 先順位を保証しながら実行するためのルーチン1501の一実施例のフローチャート を示す。好適実施例では、イベント・ルーチンはタスクによって実行される。こ のタスクは従来のプリエンプティブな優先付けられた複数スタック環境によって 実装される。このタスクは、タスクに通知された(1415)wakeupセマフォを待つ(1 503)。セマフォが通知された場合、実行コンテキストに対するポインタが検索さ れる(1505)。ルーチンは次にエントリ・セマフォを待つ(1507)。このセマフォは 、コンテキストが呼び出しを終えた場合に通知される(423)。このセマフオを待 つことによって、このルーチンは、重要なイベント・ルーチンが処理されている 間に、コンテキストがイベント・ルーチンを実行するために呼び出されることが ないことを保証する。エントリ・セマフォが通知されると(423)、コンテキスト が実行を終了したことを示し、次に、スケジュールされたイベント・ルーチンを タスク指名するためのルーチンがコールされ(1509)、こうしたルーチンの一例が 図15Cに示されている。コンテキストに関 する全てのイベント・ルーチンがタスク指名され、次に、制御のコンテキストの スレッドが非活動にセットされ(1511)、コンテキストのエントリ・セマフォが通 知される(1513)。このことは、コンテキストがイベント・ルーチンを実行するた めにコールされていることを示している。タスクは次に、タスク・プールに戻る (1515)。 図15Cは、コンテキストにとって重要な全てのイベント・ルーチンが、新しく スケジュールされたイベント・ルーチンの非同期実行の前にタスク指名されるこ とを保証するための、Dispatch All Eventsルーチンの一実施例のフローチャー トを示す。この実施例では、ルーチンが、コンテキストのルーチン・リストから 、イベント・ルーチンに対するポインタを検索し(1537)、その要素をそのリスト から除去する。カーネル213は次に、コンテキストのルーチン・リストが空かど うか判定し(1539)、空であれば、そのコンテキストに関してスケジュールされた 全てのルーチンが処理され、ルーチンが戻る（1541)。コンテキストのルーチン ・リスト上にイベント・ルーチンが残っていれば、イベント・タスク指名ルーチ ンをコールすることによって、検索されたイベント・ルーチンがタスク指名され る(1543)。ルーチンが実行されると(1543)、それは、イベント・ルーチンが、完 了を待っている実行のためにスケジュールされた回数を示す値を戻す。このカウ ンタが０である場合（ステップ1545）、そのルーチンはコンテキストのルーチン ・リストから削除される。それ以外の場合、ルーチンは、それが再度検索され(1 537)、タスク指名され(1543)るように、ルーチン・リストの最後に再インサート される（154 9)。このループは、イベント・ルーチンが、スケジュールされた全ての実行を完 了するまで繰り返される。 図16は、Dispatch A1l Eventsルーチン1535、及びExit Contextルーチン417に よってコールされる(1543)、イベント・ルーチンをタスク指名するためのDispat ch Eventルーチン1601の一実施例を示す。このルーチンは、コールされた場合、 そのルーチンが現在活動中かを、そのルーチンに関するフラグが示すかどうかを 判定する(1603)。活動中である場合、カーネル213はエラーとなる(1605)。それ 以外の場合、カーネル213は、ルーチンが現在活動中であることを示すようにそ のフラグをセットする(1607)。イベント・ルーチンは、そのイベント・ルーチン へのポインタを使用してコールされ(1609)、実行される。実行が完了すると、フ ラグが、そのルーチンがもはや活動中でないことを示すようリセットされる(161 1)。実行前のこれらの制御フラグのスレッドをチェックするステップ、及びフラ グをセット、及びリセットする次のステップは、直接的、あるいは間接的にイベ ント・ルーチンがそれ自身をコールすることを防止することによって、無制限の 再帰を防ぐ。フラグの使用は、任意の所与の時間においてコンテキスト内に単一 の制御のスレッドだけを保証することによって、非再入コードも防止する。フラ グをリセットした後で、イベント・ルーチンのカウンタがデクリメントされ(161 3)、そのイベントの実行サイクルの１つが完了したことを示す。このカウンタ値 は次に、上述したようにコールしているルーチンに戻され(1615)、イベント・ル ーチンに対するポインタを検索し(1537)、イベント・ ルーチンを再度タスク指名する(1543)ことによって、別の実行サイクルを生じさ せる。 図15Bは、ポーリング、単一スタック環境におけるDispatch Eventルーチンの 実施例のフローチャートを示す。このルーチンは、それがイベントにポーリング を行い、それらを優先順位に従って実行するのに必要である場合に、ポーリング 環境でコールされる。図5A、5B、及び12Aは、ポーリングDispatch Eventルーチ ン1518をコールするルーチンを示す。 複数スタック・カーネル 対 単一スタック・カーネル 上述したように、本発明は単一スタック環境でも、複数スタック環境でも実施 される。カーネル213によって提供された優先付けられたイベント処理によって 、リアルタイム・アプリケーションの開発に関して両方の環境が使用可能である 。複数スタック・カーネルは、イベントの発生を、好ましくない他のコードの単 位のブロッキングを起こすことなく待つことができる、有利なコードを提供する 。 図17は、複数スタック環境で使用されるソフトウエア・アプリケーションの呼 び出し構造を示す。この例では、コンテキストＨが、コンテキストＣによって提 供されたサービスにコールを行う(1701)ことを仮定する。更にこのサービスが、 コールしたコンテキストに戻る前に、イベントの発生を待つものとする。ここで は、非同期イベントがコンテキストＧによって把握され、それがコンテキストＤ へのサービス・コールを生成する(1703)ものとする。このコード実行のシーケン スは、コンテキストＣが依然イベントが起きるのを待 っているときでさえ、実行を許可される。カーネルの複数スタック実装は、この タイプの同時実行を許可する。しかし、コンテキストＡが非同期イベントを把握 し、かつコンテキストＣにサービス・コールをする(1705)ものである場合、コン テキストＨから起動しているコンテキストＣ内に、制御の活動スレッドが既に存 在するため、そのイベントはEnter Contextメカニズムによってブロックされる 。従って、このカーネルの複数スタックの実施例は、コールされたコンテキスト の中に制御のスレッドがなく、更にそのコールされたコンテキストがコールした ものの優先順位より高いことを保証するためにチェックを行う。 カーネル213は、単一スタック実装においても具現化される。図17のソフトウ エア・アプリケーション、及び呼び出し構造を使用すると、コンテキストＨがコ ンテキストＣをコールし(1701)、コンテキストＣがイベントの発生を待つ場合、 コンテキストＣより高い優先順位のコンテキスト内のイベント・ルーチンだけが 、この待機期間の間に実行を許可される。従って、コンテキストＣが依然イベン トを待っている間に、非同期イベントがコンテキストＡ内で把握されたとすると 、コンテキストＡは、コンテキストＨからコンテキストＣへの実行のスレッドが 完了するまで、ブロックされる。カーネルの単一スタックの実施例は、コンテキ ストＣ内のイベントを待っている間、依然として、コンテキストＤ、Ｅ、及びＦ に関連付けられたイベント・ルーチンをタスク指名することができる。更に、こ のカーネルの単一スタック実施例は、コールされたコンテキスト内に 制御の活動スレッドがあるかどうかチェックする必要がない。コールされたコン テキストがコールしたコンテキストの優先順位より高いことを単にチェックする ことで、この条件を十分保証できる。 カーネル213の両バージョンは、コードの構造に一定の保証を提供するもので ある。コンテキスト条件毎の制御の単一スレッドが維持される。従って、コード の再入が除去され、プログラマに見える危険地域がない。コンテキストの呼び出 しが完全に階層的であるため、コンテキスト間の再帰はあり得ない（コンテキス ト内の再帰は許される）。両タイプのカーネルは、Wait条件の周期的入れ子がコ ンテキストの範囲内で発生しないことを保証するよう、イベント・ルーチン内で Waitステートメントの使用を制限する。コンテキスト間の待ちが階層的であるよ う保証されたので、待ち(wait-for)条件の周期が禁止され、デッドロック条件は 発生しない。 カーネル213の複数スタックのバージョンを単一スタックのバージョンの上級 版として見ることができるが、両タイプのカーネルはそれぞれ用途がある。単一 スタック・カーネルは、複数スタック操作を支援しない既存のコードと、より良 好に統合される。コードの構成要素は、好ましくないブロッキングを避けるため に状態駆動型で書かれうる。ある例では、支援されるアプリケーションはいくつ かの同位レベルのコード・エンティティを必要とせず、単一スタック環境内で提 供される強制排除機能が、アプリケーションに求められる全てとなることがある 。組み込みシステムにおいて特に真であり、その場合、単一スタック・カーネル は小さなアドレス空間を有する 構成要素のボード上で使用されうる。単一スタック・カーネルに対する縮小シス テムの要件は、こうした場合にそれを最も好ましいカーネルとすることである。 単一スタック／複数スタックはカーネル実装において最も差があるが、他の変 形が存在する。分散カーネルは、バラバラなアドレス空間にわたるEvent Handle の実施を提供する。マルチプロセッサ・カーネルは、複数のCPUを、様々なコン テキストを正しく同時に実行させるように同調させる。これらの様々な実装は、 ここで開示する本発明の範囲内に含まれるものと考えられる。 プリエンプティブ・カーネル 対 ポーリング・カーネル 本発明のカーネルの実施例は更に、ポーリング・カーネルとプリエンプティブ ・カーネルに分割される。イベントがコンテキストによって把握されると、イベ ント・ルーチンは実行のためにスケジュールされる。コンテキストを把握する優 先順位が、現在実行しているコンテキストの優先順位より高ければ、カーネルは そのイベント・ルーチンをプリエンプティブに実行することができる。上述の複 数スタック・カーネルは、プリエンプティブ・カーネルの例である。 図5A及び5Bはポーリング・カーネルにおけるEnter ContextとExit contextル ーチンを示している。本発明のポーリング・カーネルの実施は、図15Bに示すよ うにPoll Eventカーネル関数505が実行されるまで、実際にイベント・ルーチン の実行を遅延させる。このイベントは、次のコンテキストの呼び出しの前に発生 しなければならない。このため、Poll Event関数は、単一スタック・カーネル21 3のE nter Context操作501内で呼び出される(505)。この要件は、カーネルのポーリン グ・カーネルの実装を、イベントの発生とそのイベントに関連づけられたイベン ト・ルーチンの実行の間に大きな待ち時間の遅れが存在するという１つの例外を 有する、プリエンプティブ・カーネルと意味的に同等に保つ。更に、カーネル21 3のポーリング実施において、アプリケーション215は、Poll Eventカーネル・メ カニズムが、システムがアイドル状態の時はいつでも周期的に呼び出されるか、 又はイベント処理がイネーブルとなる、繰り返された命令のループ内に関与する ことを保証しなければならない。 ポーリング・カーネルが提供する、プリエンプティブの実装より有利な点は、 それが従来のプログラミング環境に、いかなる特別のオペレーティング・システ ムの支援なしに組み込まれうることである。 ポーリング・カーネルとプリエンプティブ・カーネルの間の差に関して、本発 明の範囲内の他の実施例は、複数スタック・ポーリング・カーネル、及び単一ス タック・プリエンプティブ・カーネルを含み、その構成は前述した説明及びプロ セスに基づく。 カーネル・メカニズムのハードウエア実装 ハードウエア・アーキテクチャはコンピュータの設計に含まれるトレード・オ フに関連する。この設計の一態様は、コンピュータの命令セットの定義である。 命令セットによってコンピュータの処理能力を低レベルで見ることができる。命 令セットの単純さ（例えば縮小命令セット・コンピュータ(RISC)）の維持、及び 命令セットを 複雑にする、より強力なメカニズム(CISC)の提供との間には通常トレード・オフ がある。 本発明のカーネルによって提供されたメカニズムの全ては、コンピュータの命 令セット内に実装されうる。特に、コンテキストの開始／終了毎に実行されなけ ればならないEnter Context、及びExit Contextカーネル関数は、それらの操作 を保証し、システム性能を向上させるために命令セット内に好適に組み込まれう る。これらの操作を支援するためのルーチンは、提供されたカーネルのタイプ（ 単一スタック／複数スタック）に依存するので、全体の操作が単一のマシン命令 内に統合されている必要はない。その代わり、単純な現在コンテキスト・ポイン タの組み込み、及びコンテキストの開始／終了に関して自動優先順位チェック及 び変更を支援することは、両方の環境に対して命令レベルの支援を提供する。終 了コンテキスト・ルーチンは、手順コール命令からの従来の戻りを、ランタイム ・システムに割り込む命令に置換することによって、命令セット内で拡張され、 イベントのタスク指名に関するテストを行う。 命令セット内の開始／終了コンテキスト支援に加えて、全体イベント・メカニ ズムはプロセッサ201の命令セット内に含まれる。その命令セット内のイベント ・メカニズムの直接の支援は、多くのコンピュータの命令セット内で支援されて いる割り込みサービス・ルーチン(ISR)の存在を不必要にする。 メモリの可視性 本発明の更なる一実施例は、コンテキスト間のメモリの可視性を 制御する方法を支援することである。ここで述べられた様々な実施例が、コンテ キスト間に無制限のメモリの可視性を提供する。しかし、本発明で使用されるプ ログラミング方法論は、コンテキストの可視性の要件を支援するのに十分で、よ り高い優先順位のコンテキストがより低い優先順位のコンテキストのアドレス空 間を変更する権利を有しており、逆は不可である。プロセッサ201の命令セット 内でイベント及びコンテキスト・メカニズムが支援される、カーネル213の好適 実施例は、これらの可視性の要件を強制する。このコンテキストの階層は、むし ろプログラマが明確に可視性を指定するより、メモリの可視性を暗に定義するの に使用される。メモリの保護がプロセッサ201によって直接支援されるので、ソ フトウエア・プログラマは、メモリの保護要件を直接指定しなければならないと いうことから開放され、またここでもアプリケーション215の信頼性と性能を向 上させる。

───────────────────────────────────────────────────── 【要約の続き】 トの処理をタスク指名する。

Claims (1)

1. 【特許請求の範囲】 １． アプリケーション内のコンテキスト間で階層的な呼び出し構造を強制する 方法であって、前記アプリケーションは複数のコンテキストを含み、前記コンテ キストのそれぞれは、そのコンテキストの呼び出し構造によって判定された実行 優先順位を有しており、ここで、より低い実行優先順位のコンテキストと、より 高い実行優先順位のコンテキストが提供され、前記方法が、 呼び出しコンテキストによって呼び出されたコンテキストの呼び出しを示すス テップ、 前記呼び出しコンテキストの実行優先順位を判定するステップ、及び 前記呼び出されたコンテキストの実行優先順位が前記呼び出しコンテキストの 実行優先順位以上である場合に、呼び出しを許可するステップを含むことを特徴 とする、前記方法。 ２． 前記呼び出しコンテキストの実行優先順位を判定する前記ステップが、 コンテキストが自身を呼び出しているかどうか判定するステップ、及び 前記呼び出されたコンテキストの優先順位が前記呼び出しコンテキストの優先 順位より高いかどうか判定するステップを更に含むことを特徴とする、請求項１ に記載の方法。 ３． 呼び出しを許可する前記ステップが、 前記呼び出されたコンテキストの実行優先順位に基づいて、前記呼び出された コンテキスト内のイベント・ルーチンの実行優先順位を確立するステップ、及び 前記呼び出されたコンテキストの実行レベルを上げるステップを更に含むこと を特徴とする、請求項２に記載の方法。 ４． 前記呼び出されたコンテキスト内のルーチンを実行するステップ、 前記呼び出されたコンテキストの実行レベルを下げるステップ、 前記呼び出されたコンテキストに関して更に任意の実行レベルが存在するか判 定し、更に任意の実行レベルが存在する場合には、前記ルーチンの実行を繰り返 すステップ、 前記呼び出されたコンテキスト内に実行レベルがもうない場合： 前記呼び出されたコンテキストがそのイベント・ルーチンの実行を完了した ことを示すステップ、 実行の制御を呼び出しコンテキストに戻すステップ、及び 現在のイベント・ルーチンの優先順位を、呼び出しコンテキストの実行優先 順位にセットするステップを更に含むことを特徴とする、請求項３に記載の方法 。 ５． アプリケーション内のコンテキスト間で階層的な呼び出し構造を強制する 方法であって、前記アプリケーションは複数のコンテキストを含み、前記コンテ キストのそれぞれは、そのコンテキストの呼び出し構造によって判定された実行 優先順位を有しており、ここで、より低い実行優先順位のコンテキストと、より 高い実行優先 順位のコンテキストが提供され、前記方法が、 呼び出しコンテキストによってコンテキストが呼び出される際に、開始コンテ キスト操作を実行するステップであって、ここで、呼び出されたコンテキストが 呼び出しコンテキストであり得る前記ステップ、及び 呼び出されたコンテキスト内の手順が終了した際に、終了コンテキスト操作を 実行するステップを含むことを特徴とする、前記方法。 ６． 前記開始コンテキスト操作を実行する前記ステップが、 コンテキストがそれ自身を呼び出しているかどうかを判定するステップ、 前記呼び出されたコンテキストの実行優先順位が前記呼び出しコンテキストの 実行優先順位より高いかどうかを判定するステップ、 前記呼び出されたコンテキストが前記呼び出しコンテキストより高い実行優先 順位である場合： 前記呼び出されたコンテキストの実行優先順位に基づいて、前記呼び出され たコンテキスト内のイベント・ルーチンの実行優先順位を確立するステップ、及 び 前記呼び出されたコンテキストの実行レベルを上げるステップを更に含むこ とを特徴とする、請求項５に記載の方法。 ７． 終了コンテキスト操作を実行する前記ステップが、 前記呼び出されたコンテキストのイベント・ルーチンの実行レベルを下げるス テップ、 前記呼び出されたコンテキストに関し、更に任意の実行レベルが あるかを判定するステップ、 前記呼び出されたコンテキスト内にもう実行レベルがない場合： 前記呼び出されたコンテキストが、そのイベント・ルーチンの実行を完了し たことを示すステップ、 実行制御を呼び出しコンテキストに戻すステップ、及び 現在のイベント・ルーチンの優先順位を呼び出しコンテキストの実行優先順 位にセットするステップを更に含むことを特徴とする、請求項５に記載の方法。 ８． 複数のコンテキストを有するアプリケーション内のコンテキスト間で制御 の単一スレッドを強制する方法であって、前記方法が、ルーチンを実行するコン テキストを判定するステップ、 コンテキスト内に制御の活動スレッドが存在するかどうか判定するステップ、 制御の活動スレッドを有するコンテキストによって、前記コンテキストがもは や制御の活動スレッドを有さなくなるまで、前記ルーチンの実行を遅延させるス テップ、及び 前記コンテキストがもはや制御の活動スレッドを有さなくなったときに、コン テキスト内の前記ルーチンの実行を続けるステップを含むことを特徴とする、前 記方法。 ９． 複数のコンテキストを含み、各コンテキストが前記コンテキストの呼び出 し階層によって判定され、割り当てられた実行優先順位を有し、ここで、より低 い実行優先順のコンテキストと、より高い実行優先順位のコンテキストが提供さ れ、少なくとも１つのコン テキストが更に、少なくとも１つのイベント・ルーチンを含むアプリケーション において、実行優先順位に従ってスケジュールされたイベント・ルーチンを実行 する方法が、 コンテキスト内の少なくとも１つのイベント・ルーチンをスケジュールするス テップ、 前記コンテキスト内に制御の活動スレッドがあるかどうか判定するステップ、 前記コンテキスト内に制御の活動スレッドがない場合に、前記コンテキストの 実行優先順位と同じ実行優先順位を、前記スケジュールされたイベント・ルーチ ンを実行するタスクに割り当てるステップ、及び 前記スケジュールされたイベント・ルーチンを実行するようタスクを起動する ステップを含むことを特徴とする、前記方法。 10． コンテキスト内の少なくとも１つのイベント・ルーチンをスケジュールす るステップが、 イベントの発生を示すステップ、 少なくとも１つのコンテキストによって要求されたイベントの処理を示すステ ップ、 前記イベントを処理するコンテキストを判定するステップ、 前記イベントを処理するための処理コンテキスト内に、イベント・ルーチンが あるかどうか判定するステップ、及び 前記処理コンテキスト内にイベント・ルーチンがある場合、タスクによる実行 に関して前記イベント・ルーチンを指定するステップ を更に含むことを特徴とする、請求項９に記載の方法。 11． 前記方法が、複数スタック・プログラミング環境で使用されるよう開発さ れたアプリケーション内で、呼び出し構造を強制するために使用されることを特 徴とする、請求項１に記載の方法。 12． 前記方法が、単一スタック・プログラミング環境で使用されるよう開発さ れたアプリケーション内で、呼び出し構造を強制するために使用されることを特 徴とする、請求項１に記載の方法。 13． 前記方法が、マイクロプロセッサの命令セット内で実施されることを特徴 とする、請求項１に記載の方法。 14． 前記方法が、前記コンテキストを含むアプリケーションのアドレス空間に リンクされたコード・ライブラリ内に提供され、ここで、前記コンテキスト内に 含まれるプログラミング言語の拡張を、前記方法を呼び出すための手順コールに 変換するコード・プロセッサも提供されることを特徴とする、請求項１に記載の カーネル。 15． 前記方法が、複数スタック・プログラミング環境で使用されるよう開発さ れたアプリケーション内で、呼び出し構造を強制するために使用されることを特 徴とする、請求項５に記載の方法。 16． 前記方法が、単一スタック・プログラミング環境で使用されるよう開発さ れたアプリケーション内で、呼び出し構造を強制するために使用されることを特 徴とする、請求項５に記載の方法。 17． 前記方法が、マイクロプロセッサの命令セット内で実施されることを特徴 とする、請求項５に記載の方法。 18． 前記方法が、前記コンテキストを含むアプリケーションのア ドレス空間にリンクされたコード・ライブラリ内に提供され、ここで、前記コン テキスト内に含まれるプログラミング言語の拡張を、前記方法を呼び出すための 手順コールに変換するコード・プロセッサも提供されることを特徴とする、請求 項５に記載のカーネル。 19． 前記方法が、複数スタック・プログラミング環境で使用されるよう開発さ れたアプリケーション内で、制御の単一スレッドを強制するために使用されるこ とを特徴とする、請求項８に記載の方法。 20． 前記方法が、単一スタック・プログラミング環境で使用されるよう開発さ れたアプリケーション内で、制御の単一スレッドを強制するために使用されるこ とを特徴とする、請求項８に記載の方法。 21． 前記方法が、マイクロプロセッサの命令セット内で実施されることを特徴 とする、請求項８に記載の方法。 22． 複数のコンテキスト及びコンテキスト間の呼び出し構造を含むアプリケー ションを実行するためのマイクロプロセッサであって、各コンテキストは前記呼 び出し構造によって判定される実行優先順位を有し、ここで、より低い実行優先 順位のコンテキストと、より高い優先順位のコンテキストが提供され、前記マイ クロプロセッサが、 呼び出しコンテキストによるコンテキストの呼び出しを示すステップ、 前記呼び出しコンテキストの実行優先順位を判定するステップ、及び 前記呼び出されたコンテキストの実行優先順位が、呼び出しコン テキストの実行優先順位以上である場合に、前記呼び出しを許可するステップを 実行することによって、コンテキスト間の階層呼び出し構造を強制するための複 数の命令を含むことを特徴とする、前記マイクロプロセッサ。 23． 複数のコンテキストを含むアプリケーションを実行するためのマイクロプ ロセッサであって、前記マイクロプロセッサが、 ルーチンを実行するコンテキストを判定するステップ、 前記コンテキスト内に制御の活動スレッドが存在するかどうか判定するステッ プ、 前記コンテキストがもはや制御の活動スレッドを有さなくなるまで、前記制御 の活動スレッドを有する前記コンテキストによって前記ルーチンの実行を遅延さ せるステップ、及び 前記コンテキストがもはや前記制御の活動スレッドを有さなくなったとき、前 記コンテキスト内の前記ルーチンの実行を続けるステップを実行することによっ て、コンテキスト間の制御の単一スレッドを強制するための複数の命令を含むこ とを特徴とする、前記マイクロプロセッサ。