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

Abstract

(57)【要約】 【課題】 不必要なイベントを無効にすることができ、
またイベントの受信順序を自由に変更できるイベント送
受信装置を提供すること 【解決手段】 イベント名と、送受信回数を関連付けて
登録する受信イベント管理テーブル１４と非受信イベン
ト管理テーブル１５を設け、送信側プロセス１１は、イ
ベントキュー１２に格納する際に、いずれかのテーブル
に登録されたそのイベントについての送信回数を更新す
る。受信側プロセス１３は、受信イベント管理テーブル
の送信回数と受信回数を比較し、送信回数の方が大きい
時はイベント受信回数を更新して、イベントキュー１２
からイベントを読み込む。イベント名を登録する受信イ
ベント管理テーブルと非受信イベント管理テーブルとの
間でそのイベントを相手側のテーブルに移し替えること
により、受信順序を入れ替え、受信回数を大きくするこ
とにより、不要なものを受信しないで済む。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、イベント送受信方
法及び装置に関するもので、より具体的には、イベント
キューに格納したイベントの読み出し順を決定する部分
の改良に関する。

【０００２】

【従来の技術】コンピュータシステム内でのイベントの
伝送方式の一つとして、キューを用いたものがある。こ
れはよく知られているように、あるプロセスから送信さ
れたイベントを一旦メモリ内に割り当てられたキュー
（本明細書ではこれを「イベントキュー」と称する）
に、送信された順に格納していき、そのイベントキュー
に格納された各イベントは、格納された順に取り出され
るＦＩＦＯ型のデータ構造で管理されるようになってい
る。

【０００３】また、送信されるイベントには、重要度・
緊急度が異なるものがあり、係る場合に常に上記ＦＩＦ
Ｏ型で管理されると、スムーズな処理ができなくなる。
そこで、係る問題を解決するため、送信する個々のイベ
ントに優先度（プライオリティ）を示すデータを付加
し、イベントの取り出しは、優先度が一番高いものから
順に行うようにし、仮に優先度が同じものの場合には、
先に格納したものを取り出すようにしたものがある。こ
のように優先度とＦＩＦＯ型を組み合わせたものはプラ
イオリティキューとも称されている。

【０００４】

【発明が解決しようとする課題】しかしながら、上記し
たプライオリティキュー方式では、各イベントに優先度
を付加しなければならず、そのため優先度のフラグの分
だけデータ長が長くなり、メモリの利用効率並びに伝送
効率が悪くなる。

【０００５】また、優先度（プライオリティ）を付加す
る処理が必要となるばかりでなく、優先度は、伝送する
イベントの種類のみに起因するのではなく、送信後に受
信する順番を替えたいことがあり、係る場合には送信後
に優先度の変更ができない従来のプライオリティキュー
方式では充分に対応できない。すなわち、イベントの受
信処理時間がイベントの送信間隔よりも長い時でしかも
同時に複数のイベントが送信された場合には、処理しき
れないイベントがイベントキューに滞留してしまい、新
たに送信されたイベントを受信し、個別処理するために
は、滞留している全てのイベントの受信処理を行わなけ
ればならないが、これも、同時（比較的短時間の間）に
イベントキューに格納されるイベント数が少ない場合に
は問題が発生しないので、周囲の状況により同一のイベ
ントであっても、ＦＩＦＯ型で受信しても滞留を起こさ
ない場合と、滞留を起こす場合がある。したがって、前
記イベントキューに蓄えられたイベントの受信順序を自
由に変更することができると好ましいが、従来のもので
はそれを解決できるものがなかった。

【０００６】本発明は、上記した背景に鑑みてなされた
もので、その目的とするところは、上記した問題を解決
し、滞留したイベントで不必要なイベントに対して受信
処理を行うかどうかを選択的に行えることと、特定の処
理要求イベントに対して一時的に受信処理を行わない方
法を提供することにより、イベントの受信順序を自由に
変更し、効率の良いイベントの送受信を行えるイベント
送受信方法及び装置を提供するものである。

【０００７】

【課題を解決するための手段】上記した目的を達成する
ため、本発明に係るイベント送受信方法では、送信側プ
ロセスから受信側プロセスに対してイベントを送信する
に際し、送信側プロセスは、前記イベントをイベントキ
ューに順次格納し、受信側プロセスは、前記イベントキ
ューに格納されたイベントを所定の順で読み出すように
したイベント送受信方法において、イベントの種類ごと
にイベント名（実施の形態では「イベント識別子」）と
送信回数と受信回数を関連づけて管理する受信イベント
管理テーブルを設け、イベントを送信する際に、そのイ
ベントが前記受信イベント管理テーブルに格納されてい
る場合には、前記イベントキューに格納するとともに、
その送信するイベントに対応する前記送信回数を更新
し、前記受信側プロセスが、前記イベントキューに格納
されたイベントを受信する際には、前記受信イベント管
理テーブルのイベントの送信回数と受信回数とを比較
し、前記送信回数の方が大きいイベントのみを受信する
とともに、前記受信イベント管理テーブルの受信したイ
ベントに対応する受信回数を更新するようにし、かつ、
前記受信回数の更新を前記イベントの受信と関係なく、
強制的に変更できるようにし、前記受信側プロセスが受
信したイベントに加え、前記送信回数が前記受信回数よ
りも大きくないイベントをイベントキューから削除する
ようにした（請求項１）。

