JPH10510641A

JPH10510641A - 内部実行スレッド管理方法

Info

Publication number: JPH10510641A
Application number: JP8517543A
Authority: JP
Inventors: ウォルフ，ミカエル
Original assignee: テレフオンアクチーボラゲツトエルエムエリクソン（パブル）
Priority date: 1994-12-09
Filing date: 1995-12-08
Publication date: 1998-10-13
Also published as: EP0796462A1; SE9404294D0; FI972406A0; BR9509892A; AU695271B2; ATE223083T1; DE69527978D1; DE69527978T2; NO972596D0; NO972596L; EP0796462B1; AU4276996A; MX9703999A; FI972406A; CN1169192A; CN1096027C; US5961584A; KR987000610A; WO1996018148A1; KR100421797B1

Abstract

(57)【要約】プロセスにおける内部実行スレッドを管理するためのシステムにおいて、実行スレッドはプロセスの内部イベント・メッセージによって駆動される。これらのメッセージは、イベント発生関数の分配カテゴリに基づいて、イベント受信スレッド（１２０８〜１２１２）に分配され、このような内部メッセージに関心があり、その発生のモニタリングを行わせるイベント受信スレッドに対してのみ行われる。各分配カテゴリには、多数のイベント受信スレッド、あるイベント受信スレッドへの１つのイベント発生関数に対する１つ以上のモニタリングを表わす多数の第１の実体（１２２８〜１２３８）、分配カテゴリのイベント発生関数に対するモニタリングを表わす多数の第２の実体（１２１６〜１２２０）、および分配カテゴリをモニタしたイベント処理スレッド全てを追跡する第３の実体（１２１４）が関連付けられている。

Description

