JP6642138B2 - 計算機システム、スレッド間通信方法およびプログラム - Google Patents

Description

本発明は、計算機システム、スレッド間通信方法およびプログラムに関し、特に複数スレッドが稼働する計算機を含む計算機システム、複数のスレッド間における通信方法およびプログラムに関する。

近年、オープンソースソフトウェア（Open Source Software）の普及により、数多くのソフトウェアを組み合わせて構築される巨大な分散システムが手軽に利用できるようになってきている。一例として、複数の計算機上で稼働する複数のソフトウェアが互いに独立性を保ちつつ、ＲＥＳＴ（Representational State Transfer）のようなステートレスな通信により協調することで、特定の機能が提供される場合がある。

関連技術として、特許文献１には、複数のフィルタ（機能）から構成されるフィルタパイプラインの処理において、フィルタの処理が正常終了しなかった場合、ログファイルを出力するフィルタを決定し、決定したフィルタに対してログファイル出力を実行させる技術が記載されている。

また、特許文献２には、アプリケーションプログラムに関する通信処理障害を解析するために、ネットワーク層での通信の状況をアプリケーション層での障害に関連する事象と関連付ける技術が記載されている。

特開２０１５−２１２８５３号公報 特開２０１５−１８５９７６号公報

上記特許文献の全開示内容は、本書に引用をもって繰り込み記載されているものとする。以下の分析は、本発明者によってなされたものである。

上述のように、複数のプロセス（ないしプロセスに含まれるスレッド）が協調して動作するシステムでは、あるプロセスで例外的な動作（例えばエラー）が確認された場合であっても、それを引き起こす元となった原因はそのプロセス自身ではなく、他のプロセスであることも多い。したがって、例えば、複数のプロセスがＲＥＳＴのようなステートレスな通信により協調しつつ機能を提供する場合、何らかの異常が検知されたとしても、システムに含まれるプロセス間の協調関係に関する知識を持たない利用者がエラーの真の原因を特定することは困難である。

したがって、複数のプロセス（ないしスレッド）が協調して特定の機能を提供するシステムにおいてエラーの原因を究明するためには、利用者はプロセス（ないしスレッド）間の協調関係を把握する必要がある。

なお、特許文献１に記載された技術によると、プロセス（ないしスレッド）間の関連性を抽出することはできない。また、特許文献２に記載された技術によると、アプリケーションがソケットの生成を通知したり、またはトレースビットを設定したりするには、アプリケーション側からＡＰＩ（Application Program Interface）を呼び出す必要があり、アプリケーションを改変する必要が生じる。

そこで、スレッド間の関連性を簡便に把握できるようにすることが課題となる。本発明の目的は、かかる課題解決に寄与する計算機システム、スレッド間通信方法およびプログラムを提供することにある。

本発明の第１の態様に係る計算機システムは、複数のスレッドが稼働する計算機を備え、第１のスレッドが第２のスレッドにデータを送信する場合、前記第１のスレッドが稼働する計算機は前記第１のスレッドの識別子と第１の送信用識別子を関連付けて保持し、前記第２のスレッドが前記第１のスレッドから前記データを受信する場合、前記第２のスレッドが稼働する計算機は前記第２のスレッドの識別子と前記第１の送信用識別子と第１の受信用識別子とを関連付けて保持する。

本発明の第２の態様に係るスレッド間通信方法は、第１のスレッドが第２のスレッドにデータを送信する場合、前記第１のスレッドの識別子と第１の送信用識別子を関連付けて保持するステップと、前記第２のスレッドが前記第１のスレッドから前記データを受信する場合、前記第２のスレッドの識別子と前記第１の送信用識別子と第１の受信用識別子とを関連付けて保持するステップと、を含む。

本発明の第３の態様に係るプログラムは、第１のスレッドが第２のスレッドにデータを送信する場合、前記第１のスレッドの識別子と第１の送信用識別子を関連付けて保持する処理と、前記第２のスレッドが前記第１のスレッドから前記データを受信する場合、前記第２のスレッドの識別子と前記第１の送信用識別子と第１の受信用識別子とを関連付けて保持する処理と、をコンピュータに実行させる。なお、プログラムは、非一時的なコンピュータ可読記録媒体（non-transitory computer-readable storage medium）に記録されたプログラム製品として提供することもできる。

本発明に係る計算機システム、スレッド間通信方法およびプログラムによると、スレッド間の関連性を簡便に把握することができる。

一実施形態に係る計算機システムの構成を例示する図である。 第１の実施形態に係る計算機システムに含まれる計算機の構成を例示するブロック図である。 第１の実施形態に係る計算機システムの構成を例示するブロック図である。 第１の実施形態に係る計算機システムの動作を説明するための図である。 第２の実施形態に係る計算機システムの構成を例示するブロック図である。 第２の実施形態に係る計算機システムに含まれる計算機の構成を例示するブロック図である。 第４の実施形態に係る計算機システムの構成を例示するブロック図である。 第４の実施形態に係る計算機システムのログ解析部の動作を説明するための図である。 第５の実施形態に係る計算機システムが対象とするスレッドの動作を例示する図である。 第５の実施形態に係る計算機システムの構成を例示するブロック図である。 第５の実施形態に係る計算機システムのログ解析部の動作を説明するための図である。

はじめに、一実施形態の概要について説明する。なお、この概要に付記する図面参照符号は、専ら理解を助けるための例示であり、本発明を図示の態様に限定することを意図するものではない。

図１は、一実施形態に係る計算機システムの構成を例示する図である。図１を参照すると、計算機システムは、複数のスレッド（例えばスレッド４Ａ〜４Ｃ）が稼働する計算機（例えば計算機２Ａ〜２Ｃ）を備えている。第１のスレッド（例えばスレッド４Ａ）が第２のスレッド（例えばスレッド４Ｂ）にデータを送信する場合、第１のスレッドが稼働する計算機（例えば計算機２Ａ）は第１のスレッドの識別子（例えばスレッド識別子ＩＤＡ）と第１の送信用識別子（例えばＧＵＩＤ（Global Unique Identifier）１）を関連付けて保持する。一方、第２のスレッド（例えばスレッド４Ｂ）が第１のスレッド（例えばスレッド４Ａ）から上記データを受信する場合、第２のスレッドが稼働する計算機（例えば計算機２Ｂ）は第２のスレッドの識別子（例えばスレッド識別子ＩＤＢ）と第１の送信用識別子（例えばＧＵＩＤ１）と第１の受信用識別子（例えばＧＵＩＤ２）とを関連付けて保持する。

