JP6749329B2

JP6749329B2 - 複数のスレッドを実行するための装置および方法

Info

Publication number: JP6749329B2
Application number: JP2017534544A
Authority: JP
Inventors: ダビド・ドミンゲス; アレクサンダー・ノズドリン
Original assignee: ホアウェイ・テクノロジーズ・カンパニー・リミテッド
Priority date: 2016-08-09
Filing date: 2017-04-19
Publication date: 2020-09-02
Anticipated expiration: 2037-04-19
Also published as: WO2018028845A1; EP3282357B1; US20180210772A1; JP2018530796A; EP3282357A1; RU2017124982A3; US10606673B2; RU2017124982A; RU2679546C2

Description

本発明は、複数のスレッドを実行するための装置および方法に関する。特に、本発明の装置および方法は、RPCプロシージャの効率を向上させるために、RPCバッチ内で順序付けられたリモートプロシージャコール（RPC）要求を送信することができる。

RPCは、別のプロセスのアドレス空間で関数の実行を可能にする機構であり、それは別のコンピュータにおいてでもよい。一般的なRPCプロシージャでは、クライアントによってRPC要求が生成され、その後、サーバに送信される。RPC要求に応答するRPC応答は、クライアントによってサーバから受信される。

技術水準では、共通のアプローチは、クライアントがRPC要求を送信し、それの対応するRPC応答を同一のスレッドで処理することである。RPC要求が生成されて第1のスレッドによって送信される状況では、対応するRPC応答が受信されて処理されるまで、クライアントのプロセッサは第1のスレッドによって占有される。RPC要求とそれの対応するRPC応答との間の時間間隔の間、第1のスレッドはネットワークカードを継続的にポーリングする。さらに、時間間隔は、ネットワーク通信によってもたらされる待ち時間のために大きくなる可能性がある。したがって、プロセッサは、比較的長い期間に他のスレッドによって解放されたりまたは使用されたりすることはできない。

クライアントに複数のスレッドがあり、各スレッドが1つ以上のリモートコンピュータに宛先を持つRPC要求を生成する場合、クライアントによって実行されるRPCプロシージャの効率は、1つのスレッドの連続的な占有のために低い。

上述の問題、特にクライアントの側でRPCプロシージャを実行する際の効率が低いという問題に鑑み、本発明は、技術水準を改善することを目的とする。したがって、本発明は、複数のスレッドを実行してRPCプロシージャの効率を向上させる装置および方法を提供することを目的とする。

本発明の上記の目的は、添付の独立請求項に提供される解決策によって達成される。本発明の有利な実装形態は、それぞれの従属請求項においてさらに定義される。

本発明の第1の態様は、複数のスレッドを実行するための装置を提供する。本装置は、メモリと、クライアントと、RPCマネージャとを含む。クライアントは、複数のスレッドのそれぞれについて、操作を実行するためのRPC要求を生成し、生成されたRPC要求を（データベース内に）メモリに格納するように構成されている。RPCマネージャは、格納されたRPC要求を順序付けるように構成されている。クライアントは、順序付けられたRPC要求をRPCバッチで送信するようにさらに構成されている。

したがって、装置または装置内のクライアントは、個別のRPC要求ではなく、複数のRPC要求を含むRPCバッチを送信する。このようにして、複数のRPC要求が実際にバッチで送信されるため、通信のオーバーヘッドが大幅に低減される。つまり、バッチでRPC要求を送信するということは、複数のRPC要求がクライアントによって同時に送信されることを意味する。このようにして、クライアントは、固有のプロセッサが長期間に亘って不必要に占有されることなくRPCプロシージャを効率的に実行することができる。

また、複数のRPC要求は、RPCマネージャによって順序付けられる。クライアントによって送信されたRPCバッチは、順序付けられたRPC要求を含む。したがって、RPC要求の順序（シーケンス）がRPCバッチに存在している。この順序は、RPCバッチ、例えば、サーバの受信機におけるRPC実行順序を示す。つまり、RPCバッチはRPC実行順序を定義する。この順序は、バッチからの各RPC要求の実行順序を決定する。

任意に、RPC要求に対応する応答はまたバッチ処理され、RPC要求を含むRPCバッチへの1回の応答で送信される。これにより、通信のオーバーヘッドが低減され、装置の効率が改善される。

第1の態様に係る装置の第1の実装形態において、RPCマネージャは、格納されたRPC要求が生成された時間に基づいて格納されたRPC要求を順序付けるように構成されている。

したがって、RPC要求の順序は、RPC要求の生成順序に基づいて構成されている。早めにRPC要求が生成されるほど、RPCがより早めに送信される可能性が高くなる。例えば、第1のRPCは、第2のRPCより早く時間で生成される。第1のRPCは、1つのRPCバッチで第2のRPC要求よりも高い優先度で順序付けられる。したがって、第1のRPC要求の応答は、第2のRPC要求の応答より早くクライアントに到着することが期待される。別の例によれば、第3のRPC要求が第2のRPC要求より遅く生成された場合、第3のRPC要求は、後のRPCバッチで送信される可能性がより高い。