【０００８】そして、上記した方法を実施するのに適し
た本発明に係るイベント送受信装置では、送信側プロセ
スから送信されたイベントを一次的に格納するイベント
キューと、前記イベントキューに格納されたイベントを
受信する受信側プロセスと、イベントの種類ごとにイベ
ント名と送信回数と受信回数を関連づけて管理する受信
イベント管理テーブルと、前記イベントキューにイベン
トが格納される都度、その格納されたイベントに対応す
るイベント名に関連付けられた送信回数を更新する送信
回数更新手段（実施の形態では「送信側プロセス」）
と、前記イベントキューに格納されたイベントが前記受
信側プロセスに受信される都度、その受信されたイベン
トに対応するイベント名に関連付けられた受信回数を更
新する受信回数更新手段（実施の形態では「受信側プロ
セス」）と、前記イベントの受信と関係なく、前記受信
回数を更新する受信回数強制更新手段（実施の形態では
「受信側プロセス」）とを備え、さらに、前記受信側プ
ロセスは、前記イベントキューに格納されたイベントの
うち、前記受信イベント管理テーブルのイベントの送信
回数の方が受信回数よりも大きいイベントのみを受信す
るようにし、かつ、前記受信側プロセスが受信したイベ
ントと前記送信回数が前記受信回数よりも大きくないイ
ベントをイベントキューから削除する手段（実施の形態
では「受信側プロセス」）とを備えて構成した（請求項
２）。

【０００９】なお、受信イベント管理テーブルに対する
イベント名の登録は、すべてのイベント名を登録しても
良く、或いは選択的に所望イベント名のみを登録しても
良い。

【００１０】請求項１，２に記載した発明では、受信イ
ベント管理テーブルに登録されたものでしかも送信回数
の方が受信回数よりも大きいイベントのみが受信され
る。したがって、そもそも受信側プロセスにとって、不
要なイベントがある場合には、そのイベントを受信イベ
ント管理テーブルに登録しておかなければ、受信するこ
とがない。よって、不要なイベントを受信することによ
る受信並びにその後の解析に要する時間が短縮できる。
また、受信イベント管理テーブルに格納したイベントで
あっても、イベントキューでイベントの滞留が起こった
場合、滞留したイベントのなかで不必要なものがあれ
ば、受信回数強制更新手段を用いて受信イベント管理テ
ーブルにある不必要なイベントの受信回数を送信回数と
等しく設定する。すると、不必要なイベントの受信処理
を行う必要がなくなる。

【００１１】また、別の解決手段としての本発明に係る
イベント送受信方法では、送信側プロセスから受信側プ
ロセスに対してイベントを送信するに際し、送信側プロ
セスは、前記イベントをイベントキューに順次格納し、
受信側プロセスは、前記イベントキューに格納されたイ
ベントを所定の順で読み出すようにしたイベント送受信
方法において、前記受信側プロセスが受信を許容するイ
ベント名を登録するための受信イベント管理テーブル
と、前記受信側プロセスが受信を拒否するイベント名を
登録するための非受信イベント管理テーブルを設け、前
記受信側プロセスが、前記イベントキューに格納された
イベントを受信する際には、少なくとも前記受信イベン
ト管理テーブルをアクセスし、その受信イベント管理テ
ーブルに登録されたイベント名のイベントのみ受信する
ようにし、かつ、所定の条件に従い一方の管理テーブル
に登録されたイベント名を他方の管理テーブルに移し替
えられるようにした（請求項３）。

【００１２】そして、その方法を実施するのに適した装
置としては、送信側プロセスから送信されたイベントを
一次的に格納するイベントキューと、前記イベントキュ
ーに格納されたイベントを受信する受信側プロセスと、
前記受信側プロセスが受信を許容するイベント名を登録
するための受信イベント管理テーブルと、前記受信側プ
ロセスが受信を拒否するイベント名を登録するための非
受信イベント管理テーブルと、前記受信イベント管理テ
ーブルまたは前記非受信イベント管理テーブルに対する
イベント名の登録を管理する管理手段（実施の形態では
「受信側プロセス」）とを備え、さらに、前記受信側プ
ロセスは、前記イベントキューに格納されたイベントの
うち、前記受信イベント管理テーブルのみを受信するよ
うにし、かつ、前記管理手段は、あるイベント名を登録
する場合には、両管理テーブルのうちいずれか一方に登
録し、一方の管理テーブルに登録されたイベント名を他
方の管理テーブルに移し替えられるように構成した（請
求項４）。

【００１３】請求項３，４に記載した発明では、一時的
に受信する必要のないイベントを、非受信イベント管理
テーブルに登録しておき、受信する必要ができたとき
に、非受信イベント管理テーブルに登録されているイベ
ントを受信イベント管理テーブルに登録し直すことによ
り、イベントの受信の順序を自由に変更することができ
る。これにより、イベントキューにイベントが多数格納
されて滞留を生じることがなくなり、必要なイベントを
効率良く受信することができる。そして、プライオリテ
ィイベントキューと異なり、実際に送信するイベントに
はプライオリティ（優先度）に関するフラグを付加する
のではないので、伝送するイベントのデータ長は短くな
り、短時間で送信が可能なる。そして、イベントキュー
に格納されている間に登録している管理テーブルを切り
替えることにより、送信後に状況等に応じて優先順位を
自由に替えることができる。

【００１４】そして好ましくは、請求項３に記載の各管
理テーブルが、イベント名と送信回数と受信回数を関連
づけて管理するものであって、イベントを送信する際
に、前記イベントキューに格納するとともに、そのイベ
ントが登録された前記受信イベント管理テーブルまたは
前記非受信イベント管理テーブルに登録された送信回数
を更新し、前記受信側プロセスが、前記イベントキュー
に格納されたイベントを受信する際には、対応するイベ
ント名が前記受信イベント管理テーブルに登録されてお
り、かつ、そのイベント名に関連付けられた送信回数と
受信回数とを比較し、前記送信回数の方が大きいイベン
トのみを受信するようにし、かつ、前記受信イベント管
理テーブルに登録された受信回数は、イベントを受信す
る都度更新し、さらに、その受信回数の更新を前記イベ
ントの受信と関係なく、強制的に変更できるようにし、
前記受信側プロセスが受信したイベント及び、前記送信
回数が前記受信回数よりも大きくないイベントをイベン
トキューから削除するようにすることである（請求項
５）。

