JP3550890B2 - イベント送受信方法及び装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、イベント送受信方法及び装置に関するもので、より具体的には、イベントキューに格納したイベントの読み出し順を決定する部分の改良に関する。
【０００２】
【従来の技術】
コンピュータシステム内でのイベントの伝送方式の一つとして、キューを用いたものがある。これはよく知られているように、あるプロセスから送信されたイベントを一旦メモリ内に割り当てられたキュー（本明細書ではこれを「イベントキュー」と称する）に、送信された順に格納していき、そのイベントキューに格納された各イベントは、格納された順に取り出されるＦＩＦＯ型のデータ構造で管理されるようになっている。
【０００３】
また、送信されるイベントには、重要度・緊急度が異なるものがあり、係る場合に常に上記ＦＩＦＯ型で管理されると、スムーズな処理ができなくなる。そこで、係る問題を解決するため、送信する個々のイベントに優先度（プライオリティ）を示すデータを付加し、イベントの取り出しは、優先度が一番高いものから順に行うようにし、仮に優先度が同じものの場合には、先に格納したものを取り出すようにしたものがある。このように優先度とＦＩＦＯ型を組み合わせたものはプライオリティキューとも称されている。
【０００４】
【発明が解決しようとする課題】
しかしながら、上記したプライオリティキュー方式では、各イベントに優先度を付加しなければならず、そのため優先度のフラグの分だけデータ長が長くなり、メモリの利用効率並びに伝送効率が悪くなる。
【０００５】
また、優先度（プライオリティ）を付加する処理が必要となるばかりでなく、優先度は、伝送するイベントの種類のみに起因するのではなく、送信後に受信する順番を替えたいことがあり、係る場合には送信後に優先度の変更ができない従来のプライオリティキュー方式では充分に対応できない。すなわち、イベントの受信処理時間がイベントの送信間隔よりも長い時でしかも同時に複数のイベントが送信された場合には、処理しきれないイベントがイベントキューに滞留してしまい、新たに送信されたイベントを受信し、個別処理するためには、滞留している全てのイベントの受信処理を行わなければならないが、これも、同時（比較的短時間の間）にイベントキューに格納されるイベント数が少ない場合には問題が発生しないので、周囲の状況により同一のイベントであっても、ＦＩＦＯ型で受信しても滞留を起こさない場合と、滞留を起こす場合がある。したがって、前記イベントキューに蓄えられたイベントの受信順序を自由に変更することができると好ましいが、従来のものではそれを解決できるものがなかった。
【０００６】
本発明は、上記した背景に鑑みてなされたもので、その目的とするところは、上記した問題を解決し、滞留したイベントで不必要なイベントに対して受信処理を行うかどうかを選択的に行えることと、特定の処理要求イベントに対して一時的に受信処理を行わない方法を提供することにより、イベントの受信順序を自由に変更し、効率の良いイベントの送受信を行えるイベント送受信方法及び装置を提供するものである。
【０００７】
【課題を解決するための手段】
上記した目的を達成するため、本発明に係るイベント送受信方法では、送信側プロセスから受信側プロセスに対してイベントを送信するに際し、送信側プロセスは、前記イベントをイベントキューに順次格納し、受信側プロセスは、前記イベントキューに格納されたイベントを所定の順で読み出すようにしたイベント送受信方法において、イベントの種類ごとにイベント名（実施の形態では「イベント識別子」）と送信回数と受信回数を関連づけて管理する受信イベント管理テーブルを設け、イベントを送信する際に、そのイベントが前記受信イベント管理テーブルに格納されている場合には、前記イベントキューに格納するとともに、その送信するイベントに対応する前記送信回数を更新し、前記受信側プロセスが、前記イベントキューに格納されたイベントを受信する際には、前記受信イベント管理テーブルのイベントの送信回数と受信回数とを比較し、前記送信回数の方が大きいイベントのみを受信するとともに、前記受信イベント管理テーブルの受信したイベントに対応する受信回数を更新するようにし、かつ、前記受信回数の更新を前記イベントの受信と関係なく、強制的に変更できるようにし、前記受信側プロセスが受信したイベントに加え、前記送信回数が前記受信回数よりも大きくないイベントをイベントキューから削除するようにした（請求項１）。
【０００８】
そして、上記した方法を実施するのに適した本発明に係るイベント送受信装置では、送信側プロセスから送信されたイベントを一時的に格納するイベントキューと、前記イベントキューに格納されたイベントを受信する受信側プロセスと、イベントの種類ごとにイベント名と送信回数と受信回数を関連づけて管理する受信イベント管理テーブルと、前記イベントキューにイベントが格納される都度、その格納されたイベントに対応するイベント名に関連付けられた送信回数を更新する送信回数更新手段（実施の形態では「送信側プロセス」）と、前記イベントキューに格納されたイベントが前記受信側プロセスに受信される都度、その受信されたイベントに対応するイベント名に関連付けられた受信回数を更新する受信回数更新手段（実施の形態では「受信側プロセス」）と、前記イベントの受信と関係なく、前記受信回数を更新する受信回数強制更新手段（実施の形態では「受信側プロセス」）とを備え、さらに、前記受信側プロセスは、前記イベントキューに格納されたイベントのうち、前記受信イベント管理テーブルのイベントの送信回数の方が受信回数よりも大きいイベントのみを受信するようにし、かつ、前記受信側プロセスが受信したイベントと前記送信回数が前記受信回数よりも大きくないイベントをイベントキューから削除する手段（実施の形態では「受信側プロセス」）とを備えて構成した（請求項２）。
【０００９】
なお、受信イベント管理テーブルに対するイベント名の登録は、すべてのイベント名を登録しても良く、或いは選択的に所望イベント名のみを登録しても良い。
【００１０】
請求項１，２に記載した発明では、受信イベント管理テーブルに登録されたものでしかも送信回数の方が受信回数よりも大きいイベントのみが受信される。したがって、そもそも受信側プロセスにとって、不要なイベントがある場合には、そのイベントを受信イベント管理テーブルに登録しておかなければ、受信することがない。よって、不要なイベントを受信することによる受信並びにその後の解析に要する時間が短縮できる。また、受信イベント管理テーブルに格納したイベントであっても、イベントキューでイベントの滞留が起こった場合、滞留したイベントのなかで不必要なものがあれば、受信回数強制更新手段を用いて受信イベント管理テーブルにある不必要なイベントの受信回数を送信回数と等しく設定する。すると、不必要なイベントの受信処理を行う必要がなくなる。
【００１７】
ここで、上記した送信回数更新手段は、実施の形態では、送信側プロセスの機能に一体的に組み込んでいる。しかし、本発明は必ずしも一体にする必要はなく、例えば、イベントキューに格納されるイベントを監視し、テーブルに登録された受信回数を更新するようにする手段を別途設けても良い。同様に、受信回数更新手段と受信回数強制更新手段は、実施の形態では、受信側プロセスの機能に一体的に組み込んでいるが、これもいずれか一方或いは双方とも別部材として構成しても良い。さらに、イベントを削除する手段も、実施の形態としてでは、受信側プロセスの機能に組み込んでいるが、別途形成しても良く、さらに、受信したイベントを削除する手段と、受信回数と送信回数の大小関係に基づいてイベントを削除する手段を別々に形成してももちろん良い。さらには、各管理テーブルにイベント名等を登録したり、一度登録したものを別の管理テーブルに移し替える管理手段も実施の形態では、受信側プロセスの機能に一体的に組込んでいるが、これも別途構成してもよい。
【００１８】
【発明の実施の形態】
図１は本発明が適用されるコンピュータシステムの一例の概略構成を示している。本発明の要部を説明する前に、同図に基づいてシステム全体について説明する。コンピュータがあるシステムを実行する場合には、各プロセス間でイベントの送受を行い、イベントを受け取ったプロセスは、そのイベントの内容に応じて所定の処理をし、必要に応じて他のプロセスに再度イベントを送信したり、外部に出力したりする。そして、そのイベントの送受は、イベントを受信するプロセス側にそれぞれイベントキューを接続し、送信側のプロセスは、そのイベントキューに対して逐次データを格納していき、また受信側のプロセスは、そのイベントキューに格納された自分宛のイベントを所定の順で取り出すようになっている。
【００１９】
一例を示すと、あるシステム（例えば変電所内の運転を管理するシステム）を実行するためには、複数のプロセス１ａ，１ｂ，１ｃ，１ｄ（実際には、これ以外にも多数のプロセスが存在する）を適宜関連づけて連結し、イベントを受信するプロセス１ａ，１ｂ，１ｃについては、それぞれにイベントキュー２ａ，２ｂ，２ｃを接続している。そして、各プロセスは、実際には、プログラムで構成される。
【００２０】
また、図示した例における各プロセスの機能・内容を簡単に説明すると、障害管理プロセス１ａは、システムのハードウェア並びにソフトウェアの障害の発生・復旧を通知するイベントを受信し、その情報をモニター画面に表示したりファイルに障害の履歴情報を格納したりする処理をするものである。
【００２１】
また、ハードウェア監視プロセス１ｂは、システムを構築するハードウェアの状態を監視し、障害が発生したり、また、発生した障害が復旧されたことを認識したならば、障害発生イベントまたは復旧イベントを障害管理プロセス１ａに対して送信する（実際には、イベントキュー２ａに格納する）ように機能する。
【００２２】
同様に、ソフトウェア監視プロセス１ｃは、システムを構築するソフトウェアの状態を監視し、障害が発生したり、また、発生した障害が復旧されたことを認識したならば、障害発生イベントまたは復旧イベントを障害管理プロセス１ａに対して送信する（実際には、イベントキュー２ａに格納する）ように機能する。
【００２３】
また、時刻管理プロセス１ｄは、内蔵する時計に基づいて、システム全体の時間を管理するもので、予め定められた時刻が来ると、時刻イベントを所定のプロセス１ａ〜１ｃに伝えるようになる。また、指定された時間が経過された場合には、タイマーイベントを所定のプロセス１ａ〜１ｃに伝えるようになる。そして、この時刻管理プロセス１ｄから送信されるイベントに基づいて、各プロセスでは、一定時間間隔或いは定時毎に所定の処理を実行することができるようになっている。
【００２４】
なお、この時刻管理プロセス１ｄは、内蔵する時計に基づいて所定のイベントを所定のプロセスに対して送信するだけで、他のプロセスからイベントを取得することがないので、イベントキューは接続していない。なおまた、各プロセスで実行させる基本的な処理は従来と同様のものを用いることができるので、それを実行するためのより具体的な機能の詳細な説明は省略する。
【００２５】
ここで本発明では、上記したシステム構成を前提とし、各プロセス１ａ〜１ｃがイベントキュー２ａ〜２ｃに格納されたイベントを受け取る順番を単純にＦＩＦＯ型で行うのではなく、イベントの種類やその時の状況に即し、ＦＩＦＯ型を基本としながら、適宜順番を変えたり、不要なイベントの受け取りを拒否するようにし、効率よくデータの受け取りをできるようにしている。そして、それを実行するためのイベント送受信装置の一実施の形態を図２に示している。
【００２６】
同図に示すように、コンピュータ１０内部に実装される送信側プロセス１１から送信されたイベントは、一旦イベントキュー１２に格納され、そのイベントキュー１２を介して受信側プロセス１３に受け渡されるようになっている。この基本構成は、上記した図１に示すものと同様である。なお、送信側プロセス１１は、図の例では１つのみ代表として表示したが、仮に受信側プロセス１３が図１における障害管理プロセス１ａとすると、送信側プロセス１１は、ハードウェア監視プロセス１ｂ，ソフトウェア監視プロセス１ｃ，時刻管理プロセス１ｄの３つのプロセスが並列的に存在することになる。
【００２７】
ここで本発明では、送信側プロセス１１及び受信側プロセス１３からそれぞれアクセス可能な非受信イベント管理テーブル１４と、受信イベント管理テーブル１５とを設けている。そして、各テーブル１４，１５のデータ構造は、図示するように、イベントの内容を特定するイベント識別子（イベント名）と、そのイベントを送信した送信回数と、受信側プロセス１３がそのイベントを受信した受信回数の３つのデータを関連づけて格納するようになっている。
【００２８】
そして、各管理テーブル１４，１５に対するイベント識別子の登録は、受信側プロセス１３が行う。つまり、自己が受け得るイベントを予め受信イベント管理テーブル１４か非受信イベント管理テーブル１５のいずれか一方に登録する。この時、いずれのテーブルに登録するかは、そのイベントが優先して受信する必要があるか否かにより決定され、具体的には、優先して受信するイベントは受信イベント管理テーブル１４に格納し、優先しては受信しないイベントは非受信イベント管理テーブル１５に格納するようになっている。さらに、その後の所定のタイミングで、一旦登録したイベント識別子を別の管理テーブルに移し替えることができるようになっている。さらにまた、イベントキュー１２に格納されたイベントを受信した（読み取った）場合には、受信イベント管理テーブル１４に格納された受信回数の欄の数値をインクリメント（１を加算）する機能を基本機能として持ち、さらに実際に受信したか否かに関係なく、受信回数の欄の数値の更新・書き換えを行うことができる機能も有している。
【００２９】
また、管理テーブル１４，１５の登録項目のうち送信回数の欄の数値は、送信側プロセス１１がイベントキュー１２にイベントを格納する際に、その数値をインクリメント（１を加算）するようになっている。
【００３０】
次に、送信側プロセス１１の本発明と関係する部分の機能について説明する。送信側プロセス１１は、従来から有している通常の機能に加え、図３のフローチャートに示す機能を有している。すなわち、まず、あるイベントを送信しようとした場合には、その送信先に付随する受信イベント管理テーブル１４と非受信イベント管理テーブル１５をアクセスし、そのイベント識別子の欄をサーチし、送信するイベントを検索する（Ｓ１０１）。次いで、その検索したイベント識別子に関連するイベント送信回数をインクリメントし（Ｓ１０２）、その後、送信するイベントをイベントキュー１２に登録する（Ｓ１０３）。そして、本発明では、ＦＩＦＯ型を基本とするため、イベントキュー１２への各イベントの格納は、先頭から順に行う。つまり、一番後ろに格納することになる。
【００３１】
一方、受信側プロセス１３は、上記したように初期設定としていずれかの管理テーブル１４，１５にイベント識別子を登録したり、一旦登録したイベント識別子を別のテーブルに移し替えたり、受信回数を擬似的に変更する機能に加え、イベントキュー１２に格納されたイベントを受信するという本来の機能を当然有している。すなわち、その受信機能は、先頭に格納された（一番古い）イベントから順に受信するというＦＩＦＯ型を基本とし、その際に、受信しようとしたイベントが、２つの管理テーブル１４，１５のいずれに登録されたものか、及びまたはイベント送信回数とイベント受信回数の大小関係に基づいて、「受信する／しない」の選択を行うことにより、不要なイベントを受信しないようにする。さらに、途中でイベント識別子を登録する管理テーブルを替えることにより、一旦受信しないと選択したものをその後に受信可能とし、これにより、受信する順番を替えることができるようにしている。そして、具体的な処理は、図４のフローチャートに示すようになっている。
【００３２】
すなわち、まず、イベントキュー１２に登録された一番古いイベントを検索する（Ｓ２０１）。そして、検索できた（成功）ならば、受信イベント管理テーブル１４をアクセスし、そのイベントが受信イベント管理テーブルに登録されているものか否かを判断し（Ｓ２０２）、登録されている場合には、そのイベント識別子についてのイベント送信回数とイベント受信回数を取得し、送信回数の方が大きいか否かを判断する（Ｓ２０３）。
【００３３】
そして、送信回数の方が大きい場合には、そのイベントについてのイベント受信回数をインクリメントする（Ｓ２０４）。その後、通常の受信処理、すなわち、イベントキュー１２からそのイベントを読み込んだ後（Ｓ２０５）、イベントキュー１２から読み込んだイベント２０を削除して処理を終了する（Ｓ２０６）。
【００３４】
一方、ステップ２０２の分岐判断を行った結果、取得したイベントが受信イベント管理テーブル１４に登録されていない場合（非受信イベント管理テーブル１５に登録されている）には、ステップ２０７に飛び、次に古いイベントをイベントキュー１２から検索し、検索できたならば、ステップ２０２に戻り、上記した処理を繰り返し行う。また、ステップ２０７の処理で、イベントを検索できない（失敗）、つまり、最新に格納したイベントまで処理を行ったならば、一連の受信処理を終了するようになる。
【００３５】
このように、受信イベント管理テーブル１４に登録されたイベントのみを受信するようにしたため、たとえイベントキュー１２に先に格納されたイベントがあったとしてもそのイベントが非受信イベント管理テーブル１５に登録されている場合には、読み出されない。つまり、ＦＩＦＯ型を前提としつつ、必ずしも先に格納されたイベントが先に読み出されるものではなく、必要なものから先に読み出され、その読み出し順を変えることができる。換言すると、本例では、受信イベント管理テーブル１４に登録されたイベントの中で、先に登録されたものから順に読み出す（ＦＩＦＯ型）ようにしている。
【００３６】
しかも、受信側プロセス１３により、一旦非受信イベント管理テーブル１５の登録したイベントを、その後に受信イベント管理テーブル１４側に移し替えるようにしたため、当初は、ステップ２０２の判断でＮｏとなり読み出されなかったものが、その後に管理テーブルの移し替えが行われることによりステップ２０２の判断でＹｅｓになり読み出しを可能とすることができる。また、逆に当初受信イベント管理テーブル１４に登録しておき、その後に非受信イベント管理テーブル１５に移し替え、受信を拒否することもできる。このように、完全に読み出しの順番を入れ替えることができるようになる。
【００３７】
なお、受信側プロセス１３における各管理テーブル１４，１５への登録及び移し替えは、そのプロセスを設計する際に行う。そして、このように本例では、２つの管理テーブル１４，１５を設置し、それらを適宜使いわけることにより、例えば、受信に時間がかかるとともに、さほど緊急性を有しないイベントは、とりあえず非受信イベント管理テーブルに格納しておき、イベントキュー１２に格納されたイベントがなくなるか、少なくなったときに受信イベント管理テーブルに登録し直すことにより、効率よく受信処理ができる。また、最初はすべてのイベントを受信イベント管理テーブル１４に登録しておき、例えば、混んできた（イベントキューに格納されたイベントが滞留する）場合に、受信に時間を要するイベントを非受信イベント管理テーブル１５に移し替えることにより、スムーズにイベントの読み出しをすることができるようにもできる。
【００３８】
さらに、非受信イベント管理テーブルに登録したままにすると、受信処理しないため、自己のプロセスにとって不要なイベントを受信する必要がなくなる。よって、無駄な読み込み処理や読み取ったイベントを解析する処理等がなくなり、システム全体の稼働効率が向上する。
【００３９】
一方、ステップ２０３の分岐判断で、イベント送信回数とイベント受信回数が等しいか、イベント受信回数の方が大きい場合には、ステップ２０８に飛び、検索したイベントをイベントキューから削除する。すなわち、通常であれば、送信側プロセス１１がイベントをイベントキューに登録する都度イベント送信回数の数値が１加算され（Ｓ１０２）、その登録されたイベントが読み出されることによってイベント受信回数の数値が１加算される（Ｓ２０４）ため、原則としてはイベントキュー１２にイベントが残っていると、イベント送信回数の方が必ず大きくなり、ステップ２０３の判断ではＹｅｓになる。
【００４０】
しかし、上記したように、受信側プロセス１３に、受信回数を強制的に変更する機能を与えたため、実際の受信回数以上の回数に書き換えると、イベントキュー１２にイベントが残っていても送信回数の方が小さくなり、ステップ２０３でＮｏと判断されることがある。これにより、不要なイベントを受信することなくイベントキュー１２から削除することができるようになる。よって、イベントキュー１２にイベントが残ったままとなることがなくなり、メモリの使用効率が向上する。
【００４１】
次に、上記した装置を用いて、本発明に係るイベント送受信方法の実施の形態を説明する。まず、前提として送信側プロセス１１は受信側プロセス１３に対してイベントＡとイベントＢとイベントＣを複数送信し、送信された各イベントは一旦イベントキュー１２に保存され、イベント受信プロセス１３はイベントキュー１２からイベントを所定の順で読み込むものとする。そして、受信側プロセス１３は、初期状態として、イベントＡとイベントＢを受信イベント管理テーブル１４に登録し、イベントＣを非受信イベント管理テーブル１５に登録する。なお、各テーブル１４，１５のイベント送信回数とイベント受信回数はともに「０」になっている。
【００４２】
ここで、送信側プロセス１１が、受信側プロセス１３に対してイベントを「イベントＡ」，「イベントＣ」，「イベントＢ」，「イベントＢ」，「イベントＡ」の順に送信したとする。すると、図３のフローチャートに従って、まず、最初のイベントＡは、受信イベント管理テーブル１４に登録されたイベントであるので、そのテーブル１４のイベントＡについてのイベント送信回数をインクリメントし、イベントＡをイベントキュー１２の先頭▲１▼に登録する。次にイベントＣは、非受信イベント管理テーブル１５に登録されたイベントであるので、そのテーブル１５のイベントＣについてのイベント送信回数をインクリメントし、イベントＣをイベントキュー１２の２番目▲２▼に登録する。以後係る処理を繰り返し行うことにより、図２に示すように、イベントキュー１２には、送信した順にイベントが格納されるとともに、各管理テーブル１４，１５の送信回数が所定の値となる。この時、受信はされていないため、各管理テーブル１４，１５の受信回数は０のままとなる。これにより、送信処理は終了する。
【００４３】
次に、受信処理について説明する。受信側プロセス１３は、図４に示すフローチャートに従って、まず、イベントキュー１２に登録された一番古いイベントを検索し、イベントＡを検出する（Ｓ２０１）。そして、イベントＡをキーとして受信イベント管理テーブル１４をアクセスする。すると、イベントＡは、その管理テーブル１４に登録されているため、次に受信イベント管理テーブル１４に格納されたイベントＡについての送信回数（２回）と受信回数（０回）を取得するとともに両者を比較する（Ｓ２０２，２０３）。この場合、イベントＡのイベント送信回数は、イベント受信回数よりも大きいので、ステップ２０４〜２０６を順次処理する。すなわち、▲１▼のイベントＡのイベント受信回数をインクリメントして「１」にし、イベントキュー１２の先頭▲１▼からイベントＡを読み込んだ後、イベントキュー１２から読み込んだイベントＡを削除する。
【００４４】
次に、上記処理により▲１▼のイベントＡは削除されているため、現在の一番古いイベントは、▲２▼のイベントＣとなっている。そこで、ステップ２０１から再度処理すると、イベントキュー１２に登録された現在の一番古いイベントであるイベントＣを検出する。すると、イベントＣは、非受信イベント管理テーブルから検索されるので、ステップ２０７に飛びイベントキュー１２に格納されたイベントで次に古いイベントを検索し、▲３▼のイベントＢを検出する。▲３▼のイベントＢは、受信イベント管理テーブル１４に登録されており、しかも、その管理テーブル１４のイベントＢのイベント送信回数（２）は、イベント受信回数（０）よりも大きいので、▲３▼のイベントＢのイベント受信回数をインクリメントし、イベントキュー１２から▲３▼のイベントＢを読み込んだ後、イベントキュー１２から読み込んだイベントＢを削除し処理を終了する。
【００４５】
このように、イベントキュー１２に格納した順番は、イベントＡ，Ｃ，Ｂ…の順であったが、読み出す際には、イベントＣを飛び越えてイベントＡ，Ｂの順で行われる。そして、管理テーブルに登録するイベント識別子の移し替えや、受信回数の強制修正がないとすると、イベントキュー１２に登録された一番古いイベントであるイベントＣは読み出されず、▲４▼以降に登録されたイベントＢ，Ａの順で読み出される。そして、最終的な受信イベント管理テーブル１４の受信回数は、ともに２となる。つまり、ＦＩＦＯ型であれば、「Ａ，Ｃ，Ｂ，Ｂ，Ａ」の順で読み取られ、イベントキュー１２には、イベントが何も残らないが、「Ａ，Ｂ，Ｂ，Ａ」の順で読み取られ、イベントＣはイベントキュー１２に残ったままとなる。そして、例えばイベントＣが読取りに時間がかかるような場合には、ＦＩＦＯ型ではイベントＣを読み取っている間に、イベントキュー１２にイベントが次々に格納されて滞留するが、上記のようにイベントＣを受信しないようにすることにより、他のイベントを迅速に読み取ることができ、滞留の発生を抑制できる。
【００４６】
一方、上記した▲３▼のイベントを読み取って、イベントキュー１２から削除した後で、受信側プロセス１３が、以下の処理をしたとする。すなわち、イベントＣを受信イベント管理テーブル１４に登録するとともに非受信イベント管理テーブル１５から削除し、逆にイベントＡを非受信イベント管理テーブル１５に登録して受信イベント管理テーブル１４から削除する処理を行う。さらに、受信イベント管理テーブル１４に登録されているイベントＢのイベント受信回数の値をイベント送信回数と同じ値に設定したとする。すると、受信イベント管理テーブル１４と非受信イベント管理テーブル１５は、図５に示すような内容となる。
【００４７】
この状態で、さらに受信側プロセス１３が、受信処理を継続したとすると、まず、イベントキュー１２に登録された一番古いイベントであるイベントＣを検出する。このイベントＣは、受信イベント管理テーブル１４から検索され、しかもイベントＣのイベント送信回数（１）は、イベント受信回数（０）よりも大きいので、ステップ２０４に飛び、イベントＣのイベント受信回数をインクリメントし、イベントキュー１２からイベントＣを読み込んだ後、イベントキュー１２から読み込んだイベントＣを削除する。
【００４８】
次に、イベントキュー１２に登録された一番古いイベントである▲４▼のイベントＢを検索する。このイベントＢは、受信イベント管理テーブル１４に登録されているため、イベントＢのイベント送信回数（２）と、イベント受信回数（２）を比較する。すると、送信回数は、受信回数より大きくないのでステップ２０３の分岐判断でＮｏとなり、ステップ２０８に飛び、イベントキュー１２から検索した▲４▼のイベントＢを読み取ることなくイベントキュー１２から削除する。これにより、イベントキュー１２には、▲５▼のイベントＡのみが格納されていることになる。
【００４９】
そして、イベントキュー１２に登録された一番古いイベントであるイベントＡを検出し、イベントＡは、非受信イベント管理テーブル１５に登録されているためステップ２０７に飛び、イベントキュー１２に格納されたイベントで次に古いイベントを検索しようとするが、検索できないのでそのまま処理を終了する。すなわち、上記したように途中で、管理テーブルの登録の入れ替えや、受信回数の強制変更を行った場合の読み出しの順は、「Ａ▲１▼，Ｂ▲３▼，Ｃ▲２▼」となり、▲４▼のＢは読み取られることなく削除され、▲５▼のＡはイベントキュー１２に残ったままとなる。
【００５０】
さらに、具体的な処理の流れは説明しないが、上記したイベントＢについての受信回数を送信回数と同じにする強制修正処理をしない場合には、読み出しの順は、「Ａ▲１▼，Ｂ▲３▼，Ｃ▲２▼，Ｂ▲４▼」となり、▲５▼のＡはイベントキュー１２に残ったままとなる。さらに、イベントＡについての非受信イベント管理テーブル１５側への移し替えを行わない（イベントＣの受信イベント管理テーブル１４側への移し替えのみする）場合には、読み出しの順は、「Ａ▲１▼，Ｂ▲３▼，Ｃ▲２▼，Ｂ▲４▼，Ａ▲５▼」となり、ＦＩＦＯ型とは異なる順番で、イベントキュー１２からすべてのイベントが読み出されることになる。そして、当然のことながら、管理テーブル間でのイベント識別子の移し替えのタイミングを変えることにより、読み出し順は、上記したもの以外のものになる。このように、読み出す順番や、読み出すイベントを任意に変えることができるようになる。
【００５１】
なお、上記した装置及び方法についての実施の形態は、本発明の最良のものの一つで、例えば、図１に記載のものから非受信イベント管理テーブルを除いても良い。また、非受信イベント管理テーブルを残しておいたとしても、両管理テーブルの送信回数と受信回数の項目をなくし、受信イベント管理テーブルに格納されているイベントのみを受信するようにしても良い。
【００５２】
【発明の効果】
以上のように本発明に係るイベント送受信方法及び装置では、滞留したイベントで不必要なイベントに対して受信処理を行うかどうかを選択的に行えることと、特定の処理要求イベントに対して一時的に受信処理を行わない方法を提供することにより、イベントの受信順序を自由に変更し、効率の良いイベントの送受信が行えるようになった。
【００５３】
つまり、本発明では、そもそも受信側プロセスにとって、不要なイベントがある場合には、そのイベントを受信イベント管理テーブルに登録しておかなかったり、受信イベント管理テーブルにある不必要なイベントの受信回数を送信回数と等しく設定することにより、不必要なイベントの受信処理を行う必要がなくなる。
【図面の簡単な説明】
【図１】本発明に係るイベント送受信方法及び装置が適用されるシステム全体を示す概略構成図である。
【図２】本発明に係るイベント送受信装置の実施の形態の一例を示す図である。
【図３】送信側プロセスの手順を示すフローチャート図である。
【図４】受信側プロセスの手順を示すフローチャート図である。
【図５】本発明の実施の形態で使われる、受信イベント管理テーブルと非受信イベント管理テーブルの一例である。
【符号の説明】
１１ 送信側プロセス
１２ イベントキュー
１３ 受信側プロセス
１４ 受信イベント管理テーブル
１５ 非受信イベント管理テーブル