第1の態様の第1の実装形態に係る装置の第2の実装形態において、RPCマネージャは、格納されたRPC要求のそれぞれについて少なくとも1つのオブジェクトを決定し、時間および決定されたオブジェクトに基づいて格納されたRPC要求を順序付けるように構成されている。

これにより、RPCマネージャは、RPC要求の順序を決定するときに2つのパラメータを考慮に入れる。第1のパラメータは、RPC要求が生成された時間である。第2のパラメータは、RPCに関連付けられたオブジェクトである。異なるパラメータが考慮される場合、RPC要求の順序の決定はより柔軟性がある。オブジェクトは、データであってもよく、RPC要求に含められることができ、または、RPC要求においてある種のキーで参照されることができる。そのようなオブジェクトは、例えば、データベースオブジェクトまたは操作が行われるデータであってもよい。操作は、オブジェクトの追加、オブジェクトの削除、オブジェクトのフィールドの変更、オブジェクトのフィールドへの数学的操作の適用、オブジェクトの一部の回復、オブジェクトの他のスキーマへの変換、の1つであってもよい。

第1の態様の第2の実装形態に係る装置の第3の実装形態において、すべての順序付けられたRPC要求が同一のオブジェクトに対応する。

この状況では、オブジェクトに対応する複数のRPC要求が順序付けられ、前記複数のRPC要求のうち最も早いものに基づいて送信される。このようにして、1つの最も早く生成されたRPC要求が、伝送中の同一のオブジェクトに対応する複数のRPC要求の優先度を定義する。したがって、このオブジェクトに関連するRPCプロシージャの実行が容易になる。

第1の態様の第2の実装形態に係る装置の第4の実装形態において、RPCマネージャは、第2のオブジェクトに対応する格納されたRPC要求を順序付ける前に、第1のオブジェクトに対応するすべての格納されたRPC要求を順序付けるように構成され、第1のオブジェクトに対応する少なくとも1つの順序付けられたRPC要求は、第2のオブジェクトに対応する任意の順序付けられたRPC要求よりも早くクライアントによって生成された。

これは、1つのRPCバッチを介して1つのオブジェクトに対応する複数のRPC要求の伝送を容易にする。例えば、第2のRPC要求は、第1のRPC要求の後、第3のRPC要求の前に生成される。第1のRPC要求および第3のRPC要求が第1のオブジェクトに対応し、第2のRPC要求が第2のオブジェクトに対応すると仮定すると、第3のRPC要求は、第2のRPC要求よりも高い優先度を有するよう順序付けられる。

第1の態様の第4の実装形態に係る装置の第5の実装形態において、生成された各RPC要求のステータスは、データ構造に格納されるときに設定され、その後、以前に順序付けられたRPC要求のステータスに基づいて更新される。

特定の条件で設定および更新されることのできる、RPC要求のステータスを導入することにより、装置内のRPC要求の時宜を得たかつ便利な管理が容易になる。クライアントまたはRPCマネージャは、ある戦略に従ってRPC要求のステータスを設定または更新することができ、このことは、装置内の異なる部分の実行負荷を調整することを容易にする。

第1の態様の第5の実装形態に係る装置の第6の実装形態において、生成された各RPC要求のステータスは、PENDING、SENDABLE、SENTおよびCOMPLETED、のうちの1つである。生成されたRPC要求がデータ構造に格納された時点で、ステータスはPENDINGとして設定される。オブジェクトに対応する順序付けられたRPC要求が送信されず、前記オブジェクトに対応する以前に送信されたすべてのRPC要求のステータスがCOMPLETEDとして設定されている場合、ステータスはSENDABLEとして設定される。順序付けられたRPC要求が送信され、前記順序付けられたRPC要求に対する応答がクライアントによって受信されない場合、ステータスはSENTとして設定される。順序付けられたRPC要求に対する応答が受信された場合、ステータスはCOMPLETEDとして設定される。

RPC要求の4つのステータスは、装置内のRPCプロシージャの時宜を得た管理が保証されるように、一定の条件で互いに接続される。装置は、4つのステータスに基づいて各RPC要求に関連するRPCプロシージャ全体を正確に制御することができる。

第1の態様の先行する実装形態のいずれかに係る装置の第7の実装形態において、順序付けられたRPC要求は、装置内で実行しているスレッドによってバッチで送信される。

つまり、装置内で実行している任意のスレッドが使用され、順序付けられたRPC要求を含むバッチを送信することができる。スレッドは、RPC要求を生成する複数のスレッドのうちのいずれか1つと同一でもまたは異なっていてもよい。したがって、装置は、より効率的なプロセッサ（例えば、CPU）の使用につながるバッチを送信するための専用のスレッドを有する必要はない。

