JP3395921B2 - プログラマブル・イベント連絡方法 - Google Patents

Description

【発明の詳細な説明】 【０００１】 【産業上の利用分野】本発明は、計算機システムにおけ
るプログラムの非同期実行に関し、特に、分散コンピュ
ーティング環境において、ネットワーク上に分散された
複数サーバや複数プロセスと連絡して処理を遂行するよ
うなプログラムが、自ホストや他ホストからの複数のイ
ベントの発生を待つ場合に、個々のイベントの発生をＡ
ＮＤやＯＲで条件付けして、その条件で組み合わされた
イベントの発生を待つのに好適なプログラマブル・イベ
ント連絡方法に関する。 【０００２】 【従来の技術】従来技術におけるイベントの連絡方法と
しては、例えば、株式会社日立製作所のＯＳ（オペレー
ティングシステム）であるＶＯＳ３のマニュアルの「ス
ーパバイザマクロ（ＶＯＳ３／ＡＳ ６１８０−３−１
３１−１０）」のページ８４〜８７、９４、および９５
に記載されているＷＡＩＴ機能とＰＯＳＴ機能がある。 【０００３】ＷＡＩＴマクロは、イベントを待つための
マクロであり、具体的には、イベントを待つにあたって
以下の機能を実現する。 【０００４】（１）一個のイベントを指定し当該イベン
トのみの発生を待つ。 （２）複数のイベントを指定して、その内の任意の数の
イベントの発生を待つ。 また、ＰＯＳＴマクロは、上記のＷＡＩＴマクロで指定
されたイベントの一つに対して、その発生を通知する機
能を実現するマクロである。 【０００５】 【発明が解決しようとする課題】上記従来技術では、Ｗ
ＡＩＴマクロの上記（２）の機能により、（１）ｎ個の
イベントを指定し、１個のイベントを待つようにすれ
ば、オア（ＯＲ）条件で複数イベントの内の一つを待つ
ことが可能であり、（２）ｎ個のイベントを指定し、こ
れと同数のｎ個のイベントを待つようにすれば、複数イ
ベントの発生をアンド（ＡＮＤ）条件で待つことが可能
である。 【０００６】しかし、複数イベントのうちの、いくつか
のイベントはＯＲ条件を指定し、他のいくつかはＡＮＤ
条件を指定して、さらに両者の指定条件が共に成立する
のを待つ、と言ったような条件付き組み合わせを指定し
てイベントの発生を待つことが出来ないと言う問題があ
った。 【０００７】そのため、上記のようにいくつかのイベン
トに対してＯＲ条件とＡＮＤ条件を組み合わせた条件で
イベントの発生を待つようにするためには、イベントが
発生する度に、ＯＳからユーザプログラムに制御を戻
し、ユーザプログラムでその条件が満たされたか否かを
判別して処理を進めていく必要があった。しかし、その
ようにすると、イベントが発生する度にＯＳとユーザプ
ログラム間で制御の受渡やアドレス空間の切り替えが発
生し、これがオーバヘッドとなると言う問題があった。 【０００８】本発明の目的は、上記の問題を解決し、よ
り自由度が高く、かつユーザプログラムとＯＳ間の制御
の受渡などのオーバヘッドが少ないプログラマブル・イ
ベント連絡方法を提供することにある。 【０００９】 【課題を解決するための手段】本発明では、複数イベン
トを、少なくとも１つのグループは複数のイベントを含
むような複数のグループに分割し、各グループ毎に、Ａ
ＮＤやＯＲ条件を指定できるようにし、さらに各グルー
プ間に対してもＡＮＤやＯＲ条件を指定できるようにし
た。特に、前記各グループ毎の条件を葉、各グループ間
の条件を節または根に対応させた木構造を指定できるよ
うにし、ユーザは、上記の木構造を作成してイベントの
発生を待ち、ＯＳが複数イベントの内の、個々のイベン
ト発生が発生した際に、当該イベントがいずれのグルー
プに属するかを調べ、そのグループに指定された条件が
当該イベントの発生により満たされたか否かを調べ、満
たされていれば、木構造の根方向に位置する別のグルー
プに対して同様の処理を繰り返し、順次イベントの発生
を伝搬し、根に達した時点で始めて、ユーザに対しイベ
ントの発生を通知する。 【００１０】これにより、指定された条件が整った場合
にのみイベントの発生を連絡するようにしたので、より
自由度の高いプログラマブルかつ、ユーザプログラムと
ＯＳ間での制御の受渡やアドレス空間の切り替えが多発
しない低オーバヘッドのイベント連絡方法を提供する事
が可能となる。 【００１１】 【作用】複数イベントをグループに分割し、各グループ
毎に条件設定やグルーブ間の条件指定を可能とし、これ
らの条件を木構造で表現する事により、ユーザが任意の
条件組み合わせでイベントの発生を待つ事が可能とな
り、イベント待ち条件の自由度が向上する。また、ユー
ザが指定した任意の条件が整った場合にのみイベントの
発生を連絡するようにしたので、ユーザプログラムとＯ
Ｓ間の前記オーバヘッドの問題も解決出来る。 【００１２】 【実施例】以下、図面を用いて本発明の一実施例を述べ
る。 【００１３】図１は、本発明のプログラマブル・イベン
ト連絡方法を適用した実施例の全体構成を示す。この実
施例のシステムは、ユーザプログラム１、制御プログラ
ム（以下、ＯＳと呼ぶ）１０、ネットワーク２０、およ
びディスク２１により構成されている。ユーザプログラ
ム１およびＯＳ１０は、汎用の計算機上で動作している
プログラムである。 【００１４】ユーザプログラム１は、非同期に動作可能
な制御タスク１００と制御タスク１００の子タスクであ
るタスク２００およびタスク３００の３つのタスクで構
成される。また、ユーザプログラム１は、ユーザプログ
ラムにイベントの発生を連絡する際に、どのような条件
が整った場合に連絡するかを指定するＥＣＢリスト３０
を含む。 【００１５】ＯＳ１０は、ユーザプログラム１からの入
出力要求を仲立ちするＩＯスーババイザ１１、イベント
連絡用のＷＡＩＴ処理１２とＰＯＳＴ処理１３、および
プログラムの実行をスケジューリングするディスパッチ
ャ１４を含む。このうち、本発明に係る特徴的な部分
は、イベント連絡用のＷＡＩＴ処理１２およびＰＯＳＴ
処理１３と、ＯＳ１０からユーザプログラムにイベント
の発生を連絡する際の条件を指定するＥＣＢリスト３０
である。 【００１６】以下では、まず本発明のイベント連絡方法
を利用したプログラム処理全体の処理の流れを説明し、
その後、本発明に係るイベント連絡方法の本実施例にお
ける実現方法について詳細に説明する。 【００１７】図１において、まず制御タスク１００は、
子タスクの準備完了や後で述べるデータ入力完了などの
イベント連絡用のＥＣＢリスト３０を作成する（ステッ
プ１０１）。 【００１８】ＥＣＢリスト３０の構成については後述す
るが、本実施例ではいくつかのイベント発生をａｎｄ条
件やｏｒ条件でグループ化し、さらにそのグループ単位
のイベント発生に対しても同様にａｎｄ条件やｏｒ条件
を付与し、全体としてａｎｄ条件とｏｒ条件を階層的に
組み合わせた複雑な条件でイベント発生を待つことがで
きる。 【００１９】図１のＥＣＢリスト３０の例では、ｄａｔ
ａ Ａｉの入力完了と子タスクＡが実行可能となるのを
ａｎｄ条件で待つグループＡ、およびｄａｔａ Ｂｉの
入力完了と子タスクＢが実行可能となるのをａｎｄ条件
で待つグループＢを設定し、グループＡ，Ｂのイベント
発生をｏｒ条件で待つようにしている。 【００２０】なお、前記の子タスクが実行（動作）可能
となると言うことの意味は、プログラムの起動直後では
初期化などの動作が完了しデータを受け付ける事が可能
となった状態を言い、初期化完了以降では以前に受け付
けたデータの処理が完了し新たなデータを受け付ける事
が可能となった状態を言う。 【００２１】ＥＣＢリスト３０の作成（ステップ１０
１）の後、前記ＯＳ１０の一部であるＩＯスーパバイザ
１１に対して、データのＲＥＡＤ（読み込み）を要求す
る（ステップ１０２，１０３）。具体的には、ステップ
１０２でネットワーク２０からのｄａｔａ Ａｉ（ｉは
順次入力するデータのｉ番号の意味）のＲＥＡＤを要求
し、ステップ１０３でディスク２１からのｄａｔａ Ｂ
ｊ（ｊは順次入力するデータのｊ番号の意味）のＲＥＡ
Ｄを要求している。 【００２２】その後、後続するステップでこれらのＲＥ
ＡＤの完了と、これらのＲＥＡＤで入力されたデータを
処理する子タスクであるタスク２００またはタスク３０
０が動作可能となるのを待つため、前記作成済みのＥＣ
Ｂリスト３０を指定してＷＡＩＴマクロを発行する（ス
テップ１０４）。ここで発行するＷＡＩＴマクロは、従
来技術の説明で述べたＷＡＩＴマクロに対して、本発明
に基づいて機能拡張したものである。 【００２３】発行されたＷＡＩＴマクロは、ＯＳ１０の
一部であるＷＡＩＴ処理１２により処理される。ＷＡＩ
Ｔ処理１２の詳細は図４を参照して詳述するが、その処
理の概要は以下のようなものである。 【００２４】即ち、ＷＡＩＴ処理１２は、待つべき要求
されたイベントの発生を管理するテーブル（図５で詳述
するＰＯＳＴ管理テーブル）を作成した後、制御タスク
１００をＷＡＩＴ状態にするために所定のフラグを操作
し、タスクのスケジュールを担当するディスパッチャ１
４に制御を渡し、処理を終える。 【００２５】ディスパッチャ１４は、制御が渡される
と、制御タスク１００をスケジュール対象から外し、そ
のＯＳ１０で定められているスケジューリングに従って
他のタスクの起動を実施する。 【００２６】前記ＷＡＩＴマクロ発行時のＥＣＢリスト
３０で指定した各々の条件のイベントが発生すると、そ
れらのイベントに対応するＰＯＳＴが各々発行される。
例えば、ＩＯスーパバイザ１１からはｄａｔａ Ａｉや
ｄａｔａ ＢｊのＲＥＡＤ完了を示すＰＯＳＴが発行さ
れ、タスクＡ２００やタスクＢ３００からはタスクが実
行（動作）可能となったときレディ通知のＰＯＳＴが発
行される。 【００２７】これらのＰＯＳＴは、ＯＳ１０の一部であ
るＰＯＳＴ処理１３により処理される。ＰＯＳＴ処理１
３の詳細は図６を参照して詳述するが、その概要は、Ｅ
ＣＢリストやＰＯＳＴ管理テーブルを参照して、指定さ
れた条件が満たされていたときは制御タスク１００を再
起動するために所定のフラグを操作して、ディスパッチ
ャ１４に制御を渡し処理を終える、というものである。 【００２８】これにより、ＷＡＩＴ状態であった制御タ
スク１００はディスパッチャ１４により再起動され、制
御タスク１００の前記ＷＡＩＴマクロ（ステップ１０
４）の直後からの処理が続行される。 【００２９】再起動された制御タスク１００では、ま
ず、再起動の要因となったイベントが何で有るかをＥＣ
Ｂリスト３０から知る（ステップ１０５）。具体的に
は、ＥＣＢリスト３０上のＥＣＢ管理テーブル４０−１
から知るが、ＥＣＢ管理テーブル４０−１の詳細につい
ては後述する。 【００３０】次に、次回のＷＡＩＴマクロの発行に備え
て（ＥＣＢリスト３０に設定した条件を変更したい場合
は必要に応じて）ＥＣＢリスト３０を再設定し（ステッ
プ１０６）、上記で調べたイベント発生要因に対応した
子タスク（タスクＡまたはタスクＢ）を起動し（ステッ
プ１０７）、入力されたデータの処理を行なう。 【００３１】前記ＥＣＢリスト３０では、図１に示すよ
うな条件が指定されており、ネットワーク２０からデ
ータが到着し、かつ、それを処理すべきタスクＡがデー
タを受け入れ可能状態にある場合、または、ディスク
２１からのデータ入力が完了し、かつ、それを処理すべ
きタスクＢがデータを受け入れ可能状態にある場合のい
ずれかの場合（または、両方の場合）に、ＷＡＩＴ（ス
テップ１０４）が解除され、対応する処理が実行され
る。 【００３２】以上のようにして、子タスクを起動し子タ
スクが処理を実行している間に、次のデータを入力する
ために、前記ＲＥＡＤ（ステップ１０２）からの処理を
繰り返す。 【００３３】以上が本発明のイベント連絡方法を利用し
たユーザプログラム１の全体動作の概要である。 【００３４】なお、図１に示す実施例では、説明の簡単
化のためにＲＥＡＤ（ステップ１０２）とＲＥＡＤ（ス
テップ１０３）が繰り返しループ内で常に実施されるよ
うになっているが、正確にはステップ１０５で調べたイ
ベント発生要因に対応してＲＥＡＤが発行される。 【００３５】また、図１にＥＣＢリスト３０で指定され
ている条件や個々のイベントの数や種類は、本実施例に
固有のものであり、本発明に制約を与えるものではな
い。 【００３６】次に、図２〜図６を用いて、上述した本実
施例のイベント連絡方法の詳細について説明する。ま
ず、図１のＥＣＢリスト３０の詳細、即ちＯＳ１０から
ユーザプログラム１にイベントの発生を連絡する際に、
どのような条件が整ったら連絡するか、その条件を示す
ためのＥＣＢリスト３０の詳細を述べる。 【００３７】図３はＥＣＢリスト３０の全体の構成を示
し、図２はＥＣＢリスト３０を構成する１つのＥＣＢ管
理テーブル４０の形式を示す。図３において、４０−
１、４０−２，４０−３は、それぞれ、図２の形式のＥ
ＣＢ管理テーブルである。図３に示すように、ＥＣＢリ
スト３０は、図２の形式のＥＣＢ管理テーブルにより構
成される木構造となっている。木構造にしたがって、各
ＥＣＢ管理テーブルは、各々、ルート（根）、ノード
（節）、またはリーフ（葉）の何れかに対応する。 【００３８】なお図３では、説明の簡単化のため、ノー
ドに相当するＥＣＢ管理テーブルは省略し、ＥＣＢ管理
テーブル４０−１がルートに、ＥＣＢ管理テーブル４０
−２と４０−３がリーフに、それぞれ相当する構成とし
ている。 【００３９】このような木構造のリーフに相当するＥＣ
Ｂ管理テーブル（図３では４０−２と４０−３）から、
個々のイベントに関する実際のＥＣＢ−１（５１）〜Ｅ
ＣＢ−４（５４）が指し示される。 【００４０】図２を参照して、ＥＣＢ管理テーブルの形
式について詳しく説明する。ＥＣＢ管理テーブルは、複
数イベントをグループ化しグループに含まれる個別の各
イベント間の関係条件を指定したり、また、複数のグル
ープ間の関係条件を指定するためのテーブルである。 【００４１】ＥＣＢ管理テーブルが、図３の木構造のリ
ーフに相当する場合、そのＥＣＢ管理テーブルは、複数
イベントをグループ化しグループに含まれる個別の各イ
ベント間の関係条件を指定する役割を果たす。この場
合、図２のＥＣＢ管理テーブル４０のフィールド４５群
は、複数の個別のイベントのＥＣＢをポイントし、これ
らポイントされた個別イベントがグループ化され、その
グループ化された個別イベントの数がフィールド４１に
セットされる。 【００４２】この場合、フィールド４２には、当該グル
ープに属する個別イベント間の関係条件を指定する。こ
れは、グループに属するすべての個別イベントの内、い
くつの数の個別イベントが発生すれば当該グループ全体
としてのイベントが発生したとみなすか、その数をフィ
ールド４２にセットする事で指定する。即ち、ＯＲ条件
にしたい場合はフィールド４２に１をセットし、ＡＮＤ
条件にしたい場合はフィールド４１にセットした値と同
じ値、即ちグループ内に属するすべての個別イベント数
をセットする。 【００４３】なお、フィールド４２には、フィールド４
１の値以下の任意の整数ｎをセット可能であり、この場
合には、任意のｎ個の数の個別イベントが発生するのを
待つと言う条件の指定になる。 【００４４】フィールド４３は、当該ＥＣＢ管理テーブ
ルがＥＣＢリストの木構造のどの階層に属するか、その
階層レベルを示す。いま、リーフに相当するＥＣＢ管理
テーブルについて説明しているが、その場合、階層レベ
ル４３には０がセットされる。 【００４５】ＥＣＢ管理テーブルが、図３の木構造のル
ートまたはノードに相当する場合、そのＥＣＢ管理テー
ブルは、複数のグループ間の関係条件を指定する役割を
果たす。この場合、図２のＥＣＢ管理テーブル４０のフ
ィールド４５群は、１つ下の階層の複数のＥＣＢ管理テ
ーブルをポイントし、これらポイントされたＥＣＢ管理
テーブルの数がフィールド４１にセットされる。 【００４６】この場合、フィールド４２には、フィール
ド４５群でポイントした下位のＥＣＢ管理テーブルに対
応する複数のグループ間の関係条件を指定する。指定の
仕方は、上述したリーフに相当するＥＣＢ管理テーブル
の場合と同様である。即ち、ポイントする複数のグルー
プの内、いくつのグループのイベントが発生すれば全体
としてのイベントが発生したとみなすか、その数をフィ
ールド４２にセットする。 【００４７】上述のリーフの場合と同様にして、グルー
プ間でＯＲ条件やＡＮＤ条件が設定可能である。また、
フィールド４２には、フィールド４１の値以下の任意の
整数ｎをセット可能であることも同じである。 【００４８】木構造のルートまたはノードに相当するＥ
ＣＢ管理テーブルでは、階層レベル４３には１がセット
される。したがって、ＥＣＢ管理テーブル４０が、個別
イベントをグループ化するためのもの（リーフの場合）
であるか、グループをさらにまとめてグループ間の関係
条件を指定するためのもの（ノードまたはルートの場
合）であるかは、フィールド４３の階層レベルが０か否
かによって識別可能となっている。 【００４９】ＥＣＢ管理テーブル４０のフィールド４４
には、木構造に沿って、上位のＥＣＢ管理テーブルのア
ドレスがセットされる。ルートに相当するＥＣＢ管理テ
ーブル４０では、フィールド４４に０がセットされる。 【００５０】ルート以外のＥＣＢ管理テーブル４０は、
上位のＥＣＢ管理テーブル４０のフィールド４５群から
ポイントされている。そこで、ＥＣＢ管理テーブル４０
のフィールド４７には、上位のＥＣＢ管理テーブル４０
のフィールド４５群のうちの何番目のエントリからポイ
ントされているか、その上位テーブル上の位置をセット
する。 【００５１】フィールド４５群の各エントリに対応し
て、ｆｉ（ｉ＝１〜ｎ）フィールド４６群が設けられて
いる。このｆｉフィールド４６は、初期値として０がセ
ットされ、対応する条件のイベント（即ち、対応するフ
ィールド４５でポイントされるＥＣＢのイベントまたは
ＥＣＢ管理テーブルのグループのイベント）が発生した
場合には１がセットされるようになっている。したがっ
て、制御タスク１００は、このフィールドｆｉを参照す
ることにより（図１のステップ１０５）、自タスクの再
起動要因となったイベントが何であるかが分かるように
なっている（ｆｉ＝１のものが複数ある場合も有りう
る）。 【００５２】次に、図３を参照して、本実施例における
具体的なＥＣＢリスト３０の例について詳細に説明す
る。 【００５３】図３において、ＥＣＢ管理テーブル４０−
２は、発生を待つべき複数の個々のイベントの内、ｄａ
ｔａ Ａｉの入力完了を待つためのＥＣＢ−１（５１）
とタスクＡの準備完了（ｒｅａｄｙ）を待つためのＥＣ
Ｂ−２（５２）とをグループ化し、ＡＮＤ条件でこの２
つのイベントの発生を待つ事を表している。即ち、 （１）ネットワーク２０からデータが到着し、かつ、そ
れを処理すべきタスクＡがデータを受け入れ可能にある
場合と言う条件を表している。 【００５４】そのために、ＥＣＢ管理テーブル４０−２
のフィールド４５群からＥＣＢ−１（５１）とＥＣＢ−
２（５２）をポイントしている。２つのイベントをグル
ープ化しているので、ＥＣＢ管理テーブル４０−２のイ
ベント数４１には２がセットされている。また、待ちイ
ベント数４２には２がセットされ、２つのイベントの両
方が発生することを待つ、即ち２つのイベントをａｎｄ
条件で待つ、ということを表している。ＥＣＢ管理テー
ブル４０−２はリーフであるので、階層レベル４３には
０がセットされている。 【００５５】ＥＣＢ管理テーブル４０−３は、発生を待
つべき複数の個々のイベントの内、ｄａｔａ Ｂｊの入
力完了を待つためのＥＣＢ−３（５３）とタスクＢの準
備完了（ｒｅａｄｙ）を待つためのＥＣＢ−４（５４）
とをグループ化し、ＡＮＤ条件でこの２つのイベントの
発生を待つ事を表している。即ち、 （２）ディスク２１からのデータ入力が完了し、かつ、
それを処理すべきタスクＢがデータを受け入れ可能にあ
る場合と言う条件を表している。 【００５６】そのために、ＥＣＢ管理テーブル４０−３
のフィールド４５群からＥＣＢ−３（５３）とＥＣＢ−
４（５４）をポイントしている。２つのイベントをグル
ープ化しているので、ＥＣＢ管理テーブル４０−３のイ
ベント数４１には２がセットされている。また、待ちイ
ベント数４２には２がセットされ、２つのイベントの両
方が発生することを待つ、即ち２つのイベントをａｎｄ
条件で待つ、ということを表している。ＥＣＢ管理テー
ブル４０−３はリーフであるので、階層レベル４３には
０がセットされている。 【００５７】ＥＣＢ管理テーブル４０−１は、上記の
（１）と（２）の２つグループをＯＲ条件で関連付け
し、いずれか一方のグループにおいてその条件が満たさ
れたならば、ＯＳ１０がイベントの発生をユーザプログ
ラム１に連絡する旨が表現されている。 【００５８】即ち、ＥＣＢ管理テーブル４０−１のフィ
ールド４４の上位テーブルへのアドレスがこのテーブル
４０−１のみ０であり、これによりＥＣＢ管理テーブル
４０−１が木構造のルートである事が分かる。したがっ
て、ＥＣＢ管理テーブル４０−１の条件が満たされたと
き、ユーザプログラム１に連絡する必要がある事がＯＳ
１０にて認識される。 【００５９】ＥＣＢ管理テーブル４０−１のフィールド
４５群は、ＥＣＢ管理テーブル４０−２とＥＣＢ管理テ
ーブル４０−３をポイントしている。２つのグループを
関連付けているので、ＥＣＢ管理テーブル４０−１のイ
ベント数４１には２がセットされている。また、待ちイ
ベント数４２には１がセットされ、２つのＥＣＢ管理テ
ーブル４０−２と４０−３のいずれかの条件が満たされ
ることを待つ、即ち２つのグループのイベントをｏｒ条
件で待つ、ということを表している。ＥＣＢ管理テーブ
ル４０−１はルートであるので、階層レベル４３には１
がセットされている。 【００６０】また、ＥＣＢ管理テーブル４０−１のフィ
ールド４５群のうち、第１番目のエントリにＥＣＢ管理
テーブル４０−２のアドレスがセットされているので、
ＥＣＢ管理テーブル４０−２の上位テーブルの位置４７
には１がセットされている。同様に、ＥＣＢ管理テーブ
ル４０−１のフィールド４５群のうち、第２番目のエン
トリにＥＣＢ管理テーブル４０−３のアドレスがセット
されているので、ＥＣＢ管理テーブル４０−３の上位テ
ーブルの位置４７には２がセットされている。 【００６１】さらに、ＥＣＢ管理テーブル４０−１，４
０−２，４０−３のｆｉフィールド４６は、何れも初期
値として０がセットされている。 【００６２】以上述べた図３の木構造を持つＥＣＢリス
ト３０が指定されたＷＡＩＴマクロが発行されると（図
１のステップ１０４）、ＯＳ１０の一部であるＷＡＩＴ
処理１２に制御が渡され、処理される。 【００６３】次に、図４を用いて、このＷＡＩＴ処理１
２の動作を説明する。 【００６４】図４に示すように、ＷＡＩＴ処理１２に制
御が渡ると、まずパラメータを解析し、指定された上記
ＥＣＢリスト３０の所在を知る（ステップ４００）。次
に、当該要求に対するイベントが既に発生済みか否かを
調べる（ステップ４０５）。 【００６５】このステップ４０５の判別は、ＥＣＢリス
ト３０のルートである前記図３で説明したＥＣＢ管理テ
ーブル４０−１のフィールド４２を調べることにより行
なう。このフィールド４２は、前述の図２の説明で述べ
たように、指定した複数のイベントの内、いくつの数の
イベントが発生すれば当該グループ全体としてのイベン
トが発生したものとみなすか、その数を記したものであ
り、さらに、後述するＰＯＳＴ処理１３により個々のイ
ベントが発生する都度このフィールドの値から１が減算
される。従って、ルートノードであるテーブル４０−１
のフィールド４２の値が０であればイベントが発生済み
と判断でき、０以上であればその数分の待つべきイベン
トがまだ発生していないと判断出来る。 【００６６】ステップ４０５でイベントが発生済みと判
断された場合には、当該ＷＡＩＴマクロ処理から即座に
当該ＷＡＩＴマクロ発行元に制御を戻し（ステップ４３
０）処理を終了する。 【００６７】一方、ステップ４０５でイベントがまだ発
生していないと判断された場合には、図５に示すＰＯＳ
Ｔ管理テーブル７０を作成する（ステップ４１０）。Ｐ
ＯＳＴ管理テーブル７０は、ＷＡＩＴマクロのパラメー
タであるＥＣＢリストに基づいて作成する。 【００６８】ここで、図５を参照して、ＰＯＳＴ管理テ
ーブル７０について説明する。ＰＯＳＴ管理テーブル７
０は、各ＥＣＢのアドレスと、そのＥＣＢをポイントす
るＥＣＢ管理テーブル４０のアドレスと、そのＥＣＢ管
理テーブル４０の当該ＥＣＢに対応するｆｉフィールド
４６のアドレスとを、対応させて管理するためのテーブ
ルである。 【００６９】図５のＰＯＳＴ管理テーブル７０は、図３
のＥＣＢリストにしたがって作成されたものである。Ｅ
ＣＢ−１（ＥＣＢ５１）のアドレスがエントリされ、こ
れに対応して、このＥＣＢをポイントするＥＣＢ管理テ
ーブル４０−２のアドレス、およびそのＥＣＢ管理テー
ブル４０−２の当該ＥＣＢ−１に対応するｆｉフィール
ド４６−１のアドレスが設定されている。同様に、ＥＣ
Ｂ−２（ＥＣＢ５２）のアドレスがエントリされ、これ
に対応して、このＥＣＢをポイントするＥＣＢ管理テー
ブル４０−２のアドレス、およびそのＥＣＢ管理テーブ
ル４０−２の当該ＥＣＢ−２に対応するｆｉフィールド
４６−２のアドレスが設定されている。 【００７０】図５に示すように、ＥＣＢは、その先頭部
分に、Ｗ（ＷＡＩＴ）ビット２、およびＰ（ＰＯＳＴ）
ビット３を備えている。Ｗビット２は、当該ＥＣＢがＷ
ＡＩＴ状態のときオン（ｏｎ）される。Ｐビット３は、
当該ＥＣＢがＰＯＳＴされたときオンされる。 【００７１】再び、図４を参照して、ＷＡＩＴ処理１２
の説明を続ける。図５のＰＯＳＴ管理テーブル７０を作
成した（ステップ４１０）後、当該ＷＡＩＴマクロで指
定されたＥＣＢ−１（５１）〜ＥＣＢ−４（５４）のＷ
ビット２をオンし（ステップ４１５）し、当該ＷＡＩＴ
マクロ発行元タスクをＷＡＩＴ状態にするためにスケジ
ュール可能ビットをオフ（ｏｆｆ）する（ステップ４２
０）。スケジュール可能ビットは、ディスパッチャが参
照するスケジューリングのためのビットである。 【００７２】その後、ディスパッチャに制御を渡し、デ
ィスパッチャは、当該ＷＡＩＴマクロ発行元タスクに対
応するスケジュール可能ビットがオフされているので、
当該ＷＡＩＴマクロ発行元タスクをＷＡＩＴ状態にする
（ステップ４２５）。 【００７３】以上でＷＡＩＴ処理１２の動作説明を終え
る。 【００７４】次に、上記のステップ４２５でＷＡＩＴ状
態となったタスクが待っているイベントが発生した場合
の、ＰＯＳＴ処理１３の動作を説明する。 【００７５】ＰＯＳＴ処理１３は、図１に示すネットワ
ーク２０、またはディスク２１からのデータ入力が完了
した時点でＩＯスパーバイザが発行するＰＯＳＴに応じ
て起動される。あるいは、タスクＡ２００、または、タ
スクＢ３００が現行の処理を終えｗａｉｔｉｎｇ ｆｏ
ｒ ｗｏｒｋ状態（次の処理要求を待つ状態）となる時
にＰＯＳＴを発行し、これにより起動される。 【００７６】図６を用いて、ＰＯＳＴ処理１３の動作を
説明する。以降では、上記のＰＯＳＴ処理１３の起動ケ
ースの内、ネットワーク２０からデータが到着しデータ
の入力が完了した場合を例に具体的に説明する。 【００７７】なお、ＰＯＳＴマクロの形式は従来技術で
述べたものと同じであり、イメージ的には、ＥＣＢのア
ドレスとイベントコードをパラメータとして持つ以下の
ような形式のＰＯＳＴマクロが発行された場合を例に具
体的に説明する。 【００７８】「ＰＯＳＴ 個別ＥＣＢのアドレス，イベ
ントコード」 上記のＰＯＳＴが発行され、ＰＯＳＴ処理１３が起動さ
れると、図６に示すように、まずＰＯＳＴマクロのパラ
メータで指定されているＥＣＢアドレスに対応するＥＣ
Ｂの当該イベントが発生した事を示すためのフィールド
であるところのポストビット（図に示すＰビット３）を
オンする（ステップ５００）。この例では、ネットワー
ク２０からデータが到着し、ＥＣＢ−１（図５の５１）
のＰビット３がオンされる。 【００７９】ただし、図６では省略したが、前記ポスト
ビット３が既にオンされていた場合は、誤って重複して
ＰＯＳＴが発行された場合であり、これを検知した時点
でＰＯＳＴ処理１３は処理を終了する。従って、以下の
動作説明では重複して発行されたＰＯＳＴ処理は考慮し
ていない。 【００８０】次に、先に述べた図５に示すＰＯＳＴ管理
テーブル７０を検索し、ＰＯＳＴマクロのパラメータで
指定されているＥＣＢのアドレスと同じアドレスがセッ
トされているエントリを見つける（ステップ５０５）。
今は、ＥＣＢ−１のアドレスと同じアドレスがセットさ
れている１番めのエントリを見つける事になる。 【００８１】次に、当該エントリの第３カラムに格納さ
れているＥＣＢ管理テーブル４０−ｎのアドレスを取り
出し、当該イベントをグループ管理しているテーブル４
０−２を特定し、さらに第２カラムに格納されているＥ
ＣＢ管理テーブル４０−２のフィールド４６−ｎのアド
レスを取り出し、フィールド４６−１を特定する（ステ
ップ５１０）。そして、このフィールド４６−１にイベ
ントが発生した事を覚えておくために１をセットする
（ステップ５１５）。 【００８２】次に、当該ＥＣＢ管理テーブル４０−２の
フィールド４２（待ちイベント数）が０であるか否かを
判定する（ステップ５２０）。この判定が成り立つ場合
は、既に当該グループ全体の条件を満たすイベントが発
生済みの場合であり、以降の処理（ステップ５２５〜５
３０）は実施せず、他のＰＯＳＴの発生を待つためディ
スパッチャに制御を渡し処理を終了する（ステップ５３
５）。 【００８３】これは、今説明しているケースから外れる
が、ＯＲ条件で複数のイベントをグループ管理している
場合に、最初に発生したイベントを処理する場合にの
み、そのイベントの発生を上位のＥＣＢ管理テーブルに
通知すれば良く、当該ＯＲ条件グループに含まれる２番
目以降に発生したイベントについてはその必要が無く
（既に最初のイベント発生時に上位のＥＣＢ管理テーブ
ルに通知してあるからである）、２番目以降の処理を抑
止するための判定である。 【００８４】ステップ５２０の判定が成立しない場合に
は、当該ＥＣＢ管理テーブル４０により管理されるイベ
ントグループは条件を満たすべきイベントが発生するの
を待っている場合であり、当該処理中のＰＯＳＴにより
条件が満たされるか否かをチェックする。 【００８５】このチェックのために、まず、今処理中の
ＰＯＳＴにより、待つべきイベントの数が１つ減った訳
であるから、当該ＥＣＢ管理テーブル４０のフィールド
４２にセットされているイベント待ち数を１減じる（ス
テップ５２５）。そして、再び当該フィールド４２の待
ちイベント数が０であるか否かを判定する（ステップ５
３０）。０でないときは、さらに別のイベントの発生を
待つため、ディスパッチャに制御を渡し当該ＰＯＳＴ処
理を終了する（ステップ５３５）。 【００８６】以上のようにして、図３に示した木構造の
条件の内、ＥＣＢ管理テーブル４０−２でＡＮＤ条件で
管理されるグループに属するＥＣＢ−１（５１）に対応
する１つのイベントの発生によるＰＯＳＴ処理が終了し
た事になる。 【００８７】なお、先に図２の説明で述べたように、本
実施例では指定した複数イベントの内、いくつのイベン
トの発生を待つかを（ＥＣＢ管理テーブル４０のフィー
ルド４２で）指定する事で、ＡＮＤやＯＲの条件を指定
する。従って、上記で述べて来たＥＣＢ管理テーブル４
０−２では、ＥＣＢ−１（５１）とＥＣＢ−２（５２）
の２つのイベントが登録されており、フィールド４２に
は始めにイベントの全数（即ち、２）のイベントを待つ
事が指定されているから、これら２つのイベントのＡＮ
Ｄ条件をとることを表している。 【００８８】今、上記の動作説明で述べたＥＣＢ−１
（５１）に対応するイベント発生により、ＥＣＢ管理テ
ーブル４０−２のフィルード４２の残りの待つべきイベ
ント数が１となる。次に残りのイベントであるＥＣＢ−
２（５２）に対応するイベントが発生すれば、当該グル
ープに対するＡＮＤ条件が満たされ、さらには、ルート
であるテーブル４０−１がＯＲ条件（フィルード４２に
１がセットされてる）であるため、木構造全体の条件が
満たされユーザにイベントの連絡をする事になる。 【００８９】以下に、このＥＣＢ−２（５２）に対応す
るイベントが発生した場合のＰＯＳＴ処理の手順を述べ
る。 【００９０】ＥＣＢ−２（５２）に対応するイベント
は、ディスク２１（図１）のＲＥＡＤ要求が完了すると
発生し、前記と同様にＰＯＳＴ処理１３に制御が渡って
くる。そして、ＰＯＳＴ処理１３では、上記で述べて来
た先行して発生したＥＣＢ−１（５１）の場合と同様
に、ＥＣＢ管理テーブル４０−２に対してステップ５０
０〜５３０を実施する。ステップ５２５においてフィー
ルド４２が０となり、ステップ５３０にて判定が成立す
るから、処理はステップ５４０に進む。 【００９１】そして、当該ＥＣＢ管理テーブル４０−２
がルートか否かを調べるため、上位テーブルアドレス４
４が０かどうか判断する（ステップ５４０）。当該テー
ブル４０−２は、図３に示したようにルートでは無いた
め、上位テーブルアドレス４４にはＥＣＢ管理テーブル
４０−１のアドレスが格納されている。従って、条件は
成り立たず、この場合には、当該グループの条件が満た
された事を上位テーブル（即ち、テーブル４０−１）に
反映させるために、ステップ５４５以降の処理が実行さ
れる。 【００９２】即ち、ＥＣＢ管理テーブル４０−２上のフ
ィールド４４により上位テーブルであるＥＣＢ管理テー
ブル４０−１（図３）を特定し、ＥＣＢ管理テーブル４
０−２上のフィールド４７により上位テーブル４０−１
上のフィールド４６群の内、自グループに対応するエン
トリを特定し、当該グループの条件が満たされた事を示
すために対応するｆｉフィールド４６に１をセットする
（ステップ５４５）。そして、上位テーブル４０−１に
対して、前記ステップ５２０からの処理を前記と同様に
繰り返す。 【００９３】今、図３に示すＥＣＢ管理テーブル４０−
３でグループ化されたグループの条件が満たされていな
いと仮定すると、ＥＣＢ管理テーブル４０−１のフィー
ルド４２は１であり、ステップ５２０は成り立たず、ス
テップ５２５にてフィールド４２が１減じられ残りの待
つべきイベント数が０となり、ステップ５３０が成り立
ち、ステップ５４０でルートノードであるか否が判定さ
れる。 【００９４】ＥＣＢ管理テーブル４０−１の上位テーブ
ルアドレス４４は０であり、ステップ５４０が成立する
から、木構造全体の条件が満たされたことになる。そこ
で、ユーザにイベントの連絡をするために、イベントを
待っているタスクのスケジュール可能ビットをオン（ス
テップ５５０）した後、ディスパッチャに制御を渡し
（ステップ５５５）、イベントを待っているタスクの起
動を依頼する事によりユーザへのイベントの連絡を実施
する。 【００９５】以上で、図３に示す木構造化された条件に
対する一連のＰＯＳＴ処理を全て終える。 【００９６】なお、上記では図３に示すＥＣＢ−１（５
１）、ＥＣＢ−２（５２）のグループとＥＣＢ−３（５
３）、ＥＣＢ−４（５４）のグループの内、前者のグル
ープが先に発生した場合を仮定して、前者のグループに
ついてのみ説明したが、後者のグループが先に発生した
場合も上記の説明と同様の処理であるため説明を省略す
る。 【００９７】以上のようにして、ユーザプログラムが複
数のイベントを複数のグループに分割して、各グループ
に含まれる個々のイベント間の条件付けと、グループ間
の条件付けをＥＣＢリスト３０を用いて指定可能とな
り、この指定された条件に従って、条件が満たされた場
合にのみＯＳからユーザプログラムにイベントの発生を
連絡するようにしたので、より自由度の高いプログラマ
ブル・イベント連絡が可能となり、かつ、ユーザプログ
ラムとＯＳ間での制御の受渡やアドレス空間の切り替え
回数が減少し処理効率の向上が図れる。 【００９８】 【発明の効果】本発明では、複数イベントをグループに
分割し、各グループ毎に条件設定やグルーブ間の条件指
定できるようにしているので、ユーザが任意の条件組み
合わせでイベントの発生を待つ事が可能となり、イベン
ト待ち条件の自由度が向上する。また、ユーザが指定し
た任意の条件が整った場合にのみイベントの発生を連絡
するようにしたので、ユーザプログラムとＯＳ間の制御
の受渡やアドレス空間の切り替え回数が減少し、処理効
率の向上を図ることができる。