Claims (2)

1. 送信側プロセスから受信側プロセスに対してイベントを送信するに際し、前記送信側プロセスは、前記イベントをイベントキューに順次格納し、前記受信側プロセスは、前記イベントキューに格納されたイベントを所定の順で読み出すようにしたイベント送受信方法において、
   イベントの種類ごとにイベント名と送信回数と受信回数を関連づけて管理する受信イベント管理テーブルを設け、イベントを送信する際に、そのイベントが前記受信イベント管理テーブルに格納されている場合には、前記イベントキューに格納するとともに、その送信するイベントに対応する前記送信回数を更新し、
   前記受信側プロセスが、前記イベントキューに格納されたイベントを受信する際には、前記受信イベント管理テーブルのイベントの送信回数と受信回数とを比較し、前記送信回数の方が大きいイベントのみを受信するとともに、前記受信イベント管理テーブルの受信したイベントに対応する受信回数を更新するようにし、
   かつ、前記受信回数の更新を前記イベントの受信と関係なく、強制的に変更できるようにし、
   前記受信側プロセスが受信したイベントに加え、前記送信回数が前記受信回数よりも大きくないイベントをイベントキューから削除するようにしたことを特徴とするイベント送受信方法。
2. 送信側プロセスから送信されたイベントを一時的に格納するイベントキューと、
   前記イベントキューに格納されたイベントを受信する受信側プロセスと、
   イベントの種類ごとにイベント名と送信回数と受信回数を関連づけて管理する受信イベント管理テーブルと、
   前記イベントキューにイベントが格納される都度、その格納されたイベントに対応するイベント名に関連付けられた送信回数を更新する送信回数更新手段と、 前記イベントキューに格納されたイベントが前記受信側プロセスに受信される都度、その受信されたイベントに対応するイベント名に関連付けられた受信回数を更新する受信回数更新手段と、
   前記イベントの受信と関係なく、前記受信回数を更新する受信回数強制更新手段とを備え、
   さらに、前記受信側プロセスは、前記イベントキューに格納されたイベントのうち、前記受信イベント管理テーブルのイベントの送信回数の方が受信回数よりも大きいイベントのみを受信するようにし、
   かつ、前記受信側プロセスが受信したイベントと前記送信回数が前記受信回数よりも大きくないイベントをイベントキューから削除する手段を備えたことを特徴とするイベント送受信装置。

Images