第1の態様の第7の実装形態に係る装置の第8の実装形態において、順序付けられたRPC要求は、装置の外部にあるサーバ、例えば、別のコンピューティング装置に送信される。

したがって、（2台のコンピュータ内に）互いに離れて配置され得る2つの装置間でRPC要求を伝送する効率が向上する。

第1の態様の先行する実装形態のいずれかに係る装置の第9の実装形態において、クライアントは、RPCマネージャによってアクセス可能な共有データ構造に生成されたRPC要求を格納するように構成されている。

つまり、クライアント内の複数のスレッド間で共有されるデータ構造は、RPCマネージャによってアクセスされることができる。したがって、共有データ構造に格納されたRPC要求に対する実行は、クライアントとRPCマネージャの両方によって行われるか、またはクライアントおよびRPCマネージャの両方の間で交換されることができる。実際には、内部処理および内部管理における装置の効率を柔軟に改善することができる。

第1の態様の第2〜第9の実装形態のいずれかに係る装置の第10の実装形態において、RPC要求に基づいて実行されるべき操作はデータベース操作であり、オブジェクトはデータベースオブジェクトである。

データベースは、技術分野と考えることができ、その中で、操作がデータベース操作を参照し、オブジェクトがデータベースオブジェクトを参照する。例えば、一連のデータベース操作は、データベースで行われることができる。データベース操作は、あるデータベース状態から別のデータベース状態へのマッピングである。そのようなマッピングは一貫性を保持する必要はない。さらなる例では、データベースオブジェクトは、データを格納または参照するために使用されるデータベース内の任意の定義されたオブジェクトである。例えば、データベースオブジェクトは、レコードの1つ以上のフィールド、1つ以上のレコード、または1つ以上のテーブルなどのデータベース内のデータの単位である。

本発明の第2の態様は、本発明の第1の態様に係る装置と、装置からRPCバッチを受信するように構成されているサーバとを含むシステムを提供する。

本発明の第3の態様は、複数のスレッドを実行する方法であって、複数のスレッドのそれぞれについて、操作を実行するためのRPC要求を装置によって生成するステップと、生成されたRPC要求を装置の（データベースに）メモリに、装置によって格納するステップと、格納されたRPC要求を、装置によって順序付けるステップと、RPCバッチで順序付けられたRPC要求を装置によって送信するステップとを含む、方法を提供する。

第3の態様に係る方法の第1の実装形態において、格納されたRPC要求が生成された時間に基づいて格納されたRPC要求が順序付けられる。

第3の態様の第1の実装形態に係る方法の第2の実装形態において、本方法は、格納されたRPC要求のそれぞれについて少なくとも1つのオブジェクトを装置によって決定するステップをさらに含み、格納されたRPC要求は、時間および決定されたオブジェクトに基づいて順序付けられる。

第3の態様の第2の実装形態に係る方法の第3の実装形態において、すべての順序付けられたRPC要求が同一のオブジェクトに対応する。

第3の態様の第2の実装形態に係る方法の第4の実装形態において、本方法は、第2のオブジェクトに対応する格納されたRPC要求を順序付ける前に、第1のオブジェクトに対応するすべての格納されたRPC要求を順序付けるステップをさらに含み、第1のオブジェクトに対応する少なくとも1つの順序付けられたRPC要求は、第2のオブジェクトに対応する任意の順序付けられたRPC要求よりも早く装置によって生成された。

第3の態様の第4の実装形態に係る方法の第5の実装形態において、生成された各RPC要求のステータスは、データ構造に格納されるときに設定され、その後、以前に順序付けられたRPC要求のステータスに基づいて更新される。

第3の態様の第5の実装形態に係る方法の第6の実装形態において、生成された各RPC要求のステータスは、PENDING、SENDABLE、SENTおよびCOMPLETED、のうちの1つである。生成されたRPC要求がデータ構造に格納された時点で、ステータスはPENDINGとして設定される。オブジェクトに対応する順序付けられたRPC要求が送信されず、前記オブジェクトに対応する以前に送信されたすべてのRPC要求のステータスがCOMPLETEDとして設定されている場合、ステータスはSENDABLEとして設定される。順序付けられたRPC要求が送信され、前記順序付けられたRPC要求に対する応答が装置によって受信されない場合、ステータスはSENTとして設定される。順序付けられたRPC要求に対する応答が受信された場合、ステータスはCOMPLETEDとして設定される。

第3の態様の先行する実装形態のいずれかに係る方法の第7の実装形態において、順序付けられたRPC要求は、装置内で実行しているスレッドによってバッチで送信される。

第3の態様の第7の実装形態に係る方法の第8の実装形態において、順序付けられたRPC要求は、装置の外部にあるサーバに送信される。