同様に、第２のスレッド（例えばスレッド４Ｂ）が上記データの受信に応じて第３のスレッド（例えばスレッド４Ｃ）にデータを送信する場合、第２のスレッドが稼働する計算機（例えば計算機２Ｂ）は第２のスレッドの識別子（例えばスレッド識別子ＩＤＢ）と第１の受信用識別子（例えばＧＵＩＤ２）と第２の送信用識別子（例えばＧＵＩＤ３）を関連付けて保持する。以下、同様に、スレッド間のデータ送受信に応じて、スレッドの識別子、送受用識別子、受信用識別子が互いに関連付けて計算機に蓄積される。

このとき、計算機が互いに関連付けて保持したスレッドの識別子、送受用識別子および受信用識別子の組から、関連性を有するスレッドの組を抽出することができる。例えば、図１に示す例では、計算機２Ａが保持する関連付け（ＩＤＡ，ＧＵＩＤ１）と計算機２Ｂが保持する関連付け（ＩＤＢ，ＧＵＩＤ１，ＧＵＩＤ２）において共通に含まれる送信用識別子ＧＵＩＤ１に基づいて、スレッド識別子ＩＤＡに相当するスレッド４Ａとスレッド識別子ＩＤＢに相当するスレッド４Ｂとの間に関連性（例えばデータをやりとりする関係）が存在することが判明する。したがって、かかる計算機システムによると、スレッド間の関連性を簡便に（例えばプログラムを改変することなく）把握することが可能となる。

すなわち、一実施形態によると、複数の計算機上で動作するプロセスが協調してある機能を提供するようなシステムにおいて、プロセス間の通信の履歴を送信側・受信側のプロセス情報を含めて記憶装置に記録することで、プロセス間の協調関係を時系列に把握することが可能となる。したがって、機能の利用者が予めプロセス間の協調関係を知らない場合であっても、記録されたデータを確認することで、プロセス間の協調関係を把握することができる。これにより、システムのプロセス間の協調関係に関する知識を持たない利用者であっても、エラー発生時には関連するプロセスを列挙し、列挙したプロセスのログファイルの該当時刻付近を調査することで、エラーの真の原因を特定することが可能となる。

＜実施形態１＞
次に、第１の実施形態に係る計算機システムについて図面を参照して説明する 図２は、本実施形態に係る計算機システムに含まれる計算機２の構成を例示するブロック図である。

［構成］
図２を参照すると、計算機２は、計算機２上で動作するオペレーティングシステム（ＯＳ：Operating System）５と、利用者に機能を提供する分散システムの一部を成すプロセス３と、履歴制御指示部６と、履歴保存部７と、を備えている。

また、オペレーティングシステム５は、プロセス間の通信履歴を一時保持・制御する履歴制御部８と、プロセスを管理するプロセス管理部９と、スレッドを管理するスレッド管理部１０と、プロセス間通信の終端情報を管理するソケット管理部１１と、ＴＣＰ（Transmission Control Protocol）に基づき他の計算機と通信を行うＴＣＰデータ送受信部１２と、プロセス３がオペレーティングシステム５に対して指示を行う場合に呼び出されるシステムコールゲートウェイ部１３とを有する。

履歴保存部７は、プロセス間の通信履歴を永続的な記録装置に保存する。また、履歴制御指示部６は、履歴制御部８の動作を指示する。

図２の各部について、さらに詳細に説明する。

計算機２は、いわゆるコンピュータである。コンピュータは物理的なコンピュータであっても、物理的なコンピュータ上で動作する仮想的なコンピュータであってもよい。

オペレーティングシステム５は、本実施形態で提供される機能以外にも、通常のオペレーティングシステムの機能を提供する。

履歴制御部８は、ソケットを使用してプロセス間で通信した際の履歴を一時的に保持する。また、履歴制御部８は、履歴保存部７の要求に応じて、一時的に保持する履歴データを履歴保存部７に渡すとともに、一時的に保持する履歴データを消去する。

履歴保存部７は、履歴制御部８が履歴を保持しているか否かを確認し、保持している場合、履歴制御部８が保持する履歴を受け取る。また、履歴保存部７は、受け取った履歴に関しては、履歴制御部８に対して消去を指示する。また、履歴保存部７は、受け取った履歴を永続的な記録媒体（非図示）に保存する。ここで、記録媒体は計算機上に存在してもよいし、他の計算機上に存在してもよい。

計算機２上では、複数のプロセスが動作する。ただし、簡単のため、図２には１つのプロセス３を例示した。

履歴制御指示部６は、どのプロセスに関する通信の履歴を保存するのかを履歴制御部８に指示する。

ＴＣＰデータ送受信部１２は、データ送信時にＴＣＰヘッダのオプションフィールドにＧＵＩＤ（Global Unique Identifier）を付加して送信する。

プロセス管理部９は、通信履歴を採取するか否か判断するための情報を保持する。

スレッド管理部１０は、送信用のＧＵＩＤと受信用のＧＵＩＤを保持する。

ソケット管理部１１は、通信履歴を採取するか否かを判断するための情報を保持する。

システムコールゲートウェイ部１３は、オペレーティングシステム５の各プロセスに対するインターフェイスに相当する。システムコールゲートウェイ部１３は、オペレーティングシステム５がプロセス３にエラーを返す場合、履歴制御部８に対して履歴を保持するよう指示する。

図３は、本実施形態の計算機システム１の構成を例示するブロック図である。図３には、計算機システム１と、計算機システム１を利用する機能利用部１４が示されている。計算機システム１は、計算機２Ａ〜２Ｃを備えている。

計算機２Ａ〜２Ｃは、それぞれ図２に示す計算機に相当する。計算機２Ａ〜２Ｃ上では、それぞれプロセス３Ａ〜３Ｃが動作している。なお、図３においては省略されているものの、計算機２Ａ〜２Ｃは、それぞれ図２に示す計算機２を構成する各要素を含む。プロセス３Ａ〜３Ｃは、それぞれスレッド４Ａ〜４Ｃを包含している。プロセス３Ａ〜３Ｃが包含するスレッドの数は１つであってもよいし、複数であってもよい。

プロセス３Ａ〜３Ｃは、通信を行うことにより協調し、システムとして所定の機能を提供する。機能利用部１４は、当該機能を利用する側の要素である。本実施形態では、一例として計算機の台数を３台としている。ただし、計算機の台数はこれに限定されず、例えば３台以上であってもよい。また、複数のプロセスはメッシュ状に通信してもよい。

［動作］
次に、本実施形態の計算機システム１の動作について説明する。動作には、（１）通信履歴採取対象プロセスの指定、（２）初期化、（３）システムコールエラー履歴の保存、（４）通信履歴の保存、（５）通信履歴の永続的保存が含まれる。

（１）「通信履歴採取対象プロセスの指定」
履歴制御指示部６は、履歴採取プロセスを指定するため、その実行ファイルパスの情報を履歴制御部８に通知する。履歴制御部８は、通知されたファイルパス情報を保持する。

（２）「初期化」
履歴制御指示部６は、履歴制御部８に対して初期化の要求を行う。履歴制御部８は、（２．１）プロセスの起動、（２．２）ソケットの作成、（２．３）データの送信、（２．４）データの受信、（２．５）スレッドのスリープに関するオペレーティングシステム５の動作に関して、通常のオペレーティングシステムの動作に加えて本実施形態に固有の処理を行うために、オペレーティングシステム５に対する設定を実施する。

（２．１）プロセス起動時の追加処理として、起動しようとしているプロセスが履歴採取対象であるか否かを判断するため、ＴＣＰデータ送受信部１２は履歴制御部８が保持するファイルパス名を確認する。履歴採取対象である場合、ＴＣＰデータ送受信部１２は、（プロセス管理部９が保持する）プロセスを管理するデータ構造体に履歴採取対象であることを示すフラグを設定する。プロセスを管理するデータ構造体は、１プロセスに対して１つ存在する。

（２．２）ソケット作成時の追加処理として、ＴＣＰデータ送受信部１２はプロセスを管理するデータ構造体を確認し、プロセスが履歴採取対象か否かを判断する。履歴採取対象である場合、ＴＣＰデータ送受信部１２は（ソケット管理部１１が保持する）ソケットを管理するデータ構造体に履歴採取対象であることを示すフラグを設定する。ソケットを管理するデータ構造体は、１ソケットに対して１つ存在する。ここで、ソケットとは、他のプロセスと通信する場合に作成される通信路の終端部で、２つのソケットを接続することによりプロセス間の通信が可能となる。

（２．３）データ送信時の追加処理として、ＴＣＰデータ送受信部１２はソケットを管理するデータ構造体を確認し、履歴採取対象か否かを判断する。履歴採取対象である場合、ＴＣＰデータ送受信部１２は送信用ＧＵＩＤが（スレッド管理部１０が保持する）スレッドを管理するデータ構造体に保持されているか否かを確認する。保持されていない場合、ＴＣＰデータ送受信部１２は送信用ＧＵＩＤを生成してスレッドを管理するデータ構造体に保持する。その後、ＴＣＰデータ送受信部１２は履歴制御部８に対してデータ送信履歴の保存を指示する。ここで保存するデータには、時刻、プロセスＩＤ、スレッドＩＤ、スレッドを管理するデータ構造体が保持する送信用ＧＵＩＤ、受信用ＧＵＩＤ、ログのタイプ（データ送信）、ソケット情報（ＩＮＥＴドメインであれば、ＩＰ（Internet Protocol）アドレス、ポート番号）が含まれる。その後、ＴＣＰデータ送受信部１２は、送信用ＧＵＩＤをＴＣＰヘッダのオプションフィールドに付加してデータを送信する。

（２．４）データ受信時の追加処理として、ＴＣＰデータ送受信部１２は受信したＴＣＰヘッダのオプションに、本実施形態で付加した送信用ＧＵＩＤが存在するか否かを確認する。送信用ＧＵＩＤが存在する場合、ＴＣＰデータ送受信部１２はソケットを管理するデータ構造体を確認し、履歴採取対象か否かを判断する。履歴採取対象である場合、ＴＣＰデータ送受信部１２は受信用ＧＵＩＤがスレッドを管理するデータ構造体に保持されているか確認する。保持されていない場合、ＴＣＰデータ送受信部１２は受信用ＧＵＩＤを生成してスレッドを管理するデータ構造体に保持する。その後、ＴＣＰデータ送受信部１２は履歴制御部８に対してデータ受信履歴の保存を指示する。保存するデータには、時刻、プロセスＩＤ、スレッドＩＤ、ＴＣＰヘッダのオプションに付与されていた送信用ＧＵＩＤ、スレッドを管理するデータ構造体が保持する受信用ＧＵＩＤ、ログのタイプ（データ受信）、ソケット情報（ＩＮＥＴドメインであれば、ＩＰアドレス、ポート番号）が含まれる。その後、ＴＣＰデータ送受信部１２は、データ受信処理を行う。

（２．５）スレッドのスリープ時の追加処理として、ＴＣＰデータ送受信部１２は送信用・受信用ＧＵＩＤがスレッドを管理するデータ構造体に保持されているか否かを確認する。保持されている場合、ＴＣＰデータ送受信部１２はこれらのＧＵＩＤをクリアする。スレッドのスリープとは、スレッドが自発的にＣＰＵ（Central Processing Unit）を解放する場合であり、Ｉ／Ｏ（Input/Output）待ちによるスリープは含まれない。これにより、次にデータ送受信が発生した場合、新しいＧＵＩＤが生成される。

（３）「システムコールエラー履歴の保存」
システムコールゲートウェイ部１３は、オペレーティングシステム５がプロセスにエラーを返却するか否かを判断する。エラーを返却する場合、システムコールゲートウェイ部１３はプロセスを管理するデータ構造体を確認し、プロセスが履歴採取対象か否かを判断する。プロセスが履歴採取対象である場合、システムコールゲートウェイ部１３は履歴制御部８に対してエラー履歴の保存を指示する。保存するデータには、時刻、プロセスＩＤ、スレッドＩＤ、スレッドを管理するデータ構造体が保持する送信用ＧＵＩＤ、受信用ＧＵＩＤ、ログのタイプ（エラー）が含まれる。

（４）「通信履歴の保存」
履歴制御部８は、他の要素からの指示により、時刻、プロセスＩＤ、スレッドＩＤ、スレッドを管理するデータ構造体に含まれる送信用ＧＵＩＤ、受信用ＧＵＩＤ、イベントの種類（データの送信、受信、システムコールのエラー）を保存する。

（５）「通信履歴の永続的保存」
履歴保存部７は、履歴制御部８に対して、保存された通信履歴が存在するか否かを問い合わせる。通信履歴が存在する場合、履歴保存部７はその履歴を履歴制御部８から取得し、計算機２上のハードディスク等の永続的記録媒体に保存する。履歴保存部７は、永続的記録媒体に保存したデータに関しては履歴制御部８から削除するように、履歴制御部８に指示する。

図４は、本実施形態の計算機システムの動作の具体例を示す。スレッド４を示す箱内の左側に付された番号は受信用ＧＵＩＤを示し、右側に付された番号は送信用ＧＵＩＤを示す。図４の丸囲み（破線）において、左端のスレッド４Ａが稼働する計算機２Ａはデータ送信時に受信用ＧＵＩＤ「１」、送信用ＧＵＩＤ「２」のペア「１・２」のログを記録する。一方、中央のスレッド４Ｂが稼働する計算機２Ｂは、データ受信時およびデータ送信時に、それぞれ、ＧＵＩＤのペア「２・４」および「４・５」のログを記録する。また、右端のスレッド４Ｃが稼働する計算機は、データ受信時にＧＵＩＤのペア「５・７」のログを記録する。したがって、これらのＧＵＩＤをマッチング（照合）することにより、スレッド４Ａ〜４Ｃが互いに関連性を有することを把握できる。

［効果］
本実施形態によると、対象となる分散システムに関する動作説明資料が存在しない場合であっても、プロセス間の協調関係を確認することができる。その理由は、各計算機２の履歴保存部７が保存した履歴を収集し、ＧＵＩＤのマッチングを行うことで、どのプロセスがどのプロセスに対してデータを送信したのかを確認することができるからである。

また、本実施形態によると、あるプロセスでエラーが発生した場合、そのエラーの原因が他の計算機のプロセスにあった場合でも容易に判別することができる。その理由は、プロセスが出力するエラーログと、上記の効果によるプロセス間の関連性を確認することで、確認すべき他のプロセスのログを判断でき、調査を実施することができるからである。

さらに、本実施形態によると、プロセスが出力するエラーログが不十分な場合でも、エラーの原因を判断することができる。その理由は、プロセスがエラーログにエラーを残さない場合であっても、システムコールゲートウェイ部１３が記録するエラーの履歴を確認することで、どのプロセスにどのようなエラーが発生していたのかを判断できるからである。

＜実施形態２＞
次に、第２の実施形態に係る計算機システムについて図面を参照して説明する。第１の実施形態に係る計算機システム（図２、図３参照）では、スレッド間の通信がＴＣＰ通信の場合を想定している。一方、本実施形態では、図５に示すような同一計算機内のスレッド間の通信にも適用可能とする。

［構成］
図６は、図５のような計算機システム１においても適用可能な計算機２の構成を例示するブロック図である。図６を参照すると、本実施形態の計算機２では、第１の実施形態における計算機２（図２）におけるソケット管理部１１とＴＣＰデータ送受信部１２が、それぞれ、リソース管理部１５とリソース処理部１６に変更されている。

リソースとは、あるスレッドから他のスレッドに対して何らかの作用を発生させるオペレーティングシステム５のリソースである。例えば、同一のオペレーティングシステム５内で動作するスレッド間でテータを送受信するソケット、条件変数、プロセス間メッセージ通信、セマフォ等がリソースに該当する。

リソース管理部１５は、リソース状態履歴を採取するか否かを判断するための情報、および、リソースの状態を変更した操作に対応するＧＵＩＤを保持する。

スレッド管理部１０は、２種類のＧＵＩＤを保持する。一方のＧＵＩＤは、リソース状態を変更する場合に更新されるＧＵＩＤ（「送信用ＧＵＩＤ」という。）である。他方のＧＵＩＤは、リソース状態変更に応じてスレッドが実行状態になる場合に更新されるＧＵＩＤ（「受信用ＧＵＩＤ」という。）である。

［動作］
次に、本実施形態の計算機システム（図５、図６）の動作について説明する。動作には、（１）リソース履歴採取対象プロセスの指定、（２）初期化、（３）システムコールエラー履歴の保存、（４）リソース履歴の保存、（５）リソース履歴の永続的保存が含まれる。

（１）「リソース履歴採取対象プロセスの指定」
履歴制御指示部６は、履歴採取プロセスを指定するため、その実行ファイルパスの情報を履歴制御部８に通知する。履歴制御部８は、通知されたファイルパス情報を保持する。

（２）「初期化」
履歴制御指示部６は、履歴制御部８に対して初期化の要求を行う。履歴制御部８は、（２．１）プロセスの起動、（２．２）リソースの作成、（２．３）〜（２．４）リソースの状態変更、（２．５）スレッドのスリープに関するオペレーティングシステム５の動作に関して、通常のオペレーティングシステムの動作に加えて本実施形態に固有の処理を行うため、オペレーティングシステム５に対して設定を実施する。

（２．１）プロセス起動時の追加処理として、起動しようとしているプロセスが履歴採取対象であるか否かを判断するため、リソース処理部１６は履歴制御部８が保持しているファイルパス名を確認する。履歴採取対象である場合、リソース処理部１６は（プロセス管理部９が保持する）プロセスを管理するデータ構造体に履歴採取対象であることを示すフラグを設定する。プロセスを管理するデータ構造体は、１プロセスに対して１つ存在する。

（２．２）リソース作成時の追加処理として、リソース処理部１６はプロセスを管理するデータ構造体を確認し、プロセスが履歴採取対象か否かを判断する。履歴採取対象である場合、リソース処理部１６は（リソース管理部１５が保持する）リソースを管理するデータ構造体に履歴採取対象であることを示すフラグを設定する。リソースを管理するデータ構造体は、１リソースに対して１つ存在する。

（２．３）リソース状態変更時の追加処理として、リソース処理部１６はリソースを管理するデータ構造体を確認し、履歴採取対象か否かを判断する。履歴採取対象である場合、リソース処理部１６は送信用ＧＵＩＤが（スレッド管理部１０が保持する）スレッドを管理するデータ構造体に保持されているか否かを確認する。保持されていない場合、リソース処理部１６は送信用ＧＵＩＤを生成してスレッドを管理するデータ構造体に保持する。その後、リソース処理部１６は履歴制御部８に対してデータ送信履歴の保存を指示する。保存するデータには、時刻、プロセスＩＤ、スレッドＩＤ、スレッドを管理するデータ構造体が保持する送信用ＧＵＩＤ、受信用ＧＵＩＤ、ログのタイプ（リソース状態変更）、リソース情報が含まれる。その後、リソース処理部１６は送信用ＧＵＩＤをリソース管理部１５が持つＧＵＩＤ記憶部に保存する。

（２．４）リソース状態変更により、他のスレッドを待機状態から実行可能状態に変更する必要性がある場合、リソース処理部１６は、実行可能状態になったスレッドをスレッドＣとして、スレッドＣに対応する受信用ＧＵＩＤがスレッドを管理するデータ構造体に保持されているか否かを確認する。保持されていない場合、リソース処理部１６は受信用ＧＵＩＤを生成してスレッドを管理するデータ構造体に保持する。その後、リソース処理部１６は、履歴制御部８に対してスレッド動作履歴の保存を指示する。保存するデータには、時刻、プロセスＩＤ、スレッドＩＤ、リソース管理部１５が持つ送信用ＧＵＩＤ、スレッドＣを管理するデータ構造体が保持する受信用ＧＵＩＤ、ログのタイプ（データ受信）、リソース情報が含まれる。

（２．５）スレッドのスリープ時の追加処理として、リソース処理部１６は送信用・受信用ＧＵＩＤがスレッドを管理するデータ構造体に保持されているか否かを確認する。保持されている場合、リソース処理部１６はこれらのＧＵＩＤをクリアする。スレッドのスリープとは、スレッドが自発的にＣＰＵを解放する場合であり、Ｉ／Ｏ待ちによるスリープは含まれない。これにより、次にデータ送受信が発生した場合、新しいＧＵＩＤが生成される。

（３）「システムコールエラー履歴の保存」
システムコールゲートウェイ部１３は、オペレーティングシステム５がプロセスにエラーを返却するか否かを判断する。エラーを返却する場合、システムコールゲートウェイ部１３はプロセスを管理するデータ構造体を確認し、プロセスが履歴採取対象か否かを判断する。プロセスが履歴採取対象である場合、システムコールゲートウェイ部１３は履歴制御部８に対してエラー履歴の保存を指示する。保存するデータには、時刻、プロセスＩＤ、スレッドＩＤ、スレッドを管理するデータ構造体が保持する送信用ＧＵＩＤ、受信用ＧＵＩＤ、ログのタイプ（エラー）が含まれる。

（４）「リソース履歴の保存」
履歴制御部８は、他の要素からの指示により、時刻、プロセスＩＤ、スレッドＩＤ、スレッドを管理するデータ構造体に含まれる送信用ＧＵＩＤ、受信用ＧＵＩＤ、イベントの種類（データの送信、受信、システムコールのエラー）を保存する。

（５）「通信履歴の永続的保存」
履歴保存部７は、履歴制御部８に対して、保存された通信履歴が存在するか否かを問い合わせる。存在する場合、履歴保存部７はその履歴を履歴制御部８から取得し、計算機上のハードディスク等の永続的記録媒体に保存する。履歴保存部７は、永続的記録媒体に保存したデータに関しては履歴制御部８から削除するように、履歴制御部８に指示する。

［効果］
本実施形態によると、オペレーティングシステムのリソース状態の変化を捉え、関連するスレッドの情報を記録することにより、同一計算機内で動作するスレッド間の関連性を確認することができる。

＜実施形態３＞
次に、第３の実施形態の計算機システムについて説明する。

本実施形態では、第１の実施形態の計算機システム（図２、図３）と第２の実施形態に係る計算機システム（図５、図６）を組み合わせる。

本実施形態によると、任意の計算機上で動作する任意のスレッド間の関連性を明らかにすることが可能となる。

＜実施形態４＞
次に、第４の実施形態に係る計算機システムについて図面を参照して説明する。

［構成］
図７は、本実施形態の計算機システムの構成を例示するブロック図である。図７を参照すると、本実施形態では、第１ないし第３実施形態の計算機システムに対してさらにログ解析部１７が追加されている。

［動作］
次に、本実施形態の計算機システムの動作について説明する。

図７の構成においては略記されているが、計算機２Ａ〜２Ｃは、それぞれ、以下で説明する動作を除いて、第１ないし第３の実施形態における計算機２と同様の動作を行う。

本実施形態では、履歴保存部７は、ログを永続的記録媒体に保存する代わりに、ログ解析部１７に送信する。また、履歴保存部７は、ログ解析部１７にログを送信する際、履歴保存部７が動作する計算機２を識別可能なＩＤを付与する。

また、本実施形態では、履歴制御指示部６は第３の実施形態に加えて、履歴制御部８に対してルートスレッド、および、入力値のルールを与える。ルートスレッドとは、例えば図４における一番左側のスレッドのように、あるサービスを提供するための入り口となるスレッドをいう。

さらに、データ受信時の動作として、ＴＣＰデータ送受信部１２がルートスレッドか否かの判断を行う動作を加える。ルートスレッドである場合、ＴＣＰデータ送受信部１２は受信データと入力ルールと照合し、記録すべき部分を抜き出し履歴制御部８に対して保存を指示する。保存するデータには、時刻、プロセスＩＤ、スレッドＩＤ、送信用ＧＵＩＤ、受信用ＧＵＩＤ、ログのタイプ（サービスリクエスト受信）、入力ルールを適用して抽出した受信データが含まれる。

ここで、上述した「入力値のルール」について、具体例に基づいて説明する。本実施形態では、入力データとしては、所定の構造を持ったデータを前提とする。入力値のルールとは、この構造を明らかにするとともに、入力データの特定の部分を抽出するためのルールを指す。

一例として、入力データ（ないし受信データ）は以下の構造
Service: 1
User: Yamada
Option: Coffee
を有するものとする。また、入力値のルールは「"Service:" の次の数字」とする。この場合、ＴＣＰデータ送受信部１２は入力データに入力値のルールを適用し、履歴制御部８に記録すべき部分として「１」を抽出する。

