JP3788697B2 - メッセージ制御装置 - Google Patents
メッセージ制御装置 Download PDFInfo
- Publication number
- JP3788697B2 JP3788697B2 JP32836098A JP32836098A JP3788697B2 JP 3788697 B2 JP3788697 B2 JP 3788697B2 JP 32836098 A JP32836098 A JP 32836098A JP 32836098 A JP32836098 A JP 32836098A JP 3788697 B2 JP3788697 B2 JP 3788697B2
- Authority
- JP
- Japan
- Prior art keywords
- message
- thread
- control unit
- target object
- request
- 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.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/548—Queue
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明はメッセージ制御装置に関し、特に異なるプロセスに属するオブジェクト間でメッセージを授受するメッセージ制御装置に関するものである。
【０００２】
オブジェクト指向技術を用いたシステムにおいては、異なるプロセスに属するオブジェクト間の通信はプロセス間のメッセージ（例えばリクエストメッセージ）転送で行われる。各プロセスは、メッセージを転送する順序の変更及び転送するための負荷の調整等を行うことが要求されている。
【０００３】
【従来の技術】
図20は、従来のメッセージ制御装置100の構成例(1)を示しており、このメッセージ制御装置100は、リクエストメッセージ（以後、リクエストと略称することがある）700を受信するメッセージ受信部200、リクエスト700の宛先であるターゲットオブジェクトTO_1〜TO_3と共にプロセスを構成している。
【０００４】
メッセージ制御装置100は、メッセージ受信部200に接続されたメッセージ分配部300及びターゲットオブジェクトTO_1〜TO_3にそれぞれ対応したキューバッファ431〜433で構成され、キューバッファ431〜433からターゲットオブジェクトTO_1〜TO_3へそれぞれスレッド500_1〜500_3（符号500で総称することがある）が与えられるようになっている。
【０００５】
動作において、▲１▼メッセージ受信部200は受信したリクエスト700をメッセージ分配分部300に送る。▲２▼メッセージ分配部300は、順次受信したリクエスト700を、リクエストR1，R2，R3，R9、リクエストR4，R5、及びリクエストR6，R7，R8として、その宛先のターゲットオブジェクトTO_1〜TO_3に対応したキューバッファ431〜433に分配する。▲３▼ターゲットオブジェクトTO_1〜TO_3は、一定時間毎にキューバッファ431〜433をそれぞれポーリングして、バッファリングされているリクエストがあれば１つのスレッドを作成して一つずつ取り出し実行する。
【０００６】
すなわち、各ターゲットオブジェクトTO_1〜TO_3は、リクエスト700の重要性、優先度に関わらず常にキューバッファ431〜433で先入れ先出しされたリクエスト700を取り出し処理する。
【０００７】
従って、リクエストR1，R2，R3が第１の送信元のプロセスから受信したリクエストであり、リクエストR9が第２の送信元のプロセスからのリクエストである場合で、第２のプロセスの優先度が第１のプロセスより高い場合においても、ターゲットオブジェクトTO_1はリクエストR1，R2，R3を処理した後でなければリクエストR9を処理することができない。
【０００８】
また、リクエストR3がリクエストR1，R2より即応性が求められる重要なリクエストである場合でも、リクエストR1，R2が順次処理された後でなければ処理されず、待ち時間が多くなる。
【０００９】
図21は、上記の問題を解決する従来のメッセージ制御装置100の構成例(2)を示しており、この構成例ではキューバッファ431〜433が無く、メッセージ分配部300がターゲットオブジェクトTO_1，TO_2に対して複数のスレッド500_1〜500_3及びスレッド500_4〜500_6を与えるようになっている点が上記の構成例と異なっている。
【００１０】
動作において、1)メッセージ受信部200は受信したリクエスト700をメッセージ分配部300に送る。2)メッセージ分配部300は、リクエスト700であるリクエストGet1，Set1，Get2毎にスレッド500_1〜500_3をその宛先のターゲットオブジェクト T0_1との間に作成する。ターゲットオブジェクトTO_1においては、Get処理部610がリクエストGet1，Get2を同時に処理し、Set処理部620がリクエストSet1を処理する。
【００１１】
同様に、メッセージ分配部300は、ターゲットオブジェクトTO_2向けのリクエスト701〜703毎にスレッド500_4〜500_6を作成し、ターゲットオブジェクトTO_2はリクエスト701〜703を同時に処理する。
【００１２】
従って、このようなメッセージ制御装置100においては、図20の従来例におけるキューバッファによる待ち時間は無くなる。
【００１３】
【発明が解決しようとする課題】
しかしながら、全てのリクエスト700に対してスレッド500を作成するため、同時に作成されるスレッドの数が多くなり、プロセスにおけるオーバヘッドを増加させて、システム全体の処理速度が遅くなるという課題があった。
【００１４】
従って本発明は、異なるプロセスに属するオブジェクト間でメッセージを授受するメッセージ制御装置において、システム全体の処理速度を早めることを課題とする。
【００１５】
【課題を解決するための手段】
【００１６】
図１は、本発明のメッセージ制御装置100の一例としての原理(1)を示しており、このメッセージ制御装置100は、一つのプロセス内のターゲットオブジェクトTO_1，TO_2に対応したキューバッファ431，432と、他のプロセスからのメッセージ700を受信するメッセージ受信部200からメッセージ700が与えられ、このメッセージ700を宛先の例えば該ターゲットオブジェクトTO_1に対応した該キューバッファ431に分配するメッセージ分配部300と、キューバッファ431からメッセージ700を取り出し作成したスレッド500_1を介してターゲットオブジェクトTO_1に送るスレッド制御部（図示せず）とで構成されている。このスレッド制御部はターゲットオブジェクトTO_1，TO_2に対応して設けられている。
【００１７】
さらに、メッセージ制御装置100はスレッド管理テーブル460を含み、このスレッド管理テーブル460は最大スレッド割当数部461と処理メッセージ数部462から成っている。最大スレッド割当数部461にはメッセージ制御装置100のスレッド制御部が作成することができる最大のスレッド数、すなわち、１つのプロセス内で同時に処理することができるメッセージ数が予め設定され、処理メッセージ数部462には現在処理されているメッセージ数、すなわち、現在作成されているスレッド数が設定される。
【００１８】
動作において、メッセージ分配部300は、例えばターゲットオブジェクトTO_1宛のメッセージ700をメッセージ受信部200から受け、このメッセージ700をキューバッファ431に分配する。キューバッファ431はメッセージ700を保持する。スレッド制御部は、1)キューバッファ431に保持されたメッセージ700を到着順に取り出してスレッド500_1を作成し、ターゲットオブジェクトTO_1に与える。
【００１９】
このとき、スレッド制御部は、処理メッセージ数部462を“１”だけインクリメントし、メッセージ700がターゲットオブジェクトTO_1に受信されたとき処理メッセージ数を“１”だけデクリメントする。同様に、ターゲットオブジェクトTO_2に対応したスレッド制御部も処理メッセージ数部462をインクリメント又はデクリメントする。
【００２０】
▲２▼現在の処理メッセージ数部462の値≧最大スレッド割当数部461の値であるとき、全スレッド制御部はメッセージを取り出さずスレッドを作成しない待機状態になる。
【００２１】
この結果、メッセージ制御装置100内で処理されるメッセージ数を制限することができ、プロセスのCPUが過大スレッドを負荷としたことによるオーバヘッドになることを減らしてシステム処理効率を上げることが可能になる。
【００２２】
請求項１に係る本発明においては、ターゲットオブジェクト毎且つ送信元プロセス毎に設定した優先レベル毎に設けられたキューバッファと、メッセージを該ターゲットオブジェクトに応じて該キューバッファに分配するメッセージ分配部と、該キューバッファから該メッセージを取り出して対応する該ターゲットオブジェクトに与えるべき複数のスレッドを同時に作成するスレッド制御部とを備え、該スレッド制御部は、該ターゲットオブジェクトに該メッセージを与えることができる最大スレッド割当数及び現在の処理メッセージ数を各ターゲットオブジェクト毎に管理するスレッド管理テーブルと、該優先レベルの高いメッセージのみに該複数のスレッドの一部を割り当てた第１のスレッド部及びそれ以外のスレッドを割り当てた第２のスレッド部とを有し、該第２のスレッド部に空きがないとき、該優先レベルの高いメッセージのみを該第１のスレッド部に与え、さらに該第１のスレッド部及び該第２のスレッド部に与えられる処理メッセージ数の合計が該最大スレッド割当数を越えたとき、対応するターゲットオブジェクトの該メッセージの取り出しを待機させることを特徴としている。
【００２３】
図２は、本発明のメッセージ制御装置100の原理(2)を示しており、この装置100の基本的な構成は原理(1)と同じであるが、スレッド管理テーブル460の代わりにスレッド管理テーブル460_1及び460_2がスレッド制御部毎に設けられている点が異なっている。また、スレッド管理テーブル460_1及び460_2には、各スレッド制御部が作成可能な最大のスレッド割当数部461_1，461_2（符号461で総称することがある）と処理している現在のメッセージ数部462_1，462_2（符号462で総称することがある）とが設定されるようになっている。
また、図４は、本発明のメッセージ制御装置 100 の原理 (4) を示しており、同図には、上述した例えばターゲットオブジェクト TO_1 に対応したスレッド制御部が作成できる最大スレッド割当数部 461 に予め設定された割当数 11 個のスレッドから成るスレッド部 500 が示されている。この例ではスレッド部 500 は、優先レベルが高いメッセージに対して４個の確保されたスレッドが第１のスレッド部 510 として設定されおり、残りの７個の通常のスレッドが第２のスレッド部 520 として設定されている。
【００２４】
動作においては、図２に示すように、各スレッド制御部は、メッセージ700を取り出してスレッド500を作成する毎に対応する処理メッセージ数を“１”だけインクリメントし、メッセージがターゲットオブジェクトTOに与えられる毎に“１”だけデクリメントする。
また、図４に示すように、スレッド制御部は、処理メッセージ数が第２のスレッド部 520 のスレッド割当数に達していないとき、メッセージ 700 をその優先レベルに関わりなく、通常スレッドを作成してターゲットオブジェクト TO に与える。そして、処理メッセージ数が第２のスレッド部 520 のスレッド割当数に達したとき、優先レベルの高いメッセージのみを取り出しスレッドを第１のスレッド部 510 で作成してターゲットオブジェクト TO に与える。
そして、さらに、第１のスレッド部 510 の処理メッセージ数が第１のスレッド部 510 のスレッド割当数に達したとき、すなわち、処理メッセージ数部462の値≧最大スレッド割当数部461の値のときには、待機状態になる。
【００２５】
この結果、図１の場合と同様に、プロセスのCPUが過大スレッドを負荷としたことによるオーバヘッドを減らして処理効率を上げることが可能になると共に、優先レベルの高い送信元プロセスからのメッセージ 700 を、優先してターゲットオブジェクトに与えることが可能になる。
【００２６】
また、請求項２に係る本発明においては、さらに、該プロセスにおけるCPUの稼働率に対応する該最大スレッド割当数を保持するスレッド割当管理テーブルを含むスレッド割当制御部を有し、該スレッド割当制御部が、一定時間毎に該CPU稼働率を監視し、該スレッド割当管理テーブル中の該CPU稼働率に対応した該最大スレッド割当数を該スレッド管理テーブルの該最大スレッド割当数として指定することができる。
【００２７】
図３は本発明のメッセージ制御装置100の原理(3)を示しており、この装置100の基本的な構成は、図１又は図２で示した構成と同じであるが、さらに、スレッド割当制御部470が付加されていることが異なっている。
【００２８】
スレッド割当制御部470はスレッド割当管理テーブル471を有し、このテーブル471にはプロセスにおけるCPUの稼働率480に対応した該最大スレッド割当数部461が予め設定されている。
【００２９】
動作においては、スレッド割当制御部470は、一定時間毎に該CPU稼働率480を監視し、スレッド割当管理テーブル471中の該CPU稼働率480に対応した該最大スレッド割当数を上述した該スレッド管理テーブル460中の該最大スレッド割当数部461の値として指定する。各スレッド制御部は、処理メッセージ数部462の値≧最大スレッド割当数部461の値のとき待機状態になる。
【００３０】
すなわち、スレッド割当制御部470が、スレッド割当管理テーブル471を参照して該CPU稼働率から最大スレッド割当数を求めて、これを該スレッド管理テーブル460中の該最大スレッド割当数部461に割り当てることにより、システムの負荷状態に合わせてメッセージ制御装置100の負荷を調整することが可能となる。この結果、プロセスのCPUが過大スレッドを負荷としたことによるオーバヘッドを減らして処理効率を上げることができる。
【００３１】
また、請求項３に係る本発明においては、該キューバッファ及びスレッド制御部を管理するメッセージ管理部を備え、該メッセージ管理部が、一定時間毎に該処理メッセージ数をチェックし、該処理メッセージ数の少ない該スレッド管理テーブルの該最大スレッド割当数の一部を、該処理メッセージ数が多い別のターゲットオブジェクトの該スレッド管理テーブルの該最大スレッド割当数に割り振ることが可能である。
【００３２】
すなわち、該メッセージ管理部が、各スレッド管理テーブルの処理メッセージ数／最大スレッド割当数を求め、これを各スレッド制御部の稼働率とする。そして、この稼働率の低いスレッド制御部の最大スレッド割当数の一部を稼働率の高いスレッド制御部の最大スレッド割当数に割り振る。
【００３３】
この結果、スレッド制御部の最大スレッド割当数は、稼働率が高いほど大きくなり、メッセージ制御装置100の処理効率を上げることができる。
【００３８】
また、請求項４に係る本発明においては、送信元プロセス毎に優先レベルが設定されており、また該キューバッファが該優先レベル毎に設けられており、該スレッド制御部が、該優先レベルの高い方のキューバッファから優先して該メッセージを取り出すことができる。
【００３９】
まず、該送信元プロセス毎に優先レベルが設定する。すなわち、各プロセスからのメッセージには、対応した優先レベルが設定される。さらに、この優先レベルに対応してキューバッファが設けられている。
【００４０】
スレッド制御部は、優先レベルの高いキューバッファから優先してメッセージを取り出しスレッドを作成しターゲットオブジェクトに与える。
【００４１】
この結果、優先レベルの高い送信元プロセスからのメッセージを優先して処理することが可能となる。
【００４２】
また、請求項５に係る本発明においては、さらに、該キューバッファを送信元プロセス毎に設けることができる。
【００４３】
図５は、本発明のメッセージ制御装置100の原理(5)を示しており、同図には図１に示したキューバッファ431及びターゲットオブジェクトTO_1のみが示されている。キューバッファ431は、例えば送信元プロセス1〜nにそれぞれ対応したキューバッファ431_1〜431_nが設定されている。
【００４４】
動作において、メッセージ分配部300が（図１参照）、受信したメッセージを送信元のプロセス1〜n毎に対応したキューバッファ431_1〜431_nに分配する。スレッド制御部（図示せず）は、キューバッファ431_1〜431_nから順次メッセージ700を取り出しスレッド500を作成してターゲットオブジェクトTOに与える。
【００４５】
この結果、各プロセスからのメッセージ700を均等にターゲットオブジェクトTOに送ることが可能となる。
【００４６】
また、請求項６に係る本発明においては、該メッセージに含まれるオペレーション毎に優先レベルが設定されており、該オペレーションの優先レベル順に該メッセージを並び換えるメッセージソート制御部をさらに設けることができる。
【００４７】
図６は、本発明のメッセージ制御装置100の原理(6)を示している。同図(1)は、メッセージ700が含む情報を示しており、この情報はメッセージ名R、キューバッファ431に到着した順序ｘ、オペレーション名Ｏ及びその優先レベルｐから成っている。
【００４８】
同図(2)は、キューバッファ431に保持されている並び換え前の到着順のメッセージ(R1〜R6）700を示しており、各メッセージR1〜R6のオペレーションＯは、“G”，“A”，“S”，“P”，“B”，“S”であり、その優先レベルは、“3”，“1”，“3”，“2”，“2”，“3”である。
【００４９】
動作において、メッセージソート制御部（図示せず）は、優先レベルに従って同図(2)に示したメッセージR1，R2，R3，R4，R5，R6の順序をオペレーションの優先レベルPに従ってソートし、同図(3)に示すようにオペレ−ション/優先レベルA1，P2，B2，G3，S3，S3の順に並び換える。すなわち、メッセージは、メッセージR2，R4，R5，R1，R3，R6の順になる。
【００５０】
この結果、優先レベルの高いオペレーションを含むメッセージを優先してターゲットオブジェクトTOに与えることになる。
【００５１】
また、請求項７に係る本発明においては、該メッセージにタイムスタンプを付与し、該スレッド制御部が、該タイムスタンプが一定時間以上経過した該メッセージを優先して引き出すことができる。
【００５２】
図７は、本発明のメッセージ制御装置100の原理(7)を示している。同図(1)はメッセージ700が含む情報を示しており、この情報はメッセージ名R、到着順ｘ及びタイムスタンプTcから成っている。同図(2)は、キューバッファ431が保持するメッセージR20，R12，R13，R8，R15，R2を示している。これらのメッセージR20，R12，R13、R8，R15，R2のタイムスタンプTcの値“4”，“10”，“9”，“13”，“7”，“21”は、メッセージ700がスレッド500を介してキューバッファ431からターゲットオブジェクトTOに与えられた後、“１”だけカウントアップされた値を示している。
【００５３】
動作において、メッセージソート制御部（図示せず）は、メッセージR2のタイムスタンプTc＝21が予め設定された値“20”を越えていることを検出して、同図(3)で示すようにメッセージR2をキューバッファ431の先頭に割り込ませ、メッセージR2を最優先でターゲットオブジェクトTOに送るようにする。この結果、メッセージが少なくとも一定時間内に取り出されることになる。
【００５４】
また、請求項８に係る本発明においては、各プロセスに排他制御フラグが割り当てられており、また該メッセージが排他制御情報を有しており、該スレッド制御部は、取り出した該メッセージの該制御情報が設定されているとき、該排他制御フラグを設定し、該排他制御フラグが設定されているとき、全てのスレッド制御部は該排他制御情報が設定された該メッセージのみ取り出すことが可能である。
【００５５】
すなわち、プロセス内に排他制御フラグが設けられ、またメッセージが排他制御情報を有している。スレッド制御部は、排他制御情報が設定されているメッセージを取り出したとき、スレッドを作成してメッセージをターゲットオブジェクトに与えると共に、排他制御フラグを設定する。
【００５６】
この排他制御フラグが設定されている間、全てのスレッド制御部は排他制御情報が設定されているメッセージのみを取り出し他のメッセージは取り出さない。排他制御フラグは、排他制御情報が設定されており現在、スレッドが作成されている全てのメッセージが対応するターゲットオブジェクトで処理されたとき、その設定が解除される。
【００５７】
この結果、該排他制御フラグが設定された特定のメッセージを優先して取り出しターゲットオブジェクトに与えることが可能となる。
【００５８】
また、請求項９に係る本発明においては、該メッセージとしてリクエストメッセージを用いることができる。
【００５９】
さらに、請求項10に係る本発明においては、該送信元プロセスが送信元オブジェクトであってもよい。
【００６０】
【発明の実施の形態】
図８は、本発明に係るメッセージ制御装置100の実施例(1)を示しており、この実施例では、メッセージ制御装置100は、ターゲットオブジェクト別メッセージ分配部（以後、TO別メッセージ分配部と略称する）310と、このTO別メッセージ分配部310に接続されターゲットオブジェクトTO_1〜TO_3にリクエストメッセージ700を与えるメッセージ管理部400とで構成されている。なお、以下の説明ではメッセージとしてリクエストメッセージを一例として取り挙げるが、これに限定されず他の種々のメッセージも適用可能である。
【００６１】
メッセージ管理部400は、ターゲットオブジェクトTO_1〜TO_3に対応したユーザ別メッセージ分配部410_1〜410_3（符号410で総称することがある）、これらの分配部410_1〜410_3に接続されたメッセージソート制御部420_1〜420_3（符号420で総称することがある）、これらの制御部420_1〜420_3に接続されたキューバッファ431〜433、及びこれらのバッファ431〜433に接続されたスレッド制御部440_1〜440_3（符号440で総称することがある）で構成されている。
【００６２】
そして、ユーザ別メッセージ分配部410_1〜410_3はTO別メッセージ分配部310に共通接続され、スレッド制御部440_1〜440_3はそれぞれターゲットオブジェクトTO_1〜TO_3に接続されている。また、キューバッファ431〜433はそれぞれユーザ別キューバッファ431_1〜431_4、432_1〜432_4、及び433_1〜433_4で構成されている。スレッド制御部440_1〜440_3には、最大スレッド割当数部461及び処理メッセージ数部462からなるスレッド管理テーブル460（図２参照）が含まれており、図８には処理メッセージ数462のみが処理メッセージ数カウンタ462として例示されている。
【００６３】
動作において、TO別メッセージ分配部310は、受信したリクエスト700をその宛先のターゲットオブジェクトTO_1〜TO_3に対応したユーザ別メッセージ分配部410に分配する。ユーザ別メッセージ分配部410は、メッセージソート制御部420を介してリクエスト700を送信元のユーザ（プロセス、オブジェクト等）毎に分配して例えばキューバッファ431ではユーザ別キューバッファ431_1〜431_4に与える。
【００６４】
そして、例えばスレッド制御部440_1は、キューバッファ431_1〜431_4にバッファリングされているリクエスト700を順次取り出しスレッド500を作成してターゲットオブジェクトTO_1に送ると共に、リクエスト700を取り出す毎に処理メッセージ数カウンタ462を“１”だけインクリメントする。処理メッセージ数カウンタ462の値≧最大スレッド割当数のとき、スレッド制御部440_1は待機状態となりリクエスト700の取り出しを停止する。
【００６５】
ターゲットオブジェクトTO_1は受信した複数のリクエスト700を同時に処理し、１つのリクエスト700の処理が終了したとき、これをスレッド制御部440_1に通知する。スレッド制御部440_1は、処理メッセージ数カウンタ462を“１”だけデクリメントし、処理メッセージ数カウンタ462の値＜最大スレッド割当数部461の値のとき、リクエスト700の取り出しを再開する。
【００６６】
この結果、過大なスレッドを作成してCPUをオーバヘッド状態にせずにシステム全体の処理速度を遅くすることなくメッセージの授受を行うことが可能となると共に、各プロセス（ユーザ）からのメッセージ700を均等にターゲットオブジェクトTOに送ることが可能となる。
【００６７】
なお、この実施例においては、各スレッド制御部440が、それぞれ最大スレッド割当数及び処理メッセージ数から成るスレッド管理テーブル460を備え、最大スレッド割当数と処理メッセージ数カウンタ462の値とを比較してリクエスト700の取り出しを待機するか否かを判定したが、これとは異なり、プロセス全体に対して１つのスレッド管理テーブル460を設け、スレッド制御部440が１つのリクエスト700を取り出す毎に処理メッセージ数カウンタ462を“１”だけインクリメントし、処理メッセージ数カウンタ462の値≧最大スレッド割当数部461の値のとき全てのスレッド制御部440がリクエスト700の取り出しを停止して待機状態にしても同様の効果が得られる。
【００６８】
図９は、図８の実施例(1)におけるキューバッファ431_1〜431_3、スレッド制御部440及びターゲットオブジェクトTO_1の動作をより詳細に示したものである。ターゲットオブジェクトTO_1を宛先とするリクエストR1(Get)，R2(Set)，R3(Act)、リクエストR4(Del)，R5(Trm)，R7(Set)，R9(Del)、及びリクエストR6(Get)，R8(Get)が、ユーザ別メッセージ分配部410_1（同図参照）で送信元であるユーザ１〜３別に分配され、ユーザ１用キューバッファ431_1〜ユーザ３用キューバッファ431_3にバッファリングされている。なお、リクエストR1〜R9の添数字はリクエストの入力順番を示している（以下同様）。
【００６９】
図10は、図８及び図９に示したスレッド制御部440の動作手順例(1)を示しており、図９を参照して以下にスレッド制御部440の動作を説明する。まず、スレッド制御部440は、リクエストを取り出すキューバッファのユーザ番号をｉ＝１に設定し（ステップS10）、リクエストがあるか否かを判定する（同S11）。リクエストが無い場合、ステップS13に進むが、リクエストR1があるので、▲１▼キューバッファ431_1からリクエストR1を取り出し（同S12）、スレッドを作成してターゲットオブジェクトTO_1に与えた後、ステップS13に進む。
【００７０】
ステップS13において、スレッド制御部440は、ｉを１だけインクリメントし、このｉ（＝２）＞ｎ（ｎ：ユーザ数“３”）であるか否かを判定する。ｉ≦３であるので、ステップS10に戻り、キューバッファのユーザ番号をｉ＝２に設定し、リクエストR4が有るので（同S11）、▲２▼キューバッファ430_2からリクエストR4を取り出し、スレッドを作成してターゲットオブジェクトTO_1に与える（同S12)。
【００７１】
以下同様にして、ステップS13，S10，S11を経由して、▲３▼キューバッファ431_3からリクエストR6を取り出し、スレッドを作成してターゲットオブジェクトTO_1に与え（同S12）、ステップS13に進む。ステップS13において、ｉを“１”だけインクリメントするとｉ＝“４”となり、ｉ＞３となる。そこで、ｉ＝１に戻してステップS10に戻る。
【００７２】
以後同様の動作を繰り返して、スレッド制御部440は、キューバッファ431_1〜431_3から順次、リクエストR2，R5，R8，R3，R7，R9を取り出してターゲットオブジェクトTO_1に与える。
【００７３】
この手順によれば、リクエストは送信元のユーザに関して均等に処理される。従って、キューバッファをユーザ別に分けない場合と比較して、ユーザ当たりのリクエストの待ち時間が短縮されることになる。
【００７４】
図11は、本発明のメッセージ制御装置100の実施例(2)を示している。この実施例では複数のネットワーク制御システムをネットワーク管理システムが管理するネットワーク監視制御システムにおける情報管理例を示しており、特にネットワーク管理システムにおけるメッセージ制御装置が、短時間に多数のリクエストを複数のネットワーク制御システムから送信元プロセスを構成する上位制御オブジェクトSO_1〜SO_3を介して受信した場合を示している。
【００７５】
メッセージ制御装置100は、図８に示した実施例(1)の構成要素にさらにCPUの稼働率480を入力しスレッド割当管理テーブル471（図３参照）を有するスレッド割当制御部470を備えている。
【００７６】
動作において、上位制御オブジェクトSO_1〜SO_3からのリクエストR10，R12、リクエストR11，R19、及びリクエストR1，R3，R4，R8，R15は、メッセージ分配部300（図３参照）で分配され、それぞれキューバッファ431〜433にバッファリングされる。スレッド割当制御部470は、▲１▼現在のCPUの稼働率、例えば80％を入力し、スレッド割当管理テーブル471を参照して機能オブジェクトであるターゲットオブジェクトTO_1〜TO_3の最大スレッド割当数“２”，“２”，“２”を得る（図３参照）。▲２▼この割当数“２”，“２”，“２”をスレッド割当制御部470は、スレッド制御部440（図８参照）のスレッド管理テーブル460の最大スレッド割当数（図２参照）とする。
【００７７】
スレッド制御部440_1〜440_3は、それぞれ最大スレッド割当数“２”，“２”，“２”のスレッド500を作成して、リクエストR10，R12、リクエストR11，R19、及びリクエストR1，R3をターゲットオブジェクトTO_1，TO_2，及びTO_3に与える。そして、例えばスレッド制御部440_3は、キューバッファ433がリクエストR4，R8，R15をバッファリングしているにも関わらず最大スレッド割当数“２”以上のスレッドを作成してリクエストR4，R8，R15を取り出さない。
【００７８】
一定時間後、スレッド割当制御部470は、▲１▼例えばCPU稼働率“20％”を入力すると、スレッド割当管理テーブル471からターゲットオブジェクトTO_1〜TO_3の最大スレッド割当数“12”，“9”，“8”を得て（図３参照）、▲２▼スレッド制御部440_1〜440_3（図８参照）の最大スレッド割当数とする。
【００７９】
最大スレッド割当数が“８”となったスレッド制御部440_3は、さらにリクエストR4，R8，R15を取り出し、スレッド500を作成してターゲットオブジェクトTO_3に与えることが可能となる。
【００８０】
すなわち、CPUの稼働率に対応した数のスレッドを作成することにより、CPUが過大なスレッド処理の負荷によりオーバヘッドすることなしに全体の処理を早め、リクエストの転送速度を上げることが可能となる。
【００８１】
図12は、本発明のメッセージ制御装置におけるメッセージ管理部400の動作手順例を示している。以下に、図８を参照してメッセージ管理部400の動作を説明する。但し、ユーザはｎ、すなわちターゲットオブジェクトTO_1〜TO_n、スレッド制御部440_1〜440_n等として説明する。
【００８２】
メッセージ管理部400は、ｉを初期値“０”に設定した後、各ターゲットオブジェクトTOに対応したスレッド管理テーブル460_1〜460_n（図２参照）の最大スレッド割当数及び処理メッセージ数（図12の処理メッセージ数カウンタ462の値）を読み出し、各ターゲットオブジェクトTO_1〜TO_nの稼働率OR＝処理メッセージ数/最大スレッド割当数を演算で昇順（小→大）にソートをする（ステップS20）。稼働率ORは、ソートされた昇順にOR_1〜OR_ｎとする。
【００８３】
そして、メッセージ管理部400は、ステップS21でｉを“１”だけインクリメントした後、ステップS22に進み、ｉ＜ｎ（ｎ：ターゲットオブジェクト数＋１）であるか否かを判定し、ｉ≧ｎであるとき動作を終了する。初回は、ｉ（＝１）＜ｎであるので、ステップS23に進み、最も小さい稼働率OR_1／最も大きい稼働率OR_n-1を演算し、演算結果が一定の値“α”以上でないとき、ステップS24に進む。
【００８４】
ステップS24において、稼働率OR_1及びOR_n-1に対応するターゲットオブジェクトが例えばそれぞれターゲットオブジェクトTO_1及びTO_3であるとしたとき、ターゲットオブジェクトTO_1の未だ使われていない未使用スレッド数の２分の１をターゲットオブジェクトTO_3の最大スレッド割当数に割り振り、ステップS21に戻る。
【００８５】
以下同様にして、OR_i/OR_(n-i)＞αのとき、稼働率の少ないターゲットオブジェクトの未使用スレッド数の２分の１を稼働率の大きいターゲットオブジェクトの最大スレッド割当数に割り振る処理を実行する。
【００８６】
この結果、ターゲットオブジェクトに割り当てられた、すなわちスレッド作成部に割り当てられた最大スレッド割当数を動的に稼働率の高いターゲットオブジェクトに割り振ることになり、メッセージ制御装置内で限られた数のスレッドを効率的に使うことが可能となる。
【００８７】
図13は、本発明のメッセージ制御装置100の実施例(3)を示しており、この実施例は図11に示した実施例(2)と同様に複数のネットワーク制御システムからリクエストを受信するメッセージ制御装置100を示している。
【００８８】
メッセージ制御装置100は、各ネットワーク制御システムに含まれる上位制御オブジェクトSO_1〜SO_5からのリクエストをバッファリングして、機能オブジェクトであるターゲットオブジェクトTO_1に与えるキューバッファ430を含んでいる。上位制御オブジェクトSO_1〜SO_5の中の特にオブジェクトSO_1及びSO_2には、ユーザレベル１が設定され、他のオブジェクトSO_3〜SO_5にはユーザレベル２が設定されている。
【００８９】
キューバッファ430は、オブジェクトSO_1〜SO_5からのリクエストをバッファリングするキューバッファ431_1〜431_5から成り、各オブジェクトSO_1〜SO_5のユーザレベルに対応してキューバッファ431_1及び431_2がユーザレベル１用キューバッファ部430_1を構成し、キューバッファ431_3〜431_5がユーザレベル２用キューバッファ部430_2を構成している。
【００９０】
また、ターゲットオブジェクトTO_1には、処理可能なリクエスト数としてユーザレベル１用に３つ及びユーザレベル２用に７つが設定されているものとする。そして、キューバッファ431_1〜431_5は、それぞれリクエストR10，R12、リクエストR11，R19、リクエストR1，R3，R4，R8，R15、リクエストR2，R6，R7，R9，R16、リクエストR5，R13，R14，R17，R18をバッファリングしている。
【００９１】
図14は、起動時にメッセージ管理部400が読み込む定義ファイル例を示している。同図(1)のファイルには、ユーザとそのユーザレベルが示されており、ユーザである“Administrator”、“amelio”、“atari”、“okonomy”、“sussy”、“sundo”、…にそれぞれユーザレベル“1”、“2”、“2”、“2”、“2”、“2”、…が設定されている。
【００９２】
同図(2)のファイルには、リクエスト名とその優先レベル及び排他制御情報が示されており、例えば、リクエスト名が“Create”及び“Back_Up”の優先レベル及び排他制御情報は、それぞれ“２”、“１”及び“OFF”、“ON”である。
【００９３】
図15は、スレッド制御部440の動作例(1)を示しており、この動作例ではメッセージ管理部400（図８参照）が図14に示したファイルのデータを読み込んでいる状態であり、このデータをスレッド制御部440は参照する。また、スレッド制御部440は、ターゲットオブジェクトTO_1が同時に処理可能なリクエスト数（同時リクエスト数）として上述したようにユーザレベル１用に３つ及びユーザレベル２用に７つが設定されていることを、後述する同時リクエスト数D1＝３、D2＝７として知っているものとする。
【００９４】
図16は、図15に示したスレッド制御部440の動作手順例(2)を示している。この手順例を概念的に述べると、まずスレッド制御部440はユーザレベルの高いキューバッファから順次リクエストを取り出しスレッドを作成してターゲットオブジェクトTO_1に送り、作成したスレッド数がターゲットオブジェクトTO_1が同時に処理できるユーザレベルの高いリクエストの最大数＝“３”に達したとき、リクエストの取り出しを停止状態にする。そして、次にユーザレベルの高いキューバッファ430_1からのリクエストの取り出し動作に移行する。
【００９５】
これを更に詳しく図15を参照して説明する。スレッド制御部440は、ステップS30でｉを“０”に初期設定してステップS31に進み、ｉを“１”だけインクリメントし、リクエスト数Pi＝P1を“０”に初期設定する。なお、リクエスト数Piはユーザレベルｉのキューバッファから取り出したリクエスト数である。
【００９６】
ステップS32でスレッド制御部440は、同時リクエスト数D1＝３とリクエスト数P1を比較し、D1＞P1であるのでステップS33に進む。ユーザレベル１のキューバッファ431_1にリクエストR10（図13参照）が存在するので（ステップS33，S34）、このリクエストR10を取り出しスレッドを作成してターゲットオブジェクトTO_1に送信し（同S35）、リクエスト数P1を“１”だけインクリメントしたP1＝１としてステップS32に戻る。
【００９７】
以後同様にして、スレッド制御部440は、順次キューバッファ431_2及び431_1からリクエストR11及びR12を取り出しスレッドを作成してターゲットオブジェクトTO_1に送信する。ステップS35からS32に戻ったとき、D1（＝３）≦P1（＝３）であるので、ユーザレベル１のリクエストの送信を待機状態にする。そして、ステップS31に戻り、iを“１”だけインクリメントしてｉ＝２とし、P2を“０”に初期設定して、ユーザレベル２のキューバッファ431_3〜431_5からのリクエストの取り出しを開始する。
【００９８】
以下同様にして、スレッド制御部440は、順次、キューバッファ431_3〜431_5から同時リクエスト数D2が指定する７つのリクエストR1，R2，R5，R3，R6，R13，R4（図13参照）取り出しスレッドを作成してターゲットオブジェクトTO_1に送信して、待機状態になる。なお、図16に示した手順には、スレッド制御部440が同一ユーザレベルの複数のキューバッファから、順次リクエストを取り出す手順は省略されている。
【００９９】
この結果、ユーザレベル１及び２用のスレッドがそれぞれ３及び７つ作成され、ターゲットオブジェクトTO_1は合計10のリクエストを同時に処理する形となる。そして、例えば、オブジェクトTO_1が、ユーザレベル１の２つのリクエストの処理を完了すると、図15に示すように、▲１▼ユーザレベル１用の２つのスレッド500_1が待機状態になり、▲２▼ユーザレベル２用のスレッド500_2は全て実行中の状態のままである。
【０１００】
そこで、スレッド制御部440は、▲３▼，▲４▼ユーザレベル１用のキューバッファ430_1からリクエストを取り出しユーザレベル１用のスレッド500_1の空いたスレッドを用いてオブジェクトTO_1に送信することを開始する。このとき、キューバッファ430_1にバッファリングされているリクエストが無い場合、スレッド制御部440は、▲５▼ユーザレベル２用のキューバッファ430_2からリクエストを取り出しユーザレベル１用のスレッド500_1を用いて送信することはない。ただし、キューバッファ430_1にバッファリングされているリクエストがあって、スレッド500_2に待機状態を含む場合には、スレッド制御部440は、キューバッファ430_1のリクエストをスレッド500_2に与えスレッドの作成を行うことができる。
【０１０１】
この結果、スレッド制御部440は、ユーザレベルの高い順にリクエストをターゲットオブジェクトに与えるともに、同じユーザレベルのリクエストはユーザの別なく均等に処理することが可能となる。
【０１０２】
図17は、メッセージソート制御部420（図８参照）の動作例を示しており、この動作例においても、起動時にメッセージ管理部400（図８参照）は、図14に示したユーザレベル及び優先レベル定義データを読み込んでいるものとする。
【０１０３】
同図(1)のキューバッファ431_1には、リクエストR1，R2，…，R4がこの順で待ち状態になっている。リクエストR1〜R4のオペレーション名は、それぞれ“Create”、“Set”、“Get”及び“Terminate”であり、これらのオペレーションの優先レベルは、メッセージ管理部400が読み込んだ図15(2)の優先レベルデータを参照すると“2”、“3”、“3”及び“3”であることを知ることができる。このことを同図中では符号“C2”、“S3”、“G3”及び“T3”でそれぞれ示している。
【０１０４】
この状態で、メッセージソート制御部420はリクエストR5(Create)を受信すると、“Create”の優先レベルが“２”であることを知り、リクエストR2〜R4より優先レベルが高いのでソートを開始し、同図(2)に示すように、リクエストR5をリクエストR1とリクエストR2の間に挿入するように並び換える。この結果、優先レベルの高いオペレーションを含むリクエストが優先してターゲットオブジェクトに与えられることになる。
【０１０５】
図18は、メッセージソート制御部420及びスレッド制御部440（図８参照）の動作例を示している。図17に示したメッセージソート制御部420のソート動作だけでは、優先レベルの高いオペレーションのリクエストが連続して送られてきた場合、これより優先レベルの低いオペレーションを含むリクエストはさらに遅れて送信されることになる。
【０１０６】
そこで、この動作例(2)では、キューバッファにバッファリングされた各リクエストにタイムスタンプ情報を持たせることとする。キューバッファ431_1にバッファリングされたリクエストR20，R12，R13及びR2の現在のタイムスタンプ情報はそれぞれ“4”、“10”、“9”、“20”である。
【０１０７】
スレッド制御部440は、キューバッファ431_1〜431_3の中からリクエストを取り出す毎に各リクエストR20〜R2のタイムスタンプ情報を“１”だけカウントアップし、このタイムスタンプ情報が一定の値、例えば“21”以上になったリクエストを探索する。そして、この例ではスレッド制御部440は、▲１▼リクエストR2を検出し、その優先レベルを強制的に“１”とする。そして、▲２▼メッセージソート制御部420に対してソートを要求する。
【０１０８】
▲３▼メッセージソート制御部420は、優先レベル順にリクエストR20〜R2をソートする。この結果、優先レベルの高いリクエストR2がリクエストR20の前に挿入されることになり、一定時間以上待たされたリクエストR2が優先的にターゲットオブジェクトTO_1に送出されることになる。
【０１０９】
図19は、スレッド制御部440（図８参照）の動作例(2)を示しており、この動作例ではメッセージ管理部400が排他制御フラグ490を有し、各リクエストは排他制御情報を有している。すなわち、スレッド制御部440は、メッセージ管理部400が読み込んだ優先レベル定義情報（図14(2)参照）を参照することにより各リクエストのオペレーヨンに対応した排他制御情報のオン/オフ状態を知ることができる。また、この動作例では、図17で示したようにメッセージソート制御部420は、入力したリクエストをそのオペレージョンの優先レベルに従ってソートするものとする。
【０１１０】
同図において、TO別キューバッファ431には、図17のキューバッファ431_1と同様にリクエストR1(C2)，R2(S3)，R3(G3)，R4(T3)がバッファリングされているものとする。これらのリクエストの優先レベルは、上述したように“2”、“3”、“3”及び“3”であり、排他制御情報は全て“オフ”（図14(2)参照）ある。
【０１１１】
例えば、メッセージソート制御部420にリクエストR5(Back_Up）入力されと、メッセージソート制御部420は、リクエストR5の優先レベルが“１”であることを知り（図14(2)参照）、リクエストR5をリクエストR1の前に挿入するようにソートする。
【０１１２】
スレッド制御部440_1はリクエストR5を取り出しスレッドを作成して送出する。このとき、リクエストR5のオペレーション“Back_Up”の排他制御情報が“オン”であることを知り（図14(2)参照）、排他制御フラグ490を設定する。この排他制御フラグ490が設定されているとき、全てのスレッド制御部440_1〜440_3は、排他制御情報が設定されているリクエストのみを取り出し送出する。
【０１１３】
この結果、優先レベルの高い特定のリクエストのみを最優先でターゲットオブジェクトに送出することが可能となる。
【０１１４】
【発明の効果】
以上説明したように、本発明に係るメッセージ制御装置によれば、メッセージ分配部がメッセージをターゲットオブジェクト毎且つ送信元プロセス毎に設定した優先レベル毎に設けられたキューバッファに分配し、スレッド制御部が、プロセス又はターゲットオブジェクト毎に予め設定された最大スレッド割当数以下の複数のスレッドを同時に作成して該メッセージを取り出し対応する該ターゲットオブジェクトに与えるように構成したので、システム全体の処理速度を早めることが可能となる。
【０１１５】
また、プロセスのCPU稼働率に対応して該最大スレッド割当数を指定するようにしたこと及び使用スレッド数が少ないターゲットオブジェクトのスレッド割当数の一部を使用スレッド数の多いターゲットオブジェクトの最大スレッド割当数割り振るようにしたことによりCPUが過大スレッドを負荷としたことによるオーバヘッドを減らして処理効率を上げることができる。
【０１１６】
さらに、プロセス毎にレベルを設定すること、メッセージのオペレーション毎に優先レベルを設定すること、又は排他制御フラグを設定することで特定のメッセージを優先してターゲットオブジェクトに与えることが可能となる。
【図面の簡単な説明】
【図１】本発明に係るメッセージ制御装置の原理(1)を示したブロック図である。
【図２】本発明に係るメッセージ制御装置の原理(2)を示したブロック図である。
【図３】本発明に係るメッセージ制御装置の原理(3)を示したブロック図である。
【図４】本発明に係るメッセージ制御装置の原理(4)を示したブロック図である。
【図５】本発明に係るメッセージ制御装置の原理(5)を示したブロック図である。
【図６】本発明に係るメッセージ制御装置の原理(6)を示したブロック図である。
【図７】本発明に係るメッセージ制御装置の原理(7)を示したブロック図である。
【図８】本発明に係るメッセージ制御装置の実施例(1)を示したブロック図である。
【図９】本発明に係るメッセージ制御装置におけるユーザ別リクエストの処理手順を示した図である。
【図１０】本発明に係るメッセージ制御装置におけるスレッド制御部の動作手順例(1)を示したフローチャート図である。
【図１１】本発明に係るメッセージ制御装置の実施例(2)を示したブロック図である。
【図１２】本発明に係るメッセージ制御装置におけるメッセージ管理部の動作手順例を示したフローチャート図である。
【図１３】本発明に係るメッセージ制御装置の実施例(3)を示したブロック図である。
【図１４】本発明に係るメッセージ制御装置で用いられるユーザレベル及び優先レベル定義テーブル例を示した図である。
【図１５】本発明に係るメッセージ制御装置におけるスレッド制御部の動作例(1)を示したブロック図である。
【図１６】本発明に係るメッセージ制御装置におけるスレッド制御部の動作手順例(2)を示したフローチャート図である。
【図１７】本発明に係るメッセージ制御装置におけるメッセージソート制御部の動作例を示したブロック図である。
【図１８】本発明に係るメッセージ制御装置におけるメッセージソート制御部及びスレッド制御部の動作例を示したブロック図である。
【図１９】本発明に係るメッセージ制御装置におけるスレッド制御部の動作例(2)を示したブロック図である。
【図２０】従来のメッセージ制御装置の構成例(1)を示したブロック図である。
【図２１】従来のメッセージ制御装置の構成例(2)を示したブロック図である。
【符号の説明】
100 メッセージ制御装置 200 メッセージ受信部
300 メッセージ分配部 310 TO別メッセージ分配部
400 メッセージ管理部 410，410_i ユーザ別メッセージ分配部
420，420_i メッセージソート制御部
430〜433，430_i〜433_i キューバッファ
440，440_i スレッド制御部 460，460_i スレッド管理テーブル
461，461_i 最大スレッド割当数部
462，462_i 処理メッセージ数部、処理メッセージ数カウンタ
470 スレッド割当制御部 471 スレッド割当管理テーブル
480 CPU稼働率 490 排他制御フラグ
500，500_i，510，520 スレッド
TO，TO_i ターゲットオブジェクト SO_i 制御オブジェクト
610 Get処理部 620 Set処理部
700〜703，R1〜R20 メッセージ，リクエストメッセージ
ｉは正の整数
図中、同一符号は同一又は相当部分を示す。
【発明の属する技術分野】
本発明はメッセージ制御装置に関し、特に異なるプロセスに属するオブジェクト間でメッセージを授受するメッセージ制御装置に関するものである。
【０００２】
オブジェクト指向技術を用いたシステムにおいては、異なるプロセスに属するオブジェクト間の通信はプロセス間のメッセージ（例えばリクエストメッセージ）転送で行われる。各プロセスは、メッセージを転送する順序の変更及び転送するための負荷の調整等を行うことが要求されている。
【０００３】
【従来の技術】
図20は、従来のメッセージ制御装置100の構成例(1)を示しており、このメッセージ制御装置100は、リクエストメッセージ（以後、リクエストと略称することがある）700を受信するメッセージ受信部200、リクエスト700の宛先であるターゲットオブジェクトTO_1〜TO_3と共にプロセスを構成している。
【０００４】
メッセージ制御装置100は、メッセージ受信部200に接続されたメッセージ分配部300及びターゲットオブジェクトTO_1〜TO_3にそれぞれ対応したキューバッファ431〜433で構成され、キューバッファ431〜433からターゲットオブジェクトTO_1〜TO_3へそれぞれスレッド500_1〜500_3（符号500で総称することがある）が与えられるようになっている。
【０００５】
動作において、▲１▼メッセージ受信部200は受信したリクエスト700をメッセージ分配分部300に送る。▲２▼メッセージ分配部300は、順次受信したリクエスト700を、リクエストR1，R2，R3，R9、リクエストR4，R5、及びリクエストR6，R7，R8として、その宛先のターゲットオブジェクトTO_1〜TO_3に対応したキューバッファ431〜433に分配する。▲３▼ターゲットオブジェクトTO_1〜TO_3は、一定時間毎にキューバッファ431〜433をそれぞれポーリングして、バッファリングされているリクエストがあれば１つのスレッドを作成して一つずつ取り出し実行する。
【０００６】
すなわち、各ターゲットオブジェクトTO_1〜TO_3は、リクエスト700の重要性、優先度に関わらず常にキューバッファ431〜433で先入れ先出しされたリクエスト700を取り出し処理する。
【０００７】
従って、リクエストR1，R2，R3が第１の送信元のプロセスから受信したリクエストであり、リクエストR9が第２の送信元のプロセスからのリクエストである場合で、第２のプロセスの優先度が第１のプロセスより高い場合においても、ターゲットオブジェクトTO_1はリクエストR1，R2，R3を処理した後でなければリクエストR9を処理することができない。
【０００８】
また、リクエストR3がリクエストR1，R2より即応性が求められる重要なリクエストである場合でも、リクエストR1，R2が順次処理された後でなければ処理されず、待ち時間が多くなる。
【０００９】
図21は、上記の問題を解決する従来のメッセージ制御装置100の構成例(2)を示しており、この構成例ではキューバッファ431〜433が無く、メッセージ分配部300がターゲットオブジェクトTO_1，TO_2に対して複数のスレッド500_1〜500_3及びスレッド500_4〜500_6を与えるようになっている点が上記の構成例と異なっている。
【００１０】
動作において、1)メッセージ受信部200は受信したリクエスト700をメッセージ分配部300に送る。2)メッセージ分配部300は、リクエスト700であるリクエストGet1，Set1，Get2毎にスレッド500_1〜500_3をその宛先のターゲットオブジェクト T0_1との間に作成する。ターゲットオブジェクトTO_1においては、Get処理部610がリクエストGet1，Get2を同時に処理し、Set処理部620がリクエストSet1を処理する。
【００１１】
同様に、メッセージ分配部300は、ターゲットオブジェクトTO_2向けのリクエスト701〜703毎にスレッド500_4〜500_6を作成し、ターゲットオブジェクトTO_2はリクエスト701〜703を同時に処理する。
【００１２】
従って、このようなメッセージ制御装置100においては、図20の従来例におけるキューバッファによる待ち時間は無くなる。
【００１３】
【発明が解決しようとする課題】
しかしながら、全てのリクエスト700に対してスレッド500を作成するため、同時に作成されるスレッドの数が多くなり、プロセスにおけるオーバヘッドを増加させて、システム全体の処理速度が遅くなるという課題があった。
【００１４】
従って本発明は、異なるプロセスに属するオブジェクト間でメッセージを授受するメッセージ制御装置において、システム全体の処理速度を早めることを課題とする。
【００１５】
【課題を解決するための手段】
【００１６】
図１は、本発明のメッセージ制御装置100の一例としての原理(1)を示しており、このメッセージ制御装置100は、一つのプロセス内のターゲットオブジェクトTO_1，TO_2に対応したキューバッファ431，432と、他のプロセスからのメッセージ700を受信するメッセージ受信部200からメッセージ700が与えられ、このメッセージ700を宛先の例えば該ターゲットオブジェクトTO_1に対応した該キューバッファ431に分配するメッセージ分配部300と、キューバッファ431からメッセージ700を取り出し作成したスレッド500_1を介してターゲットオブジェクトTO_1に送るスレッド制御部（図示せず）とで構成されている。このスレッド制御部はターゲットオブジェクトTO_1，TO_2に対応して設けられている。
【００１７】
さらに、メッセージ制御装置100はスレッド管理テーブル460を含み、このスレッド管理テーブル460は最大スレッド割当数部461と処理メッセージ数部462から成っている。最大スレッド割当数部461にはメッセージ制御装置100のスレッド制御部が作成することができる最大のスレッド数、すなわち、１つのプロセス内で同時に処理することができるメッセージ数が予め設定され、処理メッセージ数部462には現在処理されているメッセージ数、すなわち、現在作成されているスレッド数が設定される。
【００１８】
動作において、メッセージ分配部300は、例えばターゲットオブジェクトTO_1宛のメッセージ700をメッセージ受信部200から受け、このメッセージ700をキューバッファ431に分配する。キューバッファ431はメッセージ700を保持する。スレッド制御部は、1)キューバッファ431に保持されたメッセージ700を到着順に取り出してスレッド500_1を作成し、ターゲットオブジェクトTO_1に与える。
【００１９】
このとき、スレッド制御部は、処理メッセージ数部462を“１”だけインクリメントし、メッセージ700がターゲットオブジェクトTO_1に受信されたとき処理メッセージ数を“１”だけデクリメントする。同様に、ターゲットオブジェクトTO_2に対応したスレッド制御部も処理メッセージ数部462をインクリメント又はデクリメントする。
【００２０】
▲２▼現在の処理メッセージ数部462の値≧最大スレッド割当数部461の値であるとき、全スレッド制御部はメッセージを取り出さずスレッドを作成しない待機状態になる。
【００２１】
この結果、メッセージ制御装置100内で処理されるメッセージ数を制限することができ、プロセスのCPUが過大スレッドを負荷としたことによるオーバヘッドになることを減らしてシステム処理効率を上げることが可能になる。
【００２２】
請求項１に係る本発明においては、ターゲットオブジェクト毎且つ送信元プロセス毎に設定した優先レベル毎に設けられたキューバッファと、メッセージを該ターゲットオブジェクトに応じて該キューバッファに分配するメッセージ分配部と、該キューバッファから該メッセージを取り出して対応する該ターゲットオブジェクトに与えるべき複数のスレッドを同時に作成するスレッド制御部とを備え、該スレッド制御部は、該ターゲットオブジェクトに該メッセージを与えることができる最大スレッド割当数及び現在の処理メッセージ数を各ターゲットオブジェクト毎に管理するスレッド管理テーブルと、該優先レベルの高いメッセージのみに該複数のスレッドの一部を割り当てた第１のスレッド部及びそれ以外のスレッドを割り当てた第２のスレッド部とを有し、該第２のスレッド部に空きがないとき、該優先レベルの高いメッセージのみを該第１のスレッド部に与え、さらに該第１のスレッド部及び該第２のスレッド部に与えられる処理メッセージ数の合計が該最大スレッド割当数を越えたとき、対応するターゲットオブジェクトの該メッセージの取り出しを待機させることを特徴としている。
【００２３】
図２は、本発明のメッセージ制御装置100の原理(2)を示しており、この装置100の基本的な構成は原理(1)と同じであるが、スレッド管理テーブル460の代わりにスレッド管理テーブル460_1及び460_2がスレッド制御部毎に設けられている点が異なっている。また、スレッド管理テーブル460_1及び460_2には、各スレッド制御部が作成可能な最大のスレッド割当数部461_1，461_2（符号461で総称することがある）と処理している現在のメッセージ数部462_1，462_2（符号462で総称することがある）とが設定されるようになっている。
また、図４は、本発明のメッセージ制御装置 100 の原理 (4) を示しており、同図には、上述した例えばターゲットオブジェクト TO_1 に対応したスレッド制御部が作成できる最大スレッド割当数部 461 に予め設定された割当数 11 個のスレッドから成るスレッド部 500 が示されている。この例ではスレッド部 500 は、優先レベルが高いメッセージに対して４個の確保されたスレッドが第１のスレッド部 510 として設定されおり、残りの７個の通常のスレッドが第２のスレッド部 520 として設定されている。
【００２４】
動作においては、図２に示すように、各スレッド制御部は、メッセージ700を取り出してスレッド500を作成する毎に対応する処理メッセージ数を“１”だけインクリメントし、メッセージがターゲットオブジェクトTOに与えられる毎に“１”だけデクリメントする。
また、図４に示すように、スレッド制御部は、処理メッセージ数が第２のスレッド部 520 のスレッド割当数に達していないとき、メッセージ 700 をその優先レベルに関わりなく、通常スレッドを作成してターゲットオブジェクト TO に与える。そして、処理メッセージ数が第２のスレッド部 520 のスレッド割当数に達したとき、優先レベルの高いメッセージのみを取り出しスレッドを第１のスレッド部 510 で作成してターゲットオブジェクト TO に与える。
そして、さらに、第１のスレッド部 510 の処理メッセージ数が第１のスレッド部 510 のスレッド割当数に達したとき、すなわち、処理メッセージ数部462の値≧最大スレッド割当数部461の値のときには、待機状態になる。
【００２５】
この結果、図１の場合と同様に、プロセスのCPUが過大スレッドを負荷としたことによるオーバヘッドを減らして処理効率を上げることが可能になると共に、優先レベルの高い送信元プロセスからのメッセージ 700 を、優先してターゲットオブジェクトに与えることが可能になる。
【００２６】
また、請求項２に係る本発明においては、さらに、該プロセスにおけるCPUの稼働率に対応する該最大スレッド割当数を保持するスレッド割当管理テーブルを含むスレッド割当制御部を有し、該スレッド割当制御部が、一定時間毎に該CPU稼働率を監視し、該スレッド割当管理テーブル中の該CPU稼働率に対応した該最大スレッド割当数を該スレッド管理テーブルの該最大スレッド割当数として指定することができる。
【００２７】
図３は本発明のメッセージ制御装置100の原理(3)を示しており、この装置100の基本的な構成は、図１又は図２で示した構成と同じであるが、さらに、スレッド割当制御部470が付加されていることが異なっている。
【００２８】
スレッド割当制御部470はスレッド割当管理テーブル471を有し、このテーブル471にはプロセスにおけるCPUの稼働率480に対応した該最大スレッド割当数部461が予め設定されている。
【００２９】
動作においては、スレッド割当制御部470は、一定時間毎に該CPU稼働率480を監視し、スレッド割当管理テーブル471中の該CPU稼働率480に対応した該最大スレッド割当数を上述した該スレッド管理テーブル460中の該最大スレッド割当数部461の値として指定する。各スレッド制御部は、処理メッセージ数部462の値≧最大スレッド割当数部461の値のとき待機状態になる。
【００３０】
すなわち、スレッド割当制御部470が、スレッド割当管理テーブル471を参照して該CPU稼働率から最大スレッド割当数を求めて、これを該スレッド管理テーブル460中の該最大スレッド割当数部461に割り当てることにより、システムの負荷状態に合わせてメッセージ制御装置100の負荷を調整することが可能となる。この結果、プロセスのCPUが過大スレッドを負荷としたことによるオーバヘッドを減らして処理効率を上げることができる。
【００３１】
また、請求項３に係る本発明においては、該キューバッファ及びスレッド制御部を管理するメッセージ管理部を備え、該メッセージ管理部が、一定時間毎に該処理メッセージ数をチェックし、該処理メッセージ数の少ない該スレッド管理テーブルの該最大スレッド割当数の一部を、該処理メッセージ数が多い別のターゲットオブジェクトの該スレッド管理テーブルの該最大スレッド割当数に割り振ることが可能である。
【００３２】
すなわち、該メッセージ管理部が、各スレッド管理テーブルの処理メッセージ数／最大スレッド割当数を求め、これを各スレッド制御部の稼働率とする。そして、この稼働率の低いスレッド制御部の最大スレッド割当数の一部を稼働率の高いスレッド制御部の最大スレッド割当数に割り振る。
【００３３】
この結果、スレッド制御部の最大スレッド割当数は、稼働率が高いほど大きくなり、メッセージ制御装置100の処理効率を上げることができる。
【００３８】
また、請求項４に係る本発明においては、送信元プロセス毎に優先レベルが設定されており、また該キューバッファが該優先レベル毎に設けられており、該スレッド制御部が、該優先レベルの高い方のキューバッファから優先して該メッセージを取り出すことができる。
【００３９】
まず、該送信元プロセス毎に優先レベルが設定する。すなわち、各プロセスからのメッセージには、対応した優先レベルが設定される。さらに、この優先レベルに対応してキューバッファが設けられている。
【００４０】
スレッド制御部は、優先レベルの高いキューバッファから優先してメッセージを取り出しスレッドを作成しターゲットオブジェクトに与える。
【００４１】
この結果、優先レベルの高い送信元プロセスからのメッセージを優先して処理することが可能となる。
【００４２】
また、請求項５に係る本発明においては、さらに、該キューバッファを送信元プロセス毎に設けることができる。
【００４３】
図５は、本発明のメッセージ制御装置100の原理(5)を示しており、同図には図１に示したキューバッファ431及びターゲットオブジェクトTO_1のみが示されている。キューバッファ431は、例えば送信元プロセス1〜nにそれぞれ対応したキューバッファ431_1〜431_nが設定されている。
【００４４】
動作において、メッセージ分配部300が（図１参照）、受信したメッセージを送信元のプロセス1〜n毎に対応したキューバッファ431_1〜431_nに分配する。スレッド制御部（図示せず）は、キューバッファ431_1〜431_nから順次メッセージ700を取り出しスレッド500を作成してターゲットオブジェクトTOに与える。
【００４５】
この結果、各プロセスからのメッセージ700を均等にターゲットオブジェクトTOに送ることが可能となる。
【００４６】
また、請求項６に係る本発明においては、該メッセージに含まれるオペレーション毎に優先レベルが設定されており、該オペレーションの優先レベル順に該メッセージを並び換えるメッセージソート制御部をさらに設けることができる。
【００４７】
図６は、本発明のメッセージ制御装置100の原理(6)を示している。同図(1)は、メッセージ700が含む情報を示しており、この情報はメッセージ名R、キューバッファ431に到着した順序ｘ、オペレーション名Ｏ及びその優先レベルｐから成っている。
【００４８】
同図(2)は、キューバッファ431に保持されている並び換え前の到着順のメッセージ(R1〜R6）700を示しており、各メッセージR1〜R6のオペレーションＯは、“G”，“A”，“S”，“P”，“B”，“S”であり、その優先レベルは、“3”，“1”，“3”，“2”，“2”，“3”である。
【００４９】
動作において、メッセージソート制御部（図示せず）は、優先レベルに従って同図(2)に示したメッセージR1，R2，R3，R4，R5，R6の順序をオペレーションの優先レベルPに従ってソートし、同図(3)に示すようにオペレ−ション/優先レベルA1，P2，B2，G3，S3，S3の順に並び換える。すなわち、メッセージは、メッセージR2，R4，R5，R1，R3，R6の順になる。
【００５０】
この結果、優先レベルの高いオペレーションを含むメッセージを優先してターゲットオブジェクトTOに与えることになる。
【００５１】
また、請求項７に係る本発明においては、該メッセージにタイムスタンプを付与し、該スレッド制御部が、該タイムスタンプが一定時間以上経過した該メッセージを優先して引き出すことができる。
【００５２】
図７は、本発明のメッセージ制御装置100の原理(7)を示している。同図(1)はメッセージ700が含む情報を示しており、この情報はメッセージ名R、到着順ｘ及びタイムスタンプTcから成っている。同図(2)は、キューバッファ431が保持するメッセージR20，R12，R13，R8，R15，R2を示している。これらのメッセージR20，R12，R13、R8，R15，R2のタイムスタンプTcの値“4”，“10”，“9”，“13”，“7”，“21”は、メッセージ700がスレッド500を介してキューバッファ431からターゲットオブジェクトTOに与えられた後、“１”だけカウントアップされた値を示している。
【００５３】
動作において、メッセージソート制御部（図示せず）は、メッセージR2のタイムスタンプTc＝21が予め設定された値“20”を越えていることを検出して、同図(3)で示すようにメッセージR2をキューバッファ431の先頭に割り込ませ、メッセージR2を最優先でターゲットオブジェクトTOに送るようにする。この結果、メッセージが少なくとも一定時間内に取り出されることになる。
【００５４】
また、請求項８に係る本発明においては、各プロセスに排他制御フラグが割り当てられており、また該メッセージが排他制御情報を有しており、該スレッド制御部は、取り出した該メッセージの該制御情報が設定されているとき、該排他制御フラグを設定し、該排他制御フラグが設定されているとき、全てのスレッド制御部は該排他制御情報が設定された該メッセージのみ取り出すことが可能である。
【００５５】
すなわち、プロセス内に排他制御フラグが設けられ、またメッセージが排他制御情報を有している。スレッド制御部は、排他制御情報が設定されているメッセージを取り出したとき、スレッドを作成してメッセージをターゲットオブジェクトに与えると共に、排他制御フラグを設定する。
【００５６】
この排他制御フラグが設定されている間、全てのスレッド制御部は排他制御情報が設定されているメッセージのみを取り出し他のメッセージは取り出さない。排他制御フラグは、排他制御情報が設定されており現在、スレッドが作成されている全てのメッセージが対応するターゲットオブジェクトで処理されたとき、その設定が解除される。
【００５７】
この結果、該排他制御フラグが設定された特定のメッセージを優先して取り出しターゲットオブジェクトに与えることが可能となる。
【００５８】
また、請求項９に係る本発明においては、該メッセージとしてリクエストメッセージを用いることができる。
【００５９】
さらに、請求項10に係る本発明においては、該送信元プロセスが送信元オブジェクトであってもよい。
【００６０】
【発明の実施の形態】
図８は、本発明に係るメッセージ制御装置100の実施例(1)を示しており、この実施例では、メッセージ制御装置100は、ターゲットオブジェクト別メッセージ分配部（以後、TO別メッセージ分配部と略称する）310と、このTO別メッセージ分配部310に接続されターゲットオブジェクトTO_1〜TO_3にリクエストメッセージ700を与えるメッセージ管理部400とで構成されている。なお、以下の説明ではメッセージとしてリクエストメッセージを一例として取り挙げるが、これに限定されず他の種々のメッセージも適用可能である。
【００６１】
メッセージ管理部400は、ターゲットオブジェクトTO_1〜TO_3に対応したユーザ別メッセージ分配部410_1〜410_3（符号410で総称することがある）、これらの分配部410_1〜410_3に接続されたメッセージソート制御部420_1〜420_3（符号420で総称することがある）、これらの制御部420_1〜420_3に接続されたキューバッファ431〜433、及びこれらのバッファ431〜433に接続されたスレッド制御部440_1〜440_3（符号440で総称することがある）で構成されている。
【００６２】
そして、ユーザ別メッセージ分配部410_1〜410_3はTO別メッセージ分配部310に共通接続され、スレッド制御部440_1〜440_3はそれぞれターゲットオブジェクトTO_1〜TO_3に接続されている。また、キューバッファ431〜433はそれぞれユーザ別キューバッファ431_1〜431_4、432_1〜432_4、及び433_1〜433_4で構成されている。スレッド制御部440_1〜440_3には、最大スレッド割当数部461及び処理メッセージ数部462からなるスレッド管理テーブル460（図２参照）が含まれており、図８には処理メッセージ数462のみが処理メッセージ数カウンタ462として例示されている。
【００６３】
動作において、TO別メッセージ分配部310は、受信したリクエスト700をその宛先のターゲットオブジェクトTO_1〜TO_3に対応したユーザ別メッセージ分配部410に分配する。ユーザ別メッセージ分配部410は、メッセージソート制御部420を介してリクエスト700を送信元のユーザ（プロセス、オブジェクト等）毎に分配して例えばキューバッファ431ではユーザ別キューバッファ431_1〜431_4に与える。
【００６４】
そして、例えばスレッド制御部440_1は、キューバッファ431_1〜431_4にバッファリングされているリクエスト700を順次取り出しスレッド500を作成してターゲットオブジェクトTO_1に送ると共に、リクエスト700を取り出す毎に処理メッセージ数カウンタ462を“１”だけインクリメントする。処理メッセージ数カウンタ462の値≧最大スレッド割当数のとき、スレッド制御部440_1は待機状態となりリクエスト700の取り出しを停止する。
【００６５】
ターゲットオブジェクトTO_1は受信した複数のリクエスト700を同時に処理し、１つのリクエスト700の処理が終了したとき、これをスレッド制御部440_1に通知する。スレッド制御部440_1は、処理メッセージ数カウンタ462を“１”だけデクリメントし、処理メッセージ数カウンタ462の値＜最大スレッド割当数部461の値のとき、リクエスト700の取り出しを再開する。
【００６６】
この結果、過大なスレッドを作成してCPUをオーバヘッド状態にせずにシステム全体の処理速度を遅くすることなくメッセージの授受を行うことが可能となると共に、各プロセス（ユーザ）からのメッセージ700を均等にターゲットオブジェクトTOに送ることが可能となる。
【００６７】
なお、この実施例においては、各スレッド制御部440が、それぞれ最大スレッド割当数及び処理メッセージ数から成るスレッド管理テーブル460を備え、最大スレッド割当数と処理メッセージ数カウンタ462の値とを比較してリクエスト700の取り出しを待機するか否かを判定したが、これとは異なり、プロセス全体に対して１つのスレッド管理テーブル460を設け、スレッド制御部440が１つのリクエスト700を取り出す毎に処理メッセージ数カウンタ462を“１”だけインクリメントし、処理メッセージ数カウンタ462の値≧最大スレッド割当数部461の値のとき全てのスレッド制御部440がリクエスト700の取り出しを停止して待機状態にしても同様の効果が得られる。
【００６８】
図９は、図８の実施例(1)におけるキューバッファ431_1〜431_3、スレッド制御部440及びターゲットオブジェクトTO_1の動作をより詳細に示したものである。ターゲットオブジェクトTO_1を宛先とするリクエストR1(Get)，R2(Set)，R3(Act)、リクエストR4(Del)，R5(Trm)，R7(Set)，R9(Del)、及びリクエストR6(Get)，R8(Get)が、ユーザ別メッセージ分配部410_1（同図参照）で送信元であるユーザ１〜３別に分配され、ユーザ１用キューバッファ431_1〜ユーザ３用キューバッファ431_3にバッファリングされている。なお、リクエストR1〜R9の添数字はリクエストの入力順番を示している（以下同様）。
【００６９】
図10は、図８及び図９に示したスレッド制御部440の動作手順例(1)を示しており、図９を参照して以下にスレッド制御部440の動作を説明する。まず、スレッド制御部440は、リクエストを取り出すキューバッファのユーザ番号をｉ＝１に設定し（ステップS10）、リクエストがあるか否かを判定する（同S11）。リクエストが無い場合、ステップS13に進むが、リクエストR1があるので、▲１▼キューバッファ431_1からリクエストR1を取り出し（同S12）、スレッドを作成してターゲットオブジェクトTO_1に与えた後、ステップS13に進む。
【００７０】
ステップS13において、スレッド制御部440は、ｉを１だけインクリメントし、このｉ（＝２）＞ｎ（ｎ：ユーザ数“３”）であるか否かを判定する。ｉ≦３であるので、ステップS10に戻り、キューバッファのユーザ番号をｉ＝２に設定し、リクエストR4が有るので（同S11）、▲２▼キューバッファ430_2からリクエストR4を取り出し、スレッドを作成してターゲットオブジェクトTO_1に与える（同S12)。
【００７１】
以下同様にして、ステップS13，S10，S11を経由して、▲３▼キューバッファ431_3からリクエストR6を取り出し、スレッドを作成してターゲットオブジェクトTO_1に与え（同S12）、ステップS13に進む。ステップS13において、ｉを“１”だけインクリメントするとｉ＝“４”となり、ｉ＞３となる。そこで、ｉ＝１に戻してステップS10に戻る。
【００７２】
以後同様の動作を繰り返して、スレッド制御部440は、キューバッファ431_1〜431_3から順次、リクエストR2，R5，R8，R3，R7，R9を取り出してターゲットオブジェクトTO_1に与える。
【００７３】
この手順によれば、リクエストは送信元のユーザに関して均等に処理される。従って、キューバッファをユーザ別に分けない場合と比較して、ユーザ当たりのリクエストの待ち時間が短縮されることになる。
【００７４】
図11は、本発明のメッセージ制御装置100の実施例(2)を示している。この実施例では複数のネットワーク制御システムをネットワーク管理システムが管理するネットワーク監視制御システムにおける情報管理例を示しており、特にネットワーク管理システムにおけるメッセージ制御装置が、短時間に多数のリクエストを複数のネットワーク制御システムから送信元プロセスを構成する上位制御オブジェクトSO_1〜SO_3を介して受信した場合を示している。
【００７５】
メッセージ制御装置100は、図８に示した実施例(1)の構成要素にさらにCPUの稼働率480を入力しスレッド割当管理テーブル471（図３参照）を有するスレッド割当制御部470を備えている。
【００７６】
動作において、上位制御オブジェクトSO_1〜SO_3からのリクエストR10，R12、リクエストR11，R19、及びリクエストR1，R3，R4，R8，R15は、メッセージ分配部300（図３参照）で分配され、それぞれキューバッファ431〜433にバッファリングされる。スレッド割当制御部470は、▲１▼現在のCPUの稼働率、例えば80％を入力し、スレッド割当管理テーブル471を参照して機能オブジェクトであるターゲットオブジェクトTO_1〜TO_3の最大スレッド割当数“２”，“２”，“２”を得る（図３参照）。▲２▼この割当数“２”，“２”，“２”をスレッド割当制御部470は、スレッド制御部440（図８参照）のスレッド管理テーブル460の最大スレッド割当数（図２参照）とする。
【００７７】
スレッド制御部440_1〜440_3は、それぞれ最大スレッド割当数“２”，“２”，“２”のスレッド500を作成して、リクエストR10，R12、リクエストR11，R19、及びリクエストR1，R3をターゲットオブジェクトTO_1，TO_2，及びTO_3に与える。そして、例えばスレッド制御部440_3は、キューバッファ433がリクエストR4，R8，R15をバッファリングしているにも関わらず最大スレッド割当数“２”以上のスレッドを作成してリクエストR4，R8，R15を取り出さない。
【００７８】
一定時間後、スレッド割当制御部470は、▲１▼例えばCPU稼働率“20％”を入力すると、スレッド割当管理テーブル471からターゲットオブジェクトTO_1〜TO_3の最大スレッド割当数“12”，“9”，“8”を得て（図３参照）、▲２▼スレッド制御部440_1〜440_3（図８参照）の最大スレッド割当数とする。
【００７９】
最大スレッド割当数が“８”となったスレッド制御部440_3は、さらにリクエストR4，R8，R15を取り出し、スレッド500を作成してターゲットオブジェクトTO_3に与えることが可能となる。
【００８０】
すなわち、CPUの稼働率に対応した数のスレッドを作成することにより、CPUが過大なスレッド処理の負荷によりオーバヘッドすることなしに全体の処理を早め、リクエストの転送速度を上げることが可能となる。
【００８１】
図12は、本発明のメッセージ制御装置におけるメッセージ管理部400の動作手順例を示している。以下に、図８を参照してメッセージ管理部400の動作を説明する。但し、ユーザはｎ、すなわちターゲットオブジェクトTO_1〜TO_n、スレッド制御部440_1〜440_n等として説明する。
【００８２】
メッセージ管理部400は、ｉを初期値“０”に設定した後、各ターゲットオブジェクトTOに対応したスレッド管理テーブル460_1〜460_n（図２参照）の最大スレッド割当数及び処理メッセージ数（図12の処理メッセージ数カウンタ462の値）を読み出し、各ターゲットオブジェクトTO_1〜TO_nの稼働率OR＝処理メッセージ数/最大スレッド割当数を演算で昇順（小→大）にソートをする（ステップS20）。稼働率ORは、ソートされた昇順にOR_1〜OR_ｎとする。
【００８３】
そして、メッセージ管理部400は、ステップS21でｉを“１”だけインクリメントした後、ステップS22に進み、ｉ＜ｎ（ｎ：ターゲットオブジェクト数＋１）であるか否かを判定し、ｉ≧ｎであるとき動作を終了する。初回は、ｉ（＝１）＜ｎであるので、ステップS23に進み、最も小さい稼働率OR_1／最も大きい稼働率OR_n-1を演算し、演算結果が一定の値“α”以上でないとき、ステップS24に進む。
【００８４】
ステップS24において、稼働率OR_1及びOR_n-1に対応するターゲットオブジェクトが例えばそれぞれターゲットオブジェクトTO_1及びTO_3であるとしたとき、ターゲットオブジェクトTO_1の未だ使われていない未使用スレッド数の２分の１をターゲットオブジェクトTO_3の最大スレッド割当数に割り振り、ステップS21に戻る。
【００８５】
以下同様にして、OR_i/OR_(n-i)＞αのとき、稼働率の少ないターゲットオブジェクトの未使用スレッド数の２分の１を稼働率の大きいターゲットオブジェクトの最大スレッド割当数に割り振る処理を実行する。
【００８６】
この結果、ターゲットオブジェクトに割り当てられた、すなわちスレッド作成部に割り当てられた最大スレッド割当数を動的に稼働率の高いターゲットオブジェクトに割り振ることになり、メッセージ制御装置内で限られた数のスレッドを効率的に使うことが可能となる。
【００８７】
図13は、本発明のメッセージ制御装置100の実施例(3)を示しており、この実施例は図11に示した実施例(2)と同様に複数のネットワーク制御システムからリクエストを受信するメッセージ制御装置100を示している。
【００８８】
メッセージ制御装置100は、各ネットワーク制御システムに含まれる上位制御オブジェクトSO_1〜SO_5からのリクエストをバッファリングして、機能オブジェクトであるターゲットオブジェクトTO_1に与えるキューバッファ430を含んでいる。上位制御オブジェクトSO_1〜SO_5の中の特にオブジェクトSO_1及びSO_2には、ユーザレベル１が設定され、他のオブジェクトSO_3〜SO_5にはユーザレベル２が設定されている。
【００８９】
キューバッファ430は、オブジェクトSO_1〜SO_5からのリクエストをバッファリングするキューバッファ431_1〜431_5から成り、各オブジェクトSO_1〜SO_5のユーザレベルに対応してキューバッファ431_1及び431_2がユーザレベル１用キューバッファ部430_1を構成し、キューバッファ431_3〜431_5がユーザレベル２用キューバッファ部430_2を構成している。
【００９０】
また、ターゲットオブジェクトTO_1には、処理可能なリクエスト数としてユーザレベル１用に３つ及びユーザレベル２用に７つが設定されているものとする。そして、キューバッファ431_1〜431_5は、それぞれリクエストR10，R12、リクエストR11，R19、リクエストR1，R3，R4，R8，R15、リクエストR2，R6，R7，R9，R16、リクエストR5，R13，R14，R17，R18をバッファリングしている。
【００９１】
図14は、起動時にメッセージ管理部400が読み込む定義ファイル例を示している。同図(1)のファイルには、ユーザとそのユーザレベルが示されており、ユーザである“Administrator”、“amelio”、“atari”、“okonomy”、“sussy”、“sundo”、…にそれぞれユーザレベル“1”、“2”、“2”、“2”、“2”、“2”、…が設定されている。
【００９２】
同図(2)のファイルには、リクエスト名とその優先レベル及び排他制御情報が示されており、例えば、リクエスト名が“Create”及び“Back_Up”の優先レベル及び排他制御情報は、それぞれ“２”、“１”及び“OFF”、“ON”である。
【００９３】
図15は、スレッド制御部440の動作例(1)を示しており、この動作例ではメッセージ管理部400（図８参照）が図14に示したファイルのデータを読み込んでいる状態であり、このデータをスレッド制御部440は参照する。また、スレッド制御部440は、ターゲットオブジェクトTO_1が同時に処理可能なリクエスト数（同時リクエスト数）として上述したようにユーザレベル１用に３つ及びユーザレベル２用に７つが設定されていることを、後述する同時リクエスト数D1＝３、D2＝７として知っているものとする。
【００９４】
図16は、図15に示したスレッド制御部440の動作手順例(2)を示している。この手順例を概念的に述べると、まずスレッド制御部440はユーザレベルの高いキューバッファから順次リクエストを取り出しスレッドを作成してターゲットオブジェクトTO_1に送り、作成したスレッド数がターゲットオブジェクトTO_1が同時に処理できるユーザレベルの高いリクエストの最大数＝“３”に達したとき、リクエストの取り出しを停止状態にする。そして、次にユーザレベルの高いキューバッファ430_1からのリクエストの取り出し動作に移行する。
【００９５】
これを更に詳しく図15を参照して説明する。スレッド制御部440は、ステップS30でｉを“０”に初期設定してステップS31に進み、ｉを“１”だけインクリメントし、リクエスト数Pi＝P1を“０”に初期設定する。なお、リクエスト数Piはユーザレベルｉのキューバッファから取り出したリクエスト数である。
【００９６】
ステップS32でスレッド制御部440は、同時リクエスト数D1＝３とリクエスト数P1を比較し、D1＞P1であるのでステップS33に進む。ユーザレベル１のキューバッファ431_1にリクエストR10（図13参照）が存在するので（ステップS33，S34）、このリクエストR10を取り出しスレッドを作成してターゲットオブジェクトTO_1に送信し（同S35）、リクエスト数P1を“１”だけインクリメントしたP1＝１としてステップS32に戻る。
【００９７】
以後同様にして、スレッド制御部440は、順次キューバッファ431_2及び431_1からリクエストR11及びR12を取り出しスレッドを作成してターゲットオブジェクトTO_1に送信する。ステップS35からS32に戻ったとき、D1（＝３）≦P1（＝３）であるので、ユーザレベル１のリクエストの送信を待機状態にする。そして、ステップS31に戻り、iを“１”だけインクリメントしてｉ＝２とし、P2を“０”に初期設定して、ユーザレベル２のキューバッファ431_3〜431_5からのリクエストの取り出しを開始する。
【００９８】
以下同様にして、スレッド制御部440は、順次、キューバッファ431_3〜431_5から同時リクエスト数D2が指定する７つのリクエストR1，R2，R5，R3，R6，R13，R4（図13参照）取り出しスレッドを作成してターゲットオブジェクトTO_1に送信して、待機状態になる。なお、図16に示した手順には、スレッド制御部440が同一ユーザレベルの複数のキューバッファから、順次リクエストを取り出す手順は省略されている。
【００９９】
この結果、ユーザレベル１及び２用のスレッドがそれぞれ３及び７つ作成され、ターゲットオブジェクトTO_1は合計10のリクエストを同時に処理する形となる。そして、例えば、オブジェクトTO_1が、ユーザレベル１の２つのリクエストの処理を完了すると、図15に示すように、▲１▼ユーザレベル１用の２つのスレッド500_1が待機状態になり、▲２▼ユーザレベル２用のスレッド500_2は全て実行中の状態のままである。
【０１００】
そこで、スレッド制御部440は、▲３▼，▲４▼ユーザレベル１用のキューバッファ430_1からリクエストを取り出しユーザレベル１用のスレッド500_1の空いたスレッドを用いてオブジェクトTO_1に送信することを開始する。このとき、キューバッファ430_1にバッファリングされているリクエストが無い場合、スレッド制御部440は、▲５▼ユーザレベル２用のキューバッファ430_2からリクエストを取り出しユーザレベル１用のスレッド500_1を用いて送信することはない。ただし、キューバッファ430_1にバッファリングされているリクエストがあって、スレッド500_2に待機状態を含む場合には、スレッド制御部440は、キューバッファ430_1のリクエストをスレッド500_2に与えスレッドの作成を行うことができる。
【０１０１】
この結果、スレッド制御部440は、ユーザレベルの高い順にリクエストをターゲットオブジェクトに与えるともに、同じユーザレベルのリクエストはユーザの別なく均等に処理することが可能となる。
【０１０２】
図17は、メッセージソート制御部420（図８参照）の動作例を示しており、この動作例においても、起動時にメッセージ管理部400（図８参照）は、図14に示したユーザレベル及び優先レベル定義データを読み込んでいるものとする。
【０１０３】
同図(1)のキューバッファ431_1には、リクエストR1，R2，…，R4がこの順で待ち状態になっている。リクエストR1〜R4のオペレーション名は、それぞれ“Create”、“Set”、“Get”及び“Terminate”であり、これらのオペレーションの優先レベルは、メッセージ管理部400が読み込んだ図15(2)の優先レベルデータを参照すると“2”、“3”、“3”及び“3”であることを知ることができる。このことを同図中では符号“C2”、“S3”、“G3”及び“T3”でそれぞれ示している。
【０１０４】
この状態で、メッセージソート制御部420はリクエストR5(Create)を受信すると、“Create”の優先レベルが“２”であることを知り、リクエストR2〜R4より優先レベルが高いのでソートを開始し、同図(2)に示すように、リクエストR5をリクエストR1とリクエストR2の間に挿入するように並び換える。この結果、優先レベルの高いオペレーションを含むリクエストが優先してターゲットオブジェクトに与えられることになる。
【０１０５】
図18は、メッセージソート制御部420及びスレッド制御部440（図８参照）の動作例を示している。図17に示したメッセージソート制御部420のソート動作だけでは、優先レベルの高いオペレーションのリクエストが連続して送られてきた場合、これより優先レベルの低いオペレーションを含むリクエストはさらに遅れて送信されることになる。
【０１０６】
そこで、この動作例(2)では、キューバッファにバッファリングされた各リクエストにタイムスタンプ情報を持たせることとする。キューバッファ431_1にバッファリングされたリクエストR20，R12，R13及びR2の現在のタイムスタンプ情報はそれぞれ“4”、“10”、“9”、“20”である。
【０１０７】
スレッド制御部440は、キューバッファ431_1〜431_3の中からリクエストを取り出す毎に各リクエストR20〜R2のタイムスタンプ情報を“１”だけカウントアップし、このタイムスタンプ情報が一定の値、例えば“21”以上になったリクエストを探索する。そして、この例ではスレッド制御部440は、▲１▼リクエストR2を検出し、その優先レベルを強制的に“１”とする。そして、▲２▼メッセージソート制御部420に対してソートを要求する。
【０１０８】
▲３▼メッセージソート制御部420は、優先レベル順にリクエストR20〜R2をソートする。この結果、優先レベルの高いリクエストR2がリクエストR20の前に挿入されることになり、一定時間以上待たされたリクエストR2が優先的にターゲットオブジェクトTO_1に送出されることになる。
【０１０９】
図19は、スレッド制御部440（図８参照）の動作例(2)を示しており、この動作例ではメッセージ管理部400が排他制御フラグ490を有し、各リクエストは排他制御情報を有している。すなわち、スレッド制御部440は、メッセージ管理部400が読み込んだ優先レベル定義情報（図14(2)参照）を参照することにより各リクエストのオペレーヨンに対応した排他制御情報のオン/オフ状態を知ることができる。また、この動作例では、図17で示したようにメッセージソート制御部420は、入力したリクエストをそのオペレージョンの優先レベルに従ってソートするものとする。
【０１１０】
同図において、TO別キューバッファ431には、図17のキューバッファ431_1と同様にリクエストR1(C2)，R2(S3)，R3(G3)，R4(T3)がバッファリングされているものとする。これらのリクエストの優先レベルは、上述したように“2”、“3”、“3”及び“3”であり、排他制御情報は全て“オフ”（図14(2)参照）ある。
【０１１１】
例えば、メッセージソート制御部420にリクエストR5(Back_Up）入力されと、メッセージソート制御部420は、リクエストR5の優先レベルが“１”であることを知り（図14(2)参照）、リクエストR5をリクエストR1の前に挿入するようにソートする。
【０１１２】
スレッド制御部440_1はリクエストR5を取り出しスレッドを作成して送出する。このとき、リクエストR5のオペレーション“Back_Up”の排他制御情報が“オン”であることを知り（図14(2)参照）、排他制御フラグ490を設定する。この排他制御フラグ490が設定されているとき、全てのスレッド制御部440_1〜440_3は、排他制御情報が設定されているリクエストのみを取り出し送出する。
【０１１３】
この結果、優先レベルの高い特定のリクエストのみを最優先でターゲットオブジェクトに送出することが可能となる。
【０１１４】
【発明の効果】
以上説明したように、本発明に係るメッセージ制御装置によれば、メッセージ分配部がメッセージをターゲットオブジェクト毎且つ送信元プロセス毎に設定した優先レベル毎に設けられたキューバッファに分配し、スレッド制御部が、プロセス又はターゲットオブジェクト毎に予め設定された最大スレッド割当数以下の複数のスレッドを同時に作成して該メッセージを取り出し対応する該ターゲットオブジェクトに与えるように構成したので、システム全体の処理速度を早めることが可能となる。
【０１１５】
また、プロセスのCPU稼働率に対応して該最大スレッド割当数を指定するようにしたこと及び使用スレッド数が少ないターゲットオブジェクトのスレッド割当数の一部を使用スレッド数の多いターゲットオブジェクトの最大スレッド割当数割り振るようにしたことによりCPUが過大スレッドを負荷としたことによるオーバヘッドを減らして処理効率を上げることができる。
【０１１６】
さらに、プロセス毎にレベルを設定すること、メッセージのオペレーション毎に優先レベルを設定すること、又は排他制御フラグを設定することで特定のメッセージを優先してターゲットオブジェクトに与えることが可能となる。
【図面の簡単な説明】
【図１】本発明に係るメッセージ制御装置の原理(1)を示したブロック図である。
【図２】本発明に係るメッセージ制御装置の原理(2)を示したブロック図である。
【図３】本発明に係るメッセージ制御装置の原理(3)を示したブロック図である。
【図４】本発明に係るメッセージ制御装置の原理(4)を示したブロック図である。
【図５】本発明に係るメッセージ制御装置の原理(5)を示したブロック図である。
【図６】本発明に係るメッセージ制御装置の原理(6)を示したブロック図である。
【図７】本発明に係るメッセージ制御装置の原理(7)を示したブロック図である。
【図８】本発明に係るメッセージ制御装置の実施例(1)を示したブロック図である。
【図９】本発明に係るメッセージ制御装置におけるユーザ別リクエストの処理手順を示した図である。
【図１０】本発明に係るメッセージ制御装置におけるスレッド制御部の動作手順例(1)を示したフローチャート図である。
【図１１】本発明に係るメッセージ制御装置の実施例(2)を示したブロック図である。
【図１２】本発明に係るメッセージ制御装置におけるメッセージ管理部の動作手順例を示したフローチャート図である。
【図１３】本発明に係るメッセージ制御装置の実施例(3)を示したブロック図である。
【図１４】本発明に係るメッセージ制御装置で用いられるユーザレベル及び優先レベル定義テーブル例を示した図である。
【図１５】本発明に係るメッセージ制御装置におけるスレッド制御部の動作例(1)を示したブロック図である。
【図１６】本発明に係るメッセージ制御装置におけるスレッド制御部の動作手順例(2)を示したフローチャート図である。
【図１７】本発明に係るメッセージ制御装置におけるメッセージソート制御部の動作例を示したブロック図である。
【図１８】本発明に係るメッセージ制御装置におけるメッセージソート制御部及びスレッド制御部の動作例を示したブロック図である。
【図１９】本発明に係るメッセージ制御装置におけるスレッド制御部の動作例(2)を示したブロック図である。
【図２０】従来のメッセージ制御装置の構成例(1)を示したブロック図である。
【図２１】従来のメッセージ制御装置の構成例(2)を示したブロック図である。
【符号の説明】
100 メッセージ制御装置 200 メッセージ受信部
300 メッセージ分配部 310 TO別メッセージ分配部
400 メッセージ管理部 410，410_i ユーザ別メッセージ分配部
420，420_i メッセージソート制御部
430〜433，430_i〜433_i キューバッファ
440，440_i スレッド制御部 460，460_i スレッド管理テーブル
461，461_i 最大スレッド割当数部
462，462_i 処理メッセージ数部、処理メッセージ数カウンタ
470 スレッド割当制御部 471 スレッド割当管理テーブル
480 CPU稼働率 490 排他制御フラグ
500，500_i，510，520 スレッド
TO，TO_i ターゲットオブジェクト SO_i 制御オブジェクト
610 Get処理部 620 Set処理部
700〜703，R1〜R20 メッセージ，リクエストメッセージ
ｉは正の整数
図中、同一符号は同一又は相当部分を示す。
Claims (10)
- 異なるプロセスに属するオブジェクト間でメッセージを授受するメッセージ制御装置において、
ターゲットオブジェクト毎且つ送信元プロセス毎に設定した優先レベル毎に設けられたキューバッファと、
該メッセージを該ターゲットオブジェクトに応じて該キューバッファに分配するメッセージ分配部と、
該キューバッファから該メッセージを取り出して対応する該ターゲットオブジェクトに与えるべき複数のスレッドを同時に作成するスレッド制御部と、
を備え、
該スレッド制御部は、該ターゲットオブジェクトに該メッセージを与えることができる最大スレッド割当数及び現在の処理メッセージ数を各ターゲットオブジェクト毎に管理するスレッド管理テーブルと、該優先レベルの高いメッセージのみに該複数のスレッドの一部を割り当てた第１のスレッド部及びそれ以外のスレッドを割り当てた第２のスレッド部とを有し、該第２のスレッド部に空きがないとき、該優先レベルの高いメッセージのみを該第１のスレッド部に与え、さらに該第１のスレッド部及び該第２のスレッド部に与えられる処理メッセージ数の合計が該最大スレッド割当数を越えたとき、対応するターゲットオブジェクトの該メッセージの取り出しを待機させることを特徴としたメッセージ制御装置。 - 請求項１において、
さらに、該プロセスにおけるCPUの稼働率に対応する該最大スレッド割当数を保持するスレッド割当管理テーブルを含むスレッド割当制御部を有し、
該スレッド割当制御部が、一定時間毎に該CPU稼働率を監視し、該スレッド割当管理テーブル中の該CPU稼働率に対応した該最大スレッド割当数を該スレッド管理テーブルの該最大スレッド割当数として指定することを特徴としたメッセージ制御装置。 - 請求項１において、
該キューバッファ及びスレッド制御部を管理するメッセージ管理部を備え、該メッセージ管理部が、一定時間毎に該処理メッセージ数をチェックし、該処理メッセージ数の少ない該スレッド管理テーブルの該最大スレッド割当数の一部を、該処理メッセージ数が多い別のターゲットオブジェクトの該スレッド管理テーブルの該最大スレッド割当数に割り振ることを特徴とするメッセージ制御装置。 - 請求項１において、
該スレッド制御部が、該優先レベルの高い方のキューバッファから優先して該メッセージを取り出すことを特徴としたメッセージ制御装置。 - 請求項１において、
該キューバッファが、さらに、送信元プロセス毎に設けられていることを特徴としたメッセージ制御装置。 - 請求項１において、
該メッセージに含まれるオペレーション毎に優先レベルが設定されており、該オペレーションの優先レベル順に該メッセージを並び換えるメッセージソート制御部をさらに設けたことを特徴とするメッセージ制御装置。 - 請求項１において、
該メッセージにタイムスタンプを付与し、該スレッド制御部が、該タイムスタンプが一定時間以上経過した該メッセージを優先して引き出すことを特徴としたメッセージ制御装置。 - 請求項１において、
各プロセスに排他制御フラグが割り当てられており、また該メッセージが排他制御情報を有しており、該スレッド制御部は、取り出した該メッセージに該制御情報が設定されているとき、該排他制御フラグを設定し、該排他制御フラグが設定されているとき、全てのスレッド制御部は該排他制御情報が設定された該メッセージのみを取り出すことを特徴としたメッセージ制御装置。 - 請求項１において、
該メッセージがリクエストメッセージであることを特徴としたメッセージ制御装置。 - 請求項１乃至９のいずれかにおいて、
該送信元プロセスが送信元オブジェクトであることを特徴としたメッセージ制御装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP32836098A JP3788697B2 (ja) | 1998-11-18 | 1998-11-18 | メッセージ制御装置 |
| US09/328,369 US6848107B1 (en) | 1998-11-18 | 1999-06-09 | Message control apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP32836098A JP3788697B2 (ja) | 1998-11-18 | 1998-11-18 | メッセージ制御装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000155693A JP2000155693A (ja) | 2000-06-06 |
| JP3788697B2 true JP3788697B2 (ja) | 2006-06-21 |
Family
ID=18209385
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP32836098A Expired - Fee Related JP3788697B2 (ja) | 1998-11-18 | 1998-11-18 | メッセージ制御装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6848107B1 (ja) |
| JP (1) | JP3788697B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010086137A (ja) * | 2008-09-30 | 2010-04-15 | Fujitsu Ltd | メッセージキューイング方法及びプログラム |
Families Citing this family (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20010032278A1 (en) | 1997-10-07 | 2001-10-18 | Brown Stephen J. | Remote generation and distribution of command programs for programmable devices |
| US20100131078A1 (en) * | 1999-10-27 | 2010-05-27 | Brown David W | Event driven motion systems |
| US8032605B2 (en) * | 1999-10-27 | 2011-10-04 | Roy-G-Biv Corporation | Generation and distribution of motion commands over a distributed network |
| US7904194B2 (en) * | 2001-02-09 | 2011-03-08 | Roy-G-Biv Corporation | Event management systems and methods for motion control systems |
| JP3975703B2 (ja) * | 2001-08-16 | 2007-09-12 | 日本電気株式会社 | 情報処理システムにおける優先実行制御方法及びその装置並びにプログラム |
| US8027349B2 (en) | 2003-09-25 | 2011-09-27 | Roy-G-Biv Corporation | Database event driven motion systems |
| US20060064503A1 (en) | 2003-09-25 | 2006-03-23 | Brown David W | Data routing systems and methods |
| US20070022194A1 (en) * | 2003-09-25 | 2007-01-25 | Brown David W | Database event driven motion systems |
| WO2005048086A2 (en) | 2003-11-17 | 2005-05-26 | Roy-G-Biv Corporation | Command processing systems and methods |
| US20050262055A1 (en) * | 2004-05-20 | 2005-11-24 | International Business Machines Corporation | Enforcing message ordering |
| JP4564390B2 (ja) * | 2005-03-31 | 2010-10-20 | 東芝ストレージデバイス株式会社 | 情報処理装置 |
| US8187883B2 (en) * | 2005-10-21 | 2012-05-29 | Wisconsin Alumni Research Foundation | Method and system for delivering nucleic acid into a target cell |
| US7613281B2 (en) * | 2005-12-13 | 2009-11-03 | Sap Ag | Monitoring a response time for a user request |
| JP2008027344A (ja) * | 2006-07-25 | 2008-02-07 | Nec Access Technica Ltd | オブジェクト間の非同期メッセージ管理方式および非同期メッセージ管理方法 |
| JP4776571B2 (ja) * | 2007-03-16 | 2011-09-21 | 富士通株式会社 | 実行制御プログラム，実行制御方法及び実行制御装置 |
| JP5331050B2 (ja) * | 2009-08-27 | 2013-10-30 | 日本電信電話株式会社 | データ同期システム、データ同期方法、情報処理装置、情報処理方法、およびプログラム |
| WO2013171854A1 (ja) * | 2012-05-16 | 2013-11-21 | 株式会社日立製作所 | 計算機、スレッド割当管理方法及びプログラム |
| CN103618586B (zh) * | 2013-11-07 | 2017-07-28 | 华为技术有限公司 | 一种发送响应帧的方法及装置 |
| KR102441299B1 (ko) * | 2017-11-27 | 2022-09-08 | 스노우플레이크 인코포레이티드 | 데이터베이스 시스템으로의 배치 데이터 수집 |
| CN110515749B (zh) * | 2019-08-30 | 2022-06-24 | 深圳乐信软件技术有限公司 | 信息发送的队列调度的方法、装置、服务器和存储介质 |
| WO2022172365A1 (ja) * | 2021-02-10 | 2022-08-18 | 日本電信電話株式会社 | リソース制御装置、リソース制御システム、および、リソース制御方法 |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0397354A (ja) * | 1989-09-11 | 1991-04-23 | Nec Corp | メッセージ送信制御装置 |
| JPH051163A (ja) | 1991-06-26 | 1993-01-08 | Nok Corp | 透明アクリルゴム成形品の表面処理方法 |
| US5430850A (en) | 1991-07-22 | 1995-07-04 | Massachusetts Institute Of Technology | Data processing system with synchronization coprocessor for multiple threads |
| JPH076043A (ja) * | 1993-03-05 | 1995-01-10 | Mitsubishi Electric Corp | マルチスレッド・サーバ |
| JPH06332834A (ja) * | 1993-05-25 | 1994-12-02 | Hitachi Ltd | リモートプロシジャコール方法 |
| EP0737335A1 (en) * | 1993-12-30 | 1996-10-16 | International Business Machines Corporation | Queue management in a data processing link |
| US5504898A (en) * | 1994-06-20 | 1996-04-02 | Candle Distributed Solutions, Inc. | Threaded environment for AS/400 |
| JPH08166929A (ja) * | 1994-12-13 | 1996-06-25 | Hitachi Ltd | 共用資源排他制御システム |
| US5752031A (en) * | 1995-04-24 | 1998-05-12 | Microsoft Corporation | Queue object for controlling concurrency in a computer system |
| JPH0969053A (ja) * | 1995-08-31 | 1997-03-11 | Toshiba Corp | メッセージ受信機構に於けるマルチスレッド制御方式及びキューイング方式 |
| US5828881A (en) * | 1995-11-09 | 1998-10-27 | Chromatic Research, Inc. | System and method for stack-based processing of multiple real-time audio tasks |
| JPH09244984A (ja) * | 1996-03-08 | 1997-09-19 | Nippon Telegr & Teleph Corp <Ntt> | イベント順序補正方法 |
| US5826081A (en) | 1996-05-06 | 1998-10-20 | Sun Microsystems, Inc. | Real time thread dispatcher for multiprocessor applications |
| JPH1049381A (ja) * | 1996-07-04 | 1998-02-20 | Internatl Business Mach Corp <Ibm> | 複数のデータ処理要求の処理方法及び処理システム、プログラムの実行方法及びシステム |
-
1998
- 1998-11-18 JP JP32836098A patent/JP3788697B2/ja not_active Expired - Fee Related
-
1999
- 1999-06-09 US US09/328,369 patent/US6848107B1/en not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010086137A (ja) * | 2008-09-30 | 2010-04-15 | Fujitsu Ltd | メッセージキューイング方法及びプログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000155693A (ja) | 2000-06-06 |
| US6848107B1 (en) | 2005-01-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3788697B2 (ja) | メッセージ制御装置 | |
| US6922408B2 (en) | Packet communication buffering with dynamic flow control | |
| US5924097A (en) | Balanced input/output task management for use in multiprocessor transaction processing system | |
| EP0891585B1 (en) | A method and apparatus for client managed flow control on a limited memory computer system | |
| US8149846B2 (en) | Data processing system and method | |
| CN108762896A (zh) | 一种基于Hadoop集群任务调度方法及计算机设备 | |
| US8024744B2 (en) | Method and system for off-loading user queries to a task manager | |
| JP2012503257A (ja) | 記憶側記憶要求管理 | |
| CN102096599A (zh) | 一种多队列任务调度方法及相关系统和设备 | |
| CN101951411A (zh) | 云调度系统及方法以及多级云调度系统 | |
| CN112888005B (zh) | 一种面向mec的分布式业务调度方法 | |
| JPH05216842A (ja) | 資源管理装置 | |
| van der Boor et al. | Zero-wait load balancing with sparse messaging | |
| Hordijk et al. | Analysis of a customer assignment model with no state information | |
| EP0647047A2 (en) | Client/server computer system | |
| US7086059B2 (en) | Throttling queue | |
| JP2004046372A (ja) | 分散処理システム、リソース割当方法およびプログラムならびにリソース割当プログラムが記録された記録媒体 | |
| US20080034054A1 (en) | System and method for reservation flow control | |
| Peng et al. | BQueue: A coarse-grained bucket QoS scheduler | |
| US11409570B2 (en) | Dynamic management of system computing resources | |
| Zhang et al. | RICH: Strategy-proof and efficient coflow scheduling in non-cooperative environments | |
| CN115242727B (zh) | 用户请求处理方法、装置、设备和介质 | |
| AU746999B2 (en) | Device for shared management of a resource among several users | |
| US20050213925A1 (en) | Fiber channel switching system | |
| Liu et al. | Efficient coflow scheduling of multi-stage jobs with isolation guarantee |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20041213 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050412 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050613 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051122 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060123 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060322 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060323 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090407 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100407 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110407 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110407 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120407 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130407 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140407 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |