JPH11238046A - コンピュータシステム - Google Patents
コンピュータシステムInfo
- Publication number
- JPH11238046A JPH11238046A JP10327125A JP32712598A JPH11238046A JP H11238046 A JPH11238046 A JP H11238046A JP 10327125 A JP10327125 A JP 10327125A JP 32712598 A JP32712598 A JP 32712598A JP H11238046 A JPH11238046 A JP H11238046A
- Authority
- JP
- Japan
- Prior art keywords
- processing
- request
- server
- computer system
- rpc
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
- H04L49/9063—Intermediate storage in different physical parts of a node or terminal
- H04L49/9068—Intermediate storage in different physical parts of a node or terminal in the network interface card
- H04L49/9073—Early interruption upon arrival of a fraction of a packet
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/62—Establishing a time schedule for servicing the requests
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Multi Processors (AREA)
Abstract
(57)【要約】
【課題】 処理要求のマルチスレッド処理を実行し、ま
た、処理されずにデータベースに残されている要求を回
復する。 【解決手段】 サーバ２０は、クライアント３０から出
されたリモートプロシージャコール（ＲＰＣ）要求を並
列的に処理する方法及び装置であり、リモートプロシー
ジャコール要求が来ると、それをキュー２１に登録し、
不揮発性メモリに格納する機能を含む。処理要求を受け
付けた旨の応答は、クライアント３０に対し直ちに返さ
れる。ＲＰＣ要求はキュー２１から取り出され、並列的
に処理される。完了した処理の通知は、通知クライアン
トに送られる。サーバ障害またはシステム障害が発生し
た場合、システムが復元した時に不揮発性メモリから処
理要求が取り出され、サーバ２０が受け取った順序でキ
ュー２１に入れられる。
た、処理されずにデータベースに残されている要求を回
復する。 【解決手段】 サーバ２０は、クライアント３０から出
されたリモートプロシージャコール（ＲＰＣ）要求を並
列的に処理する方法及び装置であり、リモートプロシー
ジャコール要求が来ると、それをキュー２１に登録し、
不揮発性メモリに格納する機能を含む。処理要求を受け
付けた旨の応答は、クライアント３０に対し直ちに返さ
れる。ＲＰＣ要求はキュー２１から取り出され、並列的
に処理される。完了した処理の通知は、通知クライアン
トに送られる。サーバ障害またはシステム障害が発生し
た場合、システムが復元した時に不揮発性メモリから処
理要求が取り出され、サーバ２０が受け取った順序でキ
ュー２１に入れられる。
Description
【０００１】
【発明の属する技術分野】この発明は、クライアントか
らの要求をキューに登録し、その要求に対する応答をク
ライアントに返すための装置及び方法に関する。また、
この発明は処理されずにデータベースに残されている要
求の確実な回復（リカバリ）を保証する。
らの要求をキューに登録し、その要求に対する応答をク
ライアントに返すための装置及び方法に関する。また、
この発明は処理されずにデータベースに残されている要
求の確実な回復（リカバリ）を保証する。
【０００２】
【従来の技術】コンピュータシステムでプロセスによる
処理を実現する時、メモリ構造が頻繁に使用される。各
種アプリケーションで頻繁に使用される２種類のメモリ
構造は、先入れ先出し法（ＦＩＦＯ）による構造、つま
りキュー（待ち行列）、と後入れ先出し法（ＬＩＦＯ）
による構造、つまりスタックである。これらのメモリ構
造では、データは順次に記憶される。キューではデータ
は記憶された順序で取り出されるのに対し、スタックで
はデータは記憶された順序と逆の順序で取り出される。
オペレーティングシステム、アプリケーションプログラ
ム、及び他のプログラムでは、多くの場合、キューを利
用する。オペレーティングシステムが１つの要求を実行
している間、後続の要求はキューに格納され、到着順に
処理される。このようなバッファ処理は、コンピュータ
の通信ポートでデータを受信する場合など、他のアプリ
ケーションにも共通したキューメモリ構造の使用法であ
る。例えば、通信ポートにおける入力データの受信速度
がデータの処理速度より高速の場合は、キューを利用す
ることで、これら２つのデータ速度の同期を取ることが
できる。これは、入力データ速度に合わせて入力データ
をキューに入れ、プロセッサの処理速度に合わせてデー
タをキューから取り出すことで行われる。
処理を実現する時、メモリ構造が頻繁に使用される。各
種アプリケーションで頻繁に使用される２種類のメモリ
構造は、先入れ先出し法（ＦＩＦＯ）による構造、つま
りキュー（待ち行列）、と後入れ先出し法（ＬＩＦＯ）
による構造、つまりスタックである。これらのメモリ構
造では、データは順次に記憶される。キューではデータ
は記憶された順序で取り出されるのに対し、スタックで
はデータは記憶された順序と逆の順序で取り出される。
オペレーティングシステム、アプリケーションプログラ
ム、及び他のプログラムでは、多くの場合、キューを利
用する。オペレーティングシステムが１つの要求を実行
している間、後続の要求はキューに格納され、到着順に
処理される。このようなバッファ処理は、コンピュータ
の通信ポートでデータを受信する場合など、他のアプリ
ケーションにも共通したキューメモリ構造の使用法であ
る。例えば、通信ポートにおける入力データの受信速度
がデータの処理速度より高速の場合は、キューを利用す
ることで、これら２つのデータ速度の同期を取ることが
できる。これは、入力データ速度に合わせて入力データ
をキューに入れ、プロセッサの処理速度に合わせてデー
タをキューから取り出すことで行われる。
【０００３】１つのサーバと複数のクライアントを使用
する分散処理システムでは、いくつかのクライアントか
らの処理要求が同時に、または殆ど同時に、サーバに到
着することがある。例えば、２つの処理要求がほぼ同時
にサーバに到着した場合は、片方の処理要求は、他方の
処理を完了するまでその処理が遅延される。したがっ
て、遅延された処理要求に対する応答も、クライアント
に遅れて戻される。
する分散処理システムでは、いくつかのクライアントか
らの処理要求が同時に、または殆ど同時に、サーバに到
着することがある。例えば、２つの処理要求がほぼ同時
にサーバに到着した場合は、片方の処理要求は、他方の
処理を完了するまでその処理が遅延される。したがっ
て、遅延された処理要求に対する応答も、クライアント
に遅れて戻される。
【０００４】
【発明が解決しようとする課題】このように、従来のシ
ステムでは、サーバにおいてある処理要求の処理が遅延
すると、それに対応する応答もクライアントに対して遅
れて返されていた。このため、処理要求を発したクライ
アントは、場合によっては応答が返ってくるまで長時間
待たされる可能性があった。
ステムでは、サーバにおいてある処理要求の処理が遅延
すると、それに対応する応答もクライアントに対して遅
れて返されていた。このため、処理要求を発したクライ
アントは、場合によっては応答が返ってくるまで長時間
待たされる可能性があった。
【０００５】本発明はこのような問題を解決するために
なされたものであり、処理要求を発したクライアントを
長時間待たせることがないシステム及び方法を提供する
ことを目的とする。また、本発明は、サーバに障害が発
生した場合に、処理待ちキューに登録されていた未処理
の処理要求を復旧するためのシステム及び方法を提供す
る。
なされたものであり、処理要求を発したクライアントを
長時間待たせることがないシステム及び方法を提供する
ことを目的とする。また、本発明は、サーバに障害が発
生した場合に、処理待ちキューに登録されていた未処理
の処理要求を復旧するためのシステム及び方法を提供す
る。
【０００６】
【課題を解決するための手段】この発明は、同時に到来
する処理要求のマルチスレッド処理を実行するための装
置及び方法を提供する。また、この発明は処理されずに
データベースに残されている要求の回復（リカバリ）の
ための方法及び装置も提供する。
する処理要求のマルチスレッド処理を実行するための装
置及び方法を提供する。また、この発明は処理されずに
データベースに残されている要求の回復（リカバリ）の
ための方法及び装置も提供する。
【０００７】本発明では、マルチスレッド処理を実現す
るために、リモート・プロシージャ・コール（ＲＰＣ）
サーバを用いる。ＲＰＣサーバにおいては、処理待ちの
処理要求を登録するキューがメモリ上に構築されるとと
もに、システム障害に備えてそれら処理要求を保存する
データベースがディスク等の不揮発性記憶装置上に構築
される。ＲＰＣサーバはＲＰＣ要求を受け取ると、その
要求をキューに入れ、データベースに保存する。次に、
ＲＰＣサーバは新しい要求が到着したことをバックグラ
ウンドスレッドに通知し、直ちに応答を返す。バックグ
ラウンドスレッドは、キューからＲＰＣ要求を取り出
し、スレッドを生成してそのＲＰＣ要求を処理する。処
理中にＲＰＣサーバに障害が発生してＲＰＣ要求を完了
できない場合は、ＲＰＣサーバはデータベースからＲＰ
Ｃ要求を取り出して処理する。
るために、リモート・プロシージャ・コール（ＲＰＣ）
サーバを用いる。ＲＰＣサーバにおいては、処理待ちの
処理要求を登録するキューがメモリ上に構築されるとと
もに、システム障害に備えてそれら処理要求を保存する
データベースがディスク等の不揮発性記憶装置上に構築
される。ＲＰＣサーバはＲＰＣ要求を受け取ると、その
要求をキューに入れ、データベースに保存する。次に、
ＲＰＣサーバは新しい要求が到着したことをバックグラ
ウンドスレッドに通知し、直ちに応答を返す。バックグ
ラウンドスレッドは、キューからＲＰＣ要求を取り出
し、スレッドを生成してそのＲＰＣ要求を処理する。処
理中にＲＰＣサーバに障害が発生してＲＰＣ要求を完了
できない場合は、ＲＰＣサーバはデータベースからＲＰ
Ｃ要求を取り出して処理する。
【０００８】
【発明の実施の形態】以下図面を参照して、本発明の好
適な実施の形態を詳細に説明する。
適な実施の形態を詳細に説明する。
【０００９】図１は、従来の分散処理システム１を示
し、このシステムはＲＰＣ（リモート・プロシージャ・
コール）サーバ２、ＲＰＣクライアント３、及び通知ク
ライアント５とを含む。ＲＰＣクライアント３はＲＰＣ
サーバ２へ要求を送り、サーバ２から応答を受け取る。
ＲＰＣサーバ２は、ＲＰＣクライアント３からの要求の
処理を管理する。通知クライアント５は、ＲＰＣサーバ
２によるＲＰＣ要求実行中に何等かのイベントが発生し
た場合、通知を受け取ることができる。
し、このシステムはＲＰＣ（リモート・プロシージャ・
コール）サーバ２、ＲＰＣクライアント３、及び通知ク
ライアント５とを含む。ＲＰＣクライアント３はＲＰＣ
サーバ２へ要求を送り、サーバ２から応答を受け取る。
ＲＰＣサーバ２は、ＲＰＣクライアント３からの要求の
処理を管理する。通知クライアント５は、ＲＰＣサーバ
２によるＲＰＣ要求実行中に何等かのイベントが発生し
た場合、通知を受け取ることができる。
【００１０】サーバ２における要求処理は、先入れ先出
し（ＦＩＦＯ）法で行われる。つまり、ＲＰＣクライア
ント３からのＲＰＣ要求は、受け取られた順に処理され
る。さらに、ＲＰＣサーバ２からＲＰＣクライアント３
への応答は、処理の完了後に戻される。使用頻度が高い
システムでは、複数のクライアント３からのＲＰＣ要求
が同時または殆ど同時に、ＲＰＣサーバ２へ到着するこ
とがある。しかし、ＲＰＣサーバ２はシングルスレッド
プロセッサであるため、複数のクライアント３からのす
べてのＲＰＣ要求は逐次的に処理される。
し（ＦＩＦＯ）法で行われる。つまり、ＲＰＣクライア
ント３からのＲＰＣ要求は、受け取られた順に処理され
る。さらに、ＲＰＣサーバ２からＲＰＣクライアント３
への応答は、処理の完了後に戻される。使用頻度が高い
システムでは、複数のクライアント３からのＲＰＣ要求
が同時または殆ど同時に、ＲＰＣサーバ２へ到着するこ
とがある。しかし、ＲＰＣサーバ２はシングルスレッド
プロセッサであるため、複数のクライアント３からのす
べてのＲＰＣ要求は逐次的に処理される。
【００１１】図２は、図１に示されているシステム１を
使用するリモート・プロシージャ・コール（ＲＰＣ）シ
ングルスレッド処理を示したタイミング図である。図２
では、２つのＲＰＣクライアント３が、同時にまたは殆
ど同時に、ＲＰＣサーバ２へＲＰＣ要求ＰＲ１とＰＲ２
をそれぞれ送信している（Ｔ１）。この例では、ＲＰＣ
サーバ２は最初のＲＰＣ要求ＰＲ１を処理し、その間、
２番目の要求ＰＲ２はキューに入れられる（Ｔ１）。最
初のＲＰＣ要求ＰＲ１の処理が完了すると（Ｔ２）、Ｒ
ＰＣサーバ２は、その要求に対応するＲＰＣクライアン
ト３へ最初の応答Ｒ１を送り、２番目のＲＰＣ要求ＲＰ
２の処理を開始する。２番目のＲＰＣ要求ＰＲ２を完了
すると（Ｔ３）、ＲＰＣサーバ２は、対応するＰＲＣク
ライアント３へ２番目の応答Ｒ２を送る。ここで、もし
最初のＲＰＣ要求ＰＲ１を完了するためにかなりの時間
が必要な場合は、２番目のＲＰＣ要求ＰＲ２が普通なら
短時間で完了するような場合でさえも、２番目のＲＰＣ
クライアント３は２番目の応答Ｒ２を受け取るまでかな
りの時間待たされることになる。例えば、最初のＲＰＣ
要求ＰＲ１の処理時間が３０秒で、２番目のＲＰＣ要求
ＰＲ２の処理時間が１秒の場合でも、２番目のＲＰＣク
ライアント３は３１秒後に２番目の応答Ｒ２を受け取る
ことになる。３つ以上のＲＰＣ要求がサーバ２に同時ま
たは殆ど同時に到着する時は、応答の遅れはさらに深刻
になる可能性がある。
使用するリモート・プロシージャ・コール（ＲＰＣ）シ
ングルスレッド処理を示したタイミング図である。図２
では、２つのＲＰＣクライアント３が、同時にまたは殆
ど同時に、ＲＰＣサーバ２へＲＰＣ要求ＰＲ１とＰＲ２
をそれぞれ送信している（Ｔ１）。この例では、ＲＰＣ
サーバ２は最初のＲＰＣ要求ＰＲ１を処理し、その間、
２番目の要求ＰＲ２はキューに入れられる（Ｔ１）。最
初のＲＰＣ要求ＰＲ１の処理が完了すると（Ｔ２）、Ｒ
ＰＣサーバ２は、その要求に対応するＲＰＣクライアン
ト３へ最初の応答Ｒ１を送り、２番目のＲＰＣ要求ＲＰ
２の処理を開始する。２番目のＲＰＣ要求ＰＲ２を完了
すると（Ｔ３）、ＲＰＣサーバ２は、対応するＰＲＣク
ライアント３へ２番目の応答Ｒ２を送る。ここで、もし
最初のＲＰＣ要求ＰＲ１を完了するためにかなりの時間
が必要な場合は、２番目のＲＰＣ要求ＰＲ２が普通なら
短時間で完了するような場合でさえも、２番目のＲＰＣ
クライアント３は２番目の応答Ｒ２を受け取るまでかな
りの時間待たされることになる。例えば、最初のＲＰＣ
要求ＰＲ１の処理時間が３０秒で、２番目のＲＰＣ要求
ＰＲ２の処理時間が１秒の場合でも、２番目のＲＰＣク
ライアント３は３１秒後に２番目の応答Ｒ２を受け取る
ことになる。３つ以上のＲＰＣ要求がサーバ２に同時ま
たは殆ど同時に到着する時は、応答の遅れはさらに深刻
になる可能性がある。
【００１２】図３は、この問題を解決するマルチスレッ
ドＲＰＣシステム１０のブロック図である。このマルチ
スレッドＲＰＣシステム１０は、１つのＲＰＣサーバ２
０とそのサーバに接続される１つまたは複数のＲＰＣク
ライアント３０とを含む。この例では１つだが、ＲＰＣ
システム１０に複数のＲＰＣサーバ２０が含まれていて
ももちろんよい。ＲＰＣサーバ２０には、キュー２１と
データベース２２とが含まれている。データベース２２
は、システム障害時にも記憶内容が消えないよう、不揮
発性の記憶装置上に構築されている。例えば、不揮発性
記憶装置としては、例えばハードディスク装置などの外
部記憶装置などを用いることができる。また、ＲＰＣサ
ーバ２０には、少なくとも４種類のモジュール、つまり
スレッドが含まれている。それらは、作成（スポーン：
spawn）スレッド２３、処理スレッド２４n、応答スレッ
ド２５、及び回復スレッド２６である。作成スレッド２
３は、キュー２１からＲＰＣ要求を取り出し、処理スレ
ッド２４1から２４iを作成する（ここでｉは、キュー２
１で待ち状態のＲＰＣ要求の数に等しい）。応答スレッ
ド２５と作成スレッド２３は、ＲＰＣサーバ２０のシャ
ットダウン等の特定のイベントが発生しない限り、連続
して実行される。処理スレッド２４nは、ＲＰＣ要求を
処理する。しかし、並列的な処理スレッド２４nの数
は、ＲＰＣ要求の処理時に拘束される処理資源の量を制
限するために、制限されることがある。処理スレッドカ
ウンタ（単にカウンタと呼ぶこともある）２７は、作成
スレッド２３が処理スレッド２４iを作成するたびに１
ずつ増加する。作成スレッド２３が新しい処理スレッド
２４iを作成しようとした時に処理スレッドカウンタ２
７が所定値に達すると、条件変数２８にシグナルが送ら
れるまで、作成スレッド２３は待ち状態になる。処理ス
レッド２４iがクローズされる度に、処理スレッドカウ
ンタ２７は１だけ減少し、条件変数２８にシグナルが送
られる。
ドＲＰＣシステム１０のブロック図である。このマルチ
スレッドＲＰＣシステム１０は、１つのＲＰＣサーバ２
０とそのサーバに接続される１つまたは複数のＲＰＣク
ライアント３０とを含む。この例では１つだが、ＲＰＣ
システム１０に複数のＲＰＣサーバ２０が含まれていて
ももちろんよい。ＲＰＣサーバ２０には、キュー２１と
データベース２２とが含まれている。データベース２２
は、システム障害時にも記憶内容が消えないよう、不揮
発性の記憶装置上に構築されている。例えば、不揮発性
記憶装置としては、例えばハードディスク装置などの外
部記憶装置などを用いることができる。また、ＲＰＣサ
ーバ２０には、少なくとも４種類のモジュール、つまり
スレッドが含まれている。それらは、作成（スポーン：
spawn）スレッド２３、処理スレッド２４n、応答スレッ
ド２５、及び回復スレッド２６である。作成スレッド２
３は、キュー２１からＲＰＣ要求を取り出し、処理スレ
ッド２４1から２４iを作成する（ここでｉは、キュー２
１で待ち状態のＲＰＣ要求の数に等しい）。応答スレッ
ド２５と作成スレッド２３は、ＲＰＣサーバ２０のシャ
ットダウン等の特定のイベントが発生しない限り、連続
して実行される。処理スレッド２４nは、ＲＰＣ要求を
処理する。しかし、並列的な処理スレッド２４nの数
は、ＲＰＣ要求の処理時に拘束される処理資源の量を制
限するために、制限されることがある。処理スレッドカ
ウンタ（単にカウンタと呼ぶこともある）２７は、作成
スレッド２３が処理スレッド２４iを作成するたびに１
ずつ増加する。作成スレッド２３が新しい処理スレッド
２４iを作成しようとした時に処理スレッドカウンタ２
７が所定値に達すると、条件変数２８にシグナルが送ら
れるまで、作成スレッド２３は待ち状態になる。処理ス
レッド２４iがクローズされる度に、処理スレッドカウ
ンタ２７は１だけ減少し、条件変数２８にシグナルが送
られる。
【００１３】ＲＰＣ要求は、要求ライン３１を介してＲ
ＰＣクライアント３０から送られ、ＲＰＣサーバ２０に
より受け取られる。各ＲＰＣ要求に関する応答は、対応
する応答ライン３２を介してＲＰＣクライアントへ戻さ
れる。
ＰＣクライアント３０から送られ、ＲＰＣサーバ２０に
より受け取られる。各ＲＰＣ要求に関する応答は、対応
する応答ライン３２を介してＲＰＣクライアントへ戻さ
れる。
【００１４】ＲＰＣクライアント３０から送られてきた
ＲＰＣ要求がＲＰＣサーバ２０で受け取られると、それ
らの要求は受け取られた順に応答スレッド２５によりキ
ュー２１に入れられる。また、応答スレッド２５は、Ｒ
ＰＣ要求をデータベース２２へ保存（セーブ）する。次
に、応答スレッド２５は、キュー２１に追加された新し
いＲＰＣ要求について、作成スレッド２３に直ちに通知
する。
ＲＰＣ要求がＲＰＣサーバ２０で受け取られると、それ
らの要求は受け取られた順に応答スレッド２５によりキ
ュー２１に入れられる。また、応答スレッド２５は、Ｒ
ＰＣ要求をデータベース２２へ保存（セーブ）する。次
に、応答スレッド２５は、キュー２１に追加された新し
いＲＰＣ要求について、作成スレッド２３に直ちに通知
する。
【００１５】応答スレッド２５は、ＲＰＣ要求をキュー
２１へ登録すると、応答ライン３２を介して、ＲＰＣク
ライアント３０へ応答を返す。ＲＰＣクライアント３０
に応答を戻した後、応答スレッド２５は条件変数２９に
シグナルを送る。条件変数２９はこのシグナルを受け取
るとアイドル（休止）状態の作成スレッド２３を再起動
し、キュー２１内のＲＰＣ要求の処理を開始する。
２１へ登録すると、応答ライン３２を介して、ＲＰＣク
ライアント３０へ応答を返す。ＲＰＣクライアント３０
に応答を戻した後、応答スレッド２５は条件変数２９に
シグナルを送る。条件変数２９はこのシグナルを受け取
るとアイドル（休止）状態の作成スレッド２３を再起動
し、キュー２１内のＲＰＣ要求の処理を開始する。
【００１６】このように、ＲＰＣサーバ２０がＲＰＣ要
求を受け取ると、ＲＰＣクライアント３０は直ちにその
旨の通知を受ける。さらに、ＲＰＣクライアント３０は
応答を受け取ると、ＲＰＣサーバ２０が実際にＲＰＣ要
求を完了したものと想定し、ＲＰＣ要求がまだキュー内
にある場合でも、操作は完了したものとみなして自分自
身の処理操作を継続する。
求を受け取ると、ＲＰＣクライアント３０は直ちにその
旨の通知を受ける。さらに、ＲＰＣクライアント３０は
応答を受け取ると、ＲＰＣサーバ２０が実際にＲＰＣ要
求を完了したものと想定し、ＲＰＣ要求がまだキュー内
にある場合でも、操作は完了したものとみなして自分自
身の処理操作を継続する。
【００１７】処理スレッドカウンタ２７が所定値を超え
てなく、しかも、新たな処理スレッド２４nを作成する
だけの十分な処理資源が残されている限り、作成スレッ
ド２３はキュー２１からＲＰＣ要求を取り出し、そのＲ
ＰＣ要求を処理するために処理スレッド２４nを直ちに
作成する。
てなく、しかも、新たな処理スレッド２４nを作成する
だけの十分な処理資源が残されている限り、作成スレッ
ド２３はキュー２１からＲＰＣ要求を取り出し、そのＲ
ＰＣ要求を処理するために処理スレッド２４nを直ちに
作成する。
【００１８】データベース２２は、応答送信済みのＲＰ
Ｃクライアント３０のＲＰＣ要求の処理を妨げたり中断
させたりするような障害がＲＰＣサーバ２０に起きたと
きに、使用される。このデータベースは、ＲＰＣサーバ
２０がＲＰＣ要求を受け取った旨が応答ライン３２を介
してＲＰＣクライアント３０に直ちに通知されるため
に、必要となる。ＲＰＣサーバ２０に何等かの障害が発
生した場合にデータベース２２が備わっていないと、Ｒ
ＰＣ要求は処理されない可能性があるにもかかわらず、
ＲＰＣクライアントにはＲＰＣ要求が実行された旨の応
答が返されることになる。したがって、データベース２
２を備えておけば、ＲＰＣサーバ２０が正常に操作を再
開した時点で、受信されキューに入れられているＲＰＣ
要求の内まだ処理されていない要求をデータベース２２
から取り出し、これらのＲＰＣ要求を処理することがで
きる。回復スレッド２６は、データベース２２を検査
し、まだ処理されていない要求があるかどうかを判別す
る。処理されていない要求があると、回復スレッド２６
は、データベース２２に記憶されている最も古いＲＰＣ
要求を選択し、キュー２１へ復元（リストア）する。
Ｃクライアント３０のＲＰＣ要求の処理を妨げたり中断
させたりするような障害がＲＰＣサーバ２０に起きたと
きに、使用される。このデータベースは、ＲＰＣサーバ
２０がＲＰＣ要求を受け取った旨が応答ライン３２を介
してＲＰＣクライアント３０に直ちに通知されるため
に、必要となる。ＲＰＣサーバ２０に何等かの障害が発
生した場合にデータベース２２が備わっていないと、Ｒ
ＰＣ要求は処理されない可能性があるにもかかわらず、
ＲＰＣクライアントにはＲＰＣ要求が実行された旨の応
答が返されることになる。したがって、データベース２
２を備えておけば、ＲＰＣサーバ２０が正常に操作を再
開した時点で、受信されキューに入れられているＲＰＣ
要求の内まだ処理されていない要求をデータベース２２
から取り出し、これらのＲＰＣ要求を処理することがで
きる。回復スレッド２６は、データベース２２を検査
し、まだ処理されていない要求があるかどうかを判別す
る。処理されていない要求があると、回復スレッド２６
は、データベース２２に記憶されている最も古いＲＰＣ
要求を選択し、キュー２１へ復元（リストア）する。
【００１９】図４は、この発明によるマルチスレッドＲ
ＰＣ処理を示したタイミングチャートである。図４で、
１番目のクライアント３０は１番目のＲＰＣ要求ＰＲ１
を送り、２番目のクライアント３０は２番目のＲＰＣ要
求ＰＲ２をＲＰＣサーバ２０へ送り、それぞれ処理を依
頼する。１及び２番目のＲＰＣ要求ＰＲ１、ＰＲ２は、
殆ど同時にＲＰＣサーバ２０に到着する（Ｔ１）。ただ
し、要求ＰＲ１の方が、要求ＰＲ２より処理にかなり時
間がかかる。１及び２番目のＲＰＣ要求ＰＲ１とＰＲ２
の両方がＲＰＣサーバ２０に到着すると、それらは直ち
にキュー２１へ入れられ、対応するエントリがデータベ
ース２２に作成される（Ｔ１）。処理スレッド２４1と
２４2が作成され、別々のＰＲ１とＰＲ２要求の処理が
並行して開始される。さらに、ＲＰＣ要求ＰＲ１とＰＲ
２がキュー２１へ入れられるとすぐ、ＲＰＣサーバ２０
は応答Ｒ１とＲ２とを各々のクライアント３０へ直ちに
返し、ＲＰＣ要求ＰＲ１とＰＲ２とが処理されたことを
通知する（Ｔ１）。ＲＰＣサーバ２０は１番目のＲＰＣ
要求ＰＲ１及び２番目のＲＰＣ要求ＰＲ２とを並行して
処理するため、応答時間は、サーバ内にすでに受け付け
てられているＲＰＣ要求には依存しない。したがって、
応答時間は、シングルスレッドＲＰＣサーバの応答時間
より格段に速くなる。つまり、２番目のＲＰＣ要求ＰＲ
２の処理はＴ２で終了し、最初のＲＰＣ要求ＰＲ１の処
理はＴ３で終了する。
ＰＣ処理を示したタイミングチャートである。図４で、
１番目のクライアント３０は１番目のＲＰＣ要求ＰＲ１
を送り、２番目のクライアント３０は２番目のＲＰＣ要
求ＰＲ２をＲＰＣサーバ２０へ送り、それぞれ処理を依
頼する。１及び２番目のＲＰＣ要求ＰＲ１、ＰＲ２は、
殆ど同時にＲＰＣサーバ２０に到着する（Ｔ１）。ただ
し、要求ＰＲ１の方が、要求ＰＲ２より処理にかなり時
間がかかる。１及び２番目のＲＰＣ要求ＰＲ１とＰＲ２
の両方がＲＰＣサーバ２０に到着すると、それらは直ち
にキュー２１へ入れられ、対応するエントリがデータベ
ース２２に作成される（Ｔ１）。処理スレッド２４1と
２４2が作成され、別々のＰＲ１とＰＲ２要求の処理が
並行して開始される。さらに、ＲＰＣ要求ＰＲ１とＰＲ
２がキュー２１へ入れられるとすぐ、ＲＰＣサーバ２０
は応答Ｒ１とＲ２とを各々のクライアント３０へ直ちに
返し、ＲＰＣ要求ＰＲ１とＰＲ２とが処理されたことを
通知する（Ｔ１）。ＲＰＣサーバ２０は１番目のＲＰＣ
要求ＰＲ１及び２番目のＲＰＣ要求ＰＲ２とを並行して
処理するため、応答時間は、サーバ内にすでに受け付け
てられているＲＰＣ要求には依存しない。したがって、
応答時間は、シングルスレッドＲＰＣサーバの応答時間
より格段に速くなる。つまり、２番目のＲＰＣ要求ＰＲ
２の処理はＴ２で終了し、最初のＲＰＣ要求ＰＲ１の処
理はＴ３で終了する。
【００２０】図４に示されている応答Ｒ１とＲ２は、Ｒ
ＰＣ要求がＲＰＣサーバ２０で処理されたことを示す簡
単な内容でも、またはＲＰＣ要求が単に受け取られたこ
とだけを表す内容でも構わない。さらに、応答Ｒ１とＲ
２には、予想される完了時間等、処理に関するデータを
含めてもよい。
ＰＣ要求がＲＰＣサーバ２０で処理されたことを示す簡
単な内容でも、またはＲＰＣ要求が単に受け取られたこ
とだけを表す内容でも構わない。さらに、応答Ｒ１とＲ
２には、予想される完了時間等、処理に関するデータを
含めてもよい。
【００２１】図５は、この発明の応用例を示している。
図５では、ＲＰＣクライアント３０は、上記と同様に、
ＲＰＣ要求ＰＲ１とＰＲ２とをＲＰＣサーバ２０へ送
る。しかし、マルチスレッドＲＰＣシステム１０には通
知サーバ４０が含まれていて、この通知サーバがイベン
ト通知Ｎｉを通知クライアント５０へ送ることができる
ようになっている。つまり、ＲＰＣサーバ２０がＲＰＣ
要求を処理している間に何等かのイベントが発生する
と、ＲＰＣサーバ２０は通知サーバ４０に対し“Ｓｅｎ
ｄＥｖｅｎｔ”要求を送る。ＲＰＣサーバ２０と通知サ
ーバ４０との間で受け渡されるこれらの要求と応答も、
ＲＰＣである。つまり、“ＳｅｎｄＥｖｅｎｔ”オペレ
ーションに関して言えば、「ＲＰＣクライアント」はＲ
ＰＣサーバ２０であり、「ＲＰＣサーバ」は通知サーバ
４０である。したがって、この場合は、通知サーバ４０
は、通知クライアント５０に対し通知プロファイルに指
定されている方法を使用して通知Ｎｉを送るための処理
を実行しなければならない。通知プロファイルは、“Ｓ
ｅｎｄＥｖｅｎｔ”要求のデータに組み込むことができ
る。通知サーバ４０へ送るデータには、例えば、イベン
ト識別番号やイベントについてのその他の追加情報、及
び通知プロファイル（デリバリー（配信）方法とデリバ
リーアドレスとが含まれる）が含まれる。通知サーバ４
０は、イベント識別番号と追加情報とからユーザが読み
取り可能なイベントメッセージを作成し、指定されたデ
リバリー方法を使用してその通知をデリバリーアドレス
へ送る。
図５では、ＲＰＣクライアント３０は、上記と同様に、
ＲＰＣ要求ＰＲ１とＰＲ２とをＲＰＣサーバ２０へ送
る。しかし、マルチスレッドＲＰＣシステム１０には通
知サーバ４０が含まれていて、この通知サーバがイベン
ト通知Ｎｉを通知クライアント５０へ送ることができる
ようになっている。つまり、ＲＰＣサーバ２０がＲＰＣ
要求を処理している間に何等かのイベントが発生する
と、ＲＰＣサーバ２０は通知サーバ４０に対し“Ｓｅｎ
ｄＥｖｅｎｔ”要求を送る。ＲＰＣサーバ２０と通知サ
ーバ４０との間で受け渡されるこれらの要求と応答も、
ＲＰＣである。つまり、“ＳｅｎｄＥｖｅｎｔ”オペレ
ーションに関して言えば、「ＲＰＣクライアント」はＲ
ＰＣサーバ２０であり、「ＲＰＣサーバ」は通知サーバ
４０である。したがって、この場合は、通知サーバ４０
は、通知クライアント５０に対し通知プロファイルに指
定されている方法を使用して通知Ｎｉを送るための処理
を実行しなければならない。通知プロファイルは、“Ｓ
ｅｎｄＥｖｅｎｔ”要求のデータに組み込むことができ
る。通知サーバ４０へ送るデータには、例えば、イベン
ト識別番号やイベントについてのその他の追加情報、及
び通知プロファイル（デリバリー（配信）方法とデリバ
リーアドレスとが含まれる）が含まれる。通知サーバ４
０は、イベント識別番号と追加情報とからユーザが読み
取り可能なイベントメッセージを作成し、指定されたデ
リバリー方法を使用してその通知をデリバリーアドレス
へ送る。
【００２２】図６は、シングルスレッドＲＰＣ処理シス
テムを使用したイベント通知のシングルスレッドＲＰＣ
処理を示している。この場合、２つのＲＰＣサーバ２０
は“ＳｅｎｄＥｖｅｎｔ”ＲＰＣ要求ＰＲ１とＰＲ２と
を同時にまたは殆ど同時に通知サーバ４０へ送る（Ｔ
１）。図６に示されているように、ＰＲ１の処理を完了
した時点で、通知サーバ４０は応答Ｒ１をＲＰＣサーバ
２０へ送り返し、その後“ＳｅｎｄＥｖｅｎｔ”ＲＰＣ
要求ＰＲ２の処理を開始する（Ｔ２）。ＰＲ１、ＰＲ２
の処理を完了した後には、通知Ｎ１とＮ２とが、それぞ
れ、Ｔ２とＴ３の時点で通知クライアント５０へ送られ
る。したがって、一方のＲＰＣサーバ２０は、最初の
“ＳｅｎｄＥｖｅｎｔ”要求ＰＲ１の処理の終了に対応
するＴ２で応答を受け取る。さらに、通知サーバ４０
は、対応する通知クライアント５０に対し通知Ｎ１を送
る。しかし、２番目の“ＳｅｎｄＥｖｅｎｔ”要求ＰＲ
２に関するイベント通知Ｎ２は、１番目のＲＰＣ要求Ｐ
Ｒ１と２番目のＲＰＣ要求ＰＲ２の両方が完全に処理さ
れるまで（Ｔ３）、送られない。これは、通知サーバ４
０がＲＰＣ要求を逐次的に処理するからである。
テムを使用したイベント通知のシングルスレッドＲＰＣ
処理を示している。この場合、２つのＲＰＣサーバ２０
は“ＳｅｎｄＥｖｅｎｔ”ＲＰＣ要求ＰＲ１とＰＲ２と
を同時にまたは殆ど同時に通知サーバ４０へ送る（Ｔ
１）。図６に示されているように、ＰＲ１の処理を完了
した時点で、通知サーバ４０は応答Ｒ１をＲＰＣサーバ
２０へ送り返し、その後“ＳｅｎｄＥｖｅｎｔ”ＲＰＣ
要求ＰＲ２の処理を開始する（Ｔ２）。ＰＲ１、ＰＲ２
の処理を完了した後には、通知Ｎ１とＮ２とが、それぞ
れ、Ｔ２とＴ３の時点で通知クライアント５０へ送られ
る。したがって、一方のＲＰＣサーバ２０は、最初の
“ＳｅｎｄＥｖｅｎｔ”要求ＰＲ１の処理の終了に対応
するＴ２で応答を受け取る。さらに、通知サーバ４０
は、対応する通知クライアント５０に対し通知Ｎ１を送
る。しかし、２番目の“ＳｅｎｄＥｖｅｎｔ”要求ＰＲ
２に関するイベント通知Ｎ２は、１番目のＲＰＣ要求Ｐ
Ｒ１と２番目のＲＰＣ要求ＰＲ２の両方が完全に処理さ
れるまで（Ｔ３）、送られない。これは、通知サーバ４
０がＲＰＣ要求を逐次的に処理するからである。
【００２３】図７は、イベント通知のマルチスレッドＲ
ＰＣ処理を示すタイミングチャートである。図７に示さ
れている処理は図４に示されている処理と似ているが、
通知クライアント５０が用意されていて“ＳｅｎｄＥｖ
ｅｎｔ”処理終了時に通知Ｎｉを出す点は異なってい
る。２つのＲＰＣサーバ２０は、１番目及び２番目のＲ
ＰＣ要求ＰＲ１とＰＲ２とを通知サーバ４０に送る。１
及び２番目の“ＳｅｎｄＥｖｅｎｔ”要求ＰＲ１とＰＲ
２は、通知サーバ４０に同時または殆ど同時に到着する
（Ｔ１）。応答スレッド２５は、１及び２番目の“Ｓｅ
ｎｄＥｖｅｎｔ”要求ＰＲ１とＰＲ２をキュー２１とデ
ータベース２２へロードし、１及び２番目の応答Ｒ１と
Ｒ２を対応するＲＰＣサーバ２０へ直ちに戻す（Ｔ
１）。１及び２番目のＲＰＣ要求ＰＲ１とＰＲ２の処理
は、処理スレッド２４1及び２４2を使用して並列的に実
行される。２番目の処理要求ＰＲ２は短時間（例えば１
秒）で完了するため（Ｔ２）、対応する通知クライアン
ト５０は最初の要求ＰＲ１の処理が完了するまで待たず
に、イベントを通知される。１番目の“ＳｅｎｄＥｖｅ
ｎｔ”要求ＰＲ１の処理が完了すると（Ｔ３）、通知Ｎ
１は対応する通知クライアント５０へ送られる。したが
って、シングルスレッド通知サーバを使用する時には通
知クライアント５０に対する通知は遅れていたが、マル
チスレッドではこの遅れもなくなる。
ＰＣ処理を示すタイミングチャートである。図７に示さ
れている処理は図４に示されている処理と似ているが、
通知クライアント５０が用意されていて“ＳｅｎｄＥｖ
ｅｎｔ”処理終了時に通知Ｎｉを出す点は異なってい
る。２つのＲＰＣサーバ２０は、１番目及び２番目のＲ
ＰＣ要求ＰＲ１とＰＲ２とを通知サーバ４０に送る。１
及び２番目の“ＳｅｎｄＥｖｅｎｔ”要求ＰＲ１とＰＲ
２は、通知サーバ４０に同時または殆ど同時に到着する
（Ｔ１）。応答スレッド２５は、１及び２番目の“Ｓｅ
ｎｄＥｖｅｎｔ”要求ＰＲ１とＰＲ２をキュー２１とデ
ータベース２２へロードし、１及び２番目の応答Ｒ１と
Ｒ２を対応するＲＰＣサーバ２０へ直ちに戻す（Ｔ
１）。１及び２番目のＲＰＣ要求ＰＲ１とＰＲ２の処理
は、処理スレッド２４1及び２４2を使用して並列的に実
行される。２番目の処理要求ＰＲ２は短時間（例えば１
秒）で完了するため（Ｔ２）、対応する通知クライアン
ト５０は最初の要求ＰＲ１の処理が完了するまで待たず
に、イベントを通知される。１番目の“ＳｅｎｄＥｖｅ
ｎｔ”要求ＰＲ１の処理が完了すると（Ｔ３）、通知Ｎ
１は対応する通知クライアント５０へ送られる。したが
って、シングルスレッド通知サーバを使用する時には通
知クライアント５０に対する通知は遅れていたが、マル
チスレッドではこの遅れもなくなる。
【００２４】図５では、通知クライアント５０はＲＰＣ
クライアント３０からは独立した別個の装置として示さ
れている。しかし、ＲＰＣクライアント３０と通知クラ
イアント５０は、物理的に同じ装置（エンティティ）で
も構わない。また、さらに、通知クライアント５０への
通知Ｎｉには、イベントが発生した時刻等、ＲＰＣサー
バ２０に発生したイベントに関する追加情報を組み込む
こともできる。また、ＲＰＣサーバ２０と通知サーバ４
０とは、同じハードウエア上に構築してもよい。
クライアント３０からは独立した別個の装置として示さ
れている。しかし、ＲＰＣクライアント３０と通知クラ
イアント５０は、物理的に同じ装置（エンティティ）で
も構わない。また、さらに、通知クライアント５０への
通知Ｎｉには、イベントが発生した時刻等、ＲＰＣサー
バ２０に発生したイベントに関する追加情報を組み込む
こともできる。また、ＲＰＣサーバ２０と通知サーバ４
０とは、同じハードウエア上に構築してもよい。
【００２５】図７に示されている例では、２つのＲＰＣ
サーバ２０が最初及び２番目の“ＳｅｎｄＥｖｅｎｔ”
要求ＰＲ１とＰＲ２を通知サーバ４０へ送っている。し
かし、この発明は、ＲＰＣ要求が２つの場合だけに限定
されたものではない。任意の数の“ＳｅｎｄＥｖｅｎ
ｔ”要求を同時または殆ど同時に受け取ることができ、
また、キュー２１には任意の数の“ＳｅｎｄＥｖｅｎ
ｔ”要求がすでに格納されていても構わない。しかし、
実際には、並列的に処理できる“ＳｅｎｄＥｖｅｎｔ”
要求数には制限がある。したがって、通知サーバ４０に
は、並列的に処理されるＲＰＣ要求数について、ハード
ウエア的な制限があることがある。
サーバ２０が最初及び２番目の“ＳｅｎｄＥｖｅｎｔ”
要求ＰＲ１とＰＲ２を通知サーバ４０へ送っている。し
かし、この発明は、ＲＰＣ要求が２つの場合だけに限定
されたものではない。任意の数の“ＳｅｎｄＥｖｅｎ
ｔ”要求を同時または殆ど同時に受け取ることができ、
また、キュー２１には任意の数の“ＳｅｎｄＥｖｅｎ
ｔ”要求がすでに格納されていても構わない。しかし、
実際には、並列的に処理できる“ＳｅｎｄＥｖｅｎｔ”
要求数には制限がある。したがって、通知サーバ４０に
は、並列的に処理されるＲＰＣ要求数について、ハード
ウエア的な制限があることがある。
【００２６】図８〜図１１は、マルチスレッドＲＰＣ処
理を実行するためのフローチャートである。図８は、応
答スレッドサブルーチンを示している。ステップＳ１０
では、ＲＰＣサーバ２０は新しいＲＰＣ要求をＲＰＣク
ライアント３０から受け取る。
理を実行するためのフローチャートである。図８は、応
答スレッドサブルーチンを示している。ステップＳ１０
では、ＲＰＣサーバ２０は新しいＲＰＣ要求をＲＰＣク
ライアント３０から受け取る。
【００２７】次に、ステップＳ１１では、新しいＲＰＣ
要求はキュー２１へ入れられる。次に、ステップＳ１２
で、新しいＲＰＣ要求はデータベース２２へ記憶され
る。
要求はキュー２１へ入れられる。次に、ステップＳ１２
で、新しいＲＰＣ要求はデータベース２２へ記憶され
る。
【００２８】次に、ステップＳ１３では、ＲＰＣサーバ
２０は応答ＲｉをＲＰＣクライアント３０へ返し、新し
いＲＰＣ要求が受け取られた旨を通知する。
２０は応答ＲｉをＲＰＣクライアント３０へ返し、新し
いＲＰＣ要求が受け取られた旨を通知する。
【００２９】次に、ステップＳ１４では、条件変数２９
にシグナルを送る。作成スレッド２３がアイドル状態の
場合は、このステップにより、作成スレッドはキュー２
１に記憶されているＲＰＣ要求の処理を開始する。
にシグナルを送る。作成スレッド２３がアイドル状態の
場合は、このステップにより、作成スレッドはキュー２
１に記憶されているＲＰＣ要求の処理を開始する。
【００３０】ステップＳ１０〜Ｓ１４が繰り返される。
【００３１】図９は、スレッド作成ルーチンを示してい
る。ステップＳ２０では、ＲＰＣサーバは、応答スレッ
ド２５が条件変数２９に対しシグナルを送るまで、待ち
状態のままである。
る。ステップＳ２０では、ＲＰＣサーバは、応答スレッ
ド２５が条件変数２９に対しシグナルを送るまで、待ち
状態のままである。
【００３２】ステップＳ２１では、ＲＰＣサーバ２０は
処理スレッドカウンタ２７が所定の値に達したことを判
別する。処理スレッドカウンタ２７が所定の値に達して
いれば、処理はステップＳ２２へ移る。所定の値に達し
ていない場合は、処理はステップＳ２３へジャンプす
る。
処理スレッドカウンタ２７が所定の値に達したことを判
別する。処理スレッドカウンタ２７が所定の値に達して
いれば、処理はステップＳ２２へ移る。所定の値に達し
ていない場合は、処理はステップＳ２３へジャンプす
る。
【００３３】次に、ステップＳ２２では、ＲＰＣサーバ
２０はすでに実行されている処理スレッド２４iのいず
れかが条件変数２８に対しシグナルを送るまで待つ。
２０はすでに実行されている処理スレッド２４iのいず
れかが条件変数２８に対しシグナルを送るまで待つ。
【００３４】ステップＳ２３では、作成スレッド２３は
最も古い（すなわち最初に入れられた）ＲＰＣ要求ＰＲ
ｉをキュー２１から取り出す。処理はステップＳ２４へ
進む。ステップＳ２４では、作成スレッド２３は、ＲＰ
Ｃ要求ＰＲｉを処理するためにスレッド２４nを作成す
る。処理はステップＳ２５へ進む。ステップＳ２５で
は、処理スレッドカウンタ２７が１だけ増分される。処
理はステップＳ２６へ進む。ステップＳ２６では、ＲＰ
Ｃサーバ２０は、キュー２１にＲＰＣ要求があるかどう
か判別する。キュー２１にＲＰＣ要求がある場合は、処
理はステップＳ２３へ戻る。ＲＰＣ要求がない場合は、
処理はステップＳ２０へ戻る。
最も古い（すなわち最初に入れられた）ＲＰＣ要求ＰＲ
ｉをキュー２１から取り出す。処理はステップＳ２４へ
進む。ステップＳ２４では、作成スレッド２３は、ＲＰ
Ｃ要求ＰＲｉを処理するためにスレッド２４nを作成す
る。処理はステップＳ２５へ進む。ステップＳ２５で
は、処理スレッドカウンタ２７が１だけ増分される。処
理はステップＳ２６へ進む。ステップＳ２６では、ＲＰ
Ｃサーバ２０は、キュー２１にＲＰＣ要求があるかどう
か判別する。キュー２１にＲＰＣ要求がある場合は、処
理はステップＳ２３へ戻る。ＲＰＣ要求がない場合は、
処理はステップＳ２０へ戻る。
【００３５】図１０は、典型的なＲＰＣ処理スレッド２
４の処理ルーチンを示している。ステップＳ３０では、
処理スレッド２４nはＲＰＣ要求ＰＲiの処理を開始す
る。処理はステップＳ３１へ進む。ステップＳ３１で
は、処理が完了している場合はステップＳ３２へ進む。
処理が完了していない場合は、処理は終了し、エラーが
発生する。ステップＳ３２では、ＲＰＣ要求ＰＲiはデ
ータベース２２から削除される。次に処理はステップＳ
３４へ進む。
４の処理ルーチンを示している。ステップＳ３０では、
処理スレッド２４nはＲＰＣ要求ＰＲiの処理を開始す
る。処理はステップＳ３１へ進む。ステップＳ３１で
は、処理が完了している場合はステップＳ３２へ進む。
処理が完了していない場合は、処理は終了し、エラーが
発生する。ステップＳ３２では、ＲＰＣ要求ＰＲiはデ
ータベース２２から削除される。次に処理はステップＳ
３４へ進む。
【００３６】ステップＳ３４では、要求ＰＲiを処理す
るためにスレッド２４nに割り当てられていた処理資源
が解放される。処理はステップＳ３５へ進む。ステップ
Ｓ３５では、処理スレッドカウンタ２７は１だけ減少さ
れる。ステップＳ３６では、条件変数２８にシグナルが
送られる。そして処理は終了する。
るためにスレッド２４nに割り当てられていた処理資源
が解放される。処理はステップＳ３５へ進む。ステップ
Ｓ３５では、処理スレッドカウンタ２７は１だけ減少さ
れる。ステップＳ３６では、条件変数２８にシグナルが
送られる。そして処理は終了する。
【００３７】図１１は、回復ルーチンを示している。ス
テップＳ４１では、ＲＰＣサーバ２０は障害発生後に再
起動される。処理はステップＳ４２へ進む。ステップＳ
４２では、ＲＰＣサーバは、キュー２１内にないＲＰＣ
要求がデータベース２２に記憶されているかどうか判別
する。データベース２２にそのようなＲＰＣ要求がない
場合は、処理は終了する。そのような要求がある場合
は、処理はステップＳ４３へ進む。ステップＳ４３で
は、最も古い（最初に入れられた）ＲＰＣ要求がデータ
ベース２２からコピーされる。処理はステップＳ４４へ
進む。ステップＳ４４では、選択されたＲＰＣ要求がキ
ュー２１へ追加される。処理はステップＳ４５へ進む。
ステップＳ４５では、ＲＰＣサーバ２０は、キュー２１
にないＲＰＣ要求がデータベース２２にあるかどうか再
び判別する。データベース２２にＲＰＣ要求がある場合
は、処理はステップＳ４３へ進む。ＲＰＣ要求がない場
合は、処理は終了する。
テップＳ４１では、ＲＰＣサーバ２０は障害発生後に再
起動される。処理はステップＳ４２へ進む。ステップＳ
４２では、ＲＰＣサーバは、キュー２１内にないＲＰＣ
要求がデータベース２２に記憶されているかどうか判別
する。データベース２２にそのようなＲＰＣ要求がない
場合は、処理は終了する。そのような要求がある場合
は、処理はステップＳ４３へ進む。ステップＳ４３で
は、最も古い（最初に入れられた）ＲＰＣ要求がデータ
ベース２２からコピーされる。処理はステップＳ４４へ
進む。ステップＳ４４では、選択されたＲＰＣ要求がキ
ュー２１へ追加される。処理はステップＳ４５へ進む。
ステップＳ４５では、ＲＰＣサーバ２０は、キュー２１
にないＲＰＣ要求がデータベース２２にあるかどうか再
び判別する。データベース２２にＲＰＣ要求がある場合
は、処理はステップＳ４３へ進む。ＲＰＣ要求がない場
合は、処理は終了する。
【００３８】上記で説明した実施例では、適切にプログ
ラムされた汎用コンピュータが記載されたデータ処理を
制御する。しかし、システム全体を制御する主プロセッ
サ部すなわち中央プロセッサ部と、この中央プロセッサ
部の制御下で様々な特殊計算、機能、及び他の処理を実
行するための個別回路とを備えた専用の集積回路（例え
ばＡＳＩＣ等）でも、これらの処理機能を実現すること
はできる。また、個別のの専用電子回路やプログラマブ
ル集積電子回路、すなわちデバイス、を使用して実現す
ることもできる（例えば、個別回路要素、ＰＡＬ、ＰＬ
Ａ、ＤＬＤ、ＦＰＧＡ等のハードワイヤード電子デバイ
スまたは論理デバイス）。一般的に、図８〜図１１のフ
ローチャートを実行できる有限状態マシンが搭載可能な
デバイスまたはアセンブリならば、データ処理の制御に
使用できる。
ラムされた汎用コンピュータが記載されたデータ処理を
制御する。しかし、システム全体を制御する主プロセッ
サ部すなわち中央プロセッサ部と、この中央プロセッサ
部の制御下で様々な特殊計算、機能、及び他の処理を実
行するための個別回路とを備えた専用の集積回路（例え
ばＡＳＩＣ等）でも、これらの処理機能を実現すること
はできる。また、個別のの専用電子回路やプログラマブ
ル集積電子回路、すなわちデバイス、を使用して実現す
ることもできる（例えば、個別回路要素、ＰＡＬ、ＰＬ
Ａ、ＤＬＤ、ＦＰＧＡ等のハードワイヤード電子デバイ
スまたは論理デバイス）。一般的に、図８〜図１１のフ
ローチャートを実行できる有限状態マシンが搭載可能な
デバイスまたはアセンブリならば、データ処理の制御に
使用できる。
【００３９】好ましい実施態様を参照しながらこの発明
を説明したが、この実施態様は説明上のもので、制約的
なものと解してはならない。特許請求の範囲で定義して
いるこの発明の範囲から逸脱すること無しに、各種変更
が可能である。
を説明したが、この実施態様は説明上のもので、制約的
なものと解してはならない。特許請求の範囲で定義して
いるこの発明の範囲から逸脱すること無しに、各種変更
が可能である。
【図１】 シングルスレッド処理を使用する分散処理シ
ステムのブロック図である。
ステムのブロック図である。
【図２】 シングルスレッド処理のタイミングチャート
である。
である。
【図３】 この発明に係るマルチスレッド処理システム
のブロック図である。
のブロック図である。
【図４】 待ち合せを使用するマルチスレッド処理のタ
イミングチャートである。
イミングチャートである。
【図５】 通知サーバ及び関連構成要素のブロック図で
ある。
ある。
【図６】 通知機能を使用するシングルスレッド処理の
タイミングチャートである。
タイミングチャートである。
【図７】 通知機能を使用するマルチスレッド処理のタ
イミングチャートである。
イミングチャートである。
【図８】 応答スレッドサブルーチンを実行するフロー
チャートである。
チャートである。
【図９】 作成スレッドサブルーチンを実行するフロー
チャートである。
チャートである。
【図１０】 処理スレッドサブルーチンを実行するフロ
ーチャートである。
ーチャートである。
【図１１】 回復スレッドサブルーチンを実行するフロ
ーチャートである。
ーチャートである。
２０ サーバ、２１ キュー、２２ データベース、２
３ 作成スレッド、２４ 処理スレッド、２５ 応答ス
レッド、２６ 回復スレッド、２７ カウンタ（処理ス
レッドカウンタ）、２８，２９ 条件変数、３０ クラ
イアント。
３ 作成スレッド、２４ 処理スレッド、２５ 応答ス
レッド、２６ 回復スレッド、２７ カウンタ（処理ス
レッドカウンタ）、２８，２９ 条件変数、３０ クラ
イアント。
フロントページの続き (72)発明者 トン エイチ トロング アメリカ合衆国 カリフォルニア州 ウェ ストミンスター オレンジ ソープ アベ ニュー 8821
Claims (16)
- 【請求項１】 少なくとも１つのクライアントと、 前記クライアントから処理要求を受け取る第１のサーバ
と、 処理要求をキューに登録する手段と、 複数の処理要求を並列的に処理可能な並列処理手段と、 処理要求が前記キューに登録されたときに、前記クライ
アントのうちのその処理要求を発したクライアントに対
して応答を返す手段と、 を備えるコンピュータシステム。 - 【請求項２】 請求項１に記載のコンピュータシステム
であって、 処理要求を不揮発性メモリに格納する手段と、 前記コンピュータシステムに障害が発生した場合に、前
記不揮発性メモリから処理要求を取り出し、前記キュー
に登録する手段と、 をさらに備えるコンピュータシステム。 - 【請求項３】 請求項１に記載のコンピュータシステム
であって、 前記並列処理手段は、キューから処理要求を選択し、選
択した処理要求を複数の個別処理手段のいずれかに渡し
て処理させる手段を有することを特徴とするコンピュー
タシステム。 - 【請求項４】 請求項３に記載のコンピュータシステム
であって、前記各個別処理手段は、前記選択された要求
を受け取って処理し、その後その要求を前記不揮発性メ
モリから削除することを特徴とするコンピュータシステ
ム。 - 【請求項５】 請求項４に記載のコンピュータシステム
であって、前記第１のサーバが選択された要求を処理し
ている間にイベントが発生した時に、通知クライアント
に通知する通知手段をさらに備えたことを特徴とするコ
ンピュータシステム。 - 【請求項６】 請求項５に記載のコンピュータシステム
であって、前記通知手段は第２のサーバを備え、前記第
２のサーバは、前記第１のサーバが選択された要求を処
理している時にイベントが発生した場合に、前記第１の
サーバから要求を受け取り、イベント通知を前記通知ク
ライアントに送信することを特徴とするコンピュータシ
ステム。 - 【請求項７】 コンピュータシステムで要求を処理する
方法であって、 クライアントから処理要求を受け取り、 該処理要求を処理要求のキューに登録し、 該処理要求を外部装置に記憶させ、 該処理要求をキューに登録した時に前記クライアントに
応答を戻し、 処理要求のいずれかをキューから取り出し、 取り出した処理要求を処理することを特徴とする方法。 - 【請求項８】 請求項７に記載の方法であって、取り出
された処理要求の処理が完了した時にその処理要求を前
記外部装置から削除するステップをさらに含むことを特
徴とする方法。 - 【請求項９】 請求項８に記載の方法であって、 前記外部装置に処理要求が含まれているかどうかを判別
し、 障害からの回復時に、記憶されている各処理要求を前記
外部装置から読み取り、 読み取られた処理要求を、前記サーバが受け取った順序
に対応する順序で、前記キューに登録するステップをさ
らに含むことを特徴とする方法。 - 【請求項１０】 少なくとも一つのクライアントと、 前記クライアントから処理要求を受け取るサーバと、 処理要求をキューに登録し、処理要求を前記キューに登
録した時に、前記クライアントのうちのその処理要求を
発したクライアントに対して応答を返すモジュールと、 を備えるコンピュータシステム。 - 【請求項１１】 請求項１０に記載のコンピュータシス
テムであって、前記モジュールは処理要求を外部装置に
格納することを特徴とするコンピュータシステム。 - 【請求項１２】 請求項１１に記載のコンピュータシス
テムであって、コンピュータシステム障害が発生した場
合に、前記外部装置から処理要求を取り出し、取り出し
た要求を前記キューに登録する第２のモジュールをさら
に備えることを特徴とするコンピュータシステム。 - 【請求項１３】 請求項１１に記載のコンピュータシス
テムであって、 前記キューから処理要求を選択する第２のモジュール
と、 選択された複数の処理要求を並列的に処理する第３のモ
ジュールと、 をさらに備えることを特徴とするコンピュータシステ
ム。 - 【請求項１４】 請求項１３に記載のコンピュータシス
テムであって、処理要求は前記第３のモジュールにより
処理された後に前記外部装置から削除されることを特徴
とするコンピュータシステム。 - 【請求項１５】 請求項１４に記載のコンピュータシス
テムであって、選択された要求を前記サーバが処理して
いる間にイベントが発生すると、前記サーバから第１の
要求を受け取った後でイベント通知を通知クライアント
に送信する通知サーバをさらに含むことを特徴とするコ
ンピュータシステム。 - 【請求項１６】 請求項１３に記載のコンピュータシス
テムであって、 キューから選択した処理要求の数をカウントするカウン
タと、 前記カウンタによりカウントした処理要求の数に基づい
て、前記第３のモジュールによるキューからの処理要求
の選択を制御するリミッタと、 をさらに備えることを特徴とするコンピュータシステ
ム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/975,860 | 1997-11-21 | ||
| US08/975,860 US6081906A (en) | 1997-11-21 | 1997-11-21 | Multi-thread processing with queuing and recovery |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11238046A true JPH11238046A (ja) | 1999-08-31 |
| JPH11238046A5 JPH11238046A5 (ja) | 2004-08-19 |
Family
ID=25523496
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP10327125A Pending JPH11238046A (ja) | 1997-11-21 | 1998-11-17 | コンピュータシステム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6081906A (ja) |
| JP (1) | JPH11238046A (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007226584A (ja) * | 2006-02-24 | 2007-09-06 | Hitachi Ltd | 取引システム |
| JP2008135013A (ja) * | 2006-10-30 | 2008-06-12 | Hitachi Ltd | 注文システム |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6535878B1 (en) * | 1997-05-02 | 2003-03-18 | Roxio, Inc. | Method and system for providing on-line interactivity over a server-client network |
| US6708224B1 (en) * | 1999-01-19 | 2004-03-16 | Netiq Corporation | Methods, systems and computer program products for coordination of operations for interrelated tasks |
| JP3807588B2 (ja) * | 1999-08-12 | 2006-08-09 | 富士通株式会社 | マルチスレッド処理装置及び処理方法並びにマルチスレッドプログラムを格納したコンピュータ可読の記録媒体 |
| EP1407583B1 (en) * | 2001-07-17 | 2009-06-03 | Alcatel Internetworking, Inc. | In-band message synchronization for distributed shared memory packet switch |
| US7523200B2 (en) * | 2003-07-02 | 2009-04-21 | International Business Machines Corporation | Dynamic access decision information module |
| US7447710B2 (en) * | 2003-12-11 | 2008-11-04 | Sybase, Inc. | Database system providing self-tuned parallel database recovery |
| JP4238142B2 (ja) * | 2004-01-15 | 2009-03-11 | 株式会社日立製作所 | プログラムコンポーネントの処理要求キューの構成方法、プログラムコンポーネントの登録方法及び実行制御方法、プログラムコンポーネントの登録プログラム及び実行制御プログラム、並びに、アプリケーションサーバ |
| GB0407388D0 (en) * | 2004-03-31 | 2004-05-05 | British Telecomm | Method and apparatus for communicating data between computer devices |
| US20060067162A1 (en) * | 2004-09-29 | 2006-03-30 | Blankinship Thomas J | Ultrasonic cement scanner |
| US8065690B2 (en) * | 2005-12-01 | 2011-11-22 | Cisco Technology, Inc. | Method and system for event-based remote procedure call implementation in a distributed computing system |
| US7676811B2 (en) * | 2006-03-23 | 2010-03-09 | Microsoft Corporation | Ensuring thread affinity for interprocess communication in a managed code environment |
| US8212805B1 (en) | 2007-01-05 | 2012-07-03 | Kenneth Banschick | System and method for parametric display of modular aesthetic designs |
| WO2008098070A1 (en) | 2007-02-06 | 2008-08-14 | Mba Sciences, Inc. | A resource tracking method and apparatus |
| JP4801761B2 (ja) * | 2009-08-12 | 2011-10-26 | 株式会社日立製作所 | データベース管理方法およびシステム並びにその処理プログラム |
| US9940670B2 (en) | 2009-12-10 | 2018-04-10 | Royal Bank Of Canada | Synchronized processing of data by networked computing resources |
| ES2754099T3 (es) * | 2009-12-10 | 2020-04-15 | Royal Bank Of Canada | Tratamiento sincronizado de datos mediante recursos informáticos en red |
| WO2025010725A1 (en) * | 2023-07-13 | 2025-01-16 | Beijing Oceanbase Technology Co., Ltd. | Hybrid database implementations |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS61131043A (ja) * | 1984-11-30 | 1986-06-18 | Toshiba Corp | タスク間キユ−制御方式 |
| JPS63138439A (ja) * | 1986-12-01 | 1988-06-10 | Hitachi Ltd | 分散データベースアクセス要求処理方法 |
| JPH06332834A (ja) * | 1993-05-25 | 1994-12-02 | Hitachi Ltd | リモートプロシジャコール方法 |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5014221A (en) * | 1988-01-29 | 1991-05-07 | Digital Equipment Corporation | Mechanism for arbitrating client access to a networked print server |
| US4949251A (en) * | 1988-07-18 | 1990-08-14 | Digital Equipment Corporation | Exactly-once semantics in a TP queuing system |
| US5321813A (en) * | 1991-05-01 | 1994-06-14 | Teradata Corporation | Reconfigurable, fault tolerant, multistage interconnect network and protocol |
| US5485626A (en) * | 1992-11-03 | 1996-01-16 | International Business Machines Corporation | Architectural enhancements for parallel computer systems utilizing encapsulation of queuing allowing small grain processing |
| JPH06187302A (ja) * | 1992-12-18 | 1994-07-08 | Fujitsu Ltd | 転送要求キュー制御方式 |
| US5577204A (en) * | 1993-12-15 | 1996-11-19 | Convex Computer Corporation | Parallel processing computer system interconnections utilizing unidirectional communication links with separate request and response lines for direct communication or using a crossbar switching device |
| US5673381A (en) * | 1994-05-27 | 1997-09-30 | Cheyenne Software International Sales Corp. | System and parallel streaming and data stripping to back-up a network |
| EP0694837A1 (en) * | 1994-07-25 | 1996-01-31 | International Business Machines Corporation | Dynamic workload balancing |
| US5802371A (en) * | 1994-09-29 | 1998-09-01 | International Business Machines Corporation | Method of walking-up a call stack for a client/server program that uses remote procedure call |
| US5797005A (en) * | 1994-12-30 | 1998-08-18 | International Business Machines Corporation | Shared queue structure for data integrity |
| KR0150072B1 (ko) * | 1995-11-30 | 1998-10-15 | 양승택 | 병렬처리 컴퓨터 시스템에서의 메모리 데이타 경로 제어장치 |
| US5864738A (en) * | 1996-03-13 | 1999-01-26 | Cray Research, Inc. | Massively parallel processing system using two data paths: one connecting router circuit to the interconnect network and the other connecting router circuit to I/O controller |
| US5796934A (en) * | 1996-05-31 | 1998-08-18 | Oracle Corporation | Fault tolerant client server system |
| US5872963A (en) * | 1997-02-18 | 1999-02-16 | Silicon Graphics, Inc. | Resumption of preempted non-privileged threads with no kernel intervention |
-
1997
- 1997-11-21 US US08/975,860 patent/US6081906A/en not_active Expired - Lifetime
-
1998
- 1998-11-17 JP JP10327125A patent/JPH11238046A/ja active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS61131043A (ja) * | 1984-11-30 | 1986-06-18 | Toshiba Corp | タスク間キユ−制御方式 |
| JPS63138439A (ja) * | 1986-12-01 | 1988-06-10 | Hitachi Ltd | 分散データベースアクセス要求処理方法 |
| JPH06332834A (ja) * | 1993-05-25 | 1994-12-02 | Hitachi Ltd | リモートプロシジャコール方法 |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007226584A (ja) * | 2006-02-24 | 2007-09-06 | Hitachi Ltd | 取引システム |
| JP2008135013A (ja) * | 2006-10-30 | 2008-06-12 | Hitachi Ltd | 注文システム |
Also Published As
| Publication number | Publication date |
|---|---|
| US6081906A (en) | 2000-06-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JPH11238046A (ja) | コンピュータシステム | |
| JP2587141B2 (ja) | 共用知能メモリを介して結合された複数のプロセッサ間でメッセージを伝達するための機構 | |
| US6085277A (en) | Interrupt and message batching apparatus and method | |
| US6195701B1 (en) | Method and apparatus for synchronization and scheduling of multiple data streams and real time tasks | |
| US5566337A (en) | Method and apparatus for distributing events in an operating system | |
| US5946498A (en) | Delivery of client remote procedure calls to a server via a request queue utilizing priority and time-out | |
| CN107391271A (zh) | 一种基于消息队列系统的延时任务触发方法和装置 | |
| CN107341062B (zh) | 一种数据推送方法、装置、设备以及存储介质 | |
| US20130268647A1 (en) | Non-blocking buffered inter-machine data transfer with acknowledgment | |
| CN112667382A (zh) | 任务调度方法、装置、设备及存储介质 | |
| US11086691B2 (en) | Producer-consumer communication using multi-work consumers | |
| US20070260777A1 (en) | Queues for information processing and methods thereof | |
| CN111460350A (zh) | 一种防抖与节流封装方法及系统 | |
| CN109710421B (zh) | 消息中间件的接收者异常处理方法、服务器及存储介质 | |
| CN113419832A (zh) | 一种延迟任务的处理方法、装置及终端 | |
| CN114945005B (zh) | 一种消息处理方法及相关设备 | |
| CN112306827A (zh) | 日志采集装置、方法和计算机可读存储介质 | |
| US10949367B2 (en) | Method for handling kernel service request for interrupt routines in multi-core environment and electronic device thereof | |
| CN112711485A (zh) | 一种消息处理方法和装置 | |
| US7380248B1 (en) | Queue alerts | |
| US11210089B2 (en) | Vector send operation for message-based communication | |
| US20090024998A1 (en) | Initiation of batch jobs in message queuing information systems | |
| Yanacek | Avoiding insurmountable queue backlogs | |
| JP3257484B2 (ja) | コンピュータの通信フロー制御方式，方法および記録媒体 | |
| US20220238027A1 (en) | Application for processing distributed flight data |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050825 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050906 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060110 |