ログ解析部１７は、計算機２Ａ〜２Ｃの履歴保存部７Ａ〜７Ｃからログを収集し、収集したログを解析する。ログ解析部１７は、一例としてニューラルネットワークを用いて解析を実施することができる。ここで、ニューラルネットワークの入力層の数は、ルートスレッドの入力ルールによって識別可能な種類（バリエーション）の数以上とする。ニューラルネットワークにおいて、入力層は任意の中間層を介して出力層に到達する。出力層の数は、システム内において関連するスレッドの数以上とする。例えば図４に示すスレッド群に対して、図８に示すニューラルネットワークを使用することが考えられる。

図８の入力層に含まれる各ユニット（ニューロン）は、ルートスレッドに対する入力ルールの適用によって識別される１つ１つのバリエーションに対応する。例えば、入力ルールによって番号１，２，３の３種類に分類される場合、入力層の１番目のユニットが番号１に対応し、同様に入力層の２，３番目のユニットがそれぞれ番号２，３に対応する。かかる場合に相当する例として、上記の具体例において「Service:」の次に現れる数字が、データの構造上１，２，３の３種類に限定される場合が考えられる。なお、図８は中間層が１層の場合を例示しているが、中間層の層数は１層に限定されない。

また、図８の出力層に含まれる各ユニットは、スレッドに対して１対１に対応する。

ログ解析部１７は、ログを受信すると、受信したログを検索可能な状態で保存する。次に、ログ解析部１７はログ内に送信用ＧＵＩＤが含まれるか否かを確認する。送信用ＧＵＩＤが含まれていない場合（すなわちＮ／Ａ（Not Available）の場合、例えば図４のスレッド４Ｃにおける「ｎａ」）、ログ解析部１７は受信用ＧＵＩＤをキーとして記録済みのログを検索し、送信スレッドにより記録されたログを確認する。ログ解析部１７は、検索されたログの受信用ＧＵＩＤをキーとして再度検索を実施し、同様の動作を繰り返す。これにより、ログ解析部１７は、最終的にルートスレッドが記録したログを特定することができる。次に逆方向に向けて、ログ解析部１７はルートスレッドの送信用ＧＵＩＤをキーとして、送信先スレッドが記録したログを特定する。以上の処理によって、ログ解析部１７はルートスレッドに対する特定の入力によって動作する関連するスレッドとこれに対応するログを摘出することができる。ここでは、ログ解析部１７によるこれらの処理を「処理Ａ」という。

ログ解析部１７は、これらのログの値からルートスレッドに対する入力値ごとに時刻差分の統計情報を採取する。時刻差分は、上位スレッドが送信動作時に記録した時刻と、その下位スレッドが送信動作時に記録した時刻の差分とする。ログ解析部１７は、統計情報として、その時刻差分を母集団とする平均μと標準偏差σを求めて保持する。また、ログ解析部１７は、保持した平均μと標準偏差σを用いて、ある時点の時刻差分から標準化された値ｚを求める。

ｚ＝（時刻差分−μ）/σ

ログ解析部１７は、ルートスレッドに対する入力が番号１である場合、番号１に対応するユニット（ニューロン）の出力を１．０とし、その他のユニットはすべて０とする。このとき、ログ解析部１７は、スレッドに関連する出力ユニットの出力が１−ｚとなり、一方、関連しないスレッドに対応する出力ユニットの出力が０となるようにニューラルネットワークを学習させる。ここで、ログ解析部１７は、学習方法として、例えば勾配降下法等の公知の手法を用いることができる。

任意の数のログを使用してニューラルネットワークを学習させた後、ログ解析部１７は、ルートスレッドに対する所定の入力をニューラルネットワークに入力すれば、当該所定の入力に対する関連するスレッド群を推測することができる。ログ解析部１７は、かかる推測結果と処理Ａの結果を比較し、異なる結果が得られた場合、システムは通常とは異なる状態であるものと推測することができる。

以上より、本実施形態の計算機システムによると、システムに異常状態が生じたことを検出することができる。

＜実施形態５＞
次に、第５の実施形態に係る計算機システムについて図面を参照して説明する。

図９は、本実施形態において想定するスレッドの構成を例示する。スレッド間の協調動作は、上記の実施形態のようにソケットによる通信やオペレーティングシステムのリソース（メッセージ、メッセージ通信、条件変数、セマフォ等）を介して行われるのみならず、図９に示すようにメモリキュー１８を介して行われる場合がある。

図９において、スレッド４Ａ（Producer）とスレッド４Ｂ（Consumer）の排他はメモリ上で行われ、キュー構造等を介してスレッド４Ａ（Producer）からスレッド４Ｂ（Consumer）にデータが渡される。ここで、メモリキュー１８の前段のスレッドを「Producerスレッド」と呼び、メモリキュー１８の次段のスレッドを「Consumerスレッド」と呼ぶ。この場合、オペレーティングシステム５は直接関与することができない。図９に示すスレッド構成に対して、第４の実施形態に係る計算機システムを適用すると、スレッド４Ａ（Producer）とスレッド４Ｂ（Consumer）との間に関連があるにも関わらず、スレッド４Ａ（Producer）の送信用ＧＵＩＤとスレッド４Ｂ（Consumer）の受信用ＧＵＩＤはいずれもＮ／Ａ（図９の「ｎａ」）となる。本実施形態は、このような場合においても、スレッド間の関連を適切に抽出するための手段を提示する。

［構成］
図１０は、本実施形態に係る計算機システム１の構成を例示するブロック図である。本実施形態では、第４の実施形態の計算機システム１（図７）に対して、さらに構成指示部１９が追加されている。

構成指示部１９は、想定される時刻差分μ、想定される標準偏差σ、および、図９のProducerスレッドを特定できる情報をログ解析部１７に提供する。ここで、時間差分μはProducerスレッドがデータを受信した時刻とConsumerスレッドが他のスレッドにデータを送信した時刻との間の想定される時間差の平均値である。通常、時間差分μは微小な値をとる。一方、標準偏差σは想定されるμの標準偏差である。また、Producerスレッドを特定できる情報は、そのスレッドが動作しているノード情報、プロセスＩＤ、スレッドＩＤ等である。

構成指示部１９は、想定される時刻差分μ、想定される標準偏差σ、および、Producerスレッドを特定できる情報を、本実施形態に係る計算機システム１を予め動作させることで取得するようにしてもよい。すなわち、構成指示部１９は、計算機システム１を予備的に動作させて記録したログから、受信用ＧＵＩＤがＮ／Ａのログを抽出し、これらのログに対応するスレッドをConsumerスレッド候補とする。さらに、構成指示部１９はConsumerスレッドの送信時刻とProducerスレッドの受信時刻の差分を求め、差分の平均値μと標準偏差σを求める。