【図面の簡単な説明】 【図１】本発明の一実施例の全体構成を示す図。 【図２】本発明の実施例におけるグループ化されたイベ
ント群に含まれる個々のイベント間の条件を指定するた
めの管理（連絡）用のＥＣＢ管理テーブルを示す図。 【図３】本発明の実施例におけるイベントの発生を連絡
する際の条件を表すための木構造を示す図。 【図４】本発明の実施例におけるＷＡＩＴマクロの処理
フローチャート図。 【図５】本発明の実施例におけるＰＯＳＴ管理テーブル
を示す図。 【図６】本発明の実施例におけるＰＯＳＴマクロの処理
フローチャート図。 【符号の説明】 １…ユーザプログラム、２…ウエイトビット、３…ポス
トビット、１０…制御プログラム、１１…ＩＯスーパバ
イザ、１２…ＷＡＩＴ処理、１３…ＰＯＳＴ処理、１４
…ディスパッチャ、２０…ネットワーク、２１…ディス
ク、３０…ＥＣＢリスト、１００…制御タスク、２００
…タスクＡ、３００…タスクＢ。

フロントページの続き (56)参考文献 特開 平６−35724（ＪＰ，Ａ) 特開 平３−102532（ＪＰ，Ａ) 特開 平６−89190（ＪＰ，Ａ) 特開 平１−189733（ＪＰ，Ａ) 特開 昭63−41937（ＪＰ，Ａ) 特開 平５−73635（ＪＰ，Ａ) 特開 平５−204666（ＪＰ，Ａ) 実開 平２−46249（ＪＰ，Ｕ) 多賀直久，ソフトウェア・ノート：Ｐ Ｃ−9801用リアルタイム／マルチタス ク・モニタ ＥＬＸ−86Ｍ，ＥＬＸ− 286の機能概要，インターフェース，Ｃ Ｑ出版株式会社，1989年 １月 １日, 第15巻，第１号，ｐ．224−225 山本洋一，リアルタイム・システム設 計のポイント，インターフェース，ＣＱ 出版株式会社，1993年12月 １日，第19 巻，第12号，ｐ．151−162 ＨＩ−ＵＸ／ＷＥ２ オンライントラ ンザクション処理機能／カーネル ＴＡ ＣＴ／ＫＥＲＮＥＬ，株式会社日立製作 所，1994年 ３月31日，第２版，ｐ．55 −56 ＯＳ ＩＶ／ＸＳＰ タスク管理マク ロ命令文法書 ＡＦ ＩＩ Ｖ10用，富 士通株式会社，1992年11月30日，第２ 版，ｐ．92−100 坂村健，ＩＴＲＯＮ標準ガイドブック ’92−’93，社団法人トロン協会，パー ソナルメディア株式会社，1992年12月20 日，第１版，ｐ．193−194 (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 9/46 - 9/55 G06F 11/30 - 11/34 G06F 15/16 - 15/177 G06F 15/76 - 15/82

Claims (1)

1. (57)【特許請求の範囲】 【請求項１】計算機システムにおいて、タスクがイベン
   トの発生を待ち、イベントが発生した場合に、オペレー
   ティングシステムがそのイベントの発生を前記タスクに
   通知するプログラマブル・イベント連絡方法であって、ユーザプログラム内にイベント連絡用のリストを作成す
   ることにより、複数の個別イベントをグループ分けした
   各グループとしてのイベント発生の条件成立がグループ
   内の個別イベントの発生のＡＮＤ条件によるのかＯＲ条
   件によるのかをそれぞれ設定し、かつ前記タスクに通知
   すべき全体としてのイベント発生の条件成立が前記各グ
   ループのイベント発生のＡＮＤ条件によるのかＯＲ条件
   によるのかを設定する条件指定を行い、 前記オペレーティングシステムは、前記タスクから前記
   リストが指定されて指示されると、前記リストに基づい
   て、前記各グループのイベント発生の有無を判断し、か
   つ全体としてのイベント発生の条件が成立したことを判
   断したときに前記タスクに対してイベントの発生を通知
   することを特徴とする プログラマブル・イベント連絡方
   法。