【００１５】そして、その方法を実施するための装置と
しては、請求項４に記載の各管理テーブルが、イベント
名と送信回数と受信回数を関連づけて管理するものであ
って、前記イベントキューにイベントが格納される都
度、その格納されたイベントに対応するイベント名に関
連付けられた前記送信回数を更新する送信回数更新手段
と、前記イベントキューに格納されたイベントが前記受
信側プロセスに受信される都度、その受信されたイベン
トに対応するイベント名に関連付けられた受信回数を更
新する受信回数更新手段と、前記イベントの受信と関係
なく、前記受信回数を更新する受信回数強制更新手段と
を備え、前記受信側プロセスが、前記イベントキューに
格納されたイベントのうち、前記受信イベント管理テー
ブルのイベントの送信回数の方が受信回数よりも大きい
イベントのみを受信するようにし、かつ、前記受信側プ
ロセスが受信したイベントと前記送信回数が前記受信回
数よりも大きくないイベントをイベントキューから削除
する手段を備えて構成することである（請求項６）。

【００１６】係る構成にすると、上記した請求項１，２
と請求項３，４の作用効果を同時に発揮でき、より好ま
しいものとなる。

【００１７】ここで、上記した送信回数更新手段は、実
施の形態では、送信側プロセスの機能に一体的に組み込
んでいる。しかし、本発明は必ずしも一体にする必要は
なく、例えば、イベントキューに格納されるイベントを
監視し、テーブルに登録された受信回数を更新するよう
にする手段を別途設けても良い。同様に、受信回数更新
手段と受信回数強制更新手段は、実施の形態では、受信
側プロセスの機能に一体的に組み込んでいるが、これも
いずれか一方或いは双方とも別部材として構成しても良
い。さらに、イベントを削除する手段も、実施の形態と
してでは、受信側プロセスの機能に組み込んでいるが、
別途形成しても良く、さらに、受信したイベントを削除
する手段と、受信回数と送信回数の大小関係に基づいて
イベントを削除する手段を別々に形成してももちろん良
い。さらには、各管理テーブルにイベント名等を登録し
たり、一度登録したものを別の管理テーブルに移し替え
る管理手段も実施の形態では、受信側プロセスの機能に
一体的に組込んでいるが、これも別途構成してもよい。

【００１８】

【発明の実施の形態】図１は本発明が適用されるコンピ
ュータシステムの一例の概略構成を示している。本発明
の要部を説明する前に、同図に基づいてシステム全体に
ついて説明する。コンピュータがあるシステムを実行す
る場合には、各プロセス間でイベントの送受を行い、イ
ベントを受け取ったプロセスは、そのイベントの内容に
応じて所定の処理をし、必要に応じて他のプロセスに再
度イベントを送信したり、外部に出力したりする。そし
て、そのイベントの送受は、イベントを受信するプロセ
ス側にそれぞれイベントキューを接続し、送信側のプロ
セスは、そのイベントキューに対して逐次データを格納
していき、また受信側のプロセスは、そのイベントキュ
ーに格納された自分宛のイベントを所定の順で取り出す
ようになっている。

【００１９】一例を示すと、あるシステム（例えば変電
所内の運転を管理するシステム）を実行するためには、
複数のプロセス１ａ，１ｂ，１ｃ，１ｄ（実際には、こ
れ以外にも多数のプロセスが存在する）を適宜関連づけ
て連結し、イベントを受信するプロセス１ａ，１ｂ，１
ｃについては、それぞれにイベントキュー２ａ，２ｂ，
２ｃを接続している。そして、各プロセスは、実際に
は、プログラムで構成される。

【００２０】また、図示した例における各プロセスの機
能・内容を簡単に説明すると、障害管理プロセス１ａ
は、システムのハードウェア並びにソフトウェアの障害
の発生・復旧を通知するイベントを受信し、その情報を
モニター画面に表示したりファイルに障害の履歴情報を
格納したりする処理をするものである。

【００２１】また、ハードウェア監視プロセス１ｂは、
システムを構築するハードウェアの状態を監視し、障害
が発生したり、また、発生した障害が復旧されたことを
認識したならば、障害発生イベントまたは復旧イベント
を障害管理プロセス１ａに対して送信する（実際には、
イベントキュー２ａに格納する）ように機能する。

【００２２】同様に、ソフトウェア監視プロセス１ｃ
は、システムを構築するソフトウェアの状態を監視し、
障害が発生したり、また、発生した障害が復旧されたこ
とを認識したならば、障害発生イベントまたは復旧イベ
ントを障害管理プロセス１ａに対して送信する（実際に
は、イベントキュー２ａに格納する）ように機能する。

【００２３】また、時刻管理プロセス１ｄは、内蔵する
時計に基づいて、システム全体の時間を管理するもの
で、予め定められた時刻が来ると、時刻イベントを所定
のプロセス１ａ〜１ｃに伝えるようになる。また、指定
された時間が経過された場合には、タイマーイベントを
所定のプロセス１ａ〜１ｃに伝えるようになる。そし
て、この時刻管理プロセス１ｄから送信されるイベント
に基づいて、各プロセスでは、一定時間間隔或いは定時
毎に所定の処理を実行することができるようになってい
る。

【００２４】なお、この時刻管理プロセス１ｄは、内蔵
する時計に基づいて所定のイベントを所定のプロセスに
対して送信するだけで、他のプロセスからイベントを取
得することがないので、イベントキューは接続していな
い。なおまた、各プロセスで実行させる基本的な処理は
従来と同様のものを用いることができるので、それを実
行するためのより具体的な機能の詳細な説明は省略す
る。

【００２５】ここで本発明では、上記したシステム構成
を前提とし、各プロセス１ａ〜１ｃがイベントキュー２
ａ〜２ｃに格納されたイベントを受け取る順番を単純に
ＦＩＦＯ型で行うのではなく、イベントの種類やその時
の状況に即し、ＦＩＦＯ型を基本としながら、適宜順番
を変えたり、不要なイベントの受け取りを拒否するよう
にし、効率よくデータの受け取りをできるようにしてい
る。そして、それを実行するためのイベント送受信装置
の一実施の形態を図２に示している。

【００２６】同図に示すように、コンピュータ１０内部
に実装される送信側プロセス１１から送信されたイベン
トは、一旦イベントキュー１２に格納され、そのイベン
トキュー１２を介して受信側プロセス１３に受け渡され
るようになっている。この基本構成は、上記した図１に
示すものと同様である。なお、送信側プロセス１１は、
図の例では１つのみ代表として表示したが、仮に受信側
プロセス１３が図１における障害管理プロセス１ａとす
ると、送信側プロセス１１は、ハードウェア監視プロセ
ス１ｂ，ソフトウェア監視プロセス１ｃ，時刻管理プロ
セス１ｄの３つのプロセスが並列的に存在することにな
る。

【００２７】ここで本発明では、送信側プロセス１１及
び受信側プロセス１３からそれぞれアクセス可能な非受
信イベント管理テーブル１４と、受信イベント管理テー
ブル１５とを設けている。そして、各テーブル１４，１
５のデータ構造は、図示するように、イベントの内容を
特定するイベント識別子（イベント名）と、そのイベン
トを送信した送信回数と、受信側プロセス１３がそのイ
ベントを受信した受信回数の３つのデータを関連づけて
格納するようになっている。

【００２８】そして、各管理テーブル１４，１５に対す
るイベント識別子の登録は、受信側プロセス１３が行
う。つまり、自己が受け得るイベントを予め受信イベン
ト管理テーブル１４か非受信イベント管理テーブル１５
のいずれか一方に登録する。この時、いずれのテーブル
に登録するかは、そのイベントが優先して受信する必要
があるか否かにより決定され、具体的には、優先して受
信するイベントは受信イベント管理テーブル１４に格納
し、優先しては受信しないイベントは非受信イベント管
理テーブル１５に格納するようになっている。さらに、
その後の所定のタイミングで、一旦登録したイベント識
別子を別の管理テーブルに移し替えることができるよう
になっている。さらにまた、イベントキュー１２に格納
されたイベントを受信した（読み取った）場合には、受
信イベント管理テーブル１４に格納された受信回数の欄
の数値をインクリメント（１を加算）する機能を基本機
能として持ち、さらに実際に受信したか否かに関係な
く、受信回数の欄の数値の更新・書き換えを行うことが
できる機能も有している。

【００２９】また、管理テーブル１４，１５の登録項目
のうち送信回数の欄の数値は、送信側プロセス１１がイ
ベントキュー１２にイベントを格納する際に、その数値
をインクリメント（１を加算）するようになっている。

【００３０】次に、送信側プロセス１１の本発明と関係
する部分の機能について説明する。送信側プロセス１１
は、従来から有している通常の機能に加え、図３のフロ
ーチャートに示す機能を有している。すなわち、まず、
あるイベントを送信しようとした場合には、その送信先
に付随する受信イベント管理テーブル１４と非受信イベ
ント管理テーブル１５をアクセスし、そのイベント識別
子の欄をサーチし、送信するイベントを検索する（Ｓ１
０１）。次いで、その検索したイベント識別子に関連す
るイベント送信回数をインクリメントし（Ｓ１０２）、
その後、送信するイベントをイベントキュー１２に登録
する（Ｓ１０３）。そして、本発明では、ＦＩＦＯ型を
基本とするため、イベントキュー１２への各イベントの
格納は、先頭から順に行う。つまり、一番後ろに格納す
ることになる。

【００３１】一方、受信側プロセス１３は、上記したよ
うに初期設定としていずれかの管理テーブル１４，１５
にイベント識別子を登録したり、一旦登録したイベント
識別子を別のテーブルに移し替えたり、受信回数を擬似
的に変更する機能に加え、イベントキュー１２に格納さ
れたイベントを受信するという本来の機能を当然有して
いる。すなわち、その受信機能は、先頭に格納された
（一番古い）イベントから順に受信するというＦＩＦＯ
型を基本とし、その際に、受信しようとしたイベント
が、２つの管理テーブル１４，１５のいずれに登録され
たものか、及びまたはイベント送信回数とイベント受信
回数の大小関係に基づいて、「受信する／しない」の選
択を行うことにより、不要なイベントを受信しないよう
にする。さらに、途中でイベント識別子を登録する管理
テーブルを替えることにより、一旦受信しないと選択し
たものをその後に受信可能とし、これにより、受信する
順番を替えることができるようにしている。そして、具
体的な処理は、図４のフローチャートに示すようになっ
ている。