第3の態様の先行する実装形態のいずれかに係る方法の第9の実装形態において、本方法は、生成されたRPC要求を装置内の共有データ構造にさらに格納することができ、共有データ構造は、装置内のクライアントおよびRPCマネージャの両方によってアクセス可能である。

第3の態様の第2〜第9の実装形態のいずれかに係る方法の第10の実装形態において、RPC要求に基づいて実行されるべき操作はデータベース操作であり、オブジェクトはデータベースオブジェクトである。

本発明の方法は、装置について上述したのと同じ利点を達成する。本方法は、装置について上述した様々な実装形態によって実行される機能に対応する追加の方法ステップを用いて実行され得る。

本発明の上記の態様および実装形態は、添付の図面に関連して以下の特定の実施形態の説明において説明される。

本発明の実施形態に係る装置を概略的に示すブロック図を示す。本発明の実施形態に係るシステムを概略的に示すブロック図を示す。本発明の実施形態に係る複数のスレッドを実行する方法を示す。本発明の実施形態に係るRPC要求の管理プロセスを示す。本発明の実施形態に係るRPC要求を順序付ける方法を示す。本発明のさらなる実施形態に係るRPC要求の管理プロセスを示す。

図1は、本発明の実施形態に係る装置を概略的に示すブロック図を示す。装置100は、複数のスレッドを実行することができる。装置100は、RPCプロシージャをサポートする任意の装置、例えば、コンピュータであってもよい。

図1の装置100は、メモリ101、例えばクライアント103およびRPCマネージャ105であり得るRPC処理ユニットを含む。クライアント103およびRPCマネージャ105はそれぞれメモリ101に接続されている。接続は、例えば、読み出し、書き込みなど、メモリ101に格納されたデータの管理を、クライアント103およびRPCマネージャ105によってサポートすることができる。クライアント103は、ソフトウェアユニット、またはコンピュータ内のハードウェアであることができ、特定の機能を行うように構成されることができる。クライアント103によって行われる機能の例が以下に示される。

図2は、本発明の実施形態に係るシステムを概略的に示すブロック図を示す。システムはコンピュータシステムであってもよい。コンピュータシステムは、装置100およびサーバ200を含む。サーバ200は、装置100の外部に配置された装置、例えば、装置100と通信可能な遠隔装置であってもよい。あるいは、サーバ200は、装置100の一部であってもよく、例えば、装置100の内部に配置されたユニットであってもよい。つまり、装置100をシステムと見なし、サーバ200とクライアント103との間の通信は装置100内である。

図1および図2に示すように、クライアント103は、複数のスレッドのそれぞれに対して、操作を実行するためのRPC要求を生成し、生成されたRPC要求をメモリ101に格納するように構成されている。RPCマネージャ105は、格納されたRPC要求を順序付けるように構成されている。クライアント103は、順序付けられたRPC要求をRPCバッチで送信するようにさらに構成されている。

一例では、RPC要求に基づいて実行されるべき操作はデータベース操作であり、オブジェクトはデータベースオブジェクトである。データベース操作は、データベース上で実行されることができ、あるデータベース状態から別のデータベース状態へのマッピングとして定義され得る。このようなマッピングは、データの一貫性を保持する必要はない。データベースオブジェクトは、データを格納または参照するために使用される、データベース内の任意の定義されたオブジェクトであってもよい。例えば、データベースオブジェクトは、レコードの1つ以上のフィールド、1つ以上のレコード、または1つ以上のテーブルなどのデータベース内のデータの単位である。

図3は、本発明の実施形態に係る、複数のスレッドを実行する方法を示し、それは図1および図2に示すように、装置100によって行われることができる。複数のスレッドのそれぞれについて、クライアント103は、操作を実行するためのRPC要求を生成し（ステップ301）、生成されたRPC要求をメモリ101にさらに格納する（ステップ303）。RPCマネージャ105は、格納されたRPC要求を順序付けて、順序付けられたRPC要求をクライアントがRPCバッチで送信できるようにする（ステップ305、ステップ307）。

装置100は、マルチタスク環境で使用されてもよい。最も簡単なのはマルチスレッドである。したがって、ステップ301において、クライアント103内の1つのスレッドは、複数のスレッドをシミュレートして複数のRPC要求を生成することができる。

本発明では、順序付けられたRPC要求を送信するためにどのスレッドが使用されるかは限定されない。つまり、順序付けられたRPC要求は、装置100内で実行する任意のスレッドによってバッチで送信されることができる。RPC要求を生成するスレッドがRPC要求を送信し、その対応するRPC応答を待たなければならない従来技術と比較して、クライアント103は、順序付けられたRPC要求を含むバッチを、順序付けられたRPC要求を生成するスレッドとは異なるスレッドを用いて送信することができる。RPCプロシージャによって占有されているスレッドは、時宜を得て解放され、他のRPC要求を生成するために使用されることができる。したがって、装置100におけるRPC要求の処理の効率が向上する。

