(57)【要約】【課題】コンポーネント内の入れ子状の同期呼び出しを実施してもスレッド枯渇に起因したデッドロックの発生を解消させる。【解決手段】コンポーネント内の処理実行スレッドの指示に応じて処理を実行する処理実行手段を有し、前記処理実行手段は、一連の連続する処理を識別する処理識別情報を含む処理要求のうち予め指定された処理識別情報を含む処理要求を受信する受信手段と、前記受信手段により受信された処理要求を実行する実行手段と、を有することによって課題を解決する。【選択図】図７
2014229121.tif 000002
【特許請求の範囲】
【請求項１】
コンポーネント内の処理実行スレッドの指示に応じて処理を実行する処理実行手段を有し、
前記処理実行手段は、
一連の連続する処理を識別する処理識別情報を含む処理要求のうち予め指定された処理識別情報を含む処理要求を受信する受信手段と、
前記受信手段により受信された処理要求を実行する実行手段と、
を有する情報処理装置。
【請求項２】
前記処理実行手段に処理を要求する処理要求手段を更に有し、
前記処理要求手段は、
前記処理識別情報を付加した処理要求を前記処理実行手段に送信する送信手段を有する請求項１記載の情報処理装置。
【請求項３】
前記処理実行手段は、
前記処理実行手段が属するコンポーネントを識別するコンポーネント識別情報を前記処理要求手段と共有する記憶領域に管理する管理手段を更に有し、
前記処理要求手段は、
前記処理要求手段が管理している前記処理要求手段が属するコンポーネントを識別するコンポーネント識別情報と、前記管理手段により管理されているコンポーネント識別情報とが一致する場合、前記処理識別情報を付加した処理要求を前記処理実行手段に送信する請求項２記載の情報処理装置。
【請求項４】
前記処理実行手段は、
処理要求に前記処理識別情報が含まれているか否かを判定する判定手段を更に有し、
前記受信手段は、前記判定手段により含まれていると判定された場合、処理要求のうち予め指定された処理識別情報を含む処理要求を受信し、含まれていないと判定された場合、処理要求を要求順に受信する請求項１乃至３何れか１項記載の情報処理装置。
【請求項５】
前記受信手段は、前記判定手段により前記処理識別情報が含まれていると判定された複数の処理要求に、前記予め指定された処理識別情報を含む処理要求が含まれていない場合、処理要求を受信しない請求項４記載の情報処理装置。
【請求項６】
前記実行手段は、前記処理実行スレッドが複数ある場合であって、前記受信手段により複数の処理要求が受信された場合、前記受信された複数の処理要求を並列して実行する請求項１乃至５何れか１項記載の情報処理装置。
【請求項７】
前記実行手段により実行された処理要求に係る応答を前記処理要求手段に送信する応答送信手段を更に有し、
前記処理要求手段は、
前記応答送信手段により送信された応答を受信する応答受信手段を更に有する請求項２乃至６何れか１項記載の情報処理装置。
【請求項８】
前記応答送信手段は、処理要求が同期呼び出しに係る処理要求の場合、前記応答を前記処理要求手段に送信する請求項７記載の情報処理装置。
【請求項９】
コンポーネント内の処理実行スレッドの指示に応じて処理を実行する処理実行手段と、
前記処理実行手段に処理を要求する処理要求手段と、
を有し、
前記処理要求手段は、
一連の連続する処理を識別する処理識別情報を付加した処理要求を前記処理実行手段に送信する送信手段を有し、
前記処理実行手段は、
前記送信手段により送信された前記処理識別情報を含む処理要求のうち、予め指定された処理識別情報を含む処理要求を受信する受信手段と、
前記受信手段により受信された処理要求を実行する実行手段と、
を有するシステム。
【請求項１０】
コンポーネント内の処理実行スレッドの指示に応じて処理を実行する処理実行手段が実行する情報処理方法であって、
一連の連続する処理を識別する処理識別情報を含む処理要求のうち予め指定された処理識別情報を含む処理要求を受信する受信ステップと、
前記受信ステップにより受信された処理要求を実行する実行ステップと、
を含む情報処理方法。
【請求項１１】
コンポーネント内の処理実行スレッドの指示に応じて処理を実行する処理実行手段と、
前記処理実行手段に処理を要求する処理要求手段と、
を有するシステムにおける情報処理方法であって、
前記処理要求手段が、一連の連続する処理を識別する処理識別情報を付加した処理要求を前記処理実行手段に送信する送信ステップと、
前記処理実行手段が、前記送信ステップにより送信された前記処理識別情報を含む処理要求のうち、予め指定された処理識別情報を含む処理要求を受信する受信ステップと、
前記処理実行手段が、前記受信ステップにより受信された処理要求を実行する実行ステップと、
を含む情報処理方法。
【請求項１２】
コンピュータを、
コンポーネント内の処理実行スレッドの指示に応じて処理を実行する処理実行手段として機能させ、
前記処理実行手段は、
一連の連続する処理を識別する処理識別情報を含む処理要求のうち予め指定された処理識別情報を含む処理要求を受信する受信手段と、
前記受信手段により受信された処理要求を実行する実行手段と、
を有するプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
ソフトウェア開発の多様化、複雑化、肥大化への対策として、並行分業開発による効率化、ソフトウェア部品再利用による品質向上を実現するため、コンポーネント開発が一般に実施されている。コンポーネント開発は、ソフトウェアの部品（コンポーネント）化をサポートする分散開発フレームワークを利用して開発が行われる。代表的な分散開発フレームワークには、ＳｕｎＲＰＣ、ＣＯＲＢＡ（Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ）等がある。分散開発フレームワークは、コンポーネントのインタフェース情報を基にコンポーネントインタフェース部、コンポーネント間通信制御部、タスク制御部を含むフレームワークを開発者に提供し、コンポーネント開発をサポートする。前記フレームワークは、機能を提供するサーバコンポーネント開発をサポートするサーバスタブ、サーバコンポーネントへ機能実行依頼をするクライアントコンポーネント開発をサポートするクライアントスタブを提供する。サーバスタブは、クライアントからのリクエストを受け付ける受信ポートと、受信したリクエストに対応するサーバコンポーネントの機能を実行するタスクとで構成される。クライアントスタブは、クライアントコンポーネントにリクエストインタフェースを公開し、リクエストをメッセージに変換してサーバスタブの受信ポートへ送信する。クライアントスタブ、サーバスタブで分散環境下の通信処理を隠すことにより、コンポーネント開発者はコンポーネントのサービスロジック部分の開発に集中することが可能となる。
しかしながら、開発者は、分散開発フレームワークを用いて並行にプログラムを実行させる場合、リソース管理に気を配る必要がある。特に、開発者は、サービスロジック部以外の分散フレームワーク内部のリソース枯渇によるデッドロックを解析することが困難である。
特許文献１では、分散フレームワークで発生するデッドロック問題を解消する技術が提案されている。特許文献１に開示されている技術は、ロックの取り合いによるデッドロックの回避を意図している。より具体的には、特許文献１に開示されている技術は、分散フレームワーク間のリクエスト毎に別々のスレッドを割り当てている。このことにより、スレッド枯渇によるデッドロックを解消することができる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−２７３１５６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、スレッドの数は有限であり、特に組み込み機器の分野では、スレッド生成オーバヘッドと、スレッドリソースとが制限されるため、最低限のスレッドでの開発が求められる。
本発明は、上述課題を鑑みてなされたものであり、コンポーネント内の入れ子状の同期呼び出しを実施してもスレッド枯渇に起因したデッドロックの発生を解消させることを目的とする。
【課題を解決するための手段】
【０００５】
そこで、本発明は、コンポーネント内の処理実行スレッドの指示に応じて処理を実行する処理実行手段を有し、前記処理実行手段は、一連の連続する処理を識別する処理識別情報を含む処理要求のうち予め指定された処理識別情報を含む処理要求を受信する受信手段と、前記受信手段により受信された処理要求を実行する実行手段と、を有する。
【発明の効果】
【０００６】
本発明によれば、コンポーネント内の入れ子状の同期呼び出しを実施してもスレッド枯渇に起因したデッドロックの発生を解消させることができる。
【図面の簡単な説明】
【０００７】
【図１】デッドロックを説明するための情報処理装置の一例を示す図である。
【図２】情報処理装置のハードウェア構成の一例を示す図である。
【図３】情報処理装置のソフトウェア構成の一例を示す図である。
【図４】コンポーネント名称の一例を示す図（その１）である。
【図５】コンポーネント名称の一例を示す図（その２）である。
【図６】クライアントスタブの処理の一例を示すフローチャートである。
【図７】サーバスタブの処理の一例を示すフローチャートである。
【図８】遠隔手続呼出リクエストの一例を示す図（その１）である。
【図９】シーケンス識別子の一例を示す図である。
【図１０】実施形態２における処理の一例を示すフローチャートである。
【図１１】遠隔手続呼出リクエストの一例を示す図（その２）である。
【発明を実施するための形態】
【０００８】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
＜実施形態１＞
まず、図１を用いて分散フレームワークのスレッド枯渇によるデッドロックを説明する。なお、スレッドとは、ＣＰＵが実行する処理における処理単位である。
図１は、デッドロックを説明するための情報処理装置の一例を示す図である。
以下、図１の情報処理装置の構成と、典型的なコンポーネント間通信とについて説明する。なお、コンポーネントとは、ある機能を実現するために部品化されたソフトウェアのことである
図１は、サーバコンポーネント１０７が分散開発フレームワークを介してクライアントコンポーネント１０１にサービスを提供する構成を示している。ここで、サーバコンポーネントとは、機能を提供するコンポーネントである。また、クライアントコンポーネントとは、サーバコンポーネントに機能の実行を依頼するコンポーネントである。
サーバコンポーネント１０７と、クライアントコンポーネント１０１とは、それぞれがアドレス空間を共有するプロセスとして構成されている。
分散開発フレームワークは、サーバ処理１０８のインタフェース情報からクライアントスタブ１０４と、クライアントスタブ１１４と、サーバスタブ１１１とを生成してコンポーネント間の通信をサポートする。なお、ここでいうスタブとは、コンポーネント間の通信を仲介する機能のことである。
クライアントスタブ１０４及びクライアントスタブ１１４は、クライアントに対して遠隔手続呼出インタフェース１０３及び遠隔手続呼出インタフェース１１０を提供する。そして、クライアントスタブ１０４及びクライアントスタブ１１４は、受け付けたリクエストをメッセージに変換してサーバスタブ１１１の受信ポート１１３に送信する。クライアントスタブ１０４は、リクエストに対するリプライを受け付けるための返信ポート１０５を有する。クライアントスタブ１１４は、リクエストに対するリプライを受け付けるための返信ポート１１５を有する。
サーバスタブ１１１は、１つのリクエスト実行スレッド１１２を有し、受信ポート１１３からリクエストを受信して遠隔手続１０９を実行する。なお、図１に示されるサーバコンポーネント１０７は、プロセスが異なるクライアントコンポーネント１０１のリクエスト１０６と、自身のプロセス内からのリクエスト１１６とを受け付ける構成を示している。
【０００９】
次に、デッドロックが発生するシーケンス処理について説明する。
クライアント実行スレッド１０２は、遠隔手続呼出インタフェース１０３を実行する。そして、クライアントスタブ１０４は、リクエスト１０６をサーバスタブ１１１の受信ポート１１３に送信して、返信ポート１０５への返信を受信待ちする。
サーバスタブ１１１のリクエスト実行スレッド１１２は、リクエスト１０６を受信し、遠隔手続１０９を実行する。
遠隔手続１０９は、サーバスタブ１１１を介して処理される遠隔手続呼出インタフェース１１０を実行する。
クライアントスタブ１１４は、リクエスト１１６をサーバスタブ１１１の受信ポート１１３に送信して、返信ポート１１５への返信を受信待ちする。
上述したように、コンポーネントから自身のコンポーネントを同期呼び出しするシーケンス処理を入れ子状に繰り返すと、呼び出し毎に返信待ちでスレッドのブロックが生じる。なお、ここでいう同期呼び出しとは、処理が完了するまで処理の呼び出し元が待機する呼び出し方式のことである。サーバスタブ１１１が有するリクエスト実行スレッド１１２の数は有限であるため、返信待ちにより新規にリクエストを処理することができるリクエスト実行スレッド１１２が枯渇する。図１の構成ではリクエスト実行スレッド１１２が１つしか存在しないため、リクエスト１０６の実行中にリクエスト１１６を実行するスレッドが存在せず、クライアントスタブ１１４の返信受信待ちが解除されずデッドロックが発生する。
【００１０】
以下、本実施形態の情報処理装置について説明する。
図２は、本実施形態における情報処理装置２０１のハードウェア構成の一例を示す図である。
ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２０２は、バス２０５を介してＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）２０３や、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）２０４等と接続し、情報処理装置２０１を制御する。ＣＰＵ２０２が、ＲＯＭ２０３等に格納されているプログラムを実行することにより、後述する情報処理装置２０１の機能（ソフトウェア構成）及びフローチャートに係る処理が実現される。
ＲＯＭ２０３は、読み出し専用メモリであり、本実施形態では変更を必要としないプログラムや、パラメータ等の情報を格納する。
ＲＡＭ２０４は、読み書き可能なメモリであり、本実施形態では情報処理装置２０１により作成及び変更されるパラメータに関する情報（以下、単にパラメータという）を格納する。
なお、本実施形態では、プログラムや、変更を必要としないパラメータがＲＯＭ２０３上に配置され、情報処理装置２０１により作成及び変更されるパラメータがＲＡＭ上に配置されるものとした。しかし、上記のプログラムや、パラメータは全てハードディスクドライブ等の外部記憶装置上に配置されるようにしてもよい。その場合、ＣＰＵ２０２は、必要に応じて上記のプログラムや、パラメータを外部記憶装置からＲＡＭ上にロードして使用することができる。その他にも、上記のプログラムや、パラメータは、ＣＰＵ２０２のキャッシュメモリ上に配置されるようにしてもよい。
【００１１】
図３は、本実施形態の遠隔手続呼出システムを搭載した情報処理装置２０１のソフトウェア構成の一例を示す図である。
図３に示される情報処理装置２０１は、サービス提供側のサーバコンポーネント３１０と、サービス利用側のクライアントコンポーネント３０２とを有している。サーバコンポーネント３１０と、クライアントコンポーネント３０２とは、それぞれがアドレス空間を共有するプロセスとして構成されている。なお、本実施形態では、図３に示されるように情報処理装置２０１が、クライアントコンポーネント３０２と、サーバコンポーネント３１０との両方のコンポーネントを有するものとした。しかし、これに限る必要はなく、本実施形態の遠隔手続呼出システムは、クライアントコンポーネント３０２と、サーバコンポーネント３１０とをコンポーネント毎に複数の異なる情報処理装置へ搭載するようにしてもよい。
クライアントコンポーネント３０２からサーバコンポーネント３１０へのリクエストは遠隔手続呼出インタフェース３０５によって行われる。
図３において、実線３０９及び実線３２２等は、リクエストの流れを示し、点線３２５及び点線３２８等は、リクエストに対する返信の流れを示している。
プロセス間通信を実現する遠隔手続呼出は、分散開発フレームワークによって実現される。分散開発フレームワークは、ＣＯＲＢＡ（登録商標）等と同様にサーバ処理３１１が公開する遠隔手続３１７及び遠隔手続３２３のインタフェース情報からクライアントスタブ３０６、クライアントスタブ３１９及びサーバスタブ３１２を生成する。そして、クライアントスタブ３０６、クライアントスタブ３１９及びサーバスタブ３１２は、コンポーネント間の通信をサポートする。
【００１２】
以下、クライアントコンポーネント３０２、クライアントスタブ３０６、サーバコンポーネント３１０、サーバスタブ３１２及びクライアントスタブ３１９について説明する。
クライアントコンポーネント３０２は、クライアント処理３０３と、クライアントスタブ３０６とを有する。
クライアントスタブ３０６は、遠隔手続呼出インタフェース３０５を公開し、サーバコンポーネント３１０へのリクエスト送信処理や、リプライ受信処理を仲介する。ここで、リクエスト送信部３０８は、リクエスト送信処理、即ち、処理要求の送信を実行する。また、リプライ受信部３３０は、通信ポート３２９でリプライメッセージを受信するリプライ受信処理を実行する。また、クライアントスタブ３０６は、対応するコンポーネントを識別するコンポーネント識別子３０７を保持している。なお、コンポーネント識別子３０７は、コンポーネント識別情報の一例である。コンポーネント識別子３０７には、コンポーネント番号や、図４に示すコンポーネント名称７０１を表す文字列等が利用可能である。なお、図４は、コンポーネント名称の一例を示す図である。
クライアント処理３０３は、ＣＰＵ２０２の実行タスクとなるクライアント実行スレッド３０４を有しており、遠隔手続呼出インタフェース３０５を利用してサーバコンポーネント３１０へリクエストする。
【００１３】
サーバコンポーネント３１０は、サーバ処理３１１と、サーバスタブ３１２と、クライアントスタブ３１９とを有する。
サーバスタブ３１２は、ＣＰＵ２０２の実行タスクとなる１つ以上のリクエスト実行スレッド３１３を有する。なお、リクエスト実行スレッド３１３は、処理実行スレッドの一例である。サーバスタブ３１２は、クライアントスタブ３０６や、クライアントスタブ３１９からのリクエストを受信し、リクエストに応じた遠隔手続３１７や、遠隔手続３２３を実行して実行結果をクライアントスタブ３０６や、クライアントスタブ３１９へ送信する。また、サーバスタブ３１２のリクエスト実行部３１６は、スレッド毎に参照可能な記憶領域にコンポーネント識別子３１４を保持して管理している。なお、リクエスト実行部３１６が実行する処理は、処理実行処理の一例である。コンポーネント識別子３１４には、コンポーネント番号、図５に示すコンポーネント名称８０１を表す文字列等が利用可能である。なお、図５は、コンポーネント名称の一例を示す図である。スレッド毎に参照可能な領域としては、ヒープメモリ、共有メモリ、スレッド固有領域等が利用可能であり、リクエスト実行部３１６により実行される別の構成からも参照可能である。
サーバ処理３１１は、遠隔手続呼出によって機能公開する１つ以上の遠隔手続を有する。本実施形態では、サーバ処理３１１は、遠隔手続３１７及び遠隔手続３２３を有する。
クライアントスタブ３１９の構成は、クライアントスタブ３０６と同様である。なお、クライアントスタブ３１９は、コンポーネント識別子３２０としてコンポーネント名称７０１を利用し、遠隔手続呼出インタフェース３１８を利用することで、サーバコンポーネント３１０自身の機能を遠隔手続呼出によって実行することができる。
【００１４】
次に、図６、図７を用いて本実施形態の処理フローについて説明する。
図６は、リクエスト送信部３０８と、リプライ受信部３３０とを有するクライアントスタブ３０６や、リクエスト送信部３２１と、リプライ受信部３２７とを有するクライアントスタブ３１９の処理の一例を示すフローチャートである。なお、リクエスト送信部３０８と、リクエスト送信部３２１とが実行する処理は、処理要求処理の一例である。
図７は、リクエスト実行部３１６と、リプライ送信部３２４とを有するサーバスタブ３１２の処理の一例を示すフローチャートである。
まず、クライアント実行スレッド３０４は、遠隔手続呼出インタフェース３０５を実行する。その後、Ｓ４０１で、リクエスト送信部３０８は、クライアント実行スレッド３０４が属するコンポーネントを識別するコンポーネント識別子と、自身のコンポーネント識別子３０７とが一致するか否かを判定する。そして、リクエスト送信部３０８は、一致すると判定した場合、処理をＳ４０３に進め、一致しないと判定した場合、処理をＳ４０２に進める。なお、分散フレームワーク外のクライアント実行スレッド３０４は、コンポーネント識別子を保持していないため、Ｓ４０１で、リクエスト送信部３０８は、一致しないと判定する。
Ｓ４０２で、リクエスト送信部３０８は、遠隔手続呼出リクエスト３０９をサーバスタブ３１２のリクエスト受信ポート３１５へ送信する。ここで、サーバスタブ３１２が起動されると、リクエスト実行スレッド３１３は、リクエスト実行部３１６を実行する。即ち、リクエスト実行スレッド３１３は、リクエスト実行部３１６に処理を指示する。
【００１５】
以下、リクエスト実行部３１６の処理について、図７を用いて説明する。
Ｓ５０１で、リクエスト実行部３１６は、リクエストにシーケンス識別子が指定されているか否かを判定し、指定されていると判定した場合、処理をＳ５０２に進め、指定されていないと判定した場合、処理をＳ５０３に進める。ここで、シーケンス識別子は、一連の連続する処理を識別する処理識別情報の一例である。なお、起動時のリクエスト実行スレッド３１３はシーケンス識別子を指定しないため、Ｓ５０１で、リクエスト実行部３１６は、シーケンス識別子が指定されていないと判定する。
Ｓ５０３で、リクエスト実行部３１６は、リクエストキューの先頭から遠隔手続呼出リクエスト３０９を受信し、処理をＳ５０４に進める。即ち、リクエスト実行部３１６は、要求順に遠隔手続呼出リクエスト３０９を受信する。
Ｓ５０４で、リクエスト実行部３１６は、受信した遠隔手続呼出リクエスト３０９に対応する遠隔手続３１７を実行する。より具体的には、リクエスト実行部３１６により実行される遠隔手続３１７は、処理の過程でサーバコンポーネント３１０のクライアントスタブ３１９が公開する遠隔手続呼出インタフェース３１８を実行する。
【００１６】
図６の説明に戻る。
リクエスト実行部３１６による遠隔手続呼出インタフェース３１８の実行後、Ｓ４０１で、リクエスト送信部３２１は、リクエスト実行スレッド３１３が保持しているコンポーネント識別子と、自身のコンポーネント識別子３２０とが一致するか否かを判定する。なお、リクエスト送信部３２１は、サーバスタブ３１２のリクエスト実行スレッド３１３により実行されている。ここで、実行スレッドのコンポーネント識別子３１４（コンポーネント名称８０１）と、クライアントスタブ３１９のコンポーネント識別子３２０（コンポーネント名称７０１）とが"ＣｏｍｐｏｎｅｎｔＡ"で一致する。そのため、Ｓ４０３で、リクエスト送信部３２１は、例えば図８に示されるようなスレッドＩＤ９０２をシーケンス識別子として遠隔手続呼出リクエスト９０１に付加し、処理をＳ４０４に進める。ここで、リクエスト送信部３２１は、上述したスレッド毎に参照可能な記憶領域から取得したスレッドＩＤを遠隔手続呼出リクエスト９０１に付加するようにしてもよい。なお、図８は、スレッドＩＤが付加された遠隔手続呼出リクエストの一例を示す図である。本実施形態では、前記シーケンス識別子をスレッドＩＤとして説明するが、遠隔手続呼出が実行コンテキスト情報を引き回す場合、リクエスト送信部３２１は、前記実行コンテキストをシーケンス識別子として利用するようにしてもよい。また、図８に示される遠隔手続呼出リクエストは、遠隔手続呼出リクエストの構造を規定するものではない。例えば、シーケンス識別子は、リクエストヘッダや、リクエストデータ中に格納されるようにしてもよい。
Ｓ４０４で、リクエスト送信部３２１は、遠隔手続呼出リクエスト３２２を送信し、処理をＳ４０５に進める。
Ｓ４０５で、リクエスト送信部３２１は、図９に示されるシーケンス識別子１００１を指定したリクエストの実行を依頼するため、サーバスタブ３１２のリクエスト実行部３１６を呼び出す。
【００１７】
図７の説明に戻る。
Ｓ５０１で、リクエスト実行部３１６は、上述したように、リクエストにシーケンス識別子が指定されているか否かを判定する。ここでは、シーケンス識別子１００１が指定されているため、リクエスト実行部３１６は、シーケンス識別子が指定されていると判定し、処理をＳ５０２に進める。
Ｓ５０２で、リクエスト実行部３１６は、シーケンス識別子１００１が一致する遠隔手続呼出リクエスト９０１を選択的に受信し、処理をＳ５０４に進める。より具体的には、リクエスト実行部３１６は、リクエストに付加されているシーケンス識別子と、予め指定したスレッド毎のシーケンス識別子とが一致する遠隔手続呼出リクエスト９０１を選択して受信する。
Ｓ５０４で、リクエスト実行部３１６は、選択受信した遠隔手続呼出リクエスト９０１に対応する遠隔手続３２３を実行し、処理をＳ５０５に進める。
Ｓ５０５で、リクエスト実行部３１６は、遠隔手続呼出リクエスト３２２が同期呼び出しか否かを判定し、同期呼び出しであると判定した場合、処理をＳ５０７に進め、同期呼び出しでないと判定した場合、処理をＳ５０６に進める。
Ｓ５０７で、リプライ送信部３２４は、クライアントスタブ３１９へ遠隔手続呼出リプライ３２５を送信する。なお、リプライ送信部３２４が実行する処理は、応答送信処理の一例である。本実施形態では同期呼び出しの場合を例として説明するが、リプライが不要な一方向呼び出しの場合、Ｓ５０６で、リクエスト実行部３１６は、処理を完了して呼び出し元に処理を戻す。リクエスト実行部３１６及びリプライ送信部３２４の処理完了後、クライアントスタブ３１９のリプライ受信部３２７は、リプライを受信する。
【００１８】
図６の説明に戻る。
Ｓ４０６で、リプライ受信部３２７は、上述したようにサーバスタブ３１２からの遠隔手続呼出リプライ３２５を受信し、遠隔手続呼出インタフェース３１８が完了する。次に、遠隔手続３１７の実行が完了して、リクエスト実行部３１６に処理が戻る。なお、リプライ受信部３２７が実行する処理は、応答受信処理の一例である。
図７の説明に戻る。
次に、Ｓ５０７で、リプライ送信部３２４は、リクエスト実行部３１６に対する遠隔手続呼出リクエスト３０９に対応する遠隔手続呼出リプライ３２８を送信する。
図６の説明に戻る。
Ｓ４０６で、クライアントスタブ３０６のリプライ受信部３３０は、サーバスタブ３１２からの遠隔手続呼出リプライ３２８を受信し、遠隔手続呼出インタフェース３０５の実行が完了する。なお、リプライ受信部３３０が実行する処理は、応答受信処理の一例である。
以上、上述した方法により、本実施形態による遠隔手続呼出システムでは、同一プロセスの同一コンポーネントへの遠隔手続呼出を自身のスレッドで実行することができる。そのため、同一プロセスの同一コンポーネントへの呼出ループによるスレッド消費が発生せず、呼出ループに起因するスレッド枯渇が原因のデッドロックを解消することができる。これにより、開発者による分散開発フレームワーク内部のモニタリング作業、エラー処理等を軽減することができ、分散開発フレームワークの学習コストを削減することができる。
【００１９】
＜実施形態２＞
以下、図３、図７及び図１０を用いて実施形態２について説明する。
本実施形態は、図３に示されるサーバスタブ３１２において２つ以上のリクエスト実行スレッド３１３が存在する場合の実施形態である。
サーバスタブ３１２は、２つ以上のリクエスト実行スレッド３１３を用意し、クライアントからのリクエストを並列に実行することができる。
２つ以上のリクエスト実行スレッド３１３が存在する場合、図７のＳ５０２で、リクエスト実行部３１６が、シーケンス識別子が一致するリクエストを選択受信する前に、別のスレッドがリクエストを受信する可能性がある。
本実施形態におけるＳ５０２の処理の詳細を、図１０に示されるフローチャートを用いて説明する。なお、図１０は、本実施形態におけるリクエスト実行部３１６の処理の一例を示すフローチャートである。
図１０のＳ６０１で、リクエスト実行部３１６は、シーケンス識別子が一致するリクエストがあるか否かを判定し、一致するリクエストがあると判定した場合、処理をＳ６０２に進め、一致するリクエストがないと判定した場合、処理をＳ６０３に進める。なお、リクエスト実行部３１６によるシーケンス識別子が一致するリクエストがあるか否かの判定処理は、Ｓ５０２等で上述したため、説明を省略する。また、上述したように、リクエスト送信部３２１による遠隔手続呼出リクエストの送信後に、リクエスト実行スレッド３１３がリクエスト実行部３１６を実行する。そのため、リクエスト実行部３１６は、遠隔手続呼出リクエストを受信できない場合、別のスレッドがリクエストを実行したと判定することができる。
Ｓ６０２で、リクエスト実行部３１６は、シーケンス識別子が一致するリクエストを選択受信する。
Ｓ６０３で、リクエスト実行部３１６は、処理を完了して呼び出し元に処理を戻す。
以上、本実施形態によれば、２つ以上のリクエスト実行スレッド３１３を必要とするコンポーネントにおいても実施形態１と同様の効果を得ることができる。
【００２０】
＜実施形態３＞
以下、図３、図７及び図１１を用いて実施形態３について説明する。
本実施形態においても、実施形態２と同様に、図３に示されるサーバスタブ３１２において２つ以上のリクエスト実行スレッド３１３が存在するものとする。
本実施形態において、シーケンス識別子が指定されているリクエストと、シーケンス識別子が指定されていないリクエストとが存在するものとする。この場合、図７のＳ５０２で、本実施形態のリクエスト実行部３１６は、シーケンス識別子が一致するリクエストを選択受信する。一方、図７のＳ５０３で、本実施形態のリクエスト実行部３１６は、シーケンス識別子が指定されていない図１１に示されるような遠隔手続呼出リクエスト１１０１のみを受信する。なお、図１１は、シーケンス識別子が指定されていない遠隔手続呼出リクエストの一例を示す図である。このように、上述したように２つ以上のリクエスト実行スレッド３１３が存在する場合であっても、１つのリクエスト実行スレッド３１３のみで同一プロセスの同一コンポーネントへの入れ子状の同期呼び出しを処理することができる。即ち、複数のリクエスト実行スレッド３１３が存在する場合、リクエスト実行部３１６は、並列にリクエストを処理することができる。
以上、本実施形態によれば、入れ子状の処理で他のスレッドを消費しないため、シーケンス処理の並列度を落とすことなくサービスを提供することができる。
【００２１】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【００２２】
以上、上述した各実施形態によれば、コンポーネント内の入れ子状の同期呼び出しを実施してもスレッド枯渇に起因したデッドロックの発生を解消させることができる。
【００２３】
以上、本発明の好ましい形態について詳述したが、本実施形態は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【図１】
2014229121.tif 000003
【図２】
2014229121.tif 000004
【図３】
2014229121.tif 000005
【図４】
2014229121.tif 000006
【図５】
2014229121.tif 000007
【図６】
2014229121.tif 000008
【図７】
2014229121.tif 000009
【図８】
2014229121.tif 000010
【図９】
2014229121.tif 000011
【図１０】
2014229121.tif 000012
【図１１】
2014229121.tif 000013