【００３２】すなわち、まず、イベントキュー１２に登
録された一番古いイベントを検索する（Ｓ２０１）。そ
して、検索できた（成功）ならば、受信イベント管理テ
ーブル１４をアクセスし、そのイベントが受信イベント
管理テーブルに登録されているものか否かを判断し（Ｓ
２０２）、登録されている場合には、そのイベント識別
子についてのイベント送信回数とイベント受信回数を取
得し、送信回数の方が大きいか否かを判断する（Ｓ２０
３）。

【００３３】そして、送信回数の方が大きい場合には、
そのイベントについてのイベント受信回数をインクリメ
ントする（Ｓ２０４）。その後、通常の受信処理、すな
わち、イベントキュー１２からそのイベントを読み込ん
だ後（Ｓ２０５）、イベントキュー１２から読み込んだ
イベント２０を削除して処理を終了する（Ｓ２０６）。

【００３４】一方、ステップ２０２の分岐判断を行った
結果、取得したイベントが受信イベント管理テーブル１
４に登録されていない場合（非受信イベント管理テーブ
ル１５に登録されている）には、ステップ２０７に飛
び、次に古いイベントをイベントキュー１２から検索
し、検索できたならば、ステップ２０２に戻り、上記し
た処理を繰り返し行う。また、ステップ２０７の処理
で、イベントを検索できない（失敗）、つまり、最新に
格納したイベントまで処理を行ったならば、一連の受信
処理を終了するようになる。

【００３５】このように、受信イベント管理テーブル１
４に登録されたイベントのみを受信するようにしたた
め、たとえイベントキュー１２に先に格納されたイベン
トがあったとしてもそのイベントが非受信イベント管理
テーブル１５に登録されている場合には、読み出されな
い。つまり、ＦＩＦＯ型を前提としつつ、必ずしも先に
格納されたイベントが先に読み出されるものではなく、
必要なものから先に読み出され、その読み出し順を変え
ることができる。換言すると、本例では、受信イベント
管理テーブル１４に登録されたイベントの中で、先に登
録されたものから順に読み出す（ＦＩＦＯ型）ようにし
ている。

【００３６】しかも、受信側プロセス１３により、一旦
非受信イベント管理テーブル１５の登録したイベント
を、その後に受信イベント管理テーブル１４側に移し替
えるようにしたため、当初は、ステップ２０２の判断で
Ｎｏとなり読み出されなかったものが、その後に管理テ
ーブルの移し替えが行われることによりステップ２０２
の判断でＹｅｓになり読み出しを可能とすることができ
る。また、逆に当初受信イベント管理テーブル１４に登
録しておき、その後に非受信イベント管理テーブル１５
に移し替え、受信を拒否することもできる。このよう
に、完全に読み出しの順番を入れ替えることができるよ
うになる。

【００３７】なお、受信側プロセス１３における各管理
テーブル１４，１５への登録及び移し替えは、そのプロ
セスを設計する際に行う。そして、このように本例で
は、２つの管理テーブル１４，１５を設置し、それらを
適宜使いわけることにより、例えば、受信に時間がかか
るとともに、さほど緊急性を有しないイベントは、とり
あえず非受信イベント管理テーブルに格納しておき、イ
ベントキュー１２に格納されたイベントがなくなるか、
少なくなったときに受信イベント管理テーブルに登録し
直すことにより、効率よく受信処理ができる。また、最
初はすべてのイベントを受信イベント管理テーブル１４
に登録しておき、例えば、混んできた（イベントキュー
に格納されたイベントが滞留する）場合に、受信に時間
を要するイベントを非受信イベント管理テーブル１５に
移し替えることにより、スムーズにイベントの読み出し
をすることができるようにもできる。

【００３８】さらに、非受信イベント管理テーブルに登
録したままにすると、受信処理しないため、自己のプロ
セスにとって不要なイベントを受信する必要がなくな
る。よって、無駄な読み込み処理や読み取ったイベント
を解析する処理等がなくなり、システム全体の稼働効率
が向上する。

【００３９】一方、ステップ２０３の分岐判断で、イベ
ント送信回数とイベント受信回数が等しいか、イベント
受信回数の方が大きい場合には、ステップ２０８に飛
び、検索したイベントをイベントキューから削除する。
すなわち、通常であれば、送信側プロセス１１がイベン
トをイベントキューに登録する都度イベント送信回数の
数値が１加算され（Ｓ１０２）、その登録されたイベン
トが読み出されることによってイベント受信回数の数値
が１加算される（Ｓ２０４）ため、原則としてはイベン
トキュー１２にイベントが残っていると、イベント送信
回数の方が必ず大きくなり、ステップ２０３の判断では
Ｙｅｓになる。

【００４０】しかし、上記したように、受信側プロセス
１３に、受信回数を強制的に変更する機能を与えたた
め、実際の受信回数以上の回数に書き換えると、イベン
トキュー１２にイベントが残っていても送信回数の方が
小さくなり、ステップ２０３でＮｏと判断されることが
ある。これにより、不要なイベントを受信することなく
イベントキュー１２から削除することができるようにな
る。よって、イベントキュー１２にイベントが残ったま
まとなることがなくなり、メモリの使用効率が向上す
る。

【００４１】次に、上記した装置を用いて、本発明に係
るイベント送受信方法の実施の形態を説明する。まず、
前提として送信側プロセス１１は受信側プロセス１３に
対してイベントＡとイベントＢとイベントＣを複数送信
し、送信された各イベントは一旦イベントキュー１２に
保存され、イベント受信プロセス１３はイベントキュー
１２からイベントを所定の順で読み込むものとする。そ
して、受信側プロセス１３は、初期状態として、イベン
トＡとイベントＢを受信イベント管理テーブル１４に登
録し、イベントＣを非受信イベント管理テーブル１５に
登録する。なお、各テーブル１４，１５のイベント送信
回数とイベント受信回数はともに「０」になっている。