さらに、装置100内で実行しているスレッドは、その機能によって区別されることができる。専用のスレッドソリューションでは、1つ以上のスレッドが、バッチを送信するなどのネットワーク通信を行うために専用化されている場合がある。例えば、スレッドはRPC要求を生成するために専用化されてもよいものもあれば、スレッドはRPCバッチを送信するために専用化されてもよいものもある。したがって、クライアント103は、RPCバッチを送信するための特定のスレッドまたはスレッドの特定のグループを決定するようにさらに構成されることができる。このようにして、装置100におけるRPC要求を処理する改善された効率を保証することができる。

クライアント103は、生成されたRPC要求を、RPCマネージャ105によってアクセス可能な共有データ構造400に格納するように構成されることができる。共有データ構造400は、データベース、例えば、メモリ101内にあってもよい。

装置100は、優先順位付け機構を使用してRPC要求を所望通りに並べ替え得る。異なる優先順位付け機構では、異なるパラメータが考慮されてもよい。例えば、パラメータ「世代時間」は、より早くに生成されたRPC要求へより高い優先度を与え得る。RPCに関連付けられるパラメータ「サービス品質」は、サービスの特定の質に関連付けられているRPC要求へより高い優先度を与え得る。パラメータ“RPC size”は、特定のサイズのRPC要求へより高い優先度を与え得る。パラメータ「宛先アドレス」は、特定の宛先アドレスを有するRPC要求へより高い優先度を与え得る。

以下の実施形態では、優先順位付け機構のパラメータは、生成時間、すなわち、RPC要求が生成される時間である。

図4は、本発明の実施形態に係るRPC要求の管理プロセスを示す。図4の「時間」は、例えば、システム内の実行しているクロックを示し得る。各RPC要求1、2、3および4は、クライアント103によって、時間t1、t2、t3、t4でそれぞれ生成される。共有データ構造400は、スレッド1、スレッド2およびスレッド3のうちの1つによって生成されたRPC要求1、2、3および4を格納する。共有データ構造400にアクセス可能なRPCマネージャ105は、格納されたRPC要求1、2、3および4がクライアント103によって生成された時間に基づいてRPC要求1、2、3および4を順序付ける。クライアント103は、時間tn、例えば、スレッド4が共有データ構造400を読み取り、RPCバッチXを送信する所定の時間で、スレッド4によって、順序付けられたRPC要求1、2、3および4を含むRPCバッチXをサーバに送信する。クライアントは、RPCバッチXに含まれるRPC要求に対応するRPC応答を取得するように、連続してプールする。

格納されたRPC要求のランキングを決定するときに、RPCマネージャ105が、1つのパラメータ、例えば、格納されたRPC要求が生成される時間などを考慮する場合、RPCバッチXに含まれるRPC要求は、図4に示すように、「スレッド1によって生成されたRPC要求1→スレッド2によって生成されたRPC要求2→スレッド3によって生成されたRPC要求3→スレッド2によって生成されたRPC要求4」の順序を有することができる。このシーケンスは、RPCマネージャ105がどのようにしてRPC要求1、2、3および4を順次順序付けるかを示す。例えば、RPC要求1は、RPCマネージャ105によってより早くに順序付けられる。これは、RPC要求1のランキングが、RPC要求2、3および4のランキングよりも高いことを意味する。したがって、RPCバッチXでグループ化されているとき、RPC要求1はRPC要求2、3、4と比較してより高い優先度を有する。

さらに、RPCマネージャ105は、格納されたRPC要求のそれぞれについて1つのオブジェクトを決定し、格納されたRPC要求が生成された時間と決定されたオブジェクトの2つのパラメータに基づいて格納されたRPC要求を順序付けるように構成されることができる。つまり、各RPC要求のランキングは、格納されたRPC要求が生成された時間と決定されたオブジェクトに基づいて決定される。共有データ構造400内のRPC要求の順序は、すべてのRPC要求のランキングに基づいて決定される。特に、RPCマネージャ105は、時間およびオブジェクトに基づいて各RPC要求のランキングを割り当てるように構成されている。ランキングは、RPC要求がRPCマネージャ105によってどのように順序付けられるかを示す。

所与のオブジェクトに対して、オブジェクトに対応するRPC要求は、上述のようにRPC要求が生成される時間に従って順序付けられる。

RPC要求1、2、3および4が同一のオブジェクトに対応すると仮定すると、RPCバッチXに含まれるRPC要求は、「RPC要求1→RPC要求2→RPC要求3→RPC要求4」の順序を有することができる。