ログ解析部１７の動作は、以下の点において第４の実施形態におけるログ解析部１７の動作と相違する。

ログ解析部１７は、ログを受信すると、受信したログを検索可能な状態で保存する。次に、ログ解析部１７はログ内に送信用ＧＵＩＤが含まれるか否かを確認する。含まれていない場合（すなわちＮ／Ａの場合、図９の「ｎａ」）、ログ解析部１７は受信用ＧＵＩＤをキーとして記録済みログを検索し、送信スレッドにより記録されたログを確認する。ログ解析部１７は、検索されたログの受信用ＧＵＩＤをキーとして再度検索を実施し、同様の動作を繰り返す。

最終的にルートスレッドが記録したログを特定できた場合、ログ解析部１７は第４の実施形態で説明した「処理Ａ」と同様な動作を行い、関連するすべてのスレッドを特定することができる。ここで、ログ解析部１７は、特定できたスレッド間の関連の強さを「１」に設定する。

一方、最終的にルートスレッドに到達できず、受信用ＧＵＩＤがＮ／Ａのスレッドに到達した場合、ログ解析部１７は当該スレッドをConsumerスレッド候補とする（図１１）。この場合、ログ解析部１７はConsumerスレッド候補がProducerスレッドと関連がある可能性を検討する。ここで、Producerスレッドに入力がなされた時刻と、Consumerスレッド候補が他のスレッドにデータを送信した時刻との差をΔｔとする。ログ解析部１７は、Δｔと構成指示部１９から得た平均値μ、標準偏差σから標準化（規格化）した値ｚを求める。

ｚ＝（Δｔ−μ）/σ

ここで、ｚを引数とし正の値を取る関数ｆ（ｚ）を定義し、ProducerスレッドとConsumerスレッド候補の関連強さを１−ｆ（ｚ）とする。ただし、１−ｆ（ｚ）が負になる場合、ログ解析部１７は、関連の強さを０とする。関数ｆ（ｚ）として、例えば以下の式を用いることができる。

ｆ（ｚ）＝｜ｚ｜

以上の動作に従って、ログ解析部１７はルートスレッドに所定の入力がなされた場合に動作するスレッド間の関連の強さを求める。なお、スレッド間に関連がない場合、関連の強さは０とする。図１１は、スレッド間の関連の強さを例示する。ログ解析部１７は、これらのスレッド間の関連の強さを、第４の実施形態におけるニューラルネットワークの出力層のユニット（ニューロン）の学習データとして使用する。例えば、ルートスレッドから該当スレッドまでのパスのすべての関連の強さをパラメータとする関数ｇ（Ｘ）を適用した値を学習データとすることができる。ここで、関数ｇ（Ｘ）はパラメータ中に１つでも０に近い値が存在する場合、０に近い値を出力する関数とする。例えば、関数ｇ（Ｘ）として、次式を採用することができる。

ｇ（ｘ１，ｘ２，…，ｘｎ）＝ｘ１＊ｘ２＊ｘ３＊…＊ｘｎ （＊は積を表す）

図１１において、上記の関数ｇ（Ｘ）を適用すると、Consumerスレッド候補に対応する出力ユニットに対しては０．９が学習データとなり、その下位のスレッドに対応する出力ユニットの学習データは、それぞれ０．９，０．０となる。

［効果］
本実施形態の計算機システムによると、スレッド間の協調がメモリを経由して行われる場合であっても、スレッド間の関連性を推測し、これに基づいてシステムの異常状態を検出することが可能となる。

なお、本発明において、下記の形態が可能である。
［形態１］
上記第１の態様に係る計算機システムのとおりである。
［形態２］
前記第２のスレッドが前記データの受信に応じて第３のスレッドにデータを送信する場合、前記第２のスレッドが稼働する計算機は前記第２のスレッドの識別子と前記第１の受信用識別子と第２の送信用識別子を関連付けて保持する、
形態１に記載の計算機システム。
［形態３］
前記第１の送信用識別子、前記第１の受信用識別子、および、前記第２の送信用識別子は、ＧＵＩＤ（Global Unique Identifier）である、
形態２に記載の計算機システム。
［形態４］
前記第１のスレッドが前記第２のスレッドに前記データを送信する場合、前記第１のスレッドが稼働する計算機は前記第１のスレッドの識別子と第１の送信用識別子と前記送信の時刻とを関連付けて保持し、
前記第２のスレッドが前記第１のスレッドから前記データを受信する場合、前記第２のスレッドが稼働する計算機は前記第２のスレッドの識別子と前記第１の送信用識別子と前記第１の受信用識別子と前記受信の時刻を関連付けて保持する、
形態１ないし３のいずれか一に記載の計算機システム。
［形態５］
前記第１のスレッドが稼働する計算機と前記第２のスレッドが稼働する計算機は、同一の計算機である、
形態４に記載の計算機システム。
［形態６］
前記複数のスレッドが稼働する計算機が保持する関連付けに基づいて、互いに関連するスレッド群を学習するログ解析手段を備え、
前記ログ解析手段は、前記学習によって得られた互いに関連するスレッド群と、前記複数のスレッドが稼働する計算機が蓄積した関連付けに基づいて抽出した互いに関連するスレッド群とを比較して、スレッド群に関連するプロセスが正常に動作しているか否かを判定する、
形態４または５に記載の計算機システム。
［形態７］
前記ログ解析手段は、送信用識別子に対して受信用識別子が関連付けられていないスレッドと、当該スレッドに対してデータを送信するスレッドとの関連の強さを、後者のスレッドがデータを受信した時刻と前者のスレッドがデータを送信した時刻の差に応じて算出し、算出した関連の強さに基づいて互いに関連するスレッド群を学習する、
形態６に記載の計算機システム。
［形態８］
上記第２の態様に係るスレッド間通信方法のとおりである。
［形態９］
前記第２のスレッドが前記データの受信に応じて第３のスレッドにデータを送信する場合、前記第２のスレッドの識別子と前記第１の受信用識別子と第２の送信用識別子を関連付けて保持するステップを含む、
形態８に記載のスレッド間通信方法。
［形態１０］
前記第１の送信用識別子、前記第１の受信用識別子、および、前記第２の送信用識別子は、ＧＵＩＤ（Global Unique Identifier）である、
形態９に記載のスレッド間通信方法。
［形態１１］
前記第１のスレッドが前記第２のスレッドに前記データを送信する場合、前記第１のスレッドの識別子と第１の送信用識別子と前記送信の時刻とを関連付けて保持するステップと、
前記第２のスレッドが前記第１のスレッドから前記データを受信する場合、前記第２のスレッドが稼働する計算機は前記第２のスレッドの識別子と前記第１の送信用識別子と第１の受信用識別子と前記受の信時刻を関連付けて保持するステップと、を含む、
形態８ないし１０のいずれか一に記載のスレッド間通信方法。
［形態１２］
前記複数のスレッドが稼働する計算機が保持する関連付けに基づいて、互いに関連するスレッド群を学習するステップと、
前記学習によって得られた互いに関連するスレッド群と、前記複数のスレッドが稼働する計算機が蓄積した関連付けに基づいて抽出した互いに関連するスレッド群とを比較して、スレッド群に関連するプロセスが正常に動作しているか否かを判定するステップと、を含む、
形態１１に記載のスレッド間通信方法。
［形態１３］
前記ログ解析手段は、送信用識別子に対して受信用識別子が関連付けられていないスレッドと、当該スレッドに対してデータを送信するスレッドとの関連の強さを、後者のスレッドがデータを受信した時刻と前者のスレッドがデータを送信した時刻の差に応じて算出し、算出した関連の強さに基づいて互いに関連するスレッド群を学習するステップを含む、
形態１２に記載のスレッド間通信方法。
［形態１４］
上記第３の態様に係るプログラムのとおりである。