【００４２】ここで、送信側プロセス１１が、受信側プ
ロセス１３に対してイベントを「イベントＡ」，「イベ
ントＣ」，「イベントＢ」，「イベントＢ」，「イベン
トＡ」の順に送信したとする。すると、図３のフローチ
ャートに従って、まず、最初のイベントＡは、受信イベ
ント管理テーブル１４に登録されたイベントであるの
で、そのテーブル１４のイベントＡについてのイベント
送信回数をインクリメントし、イベントＡをイベントキ
ュー１２の先頭に登録する。次にイベントＣは、非受
信イベント管理テーブル１５に登録されたイベントであ
るので、そのテーブル１５のイベントＣについてのイベ
ント送信回数をインクリメントし、イベントＣをイベン
トキュー１２の２番目に登録する。以後係る処理を繰
り返し行うことにより、図２に示すように、イベントキ
ュー１２には、送信した順にイベントが格納されるとと
もに、各管理テーブル１４，１５の送信回数が所定の値
となる。この時、受信はされていないため、各管理テー
ブル１４，１５の受信回数は０のままとなる。これによ
り、送信処理は終了する。

【００４３】次に、受信処理について説明する。受信側
プロセス１３は、図４に示すフローチャートに従って、
まず、イベントキュー１２に登録された一番古いイベン
トを検索し、イベントＡを検出する（Ｓ２０１）。そし
て、イベントＡをキーとして受信イベント管理テーブル
１４をアクセスする。すると、イベントＡは、その管理
テーブル１４に登録されているため、次に受信イベント
管理テーブル１４に格納されたイベントＡについての送
信回数（２回）と受信回数（０回）を取得するとともに
両者を比較する（Ｓ２０２，２０３）。この場合、イベ
ントＡのイベント送信回数は、イベント受信回数よりも
大きいので、ステップ２０４〜２０６を順次処理する。
すなわち、のイベントＡのイベント受信回数をインク
リメントして「１」にし、イベントキュー１２の先頭
からイベントＡを読み込んだ後、イベントキュー１２か
ら読み込んだイベントＡを削除する。

【００４４】次に、上記処理によりのイベントＡは削
除されているため、現在の一番古いイベントは、のイ
ベントＣとなっている。そこで、ステップ２０１から再
度処理すると、イベントキュー１２に登録された現在の
一番古いイベントであるイベントＣを検出する。する
と、イベントＣは、非受信イベント管理テーブルから検
索されるので、ステップ２０７に飛びイベントキュー１
２に格納されたイベントで次に古いイベントを検索し、
のイベントＢを検出する。のイベントＢは、受信イ
ベント管理テーブル１４に登録されており、しかも、そ
の管理テーブル１４のイベントＢのイベント送信回数
（２）は、イベント受信回数（０）よりも大きいので、
のイベントＢのイベント受信回数をインクリメント
し、イベントキュー１２からのイベントＢを読み込ん
だ後、イベントキュー１２から読み込んだイベントＢを
削除し処理を終了する。

【００４５】このように、イベントキュー１２に格納し
た順番は、イベントＡ，Ｃ，Ｂ…の順であったが、読み
出す際には、イベントＣを飛び越えてイベントＡ，Ｂの
順で行われる。そして、管理テーブルに登録するイベン
ト識別子の移し替えや、受信回数の強制修正がないとす
ると、イベントキュー１２に登録された一番古いイベン
トであるイベントＣは読み出されず、以降に登録され
たイベントＢ，Ａの順で読み出される。そして、最終的
な受信イベント管理テーブル１４の受信回数は、ともに
２となる。つまり、ＦＩＦＯ型であれば、「Ａ，Ｃ，
Ｂ，Ｂ，Ａ」の順で読み取られ、イベントキュー１２に
は、イベントが何も残らないが、「Ａ，Ｂ，Ｂ，Ａ」の
順で読み取られ、イベントＣはイベントキュー１２に残
ったままとなる。そして、例えばイベントＣが読取りに
時間がかかるような場合には、ＦＩＦＯ型ではイベント
Ｃを読み取っている間に、イベントキュー１２にイベン
トが次々に格納されて滞留するが、上記のようにイベン
トＣを受信しないようにすることにより、他のイベント
を迅速に読み取ることができ、滞留の発生を抑制でき
る。

【００４６】一方、上記したのイベントを読み取っ
て、イベントキュー１２から削除した後で、受信側プロ
セス１３が、以下の処理をしたとする。すなわち、イベ
ントＣを受信イベント管理テーブル１４に登録するとと
もに非受信イベント管理テーブル１５から削除し、逆に
イベントＡを非受信イベント管理テーブル１５に登録し
て受信イベント管理テーブル１４から削除する処理を行
う。さらに、受信イベント管理テーブル１４に登録され
ているイベントＢのイベント受信回数の値をイベント送
信回数と同じ値に設定したとする。すると、受信イベン
ト管理テーブル１４と非受信イベント管理テーブル１５
は、図５に示すような内容となる。

【００４７】この状態で、さらに受信側プロセス１３
が、受信処理を継続したとすると、まず、イベントキュ
ー１２に登録された一番古いイベントであるイベントＣ
を検出する。このイベントＣは、受信イベント管理テー
ブル１４から検索され、しかもイベントＣのイベント送
信回数（１）は、イベント受信回数（０）よりも大きい
ので、ステップ２０４に飛び、イベントＣのイベント受
信回数をインクリメントし、イベントキュー１２からイ
ベントＣを読み込んだ後、イベントキュー１２から読み
込んだイベントＣを削除する。