あるいは、RPC要求1、2、3および4は異なるオブジェクトに対応していてもよい。例えば、RPC要求1および3はオブジェクト1に対応し、RPC要求2はオブジェクト2に対応し、RPC要求4はオブジェクト3に対応する。RPCマネージャ105は、図5に示すようにRPC要求1、2、3および4をどのように順序付けるかを決定することができる。

図3のステップ305の一例として、図5は、本発明の実施形態に係るRPC要求を順序付ける方法を示す。テーブル500は、クライアント103によって生成されるRPC要求の情報を含む。つまり、共有データ構造400に格納されたRPC要求はテーブル500に記録されることができる。

テーブル500は、メモリ101に格納されることができ、クライアント103およびRPCマネージャ105の両方によってアクセス可能である。テーブル500は、RPC要求に関連する任意のパラメータが変更されるたびに更新されることができる。つまり、クライアント103およびRPCマネージャ105の両方は、1つ以上のRPC要求に関連する実行をトリガとしてテーブル500を更新することができる。一例では、テーブル500は、1つ以上のRPC要求が順序付けられるたびに、RPCマネージャ105によって更新される。別の例では、テーブル500は、1つ以上のRPC要求が生成されるたびに、クライアント103によって更新される。

図5に示すように、RPCマネージャ105は、順序付けられていないRPC要求のうち、どのRPC要求がクライアント103によって生成された最も早いRPC要求であるかを決定する（ステップ501）。RPCマネージャ105は、他の生成されたRPC要求を順序付ける前に、この最も早いRPC要求を順序付ける。つまり、RPCマネージャ105は、この最も早いRPC要求のランキングを割り当てて、この最も早いRPC要求を順序付けるために、順序付けられていないRPC要求の中で最も高い優先度を与える。RPCマネージャ105は、それに応じてテーブル500をさらに更新することができる。例えば、RPCマネージャ105は、テーブル500において、この最も早いRPC要求（例えば、RPC要求1）のランキングを「1」として割り当てる。

ステップ503において、RPCマネージャ105は、この最も早いRPC要求が属するのはどのオブジェクトかを決定する。例えば、オブジェクト1が決定され、テーブル500に記録される（図5には示されていない）。

ステップ505において、RPCマネージャ105は、同一の決定されたオブジェクトに対応する他のRPC要求があるかどうかをチェックする。そうである場合、これらのRPC要求は、各RPC要求が生成される時間に基づいてRPCマネージャ105によって順序付けられる。例えば、RPC要求3およびRPC要求1は同一のオブジェクトに属しているため、RPCマネージャ105は、RPC要求2を順序付けるより早くRPC要求3を順序付ける。さらに、RPCマネージャ105は、それに応じてテーブル500を更新することができる。例えば、RPCマネージャ105は、テーブル500でRPC要求3のランキングを「2」と割り当てる。

同一の決定されたオブジェクトに対応するすべてのRPC要求が順序付けられている場合、RPCマネージャ105は、生成されたが順序付けられていないすべてのRPC要求のうち、どのRPC要求がクライアント103によって生成された最も早いものであるかを決定する。例えば、RPCマネージャ105は、ステップ501、502および503のプロシージャを反復アルゴリズムとして採用する。すなわち、図5に示すように、毎回異なる（更新された）複数のRPC要求をプロシージャの入力とすると、RPCマネージャ105は、時間およびオブジェクトなどのパラメータに基づいて、メモリ101に格納されたRPC要求を連続して順序付ける。

図6は、本発明のさらなる実施形態に係るRPC要求の管理プロセスを示す。

図6に示すように、テーブル600は、共有データ構造400に格納されたRPC要求を管理するために使用されるいくつかのパラメータを含む。パラメータは、RPC要求がクライアント103によって生成される「生成時間」、RPC要求が属する「オブジェクト」、RPCマネージャ105がRPC要求に対して割り当てる「ランキング」を含む。

パラメータは、各RPC要求のステータスをさらに含む。ステータスは、クライアント103またはRPCマネージャ105によって設定および更新されることが可能である。一例では、クライアント103は、RPC要求を共有データ構造400に格納するときに、RPC要求のステータスを設定する。別の例では、RPCマネージャ105は、以前に順序付けられたRPC要求のステータスに基づいてRPC要求のステータスを更新（リセット）することができる。

各RPC要求のステータスは、以下のPENDING、SENDABLE、SENT、およびCOMPLETEDのうちの1つであることができる。

図6に示すように、クライアント103は、RPC要求1−8のそれぞれが共有データ構造400に格納された時点で、PENDINGとしてRPC要求1−8の各ステータスを設定する。装置100は、PENDINGのステータスでRPC要求を送信する準備ができていない。

RPCマネージャ105は、例えば上記の図5の方法でRPC要求を順序付け、順序付けるステップの結果をテーブル600の項目「順序付け」に記録する。