【発明の詳細な説明】内部実行スレッド管理方法発明の技術分野本発明は、一般的に、遠隔通信データ・システム（telecommunication data s ystem）における実行機構に関する。更に特定すれば、本発明は、プロセスにおける内部実行管理に関するものである。オブジェクト指向の遠隔通信アプリケーションを実施する場合、システムの資源（チャネル、トーン・センダ(tone sender)等）および制御ロジックを表わすオブジェクト・モデルにそれを分割し、アプリケーションの制御機能を実行することが実現可能である。また、制御ロジックは、コール制御、ベアラ接続制御(b earer connection control)等のような別個のアクティビティ(activity)に分割すると有利である。アプリケーションに対する実行環境とはプロセスのことである。ここでは、プロセスとは、あるアクティビティ、例えば、通話を想定したラン・タイム環境を意味する。プロセス環境は全体的にあるプロセッサに位置し、メモリ（ヒープ、スタック）および実行機能から成る。プロセス内では、擬似的に同時にスレッドを実行する。また、プロセスは、オブジェクト・モデルも含む。スレッドとは、制御ロジックのための実行資源でのことある。１つのスレッドの実行は、オブジェクト・モデルによって発生されるイベントによって駆動される。いくつかのスレッドを同時に起動し(trigger)、次いでスレッドの優先順序にしたがって分散することも可能である。典型的に、イベントは、外部イベント、例えば、プロセスによる通知メッセージの受信に応答して発生する。スレッドは、ある特定のオブジェクトからの個々のイベント、あるオブジェクトからのいずれかのイベント、あるオブジェクト・クラスからの個々のイベント、またはあるオブジェクト・クラスからのいずれかのイベントをモニタすることができる。スレッドは、それ自体のスレッド環境(thread contex)、即ち、スタックおよびプロセッサ・レジスタを保持するが、他の全スレッドとヒープを共有する。スレッドは、複雑なアクティビティを比較的独立した下位アクティビティ(sub -activity)に分割する際に、強力な支援を提供する。スレッド内のロジックは、それがイベントの継続を必要とする状態になるまで、またはその実行を終了するまで実行を行う。スレッドが待ち状態に入るか、あるいはその実行を終了したとき、他のスレッドに実行の可能性が与えられる。これは、全ての非同期イベントは、制御ロジックがそれを処理する用意ができたときに、制御ロジックに送出されることを意味する。オブジェクト・モデルは、ＩＳＤＮ加入者の端末、接続、加入者などのような、アプリケーションに必要な実オブジェクトの抽象概念として使用される。オブジェクトは、メソッドのコール、例えば、接続オブジェクトによって提供されるメソッド「接続」のコールによって、制御ロジックにサービスを提供する。オブジェクトはデータを封入することによって、それら自体の状態を維持する。また、オブジェクトは、他のプロセッサに対してメッセージの送受信を行うことによって、プロセス外部の世界と通信することも可能である。関連技術の説明米国特許第５，４２１，０１３号では、アプリケーションはエージェント・クラスのインスタンスの集合体であり、各エージェント・クラスはそれ自体のメッセージ指名機能を有する。個々のエージェントに非プリエンプティブに (non-preemptively)時間を割り当てるマスタ指名プロセス(master dispatcher p rocess)を含むアプリケーション・プログラミング・インターフェースによって、マルチスレッドが得られる。米国特許第５，３５５，４８８号では、アプリケーション・プログラム・インターフェースによって一旦接点されたタスクは、当該タスクの完了後に、アイドル・ステータスに保持される。設定されたタスクはプール内に維持される。タスク・マネージャは、アプリケーション動作要求に応答して、まずプールを検索して、タスク要求に対応するアイドル・タスクを探し出す。対応するアイドル・タスクがプール内にあれば、制御はアプリケーション・コードに移り、実行される。米国特許第５，３４５，５８８号は、マルチ・スレッド・デジタル・データ処理環境の実行の各スレッドに、スレッドが１つ以上ある環境において実行されるプロシージャが必要とする初期化データの各集合の個別コピーを供給する方法を開示する。米国特許第５，３１９，７８２号は、第１マルチタスク・オペレーティング・システムからのタスクの指名を、第２マルチタスク・オペレーティング・システムから適宜指名される機能コールのスレッドと同期化させることを開示する。第２オペレーティング・システムは、１組のコール可能な資源を含む。タスクは、第２オペレーティング・システムからのコール可能な資源に対するスレッドの所有権が存続する間、このスレッドに拘束される。米国特許第５，３０５，４５５号では、データ処理システムが、複数のスレッドを含む少なくとも１つのプロセスを含む、マルチタスク・モードで動作可能である。プロセス毎ではなく、スレッド毎に例外管理を行う。米国特許第５，２４７，６７５号では、プログラム・スレッドに対するパラメータを指定することによって、マルチタスク・オペレーティング・システムは、当該アプリケーション・プログラムを構成するプログラム・スレッドの実行スケジュールに対して、アプリケーション・プログラムに影響を与えさせるようにしている。パラメータは、各スレッドの優先度レベルを示し、そのスレッドが常駐するクラスを指名する。概要例えば、電話交換を制御するソフトウエアのような、大きなリアル・タイム・ソフトウエア・システムを設計する場合、交換が処理しなくてはならないリアル・タイム・イベントの基本となるアプリケーション固有の複雑性は、多くの場合、プログラムを書きにくく、理解しにくく、そして維持しにくくする傾向がある。本発明の目的の１つは、アプリケーションのリアル・タイム挙動の処理を一層容易にすることによって、ソフトウエアの複雑性を低減し、書きやすく、理解し易く、しかも維持し易いものとするように、かかるソフトウエアを構築するフレームワークおよび機構を提供することである。本発明によるプロセスにおいて内部実行スレッドを管理するためのシステムでは、実行スレッドは、発生した内部または外部インシデント(incident)に応答して、イベント発生関数によって発生される、プロセス内部イベント・メッセージによって駆動される。内部イベント・メッセージは、優先度を有するイベント受信スレッドに分配される。この分配は、イベント発生関数の分配カテゴリに基づいて、イベント処理関数によって制御され、かかる内部メッセージに関心があり、その発生のモニタリングを行わせる、イベント受信スレッドに対してのみ実行される。各分配カテゴリに対してアクター(actor)があり、それらの内次のものをあげることができる。即ち、イベント受信スレッドの数、あるイベント受信スレッドに対する１つのイベント発生関数のために１つ以上のモニタリングを表わす第２の実体であって、各々、イベント受信スレッドをモニタした第１の実体全てのリストを有する前記第２の実体の数、第２の実体のリストによって、分配カテゴリをモニタリングしたイベント受信スレッド全てを追跡する１つの第３の実体、各々第２の実体のリストを保持するイベント発生関数の数である。上述の構造には多数の重要な実施例があり、請求項２〜５に記載されている。第１の実体は各々、イベント発生関数に対するポインタ、およびイベント受信スレッドの優先度に関する情報を保持する。第２の実体は各々、１つ以上の第１の実体によって指し示され、イベント受信スレッドに対するポインタを保持し、分配されたイベント・メッセージをそれに送出する。第３の実体の第２の実体のリストは、イベント受信スレッドを指し示す。各イベント発生関数は、イベントの送出のために、イベント処理関数へのポインタを保持する。その他の有益な実施例は、請求項６〜２８から明白である。図面の簡単な説明これより、図面を参照しながら、以下に本発明についてより詳細に説明する。第１図は、スレッドの実行を示す図である。第２図は、スレッドの実行についての状態遷移図である。第３図は、遠隔通信の場合における、切断プロセスを示す図である。第４図〜第７図は、イベントの各管理状況を識別するために使用されるグラフィカル・プログラミング言語において用いられるシンボルを示す。第８図は、オブジェクト・メソッド・コールおよびイベントを通じてのスレッド間の間接通信を示す。第９図は、イベントを通じてのスレッド間の直接通信を示す。第１０図は、グラフィカル言語のシンボルを使用した図において、プロセスの実行中における、ローカル・イベント・キュー内のイベントのバッファ処理を示す。第１１図は、第１０図と同じ状況を示す従来の図であるが、プロセスをそれに含まれる要素およびメッセージとともに示す。第１２図は、本発明の基本である、イベント機構の中心的なデータ構造を示す図である。第１３図〜第１８図は、第１２図の図において用いたオブジェクト・クラスのデータ構造を示す。そして、第１９図および第２０図は、２つのビット・アレイを示す。実施例の詳細な説明オブジェクト指向の遠隔通信アプリケーションを実施する場合、システムの資源（チャネル、トーン・センダ等）および制御ロジックを表わすオブジェクト・モデルにそれを分割し、アプリケーションの制御機能を実行することが実現可能である。また、制御ロジックは、コール制御、ベアラ接続制御などのような別個のアクティビティに分割すると利点がある。アプリケーションに対する実行環境とはプロセスのことである。ここでは、プロセスとは、あるアクティビティ、例えば、通話を想定したラン・タイム環境を意味する。プロセス環境は全体的にあるプロセッサに位置し、メモリ（ヒープ、スタック）および実行機能から成る。プロセス内では、擬似的に同時にスレッドを実行する。また、プロセスは、オブジェクト・モデルを含む。スレッドとは、制御ロジックのための実行資源のことである。１つのスレッドの実行は、オブジェクト・モデルによって発生されるイベントによって駆動される。いくつかのスレッドを同時に起動し、次いでスレッドの優先順序にしたがって分散することも可能である。典型的に、イベントは、外部イベント、例えば、プロセスによる通知メッセージの受信に応答して発生する。スレッドは、ある特定のオブジェクトからの個々のイベント、あるオブジェクトからのいずれかのイベント、あるオブジェクト・クラスからの個々のイベント、またはあるオブジェクト・クラスからのいずれかのイベントをモニタすることができる。スレッドは、それ自体のスレッド環境、即ち、スタックおよびプロセッサ・レジスタを保持するが、他の全スレッドとヒープを共有する。スレッドは、複雑なアクティビティを比較的独立した下位アクティビティに分割する際に、強力な支援を提供する。スレッド内のロジックは、それがイベントの継続を必要とする状態になるまで、またはその実行を終了するまで実行を行う。スレッドが待ち状態に入るか、あるいはその実行を終了したとき、他のスレッドに実行の可能性が与えられる。これは、全ての非同期イベントは、制御ロジックがそれを処理する用意ができたときに、制御ロジックに送出されることを意味する。オブジェクト・モデルは、ＩＳＤＮ加入者の端末、接続、加入者などのような、アプリケーションに必要な実オブジェクトの抽象概念として使用される。オブジェクトは、メソッド、例えば、接続オブジェクトによって提供されるメソッド「接続」のコールによって、制御ロジックにサービスを提供する。オブジェクトはデータを封入することによって、それら自体の状態を維持する。また、オブジェクトは、他のプロセッサに対してメッセージの送受信を行うことによって、プロセス外部の世界と通信することもできる。ここでは、一例として、スレッドは、主にグラフィカル・シンタックス(graph ical syntax)を有する特定のグラフィカル・プログラミング言語においてコード化されたプログラムによって用いられるオブジェクト・セマンティクス(object semantics)に対応するように特別に設計されたものであると仮定するが、Ｃ＋＋でコード化したプログラムも、これらのセマンティクスしたがうように書くことができる。これまでに述べたことの一例として、第１図は、各制御ロジックに対して実行資源として作用する２つのスレッド１０４および１０６を有するプロセス１０２を示す。スレッド１０４および１０６の実行は、このプロセスにおけるオブジェクト・ロジックによって発生され各スレッド１０４および１０６に属するローカル・イベント・キュー１１２および１１４によって管理される、イベント１０８および１１０によってそれぞれ駆動される。プロセスは、図示しないアクセス・プロセスからのアクセス・エージェント・オブジェクト(access agent object) １１８によってメッセージ１１６が受信されることによって開始される。アクセス・エージェント・オブジェクト１１８は、結果としてイベント１０８を発生し、これはスレッド１０４に分配されて、オブジェクト１１２へのメソッド・コール１２０を実行し、その結果イベント１１０を発生し、これがスレッド１０６に分配されて、このスレッドの実行が開始される。第２図において、スレッドの実行についての状態遷移図が示されている。開始および終了状態は示されていないが、次の説明から理解されよう。新たなスレッドが作成されたとき、直ちに実行を開始するのではなく、「開始イベント待ち状態」２０２、即ち、それがそれ自体に配置(post)する開始イベントにおいて待機する。矢印２０４によって示される開始イベントの受信時に、状態「実行」２０６によって示されるスレッドの実行が開始される。実行時に、スレッドは待ち状態に入り、なんらかのイベント（群）が生じるのを待つ場合もある。実際には、スレッドが待ち状態に入るか否かは、待っていたイベントが既に発生したか否かによって左右される。既に発生していれば、スレッドは実行を継続するが、矢印２１２によって示される発生したイベントを待ちつつ、矢印２０８によって示されるように状態「バッファされた状態の実行」２１０に入る。その他の場合、即ち、イベントが未だ発生していない場合、２つの待ち状態の一方２１８または２２０に入る。状態２１４「イベント待ち」は、個々のイベントを待つために用いられる。「イベント待ち」および「受信待ちイベント」への遷移矢印は、それぞれ、２１６および２１８において示されている。状態２１６「いずれかのイベント待ち」は、いずれかのイベントを待つために用いられる。「いずれかのイベント待ち」および「受信待ちイベント」への遷移矢印は、それぞれ、２２２および２２４において示されている。２つの待ち状態を有する理由は、発生したイベントの結果としてスレッドが再び開始されようとしている場合、イベントがローカル・イベント・キューと一致したときに、異なる戦略を使用するためである。いずれかのイベントを待っている場合、イベントは常に「一致」し、その他の場合、ローカル・イベント・キュー全体の検索を行わなければならない。一致があった場合、スレッドは再び実行を開始し、「実行」状態２０６に入る。状態２１０、「バッファされた状態の実行」にある場合、スレッドは、あるイベントが発生するのを待つ。イベントが既に発生していた場合（ローカル・イベント・キューにおいて発見される）、実行は直ちに同一状態で継続される。その他の場合、スレッドは待ち状態２１４または２１６の一方にはいる。第２図には終了状態はないが、スレッドの主関数が戻るときに、終了に至る。主関数が戻るためには、スレッドが実行中でなければならないので、終了状態への遷移は、「実行」状態２０６または「バッファされた状態の実行」状態２１２のいずれかから行うことができる。イベントは、全ての対象スレッドがそれを受信し、それを処理する機会を有するまで、削除してはならない。この状態がいつ発生したかを判定する問題は、イベントおよびスレッド・ブロック間の協同によって解決される。通常、関心のある全てのスレッドに分配された後に、イベント自体がそれを削除するが、スレッドは常にイベントの受信直後に処理するとは限らないので、分配直後にイベントが削除されるのを防止するための対策を取らなければならない。このような状況が発生するのは、現在待っている訳ではないイベントをスレッドが受信したときである。イベントを削除できるのは、それを待ち処理した後のみである。基準カウンタを用いて、イベントに対していくつの基準が存在するかについての追跡を行う。カウンタが０と判定されたとき、イベントはそれ自体を削除する。受信されたイベントがスレッドにバッファされるとカウンタは増分され、スレッドがバッファされているイベントを待っていて、新たな待ち状態に達した場合、または消滅(die)した場合に減分される(decremented)。スレッドが消滅すると、全てのバッファされていたイベントの基準カウンタも減分しなければならない。これについての更に詳しい説明は、後に、イベント・ブロックのより詳細な説明に関連付けて行うことにする。オブジェクトの相互作用に関して、スレッド・クラス(Thread class)が２つの実行スレッドの環境、即ち、現スレッド環境および当該スレッド自体のスレッド環境間の切替を管理する。スレッドが待っていたイベントを受信したとき、現スレッド環境はセーブされ、当該スレッド自体のスレッド環境への切替が行われる。スレッドがローカル・イベント・キューにないあるイベントを待つ必要がある場合、他のスレッドに実行の機会が与えられる。スレッド自体のスレッド環境への切替は、スレッドが待っていたイベントが受信されたときにのみ行われる。したがって、スレッドを開始するために、特殊なプロシージャを実行する。まず、スレッド・コンストラクタ(thread constructo r)が特殊な開始イベントのモニタリング(monitoring)を設定する。次に、対応するイベントを作成し配置する。その後、スレッドがこのイベントを受信し、正常に受信したあらゆるイベントと同様にそれを処理し、スレッドが待っているイベントとしてそれを認識することによって、このスレッドの実行を開始する。イベントは、内部または外部インシデントが特定のプロセスで発生した場合直ちに関心のあるスレッド全てに知らせることによって、スレッドの実行を調整するために用いられる。このようなインシデントの例は、通話の切断（外部）、およびタイム・アウト（内部）である。言い換えれば、イベント関数は、あるプロセス内で通信する機構を支援する。イベントはスレッドの実行を開始する。イベントは予め決められた受信先を有していないが、先の特殊イベントにおいてそれらの関心を宣言したスレッドに分配される。イベント関数のために、オブジェクト・ロジックおよび制御ロジックの構築を独立して行うことができる。１つのイベントは、名称、送出元、および発生器からスレッドまで情報を運ぶ関連データから成り、プロセスの範囲内でのみ存在する。イベントは、通常、受信メッセージ、例えば、加入者がフック・オン(hook on )を行ったというメッセージの結果として、プロセス内においてオブジェクトによって発生される。イベントの指定は、グラフィカル言語と設計言語との組み合わせによって行うことができる。制御ロジックは、先に述べたように、グラフィカル言語のフロースクリプト(flowscript)によって指定され、一方オブジェクト・ロジックを構成するオブジェクトは、設計言語におけるOBJECT TYPE OR CLASS（オブジェクト・タイプおよびクラス）指定によって指定することができる。イベント処理は、以下のような多数の特徴的な構造を有する。 −１つのイベントは、それをモニタしていた全スレッドに分配される。１つのプロセスの中で発生された全イベントは、共通の「レター・ボックス」に入ることになる。これは、先に述べた「イベント・ハンドラ」であり、ここから更に、当該イベントにおいてその関心を示したスレッド全てに、これらは送られる。これら特定のイベントに関心を示すものがない場合、廃棄される。これら関心の表示、即ち、イベントのモニタリングの要求(ordering)は、フローの中で明示的に行わなければならない。 −この特定イベントにおいて、その関心をモニタしていたスレッドにイベントが分配されるとき、スレッドは未だそれを処理する準備ができていない場合もある。これは、実行がこのイベントのための待ち状態に未だ達していない場合、または他のスレッドがそのとき実行中である場合にあり得ることである。すると、イベントは、そのスレッドに属するキューに入れられる（第１図のローカル・イベント・キュー１１２および１１４を参照）。スレッドがイベントを処理する準備ができた場合、ローカル・イベント・キューからスレッドを取り込む。次に、どのように進めるかを決定するために新たなイベントが必要となるまで、実行は継続される。このイベントは、他の外部イベント、またはタイム・アウトのような内部イベントの場合もある（第１図のイベント１０８および１１０を参照）。 −同報通信／アクティブ受信。イベント発生器の視点からは、イベントは特定した受信者に送出することはできない。発生されたイベントは全て、送出元のスレッドも含み、当該イベントをモニタしていたスレッド全てに分配される。この概念は、イベントを発生する実体(entity)は、イベントに関心がある実体を知らないことを暗示する。受信先は、いつ待つのか、何を待つのか（「アクティブ受信」）を決定する。 −実行は疑似並列的に行われる。スレッドは、疑似並列的即ち１度に１つづつ実行する。スレッド内の各実行は、スレッドが待っていたイベントの受信時に開始され、その後スレッドは、再び待つことをそれ自体で解決するか、あるいはその実行を終了するまで、混乱することなく実行していく。この段階では、他のスレッドが、当該イベントまたは他のものによって起動され、実行する可能性がある。ここに記載したことは、例えば、第１図のスレッド１０４および１０６に当てはまる場合がある。イベントは、それらを配置した順序で、スレッドに分配される。しかしながら、単一のイベントが１つ以上のスレッドに分配される場合があるので、スレッドは、このような場合の分配順序を示す優先度を有する。また、スレッドは受信したイベントの再分配を防止し、優先度の低いスレッドがそのイベントを受信するのを防止することもある。スレッドがイベントを受信可能となるためには、スレッドは、それが配置される前に、当該イベントを明示的にモニタしていなければならない。モニタリングによって、スレッドは、あるオブジェクト（またはオブジェクト群）からのあるイベント（またはイベント群）に対するその関心を宣言する。イベントが配置される前にモニタリングが行われた場合、モニタリングはイベント（またはイベント群）を当該スレッドに分配させる。また、スレッドは既に行ったモニタリングを除去することもでき、これによって、当該イベント（またはイベント群）がスレッドに再分配されるのを防止する。第３図は、プロセス３０２内で実行される切断(Disconnection)を示す。切断は、図示しないアクセス・プロセスからの切断メッセージ３０４によって開始される。アクセス・エージェント３０６のオブジェクト・ロジックは、その結果、イベント３０８によって、ある切断制御ロジックを実行しているスレッド３１０を起動する。このロジックは、矢印３１２によって示されるように、タイマ・オブジェクトのインスタンス３１４を作成することを要求することによって、タイミング機能(timing function)を開始する。次に、スレッド３１０の制御ロジックの実行は、タイムアウトまたは外部世界からの他のメッセージのいずれかであり得る、新たなイベントを待つ停止に到達する。この例では、タイムアウト・メッセージがインスタンス３１４によって受信され、スレッド３１０にタイムアウト・イベントを送り、再び、スレッド３１０の関数ロジックの実行を開始し、その結果、切断メッセージ３１８および３２０はそれぞれCallオブジェクト３２２およびリモート・ダイアログ・オブジェクト３２４となる。イベント処理機構は、以下のサービスを提供する。 −イベントの配置(posting)。イベント発生として定義されたオブジェクトは、発生したイベントを送ることができる。典型的な場合が見られるのは、例えば、加入者からのフック・オンまたは時間管理(time-supervision)の解放のような、内部または外部インシデント（incident）の結果として、イベントが作成されたときである。 −イベントのモニタリング。イベント受信スレッドは、受信を望むあるイベントに対する関心を告示(announce)することができる。あるスレッドによって発生される１つの特定のイベントまたは可能な全てのイベントに対する関心は、特定の予約指令において記述される。当該イベントが発生され送出されたとき／場合、そのイベントに予約した受信スレッドに到達する。 −イベントのモニタリングの取り消し。もはやあるイベントに関心がなくなったスレッドは、それに対するモニタリングを取り消すことができる。 −イベント再分配の防止。スレッドは、受信後にイベントが再分配されるのを防止することができる。イベントを「殺す」ことによって、当該イベントを未だ受信していないスレッドは、それを行うことができなくなる。これらのサービスの各々について、以下でより詳細に説明する。イベントの配置（post）とは、発生したイベントを中心的オブジェクト、即ち、イベント・ハンドラに送り、ここから、関心のあるスレッドにそれを分配することを意味する。先に述べたように、イベントは外部または内部インシデントの結果として発生される。外部インシデントは、典型的に、メッセージとしてプロセスに報告され、一方メッセージは、そのプロセス内で、イベント発生器によってイベントに変形される。後にイベントが分配されるとき、これらが配置されたのと同じ順序で行われる。イベントを配置するためのグラフィカル・プログラミング言語のシンタックスは、例えば、第４図に示す種類のイベントを配置するシンボルを含む。イベントをモニタしていた全ての待機中のスレッドがそれを受信する。図示のように、シンボルは送出されるイベントの名称を含む。シンボル入力パラメータ・データも、更に以下に続く説明から明らかとなるように、イベントと共に配置することができる。シンボルは、結果値のない出口を有し、実行すべき次のノードを直接指し示す。セマンティクスの観点から、実行されるスレッドは、例えば、イベント「Even tName 」を発生する。このイベントは、それに含まれるデータと共に、それを待っているスレッド全てに配置される。先に述べたように、イベントは特定したスレッドに配置することはできない。特定のイベントに関心がある全てのスレッドは、これらのイベントのモニタリングを命令する、即ち、あるイベントに対するイベント受信先の関心を告示することによって、それらの関心を指定しなければならない。モニタリングは、イベントを唯一に識別するデータを含むモニタ・オブジェクトを作成することによって行う。言い換えれば、モニタ・オブジェクトが、イベント受信先に変わって、イベントに対する関心を告示する。グラフィカル・プログラミング言語におけるシンタックスは、例えば、直立する黒いフラグを有する菱面体である第５図に示すシンボルによって、イベントのモニタリング開始を指定することができる。このシンボルの中には、常に、少なくとも１つの送出元と１つのイベントが指定されている。第４図および第５図にそれぞれ示し先に述べた２つのシンボルの各々は、実行すべき次のノードを指し示す出力矢印１つのみを有し、この矢印には結果値は付かない。モニタリングを望むイベント数、およびイベントが発生した異なる送出元の数に応じて、「イベントのモニタリング開始」を指定するには、４つの異なる可能性がある。これらの可能性を次にあげる。 −ある送出元からの１つのイベントのモニタリング。 −ある送出元からのあらゆるイベントのモニタリング。 −あるクラスの送出元からの１つのイベントのモニタリング。 −あるクラスの送出元からのあらゆるイベントのモニタリング。セマンティクスの観点からは、モニタリング開始のためのシンボルをフローの中で実行するとき、指定されたイベントの全インスタンスは、それらが発生したときにはいつでも、このフローに分配されることを注記すべきであろう。これらのイベントは、次に、フローによって指名されるまで、スレッドのローカル・イベント・キューに並べられる。あるクラスの送出元からのイベントをモニタするとは、当該クラスのいずれかのインスタンスがそのイベントを配置する場合、それが受信先に送出されることを意味する。既に見たように、処理を進めるためにオブジェクトまたはその他のスレッドから情報が必要なスレッドは、それ自体を待ち状態に置くことができる。すると、このスレッドの実行は中断され、他のいずれかのスレッドが実行を開始する。所望の情報がイベントの形態で受信されたときに実行は再開されるが、現在アクティブとなっているスレッドが実行を停止するまでは、再開されない。第６図は、グラフィカル・プログラミング言語によって表現されたフローにおける待ち状態を示す。待ち状態自体は楕円６０２でシンボル化され、ここからの矢印６０４，６０６，６１０および６１０が、シンボル６１２．１，６１２．２，．．．６１２．ｎを指し示す。シンボルは異なる送出元を示し、各シンボルの下にある更に別の矢印は、スレッド（フロー）が待っている各送出元からイベントを示す。第６図に見られるように、これらのイベントは、それぞれ、各送出元６１２．１，６１２．２および６１２．ｎに対して、ｅｖ１，ｅｖ２，ｅｖ３；ｅｖ４，ｅｖ５およびｅｖ８，ｅｖ９として示されている。送出元の名称がシンボル内に含まれている。アステリスクを含むシンボルも用いることができるが、これについては以下で詳しく説明する。待ち状態は名称を有することができる。また、それに関連する条件のリストも有することができる。フローの実行が待ち状態に達したとき、条件リストがあれば、これを最初に検査する。条件が満たされていない場合、エラーとなる。条件が満たされたか、あるいは条件リストが全くない場合、待ち状態に達したために実行は停止する。所与のイベントの１つが、当該イベントが連繋する送出元から受信されたとき、実行は再開される。次に、実行は、発生したイベントによって命名される矢印に従う。送出元の名称として、以下のものを適用可能である。 −オブジェクトのインスタンスを指し示す変数。イベントは、実行を再開するためには、所与のオブジェクトのインスタンスから来なければならない。 −スレッドの識別子。イベントは、実行を再開するためには、所与のスレッドのインスタンスから来なければならない。 −アステリスク（＊）。これは、どのオブジェクトまたはスレッドが発生したかには関係なく、上述のイベントのいずれかが対象となることを意味する。既に行われたモニタリングは、イベント受信先がもはや当該イベントに関心がなくなった場合は、除去してもよい。モニタリングの除去は、イベント受信先が以前に当該イベントに対する関心を告示したときに作成したモニタ・オブジェクトを削除することによって行われる。プログラミング言語では、モニタリング停止イベント(stop monitoring event )は、例えば、第７図に示すシンボルによって指定することができる。図示のように、このシンボルは、下向きのフラグを有する点で、第５図のものとは異なる。少なくとも１つの送出元および１つのイベントがシンボルと共に指定される。シンボルは、実行すべき次のノードを指し示す出立矢印を１つのみ有し、この矢印には結果値は付けられない。シンボル停止モニタリング(symbol stop monitor ing）がフローにおいて実行されると、指定したイベントのインスタンスはもはやフローによって受信されることはない。イベント発生オブジェクトが削除されたときに自動的に発生される、予め定義されている単一のイベント、即ち、イベントDEATH がある。イベントDEATH は、他のあらゆるイベントのようにモニタリングや受信が可能であるが、これはデータを全く運ばない。キーワードDEATH は、このイベントに言及するときにはいつでも使用しなければならない。スレッド間の通信にはいくつかの可能性が存在する。１つは、オブジェクト・メソッド・コールを通じての通信である。オブジェクトは、それらがあるメソッドを実行するときに、イベントを発生することができる。次に、イベントは、関心のあるスレッド全てに送出される。これは、第８図に例を用いて示されている。スレッド８０２は、矢印８０４即ちオブジェクト８０６へのメソッド・コールを送出する。一方、オブジェクト８０６は、他のスレッド８１０にイベント８０８を送出する。このように、２つのスレッド間の通信が可能である。これらの機構を適切な方法で組み合わせることによって、「互いに対話する」２つのスレッドを得ることができる。フロー自体、即ち、スレッドもイベントを発生することができる。これが暗示するのは、２つ（以上）のスレッドは、互いにイベントを送出し合い、そして互いからイベントを受信し合うことによって、直接互いに対話可能であるということである。これは、第９図に例を用いて示されており、スレッド９０２がイベント９０４を他のスレッド９０６に送出する。簡略化された図は、イベントがスレッド間で直接送出されていることを示唆しているように見えるが、そうではないことに注意されたい。イベントは、図示しない、イベント・ハンドラによって分配される。次に、プロセスにおける発生のフロー・チャートを示す第１０図、およびそのプロセスおよびその要素のいくつかを図示しプロセスを１１０２で示す第１１図について言及する。モニタされたイベントは、スレッドによって、ローカル・イベント・キューにバッファすることができる。バッファリング(buffering)とは、イベントがモニタされた後、その全ての発生の観察はできるが、モニタリングの前に発生したイベントは入手できないことを意味する。あるイベントがもはや望ましくなくなった場合、モニタリングを除去しなければならない。既に受信されているイベントは、それらが「待たれている」間、ローカル・イベント・キューに残り、この場合、スレッドはその実行を継続することが許される。スレッドが「待っている」ときにイベントが未だ発生していない場合、このスレッドの実行は、イベントが発生するまでアイドルとなる。第１０図において、１００２は、イベントｅ１のモニタリングである第１１図のプロセス１１０２の第１ステップとして、開始を示す。このソースはイベント発生器ＥＧ１である。ソースがイベント発生器ＥＧ２である、イベントｅ２のモニタリングの開始が、１００４で示されている。第１１図は、イベント発生器ＥＧ１およびＥＧ２が、それぞれ、１１０４および１１０６でプロセス１１０２に含まれるものとして示している。また、プロセス１１０２は、ローカル・イベント・キュー１１１０を有するスレッド１１０８も含む。第１０図において、１００６は、実行を中断している間イベントｅ２の発生を待っている待ち状態を示す。１００８において、イベント発生器ＥＧ１からのイベントｅ１がここで発生したことが示され、第１１図では、矢印１１１２によって、イベントｅ１がローカル・イベント・キュー１１１０にバッファされたことが示されている。第１０図の１０１０において、イベント発生器ＥＧ２からのイベントｅ２がここで発生したことが示され、１０１２において、その実行開始が示されている。第１０図のシンボル１０１４は、イベントｅ１を待つために、実行を中断することを示す。このイベントは既に発生しており、その実行開始が１０１６によって示されている。次に、イベント・ドリブン・プログラム・スレッドのスケジューリング方法について、第１２図を参照しながら、より詳細に説明する。この説明では、オブジェクト・クラスについて述べる。これは特定のクラス構造に含まれている。これらのクラスについて、その名称を以下にあげながら、順次より詳細に説明していく。第１２図において、ブロック１２０１〜１２０６は、ベース・クラスEventGen eratorの各オブジェクト・イベント発生器を示す。そのオブジェクトは、再分配のために、イベント処理機構の中心的なサービス・クラスEventHandlerのイベント・ハンドラ・オブジェクトにイベントを配置することができる。ブロック１２０８〜１２１２は、継承によってイベント・オブジェクトの受信を可能にする、抽象的ベース・クラスEventReceiver の各オブジェクト・イベント受信先（スレッド）を示す。 Event と命名されたクラスは、プロセス・イベントを表わす。Event オブジェクトは、タグおよびソース即ちイベント発生器によって唯一に定義される。各イベント発生器は、クラスDistCat の分配カテゴリのメンバであり、これによって、１群のイベント発生器のモニタリングを可能としている。第１３図を参照すると、EventGeneratorは実施のために以下のオブジェクトを用いている。 −イベントの配置を進めるため、および発生器の作成および破棄を告示するためのEventHandler。 −ある分配カテゴリにおけるメンバシップのためのDistCat 。 −発生器からのイベントに対する全てのモニタリングを追跡するためのMontIt em。例えば、EventGeneratorはイベントを配置するためにEvent を用いる。 EventHandlerは中心的なクラスであり、全てのモニタリング、イベント発生器およびイベント受信先を追跡する構造が維持される。第１４図を参照すると、EventHandlerは実施のために以下のオブジェクト・クラスを用いている。 −個々のイベント発生器に対する全てのモニタリングを追跡するためのMonIte m。 −どのイベント発生器がどの分配カテゴリに属するのかを追跡するためのDist CatNode 。ノードは二進ツリーに保持される。 −分配時までイベントをセーブし、次いでそれらを受信先に送出するEvent 。 −分配カテゴリに対する全てのモニタリングを追跡するためのErItem。 −どのイベント受信先が無効とされたかを追跡するDeadErList。 −内部オブジェクトの割り当てのためのMemory。例えば、EventHandlerは次のオブジェクト・クラスを用いる。 −分配カテゴリに対するモニタリングを登録するためのDistCat 。 −モニタリングを登録するためのEventReceiver 。 −個々のイベント発生器に対するモニタリングを登録するためのEventGenerat or。 EventReceiver は抽象的なベース・クラスであり、継承により、イベントを受信する可能性を、その派生クラスに追加する。スレッドはEventReceiver から得られる。第１５図を参照すると、EventReceiver は、実施のために、受信先の構築および廃棄の指示を送るクラスEventHandlerを用いる。例えば、EventReceiver は、受信先から得られるクラスに送出される、クラス Event を用いる。第１２図に戻ると、ブロック１２１４は、二進ツリーDistCatTree におけるノードである、オブジェクトDistCatNode（分配カテゴリ・ノード）を示す。 DistCatTree は、クラスErItem（イベント受信項目(Event Receiver Item)）のオブジェクトのリストを含む。このクラスは分配カテゴリのモニタリングを追跡するために用いられる。各オブジェクトErItemは、イベント受信先へのポインタを保持し、分配されたイベントをそれに送出する。ブロック１２１６〜１２２０は、イベント受信先１２０８〜１２１２の各１つを指し示す各ポインタ１２２２〜１２２６を有する各ErItemオブジェクトを示す。 DistCatNode は、１つの分配カテゴリの全イベント受信先を追跡する。第１６図を参照すると、DistCatNode は、BinTreeNode を継承することによって、イベント・ハンドラによる高速検索のための二進ツリーのメンバとしての特性を有する。実施のために、DistCatNode は、分配カテゴリを記憶するためにDistCat を、同一分配カテゴリの全イベント受信先のリンクを保持するためにEiItemを用いる（モニタリングを行うあらゆるイベント受信先は、内部構造では、ErItemで表される）。先の用語「リング」は、以下でも再度見られるが、上述のイベント受信先のような、リンクされた実体のリストを特徴付けるために用いられ、リストの最後の実体は、リストの最初の実体を再び指し示す。リングに言及する理由は、第１２図に一例として示した実施例は、このタイプのリストに基づいて構築するという事実のためのである。当該リストは、しかしながら、リンクされたリストの形状とする必要はない。第１７図を参照すると、クラスErItemは、内部構造においてモニタされるイベント受信先の表現である。これは、イベントがイベント受信先によって受信される、分配カテゴリに対するモニタリングを追跡する。また、これは、イベントがイベント受信先によって受信される、個々のイベント発生器（MonItem によって表わされる）に対するモニタリング全てのリングを保持する。 ErItemはRingLinkを継承するので、同一分配カテゴリのErItemは全て、共にリンクすることができる。実施のために、ErItemは以下のクラスを用いる。 −ReceiveEventおよびhandleDeadlock関数コールを送出するためのEvenReceiv er。 −対象の受信先について、個々のイベント発生器に対するモニタリング全てのリングを保持するMonItem 。 −ErItemを無効としたときに、ErItemのDistCatNodesリングからErItemを離脱させるDistCatNode 。 −占有されているメモリをErItemが正しく戻すためのMemory。 −発生したタグがモニタリングと一致したとき、およびモニタリングをアップデートおよび「ダウンデート(downdating)」するときのEventTag。インターフェースのために、ErItemはEvent を用い、イベントを分配するときに、対応するイベント受信先にこれを送出する。第１２図に戻ると、各ErItemオブジェクトは、クラスMonTem（モニタリング項目）のオブジェクトのリストも保持する。このクラスは、個々のイベント発生器のモニタリングを追跡するために用いられる。ブロック１２２８〜１２３８は、各MonItem オブジェクトを示す。第１８図を参照すると、MonItem は個々のイベント発生器のモニタリングの内部表現である。 MonItem は、次のものを継承する。 −ErItemがそのイベント受信先に対する個々のモニタリング全てを保持するリングのメンバとなることができるためのErMonLink 。 −MonItem のイベント発生リング、即ち、イベント発生器に対して行った個々のモニタリング全てのリングのメンバとなることができるためのEgMonLink 。実施のために、MonItem は次のクラスを用いる。 −イベント受信先へのポインタを保持するEritm に対するポインタを保持するためのErItem。 −発生したイベント・タグとモニタリングが一致したとき、およびモニタリングをアップデートおよび「ダウンデート」したときのEventTag。 −ErItemが、占有されているメモリを正しく戻すためのMemory。第１２図に戻ると、DistCatTree を通じて、全てのErItemに到達することが可能である。オブジェクト１２１４のように、ツリーに含まれる各DistCatNode オブジェクトは、オブジェクト１２０２〜１２０６のような個々のイベント発生器または分配カテゴリのいずれかのモニタリングを表わすために作成された、オブジェクト１２１６〜１２２０のようなErItem全てのリングを含む。第１２図では、リングは、ErItemオブジェクト１２１６〜１２２０を共に接続する矢印１２４０，１２４２および１２４４によって示されている。１つのDistCatNode のリンクにおけるErItemは全て、同一分配カテゴリのイベント発生器に対するモニタリングの結果である。通常、ErItemはリングにリンクされ、各リングはあるDistCatNode に属する。リングは受信先の優先度にしたがって順序付けられる。ErItemが作成されるのは、以前にモニタされたことがないイベント受信先に対するモニタリングが作成されたときである。次いで、ErItemを、モニタリングのイベント発生器の分配カテゴリに対応するDistCatNdeに属するErItemのリンクにリンクする。 ErItemはそれ自体に、receiveEventおよびHandlDeadlock 関数コールを送出するための対応するイベント受信先（イベント受信先１２０８〜１２１２を参照のこと）に対するポインタ（ポインタ１２１２〜１２２６を参照のこと）を有する。更に、各ErItemは、ErItemのDistCatNode のリングからの急速な離脱のために、DistCatNode （ノード１２１４を参照のこと）へのポインタを有する。第１２図において、このようなポインタは、ErItem１２１６〜１２２０の各々から発する共通矢印１２４６によって示されている。各ErItemはMonItem のリングであるメンバも有する。ErItem１２１６に対して、このようなリングはMonItem １２２８〜１２３２を含み、矢印１２４８〜１２５２によって表されている。ErItem１２１８に対して、リングはMonItem １２３４および１２３６を含み、矢印１２５４および１２５６によって表されている。ErItem１２２０の「リング」は単一の MonItem １２３８を含み、矢印１２５８によって示されている。 MonItem １２２８〜１２３８の各々は、個々のイベント発生器のモニタリングを表わす。したがって、MonItem １２２８，１２３４および１２３８は、 MonItem １２２８，１２３４，１２３８の各々から発する矢印１２６０によって示されるイベント発生器１２０２のモニタリングを表わす。同様に、MonItem １２３０および１２３６は、MonItem １２３０および１２３６の各々から発する矢印１２６２によって示されるイベント発生器１２０４のモニタリングを表わし、 MonItem １２３２は、矢印１２６４によって示されるイベント発生器１２０６のモニタリングを表わす。各場合において、モニタリング・イベント受信先は、Er Itemによって指し示される１箇所である。したがって、MonItem １２２８，１２３０および１２３２に対して、ErItem１２１６はイベント受信先１２０８を指し示し、MonItem １２３４および１２３６に対して、ErItem１２１８はイベント受信先１２１０を指し示し、MonItem １２３８に対して、ErItem１２２０はイベント受信先１２１２を指し示す。ErItemはMonItem（整列されていない）のそれらの各リングを保持し、イベント受信先が消滅したときに全てのモニタリングが適正に除去されることを確実とする。また、ErItemは、分配カテゴリのモニタリングも全て追跡する。これをどのように行うかについては、後に説明する。 ErItemは、高速メモリ（クラスMemoryによって処理される）から割り当てられたオブジェクトであるので、これらは、これらが割り当てられた元であり、これらが無効とされたときに戻るべきメモリに対するポインタも保持する。イベント発生器１２０２〜１１２０６のような各イベント発生器はMonItem のリングを保持し、リング内の各リンクは、イベント発生器をイベントのソースとして、モニタリングに対応する。したがって、イベント発生器１２０２に対して、MonItem １２２８，１２３４および１２３８は、矢印１２６６，１２６８および１２７０によって示されるリング内に含まれる。イベント発生器１２０４に対して、MonItem １２３０および１２３６は、矢印１２７２および１２７４によって示されるリング内に含まれる。イベント発生器１２０６に対して、MonItem １２３２は、矢印１２７６によって示される「リング」内に含まれる。また、各イベント発生器は、イベントの配置を進めるために、イベント・ハンドラへのポインタも保持する。更に、イベント発生器が属する分配カテゴリを示すDistCat タイプのメンバを有する。既に述べたように、MonItem は、あるイベント受信先に対する、１つのイベント発生器の１つ以上のモニタリングを表わす。また、前述からも明白となっているように、MonItem は２つのリングのメンバであり、一方のリング（受信先の優先度によって順序付けられている）はイベント発生器に属し、他方のリング（順序付けられていない）はモニタリング・イベント受信先(monitorings event rec eiver)に対応するErItemに属する。したがって、一例として、MonItem １２２８は、イベント受信先１２０８に対応するErItem１２１６に属するリング１２４８，１２５０，１２５２のメンバであるだけでなく、イベント発生器１２０２に属するリング１２６６，１２６８，１２７０のメンバでもある。各MonItem は、MonItem のErItemリングから急速に離脱するため、および分配リストを構築する場合にイベント受信先を探し出すために、そのErItemへのポインタを保持する。したがって、MonItem １２２８，１２３０および１２３２は、共通矢印１２７８によって示される、ErItem１２１６へのポインタを保持する。 MonItem１２３４および１２３６は、共通矢印１２８０によって示される、 ErItem１２１８へのポインタを保持し、MonItem １２３８は、矢印１２８２によって示される、ErItem１２２０へのポインタを保持する。また、各MonItem は、発生器のMonItem のリングから急速に離脱するために、それぞれ矢印１２６０，１２６２および１２６４によって示される、イベント発生器１２０２，１２０４および１２０６それぞれへのポインタを含む。分配リストを急速に構築するために、これらは、モニタするイベント受信先の優先度も含む。 MonItem は高速メモリ（クラスMemoryによって処理される）から割り当てられるオブジェクトであるので、これらの割り当て元であり、これらが無効とされた時にメモリを返すメモリへのポインタも保持する。 MonItem は、１つの発生器から１つの受信先へのイベントに対して行われる１つ以上のモニタリングを表わす。MonItem オブジェクトがいくつのモニタリングを表わすのかを追跡するために、基準カウンタを含んでいる。イベント・ハンドラは、イベント処理機構における中心的なオブジェクトであり、全てのモニタリングを追跡する構造を維持する。DistCatTree はイベント・ハンドラのメンバであり、モニタリングが作成されるときに、イベント・ハンドラがあるイベント発生器または分配カテゴリに対応するErItemを見つけ出すために用いられる。ErItemが見つからない場合、イベント・ハンドラは１つ作成し、それをDistCatTree に挿入する。イベント・ハンドラは、配置されたが分配されていない全イベントのリングを保持する。即ち、イベントはイベント受信先に分配されるのを待っている。イベント受信先が消滅したとき、イベントを受信できない。したがって、この受信先のために作成されたMonItem はそれ以上用いることはできない。しかしながら、 MonItem を指し示すMonitor オブジェクトが未だ存在し得るので、これらを削除することはできない。基準カウントがゼロのMonItem が離脱され削除されたときに、各ジョブの終了時にスキャンされる「消滅」MonItem のリストに、MonItem は移される。受信先が消滅した場合、ErItemにとって、状況は殆ど同じである。ユーザはEr Itemを参照するMonitor オブジェクトを有している可能性があるので、ErItemを直ちに無効とすることはできない。また、ErItemを参照する分配リストも存在する可能性がある。分配リストに伴う問題に対処するため、受信先が消滅したときに受信先へのErItemポインタを０に設定する。すると、ErItemはもはや受信先にイベントを全く送出しなくなる。各ジョブの終了時に、ゼロに等しい受信先ポインタを有する全ErItemを「消滅」ErItemのリストに移動させる。基準カウントがゼロのErItemが離脱され削除されたとき、このリストは各ジョブの終了時にスキャンされる。イベント・オブジェクトは、発生したイベントのソフトウエアによる表現であり、イベント受信先に送出される。イベントは、当該イベントが配置された元のイベント発生器へのポインタ、およびDistItemを含む分配リストを保持する。分配リストは、イベントが配置されたときに構築され、各DistItemはErItemへのポインタを含む。分配リストは、ErItemイベント受信先の優先度にしたがって順序付けられる。各イベントは、イベント・タグも含む。分配リストは、各イベントが配置されるとき、それに対して構築される。分配リストはイベント・ハンドラによって構築され、イベント・ハンドラは内部構造をスキャンしてイベントのイベント・タグと一致するMonItem およびErItemを探す。分配リストは、DistItemの単独にリンクされたリストであり、各DistItemは ErItemへのポインタを含み、一方ErItemは分配時に当該イベントをそのイベント受信先に転送する。分配リストを構築するためには、イベントを配置したイベント発生器の分配カテゴリに対応するErItemのリングを見つけなければならない。このリングは、Di stCatTree 内にノードによって保持されている。リングが見つからない場合、当該イベントに対するモニタリングがないことになり、したがって破棄（削除）することができる。更に、イベント発生器に対して行われたモニタリングを表わすMonItem のリングが必要とされる。このリングは、イベント発生器によって保持される。次に、これら２つのリングは、それぞれ、コールされたer-ring およびmon-ri ngの下でスキャンされ、両リングはイベント受信先の優先度にしたがって順序付けられたものであることを考慮しつつ、メンバは配置されたイベントのタグと照合される。スキャニングは、mon-ringをスキャンして一致するMonItem を求めることによって開始する。見つかった場合、現ErItemがMonItem によって指し示されるまで、er-ring を進める。これを行いつつ、全ての一致したErItemを分配リストに集める。MonItem によって指し示されているErItemは、次に分配リスト上に配され、er-ring を１ステップ進めて、イベントが受信先に２回分配されるのを避ける。上述のプロセスは、両リングを完全にスキャンするまで繰り返される。こうして分配リストが完成し、イベントに与えられる。配置された各イベントは、分配を待つリング上に配される。各イベントがそれ自体の分配リストを有するので分配自体は非常に単純なため、分配は以下のステップに短縮される。イベント・リング上の各イベントに対して、イベントを除去し、その分配リスト上の全受信先に分配する。各イベントの送出の間に、eventK illed フラグをチェックし、最後の受信先がKillEvent によって分配を停止したか否かを調べなければならない。この場合、分配は次のイベントを用いて続けられる。上述のように、ErItemは分配カテゴリに対するモニタリングを追跡し、MonIte m は個々のイベント発生器に対するモニタリングを追跡する。これは、ビットのアレイを保持することによって行われ、各ビットは１つのイベント・タグに対応する。ビットは、モニタリングが作成されるときにセットされ、無効とされるときにクリアされる。イベント・タグは、パートおよびインデックスと呼ばれる、２つの構成要素から成り、パートはビットアレイの部分（第１９図における０，１，２，３を参照）を示し、インデックスは対応するパート内のどのビットがセットされたのかを示す。例えば、イベント・タグ（０，９），（０，２５７）および（２，６５）は、第１９図のビットアレイと一致する。イベント・タグのインデックス構成要素の最下位ビットは常にセットされていることに注意されたい。これは、全イベントのモニタリングは常に一致しなければならないからである。例えば、第１９図のビットアレイに、全イベントに対するモニタリングを追加する場合、全パートにおける最後のビットをセットする（第２０図参照）。したがって、イベントに対してイベント・タグを構成し、シーケンス（０，５），（０，９），．．．（０，２³¹＋１），（１，３），（１，５），．．．（１，２³¹＋１），（２，３），（２，５），．．．（２，２³¹＋１），（３，３），（３，５），．．．（３，２³¹＋１）からそれらを選択する。しかしながら、イベント・タグは、１つの整数をアーギュメントとして取り、０−＞（０，５），１−＞（０，９），２−＞（０，１７），等のマッピングを行うコンストラクタ(constructor)を用いても構築可能である。また、パート０における１ｓｂの直ぐ右のビットは、予め定義されている「消滅」イベント・タグ、即ち、タグ（０，３）のために保存されている。関心のあるあらゆる受信先が、イベントを処理する前に当該イベントを削除してしまうのを避けるために、これに対処する機構が導入されている。これは、イベント機構とThreadとの間の協働である。この機構は、イベント・ハンドラおよびThreadによって増分および減分されるカウンタを有するイベントを基本とする。カウンタが０まで減分されると、それ自体を削除する。配置されたイベントのイベント・ハンドラのリングから、次に分配する１つであるイベントを取り込むときにブロック増分を行う場合。減分は、関心がある全受信先にイベントが分配された直後に行われる。イベント・カウンタを増分するスレッドがない場合、イベントはそれ自体を削除する。イベント受信先が無効とされた場合、それらを指し示すDistItemが存在し得るので、対応するErItemを無効とすることはできない。また、ErItemを指し示すMo nitor オブジェクトも存在する可能性がある。イベント発生器が無効とされた場合、それらを指し示すMonitor オブジェクトが存在し得るので、そのMonItem のリストを一掃することは不可能である。これら２つの場合に対処するために、消滅を宣言されたオブジェクトの２つのリスト、DeadErListおよびDeadMonItemList があり、これらによって、当該オブジェクトはもはや使用しないが、他のいずれかのオブジェクトによって参照されている可能性があるため、削除できないことを示す。DeadErListは、イベント受信先を失ったErItemへのポインタを含み、LeadMonItemList は、イベント発生器を失い、未だいずれかのMonitor オブジェクト（群）によって参照されているMo nItem 全てを含むリングである。各ジョブの終了時に浄化(cleanup)を行い、これは以下のステップから成る。まず、DeadErList上の各ErItemに対するMonItem のリングにおいて、基準カウントがゼロの各MonItem を削除し、その他については、DeadMonItemList に載せる。次に、ゼロに等しい基準カウントを有する全MonItem を離脱させ削除しつつ、 DeadMonItemList を最後まで進める。最後に、基準カウントがゼロに等しい全ErItemを離脱させ削除しつつ、DeadEr Listを最後まで進める。

Claims

【特許請求の範囲】１．プロセスにおいて内部実行スレッドを管理するためのシステムであって、前記実行スレッドは、発生した内部または外部インシデントに応答して、イベント発生関数（１２０２〜１２０６）によって発生される、プロセス内部イベント・メッセージによって駆動され、前記内部イベント・メッセージは、優先度を有するイベント受信スレッド（１２０８〜１２１２）に分配され、前記分配は、前記イベント発生関数の分配カテゴリに基づいてイベント処理関数によって制御され、かつ前記分配はかかる内部メッセージに関心があり、その発生のモニタリングを行わせるイベント受信スレッドに対してのみ行われ、各分配カテゴリに対して、多数のイベント受信スレッドと、あるイベント受信スレッドへの１つのイベント発生関数に対する１つ以上のモニタリングを表わす多数の第１の実体（１２２８〜１２３８）と、分配カテゴリのイベント発生関数に対するモニタリングを表わす多数の第２の実体（１２１６〜１２２０）であって、各々イベント受信スレッドをモニタした第１の実体全てのリストを有する前記第２の実体と、前記第２の実体（１２１６〜１２３８）のリストによって、分配カテゴリをモニタしたイベント受信スレッド全てを追跡する１つの第３の実体（１２１４）と、前記第１の実体（１２２８〜１２３８）のリストを各々保持する、多数のイベント発生関数とが存在する、システム。２．各第１の実体は、前記イベント発生関数へのポインタと、前記イベント受信スレッドの優先度に関する情報を保持する請求項１記載のシステム。３．各第２の実体は、１つ以上の前記第１の実体（１２２８〜１２３８）によって指し示され、イベント受信スレッドへのポインタを保持し分配されたイベント・メッセージをそれに送出する請求項１または２記載のシステム。４．前記第３の実体の前記第２の実体（１２１６〜１２２０）のリストは、前記イベント受信スレッドを指し示す請求項１〜３のいずれかに記載のシステム。５．各イベント発生関数は、イベントの送出のために、イベント処理関数へのポインタを保持する請求項１〜４のいずれかに記載のシステム。６．前記イベント受信スレッドは各優先度指示と関連付けられており、プロセスの実行中、前記第３の実体の前記第２の実体のリストは、現在のイベント受信スレッドの優先度にしたがって、順序付けられる請求項１〜５記載のシステム。７．第２の実体（１２１６〜１２２０）は、モニタリングが以前に行われていないイベント受信スレッドに対するモニタリングを作成するときに作成され、前記第２の実体（１２１６〜１２２０）は、前記第３の実体（１２１４）に属する前記第２の実体（１２１６〜１２２０）のリストに導入される請求項１〜５または６記載のシステム。８．各第２の実体は、前記第３の実体（１２１４）の第２の実体（１２１６〜１２２０）のリストからの急速な除去を可能にするために、前記第３の実体（１２１４）へのポインタを有する請求項１〜５または６または７記載のシステム。９．第２の実体（１２１６〜１２２０）への前記第１の実体（１２２８〜１２３８）のポインタは、前記第１の実体（１２２８〜１２３８）の前記第２の実体（１２１６〜１２２０）のリストからの急速な除去を可能にするため、および分配リストを構築するためのイベント受信スレッドを見つけ出すために保持され、前記第１の実体のイベント発生関数へのポインタは、第１の実体（１２２８〜１２３８）の前記イベント発生関数のリストからの急速な除去を可能にするためにある請求項１〜５または請求項６〜８のいずれか記載のシステム。１０．前記第１の実体（１２２８〜１２３８）は、高速メモリから割り当てられたオブジェクトであり、それらが割り当てられた元であり、それらが除去されるときにそれらがメモリを戻す前記メモリへのポインタを保持する請求項１〜５または請求項６〜９のいずれか記載のシステム。１１．前記第３の実体（１２１４）は、モニタリングが作成されるときに、前記イベント処理関数によって、イベント発生関数または分配カテゴリに対応する前記第２の実体（１２１６〜１２２０）を見つけるために用いられる請求項１〜５または請求項６〜１０のいずれか記載のシステム。１２．前記イベント処理関数は、配置されたが分配されていない全イベント、即ち、前記イベント受信スレッドに分配されるのを待っているもののリストを保持する請求項１〜５または請求項６〜１１のいずれか記載のシステム。１３．各第１の実体（１２２８〜１２３８）は、それが表わすモニタリングを登録するための基準カウンタを含む請求項１〜５または請求項６〜１２のいずれか記載のシステム。１４．基準カウントがゼロの第１の実体（１２２８〜１２３８）を除去し削除するとき、前記処理におけるジョブの終了時にスキャンされる使用不可の第１の実体のリストに、第１の実体を移動させる請求項１３記載のシステム。１５．前記イベント受信スレッドが使用不可となり、前記第２の実体（１２１６〜１２２０）がもはやいずれのイベントもそれに送出しない場合、前記第２の実体（１２１６〜１２２０）のイベント受信スレッドへのポインタを０に設定する請求項１〜５または請求項６〜１４のいずれか記載のシステム。１６．各第２の実体は、それが表わすモニタリングを登録するための基準カウンタを含む請求項１５記載のシステム。１７．前記処理におけるジョブの終了時に、イベント受信スレッドへのポインタがゼロに設定されている第２の実体（１２１６〜１２２０）全てを、使用不可の第２の実体（１２１６〜１２２０）のリストに移動し、基準カウントがゼロの第２の実体（１２１６〜１２２０）をリストから除去し削除するときに、各ジョブの終了時に、前記リストをスキャンする請求項１５および１６記載のシステム。１８．前記第２の実体（１２１６〜１２２０）は、高速メモリから割り当てられたオブジェクトであり、それらが割り当てられた元であり、それらが無効とされるときにそれらがメモリを戻す前記メモリへのポインタを保持する請求項１〜５または請求項６〜１７のいずれか記載のシステム。１９．イベント受信スレッドに送出される発生イベントのソフトウエア表現(E vent)は各々、前記イベントが配置された元である前記イベント発生関数へのポインタ、および１つのイベントの１つのイベント受信スレッドへの分配を表わす分配項目(DistItem)を含む分配リストを保持する請求項１〜５または請求項６〜１８のいずれか記載のシステム。２０．前記分配リストは、前記イベントが配置されるときに構築され、各分配項目は、第２の実体（１２１６〜１２２０）へのポインタを含み、前記分配リストは、前記第２の実体（１２１６〜１２２０）のイベント受信スレッドの優先度にしたがって順序付けられている請求項１９記載のシステム。２１．各イベント表現は、どのイベント発生関数がそれを配置するかには無関係に、１つのイベントのタイプを表わすイベント・タグを含む請求項１９または２０記載のシステム。２２．前記分配リストは、前記プロセスの内部構造をスキャンし、前記イベントのイベント・タグと一致する第１の実体（１２２８〜１２３８）および第２の実体（１２１６〜１２２０）を見つけ出すための前記プロセスの内部構造をスキャンすることによって、前記イベント処理関数によって構築される請求項２１記載のシステム。２３．分配カテゴリに対するモニタリングを追跡する前記第２の実体（１２１６〜１２２０）および、個々のイベント発生関数に対するモニタリングの追跡を行う前記第１の実体（１２２８〜１２３８）は、ビットのアレイによって実行され、各ビットは１つのイベント・タグに対応し、前記ビットは、モニタリングが作成されるときにセットされ、それらが終了するときにクリアされ、各イベント・タグは、前記ビットアレイのパートを示す１つと、前記対応するパートにおけるどのビットがセットされているかを示すインデックスである１つとの２つの構成要素から成る請求項２１または２２記載のシステム。２４．各関心のあるイベント受信スレッドがイベントを処理する前に当該イベントを削除するのを回避するために、前記イベント処理関数およびスレッドによって、各イベントに対応するカウンタを増分および減分するステップを含み、前記カウンタは、それが０に減分されたときにそれ自体を削除し、前記イベント処理関数の配置したイベントのリストから、分配すべき次の１つであるイベントを取り込んだときに、増分を実行し、関心のあるイベント受信スレッド全てに前記イベントが分配された直後に減分を実行する、請求項１〜５または請求項６〜２３のいずれか記載のシステムにおける方法。２５．各ジョブの後に第１および第２の実体を削除するために、前記使用不可の第２の実体のリスト（deadErList）上の各第２の実体（１２１６〜１２２０）に対して、その第１の実体（１２２８〜１２３８）のリストを識別し、基準カウントがゼロの各第１の実体を削除し、その他の場合、前記使用不可の第１の実体のリストに配するステップと、前記使用不可の第１の実体のリスト上において、基準カウントがゼロに等しい全実体を識別し、それらを除去し削除するステップと、前記使用不可の第２の実体のリスト上において、基準カウントがゼロに等しい全実体を識別し、それらを除去し削除するステップと、を含む、請求項１７〜２４のいずれか記載のシステムにおける方法。２６．分配リストを構築するために、前記イベントを配置する前記イベント発生関数の分配カテゴリに対応する第２の実体（１２１６〜１２２０）のリストを識別するステップと、前記イベント発生関数に対して行われるモニタリングを表わす前記第１の実体（１２２８〜１２３８）のリストを識別するステップと、このように識別された前記２つのリストをスキャンしながら、それらのメンバを、前記配置されたイベントのタグと照合するステップと、を含む請求項１９〜２３のいずれか記載のシステムにおける方法。２７．前記スキャンは、一致する第１の実体（１２２８〜１２３８）のために前記第１の実体のリストをスキャンするステップと、見つかった場合、前記見つかった第１の実体（１２２８〜１２３８）によって指し示されている現在の第２の実体（１２１６〜１２２０）を見つけるために、前記第２の実体のリストをスキャンしつつ、一致する第２の実体全てを前記分配リストに集め、一致する各実体に対して、前記第２の実体のリストをポインタを１ステップ歩進させ、前記イベントが２度前記イベント受信スレッドに分配されるのを避けるステップと、両リストが完全にスキャンされるまで繰り返すステップと、こうして完成した前記分配リストを、前記イベントに与えるステップと、から成る請求項２６記載の方法。２８．分配は、各配置されたイベントを分配待ちリストに配するステップと、前記リスト上の各イベントを除去し、前記イベントの分配リスト上にあるイベント受信スレッド全てにそれを分配するステップと、各イベント送出の間に、最後のイベント受信スレッドが分配を停止したか否かをチェックするステップと、を含む請求項２６または２７記載の方法。