【００４８】次に、イベントキュー１２に登録された一
番古いイベントであるのイベントＢを検索する。この
イベントＢは、受信イベント管理テーブル１４に登録さ
れているため、イベントＢのイベント送信回数（２）
と、イベント受信回数（２）を比較する。すると、送信
回数は、受信回数より大きくないのでステップ２０３の
分岐判断でＮｏとなり、ステップ２０８に飛び、イベン
トキュー１２から検索したのイベントＢを読み取るこ
となくイベントキュー１２から削除する。これにより、
イベントキュー１２には、のイベントＡのみが格納さ
れていることになる。

【００４９】そして、イベントキュー１２に登録された
一番古いイベントであるイベントＡを検出し、イベント
Ａは、非受信イベント管理テーブル１５に登録されてい
るためステップ２０７に飛び、イベントキュー１２に格
納されたイベントで次に古いイベントを検索しようとす
るが、検索できないのでそのまま処理を終了する。すな
わち、上記したように途中で、管理テーブルの登録の入
れ替えや、受信回数の強制変更を行った場合の読み出し
の順は、「Ａ，Ｂ，Ｃ」となり、のＢは読み取
られることなく削除され、のＡはイベントキュー１２
に残ったままとなる。

【００５０】さらに、具体的な処理の流れは説明しない
が、上記したイベントＢについての受信回数を送信回数
と同じにする強制修正処理をしない場合には、読み出し
の順は、「Ａ，Ｂ，Ｃ，Ｂ」となり、のＡは
イベントキュー１２に残ったままとなる。さらに、イベ
ントＡについての非受信イベント管理テーブル１５側へ
の移し替えを行わない（イベントＣの受信イベント管理
テーブル１４側への移し替えのみする）場合には、読み
出しの順は、「Ａ，Ｂ，Ｃ，Ｂ，Ａ」とな
り、ＦＩＦＯ型とは異なる順番で、イベントキュー１２
からすべてのイベントが読み出されることになる。そし
て、当然のことながら、管理テーブル間でのイベント識
別子の移し替えのタイミングを変えることにより、読み
出し順は、上記したもの以外のものになる。このよう
に、読み出す順番や、読み出すイベントを任意に変える
ことができるようになる。

【００５１】なお、上記した装置及び方法についての実
施の形態は、本発明の最良のものの一つで、例えば、図
１に記載のものから非受信イベント管理テーブルを除い
ても良い。また、非受信イベント管理テーブルを残して
おいたとしても、両管理テーブルの送信回数と受信回数
の項目をなくし、受信イベント管理テーブルに格納され
ているイベントのみを受信するようにしても良い。

【００５２】

【発明の効果】以上のように本発明に係るイベント送受
信方法及び装置では、滞留したイベントで不必要なイベ
ントに対して受信処理を行うかどうかを選択的に行える
ことと、特定の処理要求イベントに対して一時的に受信
処理を行わない方法を提供することにより、イベントの
受信順序を自由に変更し、効率の良いイベントの送受信
が行えるようになった。

【００５３】つまり、請求項１，２，５，６に記載した
発明では、そもそも受信側プロセスにとって、不要なイ
ベントがある場合には、そのイベントを受信イベント管
理テーブルに登録しておかなかったり、受信イベント管
理テーブルにある不必要なイベントの受信回数を送信回
数と等しく設定することにより、不必要なイベントの受
信処理を行う必要がなくなる。

【００５４】また、請求項３，４，５，６に記載した発
明では、一時的に受信する必要のないイベントを、非受
信イベント管理テーブルに登録しておき、受信する必要
ができたときに、非受信イベント管理テーブルに登録さ
れているイベントを受信イベント管理テーブルに登録し
直すことにより、イベントの受信の順序を自由に変更す
ることができる。

【図面の簡単な説明】

【図１】本発明に係るイベント送受信方法及び装置が適
用されるシステム全体を示す概略構成図である。

【図２】本発明に係るイベント送受信装置の実施の形態
の一例を示す図である。

【図３】送信側プロセスの手順を示すフローチャート図
である。

【図４】受信側プロセスの手順を示すフローチャート図
である。

【図５】本発明の実施の形態で使われる、受信イベント
管理テーブルと非受信イベント管理テーブルの一例であ
る。

【符号の説明】

１１ 送信側プロセス １２ イベントキュー １３ 受信側プロセス １４ 受信イベント管理テーブル １５ 非受信イベント管理テーブル

Claims (6)

【特許請求の範囲】
1. 【請求項１】 送信側プロセスから受信側プロセスに対
   してイベントを送信するに際し、前記送信側プロセス
   は、前記イベントをイベントキューに順次格納し、前記
   受信側プロセスは、前記イベントキューに格納されたイ
   ベントを所定の順で読み出すようにしたイベント送受信
   方法において、 イベントの種類ごとにイベント名と送信回数と受信回数
   を関連づけて管理する受信イベント管理テーブルを設
   け、イベントを送信する際に、そのイベントが前記受信
   イベント管理テーブルに格納されている場合には、前記
   イベントキューに格納するとともに、その送信するイベ
   ントに対応する前記送信回数を更新し、 前記受信側プロセスが、前記イベントキューに格納され
   たイベントを受信する際には、前記受信イベント管理テ
   ーブルのイベントの送信回数と受信回数とを比較し、前
   記送信回数の方が大きいイベントのみを受信するととも
   に、前記受信イベント管理テーブルの受信したイベント
   に対応する受信回数を更新するようにし、 かつ、前記受信回数の更新を前記イベントの受信と関係
   なく、強制的に変更できるようにし、 前記受信側プロセスが受信したイベントに加え、前記送
   信回数が前記受信回数よりも大きくないイベントをイベ
   ントキューから削除するようにしたことを特徴とするイ
   ベント送受信方法。