なお、上記特許文献の全開示内容は、本書に引用をもって繰り込み記載されているものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態の変更・調整が可能である。また、本発明の全開示の枠内において種々の開示要素（各請求項の各要素、各実施形態の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし、選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。

１ 計算機システム
２、２Ａ〜２Ｃ 計算機
３、３Ａ〜３Ｃ プロセス
４Ａ〜４Ｅ スレッド
５ オペレーティングシステム
６ 履歴制御指示部
７、７Ａ〜７Ｃ 履歴保存部
８ 履歴制御部
９ プロセス管理部
１０ スレッド管理部
１１ ソケット管理部
１２ ＴＣＰデータ送受信部
１３ システムコールゲートウェイ部
１４ 機能利用部
１５ リソース管理部
１６ リソース処理部
１７ ログ解析部
１８ メモリキュー
１９ 構成指示部

Claims (10)

1. 複数のスレッドが稼働する計算機を備え、
   第１のスレッドが第２のスレッドにデータを送信する場合、前記第１のスレッドが稼働する計算機は前記第１のスレッドの識別子と第１の送信用識別子を関連付けて保持し、
   前記第２のスレッドが前記第１のスレッドから前記データを受信する場合、前記第２のスレッドが稼働する計算機は前記第２のスレッドの識別子と前記第１の送信用識別子と第１の受信用識別子とを関連付けて保持する、
   ことを特徴とする計算機システム。
2. 前記第２のスレッドが前記データの受信に応じて第３のスレッドにデータを送信する場合、前記第２のスレッドが稼働する計算機は前記第２のスレッドの識別子と前記第１の受信用識別子と第２の送信用識別子を関連付けて保持する、
   請求項１に記載の計算機システム。
3. 前記第１の送信用識別子、前記第１の受信用識別子、および、前記第２の送信用識別子は、ＧＵＩＤ（Global Unique Identifier）である、
   請求項２に記載の計算機システム。
4. 前記第１のスレッドが前記第２のスレッドに前記データを送信する場合、前記第１のスレッドが稼働する計算機は前記第１のスレッドの識別子と第１の送信用識別子と前記送信の時刻とを関連付けて保持し、
   前記第２のスレッドが前記第１のスレッドから前記データを受信する場合、前記第２のスレッドが稼働する計算機は前記第２のスレッドの識別子と前記第１の送信用識別子と前記第１の受信用識別子と前記受信の時刻を関連付けて保持する、
   請求項１ないし３のいずれか１項に記載の計算機システム。
5. 前記第１のスレッドが稼働する計算機と前記第２のスレッドが稼働する計算機は、同一の計算機である、
   請求項４に記載の計算機システム。
6. 前記複数のスレッドが稼働する計算機が保持する関連付けに基づいて、互いに関連するスレッド群を学習するログ解析手段を備え、
   前記ログ解析手段は、前記学習によって得られた互いに関連するスレッド群と、前記複数のスレッドが稼働する計算機が蓄積した関連付けに基づいて抽出した互いに関連するスレッド群とを比較して、スレッド群に関連するプロセスが正常に動作しているか否かを判定する、
   請求項４または５に記載の計算機システム。
7. 前記ログ解析手段は、送信用識別子に対して受信用識別子が関連付けられていないスレッドと、当該スレッドに対してデータを送信するスレッドとの関連の強さを、後者のスレッドがデータを受信した時刻と前者のスレッドがデータを送信した時刻の差に応じて算出し、算出した関連の強さに基づいて互いに関連するスレッド群を学習する、
   請求項６に記載の計算機システム。
8. 第１のスレッドが第２のスレッドにデータを送信する場合、前記第１のスレッドの識別子と第１の送信用識別子を関連付けて保持するステップと、
   前記第２のスレッドが前記第１のスレッドから前記データを受信する場合、前記第２のスレッドの識別子と前記第１の送信用識別子と第１の受信用識別子とを関連付けて保持するステップと、を含む、
   ことを特徴とするスレッド間通信方法。
9. 前記第２のスレッドが前記データの受信に応じて第３のスレッドにデータを送信する場合、前記第２のスレッドの識別子と前記第１の受信用識別子と第２の送信用識別子を関連付けて保持するステップを含む、
   請求項８に記載のスレッド間通信方法。
10. 第１のスレッドが第２のスレッドにデータを送信する場合、前記第１のスレッドの識別子と第１の送信用識別子を関連付けて保持する処理と、
    前記第２のスレッドが前記第１のスレッドから前記データを受信する場合、前記第２のスレッドの識別子と前記第１の送信用識別子と第１の受信用識別子とを関連付けて保持する処理と、をコンピュータに実行させる、
    ことを特徴とするプログラム。

Images