図6に示すように、T_Aでは、RPC要求1より早くに生成されたRPC要求に対応するRPC応答の一部のみが装置100によって受信されたと仮定する。例えば、オブジェクト1およびオブジェクト2に属するRPC要求に対応するすべてのRPC応答が受信されたとする。オブジェクト3に属するRPC要求に対応するRPC応答は受信されていない。

T_Aにおいて、クライアント103は、オブジェクト1に属するすべてのRPC要求（すなわち、RPC要求1および3）のステータスをSENDABLEとして設定する。

RPCバッチが、より多くのRPC要求、例えば6 RPC要求を含むように装置100によって決定されると仮定する。T_Bにおいて、クライアント103は、オブジェクト2に属するすべてのRPC要求（すなわち、RPC要求2、5および7）のステータスをSENDABLEとしてさらに設定する。

オブジェクト3に属するすべての他の順序付けられたRPC要求（すなわち、RPC要求4、6および8）は、T_BでRPCマネージャ105によって順序付けられない。以前に生成され、オブジェクト3に属するRPC要求（SENTのステータスを有する）に対応するRPC応答は、受信されていないため、RPC要求4、6、および8はいずれも更新されない、すなわち、RPCバッチがもう1のRPC要求を含める能力を有するにもかかわらず、SENDABLEのステータスとして設定する。

クライアント103は、RPC要求1、2、3、5および7をそれらの順序に基づいてRPCバッチにバッチ処理する。さらに、クライアント103は、RPCバッチをサーバに送信し、T_CでSENTとしてRPC要求1、2、3、5および7のステータスを更新する。

T_Cの後に、RPC要求1、2、3および5に対応するRPC応答が装置100によって受信されたと仮定する。T_Dにおいて、クライアント103は、RPC要求1、2、3および5のステータスをCOMPLETEDとして設定する。RPC要求7に対応するRPC応答がT_Dの前に受信されなかったため、RPC要求7のステータスはSENTとして維持される。

さらに、以前に生成され、オブジェクト3に属するRPC要求に対応するRPC応答もまた、T_Dの前に装置100によって受信されたと仮定する。以前に生成され、オブジェクト3に属するRPC要求のステータスは、COMPLETEDとして設定されることができる（図6には示されていない）。T_Dにおいて、クライアント103は、オブジェクト3に属するRPC要求のステータス、すなわち、RPC要求4、6および8をSENDABLEとして設定することができる。

RPC要求4、6および8のステータスは、RPC要求4、6および8を含むRPCバッチが送信されたときにクライアント103によって更新される。

RPC要求に関連するパラメータは任意であり、同時に1つのテーブルに限定されるものではない。RPC要求の管理を実施するためにクライアント103およびRPCマネージャ105をサポートする任意の機構が本発明に含まれる。

要約すると、装置100および複数のスレッドを実行する方法は、RPCプロシージャの効率を向上させることができる。

本発明は、本明細書の様々な実施形態と共に説明されている。しかしながら、開示された実施形態に対する他の変更は、図面、開示、および添付の特許請求の範囲の検討から、請求の範囲に記載の本発明を実施する際の当業者によって理解され、達成されることができる。特許請求の範囲において、「備える（comprising）」という用語は他の要素またはステップを除外するものではなく、不定冠詞「a」または「an」は複数を除外しない。単一のプロセッサまたは他のユニットが、請求項に列挙されたいくつかの項目の機能を果たし得る。特定の手段が相互に異なる従属請求項に列挙されているという単なる事実は、これらの手段の組み合わせが有利に使用できないことを示すものではない。コンピュータプログラムは、他のハードウェアと一緒にまたは他のハードウェアの一部として供給される光記憶媒体または固体媒体のような適切な媒体上に格納／分配され得るが、インターネットまたは他の有線または無線電気通信システムを介してなど、他の形態でも分配され得る。

100 装置
101 メモリ
103 クライアント
105 RPCマネージャ
200 サーバ
400 共有データ構造
500 テーブル
600 テーブル
X RPCバッチ

Claims