2. 【請求項２】 送信側プロセスから送信されたイベント
   を一次的に格納するイベントキューと、 前記イベントキューに格納されたイベントを受信する受
   信側プロセスと、 イベントの種類ごとにイベント名と送信回数と受信回数
   を関連づけて管理する受信イベント管理テーブルと、 前記イベントキューにイベントが格納される都度、その
   格納されたイベントに対応するイベント名に関連付けら
   れた送信回数を更新する送信回数更新手段と、 前記イベントキューに格納されたイベントが前記受信側
   プロセスに受信される都度、その受信されたイベントに
   対応するイベント名に関連付けられた受信回数を更新す
   る受信回数更新手段と、 前記イベントの受信と関係なく、前記受信回数を更新す
   る受信回数強制更新手段とを備え、 さらに、前記受信側プロセスは、前記イベントキューに
   格納されたイベントのうち、前記受信イベント管理テー
   ブルのイベントの送信回数の方が受信回数よりも大きい
   イベントのみを受信するようにし、 かつ、前記受信側プロセスが受信したイベントと前記送
   信回数が前記受信回数よりも大きくないイベントをイベ
   ントキューから削除する手段を備えたことを特徴とする
   イベント送受信装置。
3. 【請求項３】 送信側プロセスから受信側プロセスに対
   してイベントを送信するに際し、送信側プロセスは、前
   記イベントをイベントキューに順次格納し、受信側プロ
   セスは、前記イベントキューに格納されたイベントを所
   定の順で読み出すようにしたイベント送受信方法におい
   て、 前記受信側プロセスが受信を許容するイベント名を登録
   するための受信イベント管理テーブルと、前記受信側プ
   ロセスが受信を拒否するイベント名を登録するための非
   受信イベント管理テーブルを設け、 前記受信側プロセスが、前記イベントキューに格納され
   たイベントを受信する際には、少なくとも前記受信イベ
   ント管理テーブルをアクセスし、その受信イベント管理
   テーブルに登録されたイベント名のイベントのみ受信す
   るようにし、 かつ、所定の条件に従い一方の管理テーブルに登録され
   たイベント名を他方の管理テーブルに移し替えられるよ
   うにしたことを特徴とするイベント送受信方法。
4. 【請求項４】 送信側プロセスから送信されたイベント
   を一次的に格納するイベントキューと、 前記イベントキューに格納されたイベントを受信する受
   信側プロセスと、 前記受信側プロセスが受信を許容するイベント名を登録
   するための受信イベント管理テーブルと、 前記受信側プロセスが受信を拒否するイベント名を登録
   するための非受信イベント管理テーブルと、 前記受信イベント管理テーブルまたは前記非受信イベン
   ト管理テーブルに対するイベント名の登録を管理する管
   理手段とを備え、 さらに、前記受信側プロセスは、前記イベントキューに
   格納されたイベントのうち、前記受信イベント管理テー
   ブルのみを受信するようにし、 かつ、前記管理手段は、あるイベント名を登録する場合
   には、両管理テーブルのうちいずれか一方に登録すると
   ともに、一方の管理テーブルに登録されたイベント名を
   他方の管理テーブルに移し替えられるようにしたことを
   特徴とするイベント送受信装置。
5. 【請求項５】 請求項３に記載の各管理テーブルが、イ
   ベント名と送信回数と受信回数を関連づけて管理するも
   のであって、 イベントを送信する際に、前記イベントキューに格納す
   るとともに、そのイベントが登録された前記受信イベン
   ト管理テーブルまたは前記非受信イベント管理テーブル
   に登録された送信回数を更新し、 前記受信側プロセスが、前記イベントキューに格納され
   たイベントを受信する際には、対応するイベント名が前
   記受信イベント管理テーブルに登録されており、かつ、
   そのイベント名に関連付けられた送信回数と受信回数と
   を比較し、前記送信回数の方が大きいイベントのみを受
   信するようにし、 かつ、前記受信イベント管理テーブルに登録された受信
   回数は、イベントを受信する都度更新し、さらに、その
   受信回数の更新を前記イベントの受信と関係なく、強制
   的に変更できるようにし、 前記受信側プロセスが受信したイベント及び、前記送信
   回数が前記受信回数よりも大きくないイベントをイベン
   トキューから削除するようにしたことを特徴とするイベ
   ント送受信方法。
6. 【請求項６】 請求項４に記載の各管理テーブルが、イ
   ベント名と送信回数と受信回数を関連づけて管理するも
   のであって、 前記イベントキューにイベントが格納される都度、その
   格納されたイベントに対応するイベント名に関連付けら
   れた前記送信回数を更新する送信回数更新手段と、 前記イベントキューに格納されたイベントが前記受信側
   プロセスに受信される都度、その受信されたイベントに
   対応するイベント名に関連付けられた受信回数を更新す
   る受信回数更新手段と、 前記イベントの受信と関係なく、前記受信回数を更新す
   る受信回数強制更新手段とを備え、 前記受信側プロセスが、前記イベントキューに格納され
   たイベントのうち、前記受信イベント管理テーブルのイ
   ベントの送信回数の方が受信回数よりも大きいイベント
   のみを受信するようにし、 かつ、前記受信側プロセスが受信したイベントと前記送
   信回数が前記受信回数よりも大きくないイベントをイベ
   ントキューから削除する手段を備えたことを特徴とする
   イベント送受信装置。