複数のスレッドを実行するための装置であって、前記装置は、
メモリと、
前記複数のスレッドのそれぞれに対して、操作を実行するための、リモートプロシージャコール、RPC、要求を生成し、前記生成されたRPC要求を前記メモリに格納するように構成された、クライアントと、
前記格納されたRPC要求のそれぞれについて少なくとも1つのオブジェクトを決定し、前記格納されたRPC要求が生成された時間と前記決定されたオブジェクトとに基づいて前記格納されたRPC要求を順序付けるように構成されたRPCマネージャと、
を備え、
前記クライアントは、前記順序付けられたRPC要求をRPCバッチで送信するようにさらに構成されており、前記RPCバッチは、異なるスレッドに対して生成されたRPC要求を含み、
前記RPCマネージャは、第2のオブジェクトに対応する格納されたRPC要求を順序付ける前に、第1のオブジェクトに対応するすべての前記格納されたRPC要求を順序付けるように構成され、前記第1のオブジェクトに対応する少なくとも1つの順序付けられたRPC要求は、前記第2のオブジェクトに対応する任意の順序付けられたRPC要求よりも早くに前記クライアントによって生成された、
装置。
生成された各RPC要求のステータスは、データ構造に格納されるときに設定され、その後、以前に順序付けられたRPC要求のステータスに基づいて更新される、請求項1に記載の装置。
生成された各RPC要求の前記ステータスは、以下の、
前記生成されたRPC要求が前記データ構造に格納された瞬間に設定される、PENDING、
オブジェクトに対応する前記順序付けられたRPC要求が送信されず、前記オブジェクトに対応する以前に送信されたすべてのRPC要求のステータスがCOMPLETEDとして設定されている場合の、SENDABLE、
前記順序付けられたRPC要求が送信され、前記順序付けられたRPC要求に対する応答が前記クライアントによって受信されない場合の、SENT、
前記順序付けられたRPC要求に対する前記応答が受信された場合の、COMPLETED
のうちの1つである、請求項2に記載の装置。
前記順序付けられたすべてのRPC要求が同一のオブジェクトに対応する、請求項1に記載の装置。
前記RPC要求に基づいて実行されるべき前記操作はデータベース操作であり、前記オブジェクトはデータベースオブジェクトである、請求項1〜4のいずれか一項に記載の装置。
前記順序付けられたRPC要求は、前記装置内で実行しているスレッドによって前記バッチ内で送信される、請求項1〜5のいずれか一項に記載の装置。
前記順序付けられたRPC要求は、前記装置の外部にあるサーバに送信される、請求項6に記載の装置。
前記クライアントは、前記RPCマネージャによってアクセス可能な共有データ構造に前記生成されたRPC要求を格納するように構成されている、請求項1〜7のいずれか一項に記載の装置。
請求項1〜8のいずれか一項に記載の装置と、
前記装置から前記RPCバッチを受信するように構成されているサーバと
を備える、システム。
複数のスレッドを実行する方法であって、
前記複数のスレッドのそれぞれについて、操作を実行するためのリモートプロシージャコール、RPC、要求を、装置によって、生成するステップと、
前記生成されたRPC要求を前記装置のメモリに、前記装置によって格納するステップと、
前記格納されたRPC要求のそれぞれについて、少なくとも1つのオブジェクトを前記装置によって決定するステップと、
前記格納されたRPC要求が生成される時間と前記決定されたオブジェクトとに基づいて前記格納されたRPC要求を、前記装置によって順序付けるステップと、
RPCバッチで前記順序付けられたRPC要求を前記装置によって送信するステップと
を含み、
前記RPCバッチは、異なるスレッドに対して生成されたRPC要求を含み、
前記方法は、第2のオブジェクトに対応する格納されたRPC要求を順序付ける前に、第1のオブジェクトに対応するすべての前記格納されたRPC要求を順序付けるステップをさらに含み、前記第1のオブジェクトに対応する少なくとも1つの順序付けられたRPC要求は、前記第2のオブジェクトに対応する任意の順序付けられたRPC要求よりも早くに前記装置によって生成された、
方法。
生成された各RPC要求のステータスは、データ構造に格納されるときに設定され、その後、以前に順序付けられたRPC要求のステータスに基づいて更新される、請求項10に記載の方法。
生成された各RPC要求の前記ステータスは、以下の、
前記生成されたRPC要求が前記データ構造に格納された瞬間に設定される、PENDING、
オブジェクトに対応する前記順序付けられたRPC要求が送信されず、前記オブジェクト
に対応する以前に送信されたすべてのRPC要求のステータスがCOMPLETEDとして設定されている場合の、SENDABLE、
前記順序付けられたRPC要求が送信され、前記順序付けられたRPC要求に対する応答が前記装置によって受信されない場合の、SENT、
前記順序付けられたRPC要求に対する前記応答が受信された場合の、COMPLETED
のうちの1つである、請求項11に記載の方法。
前記順序付けられたすべてのRPC要求が同一のオブジェクトに対応する、請求項10に記載の方法。
前記RPC要求に基づいて実行されるべき前記操作はデータベース操作であり、前記オブジェクトはデータベースオブジェクトである、請求項10〜13のいずれか一項に記載の方法。
前記順序付けられたRPC要求は、前記装置内で実行しているスレッドによって前記バッチ内で送信される、請求項10〜14のいずれか一項に記載の方法。
前記順序付けられたRPC要求は、前記装置の外部にあるサーバに送信される、請求項15に記載の方法。
前記方法は、前記生成されたRPC要求を前記装置内の共有データ構造に格納するステップをさらに含み、前記共有データ構造は、前記装置内のクライアントおよびRPCマネージャの両方によってアクセス可能である、請求項10〜16のいずれか一項に記載の方法。