(57)【要約】【課題】アプリケーションにおいて発生するタイミング依存の不具合の再現率が高いスレッドのスケジュール方法を見出すことを可能とする。【解決手段】調査プログラム１１は、複数のスレッドのスケジュール方法を表すスレッド制御ポリシーを設定する。スレッド制御用スレッド１４１は、設定されたスレッド制御ポリシーによって表されるスケジュール方法で複数のスレッドが実行されるための制御を行う。調査プログラム１１は、不具合発生プログラム１２に不具合が発生したことが検出された場合に、不具合が発生したこと及び複数のスレッドが実行されてから不具合が発生するまでの時間を統計情報として実行結果統計情報記録ＤＢ１３に記録する。調査プログラム１１は、実行結果統計情報記録ＤＢ１３に記録された統計情報に基づいて、不具合発生プログラム１２に発生した不具合の発生頻度が高いスレッド制御ポリシーを特定する。【選択図】      図２
2010003153.tif 000002
【特許請求の範囲】
【請求項１】
複数のスレッドが同時に実行されるアプリケーションにおいて発生したタイミング依存の不具合を再現する情報処理装置において、
前記複数のスレッドが実行される際の当該複数のスレッドのスケジュール方法を表すスレッド制御ポリシーが設定される設定手段と、
前記設定手段に設定されたスレッド制御ポリシーによって表されるスケジュール方法で前記複数のスレッドが実行されるための制御を行うスレッド制御手段と、
前記スケジュール方法で前記複数のスレッドが実行された際に、前記アプリケーションに前記不具合が発生したことを検出する検出手段と、
前記不具合が発生したことが検出された場合、当該不具合が発生したこと及び前記複数のスレッドが実行されてから当該不具合が発生するまでの時間を統計情報として、前記設定されたスレッド制御ポリシー毎に記録する実行結果統計情報記録手段と、
前記実行結果統計情報記録手段に記録された統計情報に基づいて、前記アプリケーションプログラムに発生した前記不具合の発生頻度が高いスレッド制御ポリシーを特定する特定手段と
を具備することを特徴とする情報処理装置。
【請求項２】
前記複数のスレッドが実行される優先度の各々を管理するスレッド管理手段を更に具備し、
前記スレッド制御ポリシーは、前記管理手段において管理される前記優先度を予め定められた順序で繰り返し上下させることにより、前記複数のスレッドを予め定められた順序で実行させるスケジュール方法を表す
ことを特徴とする請求項１記載の情報処理装置。
【請求項３】
前記複数のスレッドを実行する複数のプロセッサを更に具備し、
前記スレッド制御ポリシーは、前記複数のプロセッサに前記複数のスレッドの各々を同時に実行させるスケジュール方法を表す
ことを特徴とする請求項１記載の情報処理装置。
【請求項４】
前記スレッド制御ポリシーは、前記複数のスレッド毎に設定された当該スレッドが実行される頻度に基づいて、当該複数のスレッドを実行させるスケジュール方法を表すことを特徴とする請求項１記載の情報処理装置。
【請求項５】
前記スレッド制御ポリシーは、予め定められている前記複数のスレッドの待機時間に予め設定された割合をかけた時間を待機時間として当該複数のスレッドを実行させるスケジュール方法を表すことを特徴とする請求項１記載の情報処理装置。
【請求項６】
複数のスレッドが同時に実行されるアプリケーションにおいて発生したタイミング依存の不具合を再現し、設定手段及び実行結果統計情報記録手段を備える情報処理装置によって実行されるプログラムであって、
前記情報処理装置に、
前記複数のスレッドが実行される際の当該複数のスレッドのスケジュール方法を表すスレッド制御ポリシーを前記設定手段に設定するステップと、
前記設定手段に設定されたスレッド制御ポリシーによって表されるスケジュール方法で前記複数のスレッドが実行されるための制御を行うステップと、
前記スケジュール方法で前記複数のスレッドが実行された際に、前記アプリケーションに前記不具合が発生したことを検出するステップと、
前記不具合が発生したことが検出された場合、当該不具合が発生したこと及び前記複数のスレッドが実行されてから当該不具合が発生するまでの時間を統計情報として、前記設定されたスレッド制御ポリシー毎に前記実行結果統計情報記録手段に記録するステップと、
前記実行結果統計情報記録手段に記録された統計情報に基づいて、前記アプリケーションに発生した前記不具合の発生頻度が高いスレッド制御ポリシーを特定するステップと
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチスレッドアプリケーションにおけるタイミング依存の不具合の現象再現率を向上させるために用いられる情報処理装置及びプログラムに関する。
【背景技術】
【０００２】
一般的に、例えば複数のスレッドが同時に実行されるマルチスレッドアプリケーションプログラム（以下、アプリケーションと表記）においてタイミング依存の不具合が発生した場合には、当該不具合が発生した原因を調査する場合がある。このアプリケーションにおいて発生するタイミング依存の不具合には、例えば複数のスレッド間におけるデッドロックまたは当該複数のスレッドが同時にアクセスすることによるメモリ破壊等が挙げられる。
【０００３】
上記したタイミング依存の不具合の原因を調査するためには、例えば当該タイミング依存の不具合（以下、現象と表記）を再現する必要がある。このような場合には、例えば同等スペックのマシン（情報処理装置）を用意する等の現象再現時の環境と同等の環境を用意し、当該情報処理装置において高負荷連続実行を行うことによって現象を再現することができる。
【０００４】
しかしながら、このような現象再現方法では、例えば現象が発生した実機を用いないと当該現象を再現できない場合がある。また、現象を再現するのに多大な時間がかかる場合がある。
【０００５】
また、上記したようにして現象発生の原因が調査された場合には、当該現象が発生しないようにアプリケーションを修正することになる。この場合、修正されたアプリケーション（修正版モジュール）においては、当該修正により現象が発生しないことを証明する必要がある。このためには、例えば修正版モジュールのロジック上の説明の他に、現象が発生（再現）するような十分な時間連続稼働させたとしても再現しないこと示さなければならない場合も多い。したがって、修正版モジュールでは現象が再現しないこと（非再現）の確認に多大な時間を要する場合がある。
【０００６】
したがって、例えば単純に現象が再現されるまでアプリケーションを実行するのではなく、短時間で現象を再現させる仕組みが必要である。
【０００７】
そこで、例えば汎用的なデバッガを使用することが考えられる。例えば汎用的なデバッガを使用して各スレッドを少しずつ実行（例えば、ステップ実行）して稀な状況（再現しにくい現象）を発生させることができる。
【０００８】
ところで、例えば実行過程で指定されたスレッドを先に実行し、かつ実行後に、元のプログラムで指定された優先度や状態を復帰する技術（以下、先行技術１と表記）が開示されている（例えば、特許文献１を参照）。この先行技術１によれば、プログラムが本来持つ意味を保存したまま、スレッド指定部により指定されたスレッドを一時的に優先実行させることができる。
【０００９】
例えば上記した汎用的なデバッガを使用することにより、現象の発生の原因箇所にあたりがつけば、先行技術１を利用することによって現象の発生の原因調査の効率を更に改善させることができることが考えられる。
【００１０】
具体的には、まず、例えばユーザの操作に応じてアプリケーションを特定のデバッガにつないで実行する。ユーザの操作に応じて特定のタイミングでアプリケーションを一時停止する。次に、ユーザが実行させたいスレッドを当該ユーザが指定して再開させる。この場合、指定されたスレッドは一時的に高い優先度に設定されるため直後に実行される。また、指定されたスレッドの処理終了後には、当該スレッドの優先度は元の状態に戻される。このように、汎用的なデバッガ及び先行技術１を用いることにより調査効率を改善することができる。以下、ここで説明したような汎用的デバッガ及び先行技術１による現象を再現する方法を第１の現象再現方法と称する。
【００１１】
一方、任意のスレッドスケジューリングアルゴリズムを用いた汎用のマルチスレッドＯＳ（Operating System）上においても、リアルタイムＯＳのディスパッチ処理と割り込み処理とを忠実に模倣するリアルタイムＯＳシミュレータ（以下、先行技術２と表記）が開示されている（例えば、特許文献２を参照）。この先行技術２を利用することによって、例えば汎用のマルチスレッドＯＳ上でリアルタイムＯＳのディスパッチ処理と割り込み処理とを模倣するシミュレータの上でアプリケーションを実行させることで、スレッドのコンテキスト切替頻度を挙げて現象が発生する頻度を向上させることができる。以下、ここで説明したような先行技術２を利用した現象を再現する方法を第２の現象再現方法と称する。
【特許文献１】特開平７−７３０５１号公報
【特許文献２】特開２００２−７１４７号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
しかしながら、上記した第１の現象再現方法では、例えばアプリケーションの不具合の原因が特定できていない場合には、どのタイミングでアプリケーションを一時停止してどのスレッドを実行すればよいかが分からないため、現象を再現することができない可能性がある。また、第１の現象再現方法では、現象の再現環境は別途用意する必要がある。例えば現象の再現環境を用意しないとすると、不具合の原因が複数隠れていたような場合には、当該原因が複数あることに気付くことなくそのうちの１箇所だけを修正し、その非再現だけをステップ実行等で確認するのみで調査を終了する可能性がある。
【００１３】
第２の現象再現方法では、アプリケーションをスレッドスケジューラの異なるいくつかのＯＳで実行できる。
【００１４】
しかしながら、第２の現象再現方法では、例えばスレッドが実行される優先度（以下、スレッド優先度と表記）が低いスレッドとスレッド優先度が高いスレッドとのタイミング依存の不具合の場合には、スレッド優先度の低いスレッドへの処理割当が抑制されたままであるため、稀なタイミングによる不具合の場合には発生頻度が依然として上がらない可能性がある。また、第２の現象再現方法では、例えばsleep時間が長引いた等の稀なタイミングによる不具合の場合は想定されていないため、発生頻度は依然として上がらない可能性がある。また、第２の現象再現方法では、現象が発生したＯＳと互換性を持つリアルタイムＯＳシミュレータを用意する必要がある。
【００１５】
そこで、本発明の目的は、アプリケーションにおいて発生するタイミング依存の不具合の再現率が高いスレッドのスケジュール方法を見出すことが可能な情報処理装置及びプログラムを提供することにある。
【課題を解決するための手段】
【００１６】
本発明の１つの態様によれば、複数のスレッドが同時に実行されるアプリケーションプログラムにおいて発生したタイミング依存の不具合を再現する情報処理装置が提供される。この情報処理装置は、前記複数のスレッドが実行される際の当該複数のスレッドのスケジュール方法を表すスレッド制御ポリシーが設定される設定手段と、前記設定手段に設定されたスレッド制御ポリシーによって表されるスケジュール方法で前記複数のスレッドが実行されるための制御を行うスレッド制御手段と、前記スケジュール方法で前記複数のスレッドが実行された際に、前記アプリケーションに前記不具合が発生したことを検出する検出手段と、前記不具合が発生したことが検出された場合、当該不具合が発生したこと及び前記複数のスレッドが実行されてから当該不具合が発生するまでの時間を統計情報として、前記設定されたスレッド制御ポリシー毎に記録する実行結果統計情報記録手段と、前記実行結果統計情報記録手段に記録された統計情報に基づいて、前記アプリケーションに発生した前記不具合の発生頻度が高いスレッド制御ポリシーを特定する特定手段とを具備する。
【発明の効果】
【００１７】
本発明によれば、アプリケーションにおいて発生するタイミング依存の不具合の再現率が高いスレッドのスケジュール方法を見出すことを可能とする。
【発明を実施するための最良の形態】
【００１８】
以下、図面を参照して、本発明の各実施形態について説明する。
【００１９】
［第１の実施形態］
図１は、本発明の第１の実施形態に係る情報処理装置の機能構成を示すブロック図である。図１に示す情報処理装置１０は、例えば複数のスレッドが同時に実行されるマルチスレッドアプリケーション（プログラム）において発生したタイミング依存の不具合（現象）を再現する際に用いられる。このマルチスレッドアプリケーションにおいて発生するタイミング依存の不具合には、例えば複数のスレッド間におけるデッドロックまたは当該複数のスレッドが同時にアクセスすることによるメモリ破壊等が挙げられる。
【００２０】
なお、複数のスレッドは、マルチスレッドアプリケーションプログラムを構成する。この複数のスレッドは、例えば情報処理装置１０のＣＰＵ（図示せず）によって実行されるものである。
【００２１】
図１に示すように、情報処理装置１０上では、調査プログラム（スレッド制御ポリシー−現象発生有無相関調査プログラム）１１及び上記したタイミング依存の不具合が発生したマルチスレッドアプリケーションプログラム（以下、不具合発生プログラムと表記）１２が動作する。また、情報処理装置１０は、実行結果統計情報記録データベース（ＤＢ）１３を備える。
【００２２】
情報処理装置１０は、当該装置の各機能を実現するためのハードウェア構成、またはハードウェアとソフトウェアとの組み合わせ構成として実現されている。ソフトウェアは、予め記憶媒体又はネットワークからインストールされ、当該装置にその機能を実現させるためのプログラムからなる。
【００２３】
なお、以下に説明する処理は、例えば情報処理装置１０のＣＰＵが調査プログラム１１または不具合発生プログラム１２を実行することにより実現されるものであるが、以下では便宜的に、調査プログラム１１または不具合発生プログラム１２が実行するものとして説明する。
【００２４】
調査プログラム１１は、スレッド制御ポリシーを保持する。スレッド制御ポリシーは、例えば不具合発生プログラム１２を構成する複数のスレッドが実行される際の、当該複数のスレッドのスケジュール方法を表す。このスレッド制御ポリシーの詳細については後述する。
【００２５】
調査プログラム１１は、例えば情報処理装置１０を利用するユーザの指示に応じて、保持されているスレッド制御ポリシーを実行結果統計情報記録ＤＢ１３にセット（設定）する。
【００２６】
なお、調査プログラム１１は、複数のスレッド制御ポリシーを保持していてもよい。また、調査プログラム１１は、複数のスレッド制御ポリシーを実行結果統計情報記録ＤＢ１３にセットしても構わない。
【００２７】
調査プログラム１１は、スレッド制御ポリシーが実行結果統計情報記録ＤＢ１３にセットされると、不具合発生プログラム１２を実行する。
【００２８】
このとき、調査プログラム１１は、不具合発生プログラム１２にスレッド制御用ＤＬＬ（Dynamic Link Library）１４をロードさせる。これにより、不具合発生プログラム１２は、ロードされたスレッド制御用ＤＬＬ１４の内容（処理）を実行する。
【００２９】
以下では、煩雑さを避けるために、スレッド制御用ＤＬＬ１４をロードすることによって不具合発生プログラム１２が実行する処理については、スレッド制御用ＤＬＬ１４が実行するものとして説明する。なお、他のＤＬＬ（例えば、kernel32.dll等）１５についてもスレッド制御用ＤＬＬ１４と同様である。
【００３０】
スレッド制御用ＤＬＬ１４は、調査プログラム１１によって実行結果統計情報記録ＤＢ１３にセットされたスレッド制御ポリシーに応じて、不具合発生プログラム１２を構成する複数のスレッドを実行させる。これにより、不具合発生プログラム１２において上記したタイミング依存の不具合が発生した場合には、例えばその旨が統計情報として実行結果統計情報記録ＤＢ１３に記録される。統計情報は、調査プログラム１１によって実行結果統計情報記録ＤＢ１３に記録される。
【００３１】
次に、図２を参照して、図１に示す情報処理装置１０における処理の流れについて説明する。
【００３２】
なお、図２に示すように、不具合発生プログラム１２は、スレッド１２１及びスレッド１２２を含む複数のスレッドから構成されるものとする。また、スレッド制御用ＤＬＬ１４は、スレッド制御用スレッド１４１及びスレッド管理テーブル１４２を含むものとする。
【００３３】
まず、調査プログラム１１は、例えば情報処理装置１０を利用するユーザの操作（指示）に応じて、当該調査プログラム１１が保持しているスレッド制御ポリシーを実行結果統計情報記録ＤＢ１３にセットする（ステップＳ１）。このスレッド制御ポリシーは、例えばユーザによって予め定められている。
【００３４】
調査プログラム１１は、ステップＳ１の処理が実行されると、不具合発生プログラム１２を実行する（ステップＳ２）。
【００３５】
調査プログラム１１は、不具合発生プログラム１２内に新規スレッドを作成（注入）する。この新規スレッドは、スレッド制御用ＤＬＬ１４をロードするスレッドである。不具合発生プログラム１２内に作成された新規スレッドは、スレッド制御用ＤＬＬ１４のロード処理にて、スレッド制御用スレッド１４１を作成する。このとき、作成されたスレッド制御用スレッド１４１が実行される優先度（スレッド優先度）は、「最高」に設定される。
【００３６】
次に、スレッド制御用スレッド１４１は、調査プログラム１１によってセットされたスレッド制御ポリシーを実行結果統計情報記録ＤＢ１３からロードする（ステップＳ３）。このとき、実行結果統計情報記録部ＤＢ１３に複数のスレッド制御ポリシーがセットされている場合には、その全てのスレッド制御ポリシーがロードされる。
【００３７】
スレッド制御用スレッド１４１は、既に存在するスレッドをスレッド管理テーブル１４２に登録する。この既に存在するスレッドは、上記した調査プログラム１１によって不具合発生プログラム１２が実行された後に作成された不具合発生プログラム１２を構成するスレッド（例えば、スレッド１２１及び１２２）である。
【００３８】
スレッド制御用スレッド１４１は、スレッドをスレッド管理テーブル１４２に登録する際、当該スレッドが実行される優先度（スレッド優先度）を当該スレッドに対応付けてスレッド管理テーブル１４２に登録（設定）する。この場合、スレッド制御用スレッド１４１は、スレッドに対応付けてスレッド優先度「中」をスレッド管理テーブル１４２に登録する。
【００３９】
また、例えば不具合発生プログラム１２を構成する新しいスレッドが作成された場合、スレッド制御用スレッド１４１は、例えばＤＬＬ＿ＴＨＲＥＡＤ＿ＡＴＴＡＣＨによるＤＬＬに対する通知等を利用してその旨を検知する。スレッド制御用スレッド１４１は、新しいスレッドが作成された旨が検知された場合、当該新しいスレッド及び当該スレッドの優先度を対応付けてスレッド管理テーブル１４２に登録する。このとき、スレッドの優先度は「中」に設定される。
【００４０】
上記した処理が実行されると、スレッド制御用スレッド１４１は、ステップＳ３において実行結果統計情報記録ＤＢ１３からロードされたスレッド制御ポリシーに応じた制御を実行する。つまり、スレッド制御用スレッド１４１は、スレッド制御ポリシーによって表されるスケジュール方法で複数のスレッドが実行される（複数のスレッドを実行させる）ための制御を行う。これにより、不具合発生プログラム１２を構成する複数のスレッド（例えば、スレッド１２１及び１２２）が、スレッド制御ポリシーによって表されるスケジュール方法に基づいて実行される。
【００４１】
調査プログラム１１は、上記したようにスレッド制御用スレッド１４１によるスレッド制御ポリシーに応じた制御に応じて実行される複数のスレッドから構成される不具合発生プログラム１２にタイミング依存の不具合が発生したことを検出する。調査プログラム１１は、例えば不具合発生プログラム１２の子プロセスからのシグナル検知または当該子プロセスの終了コードによって、当該不具合発生プログラム１２にタイミング依存の不具合が発生したことを検出することができる。
【００４２】
調査プログラム１１は、不具合発生プログラム１２に不具合が発生したと検出された場合に、例えば当該不具合が発生したこと及び当該不具合が発生するまでの時間を統計情報として実行結果統計情報記録ＤＢ１３に記録する（ステップＳ４）。
【００４３】
図３は、スレッド制御用ＤＬＬ１４に含まれるスレッド管理テーブル１４２のデータ構造の一例を示す。図３に示すように、スレッド管理テーブル１４２には、不具合発生プログラム１２を構成する複数のスレッドの各々（を識別するスレッドＩＤ）及び当該スレッドの優先度（スレッド優先度）が対応付けて保持される。
【００４４】
図３に示す例では、スレッド管理テーブル１４２には、スレッドＩＤ「０ｘＡＡＢＢＣＣＤＤ」及び優先度「中」が対応付けて保持されている。このスレッドＩＤ「０ｘＡＡＢＢＣＣＤＤ」は、例えばスレッド１２１を識別するためのスレッドＩＤである。
【００４５】
また、スレッド管理テーブル１４２には、スレッドＩＤ「０ｘ１１２２３３４４」及び優先度「中」が対応付けて保持されている。このスレッドＩＤ「０ｘ１１２２３３４４」は、例えばスレッド１２２を識別するためのスレッドＩＤである。
【００４６】
次に、図４のフローチャートを参照して、調査プログラム１１の処理手順について説明する。
【００４７】
まず、調査プログラム１１は、情報処理装置１０を利用するユーザの操作に応じて実行される（ステップＳ１１）。
【００４８】
次に、調査プログラム１１は、ユーザの操作に応じて、スレッド制御ポリシー、不具合発生プログラム１２のプログラム実行所要時間（の上限値）及び不具合発生プログラム１２の実行回数を、実行結果統計情報記録ＤＢ１３に設定する（ステップＳ１２）。このとき、スレッド制御ポリシーは、例えば予め調査プログラム１１に保持されている複数のスレッド制御ポリシーの中から１つまたは複数がユーザに選択されることによって設定される。また、プログラム実行所要時間は、ユーザによってその都度指定されてもよいし、例えば予め定められている時間（例えば、３０分）が設定される構成であっても構わない。同様に、実行回数は、ユーザによってその都度指定されてもよいし、例えば予め定められた回数（例えば、５回）が設定される構成であっても構わない。
【００４９】
調査プログラム１１は、実行結果統計情報記録ＤＢ１３内に、統計情報の記録（保存）先を作成する（ステップＳ１３）。
【００５０】
調査プログラム１１は、上記したステップＳ１２において設定されたスレッド制御ポリシーのうちの１つを実行結果統計情報記録ＤＢ１３に登録（セット）する（ステップＳ１４）。
【００５１】
ここで、調査プログラム１１は、不具合発生プログラム１２を実行する（ステップＳ１５）。
【００５２】
調査プログラム１１は、不具合発生プログラム１２内に新規スレッドを注入（作成）し、当該新規スレッドにスレッド制御用ＤＬＬ１４をロードさせる（ステップＳ１６）。
【００５３】
ここで、図５のフローチャートを参照して、上記した図４に示すステップＳ１６の処理において作成された新規スレッドの処理手順について説明する。
【００５４】
まず、不具合発生プログラム１２内に作成された新規スレッドは、スレッド制御用ＤＬＬ１４をロードする（ステップＳ３１）。
【００５５】
新規スレッドは、スレッド制御用ＤＬＬ１４のロード処理において、スレッド制御用スレッド１４１を作成する（ステップＳ３２）。
【００５６】
次に、新規スレッドは、作成されたスレッド制御用スレッド１４１の優先度を「最高」に設定する（ステップＳ３３）。
【００５７】
上記したステップＳ３１〜ステップＳ３３の処理を実行すると、新規スレッドの処理は終了する。
【００５８】
ここで、図６のフローチャートを参照して、上記した図５に示すステップＳ３２の処理において新規スレッドによって作成されたスレッド制御用スレッド１４１の処理手順について説明する。
【００５９】
まず、スレッド制御用スレッド１４１は、実行結果統計情報記録ＤＢ１３に登録（セット）されているスレッド制御ポリシーを、当該実行結果統計情報記録ＤＢ１３からロードする（ステップＳ４１）。このロードされたスレッド制御ポリシーは、上記した図４に示すステップＳ１４の処理において実行結果統計情報記録ＤＢ１３に登録されたスレッド制御ポリシーである。
【００６０】
スレッド制御用スレッド１４１は、不具合発生プログラム１２を構成する既に存在するスレッド（を識別するためのスレッドＩＤ）をスレッド管理テーブル１４２に登録する（ステップＳ４２）。
【００６１】
スレッド制御用スレッド１４１は、スレッド管理テーブル１４２に登録されたスレッドの優先度（スレッド優先度）を全て「中」に設定する（ステップＳ４３）。換言すれば、スレッド制御用スレッド１４１は、スレッド管理テーブル１４２に登録された全てのスレッドに対応付けて当該スレッド管理テーブル１４２に保持されているスレッド優先度を「中」に設定する。
【００６２】
スレッド制御用スレッド１４１は、上記したステップＳ３１においてロードされたスレッド制御ポリシーに応じて複数のスレッドが実行されるための制御を実行する（ステップＳ４４）。
【００６３】
なお、上記したスレッド制御用スレッド１４１による処理の詳細については後述する。
【００６４】
また、ここで、図７のフローチャートを参照して、例えば不具合発生プログラム１２内で新たにスレッドが作成された際の当該スレッドの処理手順について説明する。
【００６５】
まず、不具合発生プログラム１２内で新たに作成されたスレッド（例えば、スレッド１２２）は、スレッド制御用ＤＬＬ１４へのアタッチ処理（上記したＤＬＬ＿ＴＨＲＥＡＤ＿ＡＴＴＡＣＨ）にて当該スレッド（を識別するためのスレッドＩＤ）をスレッド管理テーブル１４２に登録する（ステップＳ５１）。
【００６６】
このとき、不具合発生プログラム１２内で新たに作成されたスレッドは、当該スレッドに対応付けて当該スレッドの優先度（スレッド優先度）を「中」に設定する（ステップＳ５２）。
【００６７】
上記したステップＳ５１及びステップＳ５２の処理が実行されると、不具合発生プログラム１２内で新たに作成されたスレッドのメインルーチンが実行される（ステップＳ５３）。
【００６８】
ここで、再び図４に戻ると、調査プログラム１１は、不具合発生プログラム１２の処理が終了したか、または上記ステップＳ１２において設定されたプログラム実行所要時間（の上限値）が経過した（つまり、時間切れ）か否かを判定する（ステップＳ１７）。ここでは、例えば当該不具合発生プログラム１２の処理の全てが完了した場合、または当該不具合発生プログラム１２において不具合が発生した場合に、当該不具合発生プログラム１２の処理が終了したと判定される。
【００６９】
なお、ここでの不具合発生プログラム１２の処理とは、上記した図６に示すステップＳ４４におけるスレッド制御用スレッド１４１によるスレッド制御ポリシーに応じて複数のスレッドが実行されることにより実現される処理である。
【００７０】
不具合発生プログラム１２の処理が終了した、または時間切れであると判定された場合（ステップＳ１７のＹＥＳ）、調査プログラム１１は、不具合発生プログラム１２の実行結果を示す統計情報を実行結果統計情報記録ＤＢ１３に記録する（ステップＳ１８）。調査プログラム１１は、不具合発生プログラム１２が複数のスレッドを実行するときの当該複数のスレッドのスケジュール方法（つまり、ステップＳ１４において登録されたスレッド制御ポリシー）毎に統計情報を記録する。
【００７１】
このとき、上記した不具合発生プログラム１２において不具合が発生することなく当該不具合発生プログラム１２の処理が終了または時間切れとなった場合には、調査プログラム１１は、不具合が発生しない旨を統計情報として実行結果統計情報記録ＤＢ１３に記録する。一方、不具合発生プログラム１２において不具合が発生したことによって当該不具合発生プログラム１２の処理が終了した場合には、調査プログラム１１は、当該不具合が発生したこと及び当該不具合発生までの時間を統計情報として実行結果統計情報記録ＤＢ１３に記録する。
【００７２】
次に、調査プログラム１１は、上記したステップＳ１２において設定された実行回数、不具合発生プログラム１２が実行されたか否かを判定する（ステップＳ１９）。
【００７３】
設定された実行回数、不具合発生プログラム１２が実行されたと判定された場合（ステップＳ１９のＹＥＳ）、調査プログラム１１は、上記したステップＳ１２において設定されたスレッド制御ポリシーの全てについて上記したステップＳ１４〜ステップＳ１９の処理が実行されたか否かを判定する（ステップＳ２０）。
【００７４】
スレッド制御ポリシーの全てについて上記したステップＳ１４〜ステップＳ１９の処理が実行されたと判定された場合には（ステップＳ２０のＹＥＳ）、調査プログラム１１は、実行結果統計情報記録ＤＢ１３に記録されている統計情報に基づいて、不具合発生プログラム１２において不具合の発生頻度（現象発生頻度）の（最も）高いスレッド制御ポリシーを特定する。調査プログラム１１は、特定されたスレッド制御ポリシーを例えばユーザに対して提示する（ステップＳ２１）。これにより、スレッド制御ポリシーを提示されたユーザは、例えば不具合発生プログラム１２において発生したタイミング依存の不具合（現象）の原因の調査のために当該現象を再現する必要がある場合には、当該提示されたスレッド制御ポリシー（によって表されるスケジュール方法）に応じて不具合発生プログラム１２を動作させることで、容易に当該現象を再現することが可能となる。
【００７５】
一方、上記したステップＳ１７において、不具合発生プログラム１２が終了しておらず、且つ時間切れでもない場合には、当該ステップＳ１７の処理が繰り返される。
【００７６】
また、上記したステップＳ１９において、設定された実行回数、不具合発生プログラム１２が実行されていないと判定された場合、ステップＳ１５に戻って処理が繰り返される。つまり、ステップＳ１４において登録された１つのスレッド制御ポリシーに応じて、ステップＳ１２において設定された実行回数、不具合発生プログラム１２が実行される。つまり、例えば実行回数が５回である場合には、１つのスレッド制御ポリシーに応じて５回不具合発生プログラム１２が実行され、当該実行された５回分の統計情報が実行結果統計情報記録ＤＢ１３に記録されることになる。
【００７７】
また、上記したステップＳ２０において、スレッド制御ポリシーの全てについて上記したステップＳ１４〜ステップＳ１９の処理が実行されていないと判定された場合には、ステップＳ１４に戻って処理が繰り返される。
【００７８】
なお、上記したステップＳ２１における現象発生頻度（現象再現率）は、例えばステップＳ１２において設定された実行回数のうち、現象（タイミング依存の不具合）が発生した回数または当該現象が発生した時間等に基づいて算出される。現象発生頻度は、例えば現象発生の平均時間等により算出することが考えられる。具体的には、現象発生頻度は、１−（不具合が発生するまでの時間の合計）／（プログラムの実行所要時間×実行回数）により算出される。つまり、現象発生頻度は、不具合が発生するまでの時間の合計が小さい（平均的に早く不具合が発生する）ほど、大きい値となる。また、現象発生頻度の算出は、これに限られず、種々の方法が考えられる。
【００７９】
ここで、前述したスレッド制御ポリシーの詳細について説明する。本実施形態に係るスレッド制御ポリシーは、例えば不具合発生プログラム１２を構成する複数のスレッドを所定の（予め定められた）順序で実行させるスケジュール方法を表す。この場合、スレッド制御用スレッド１４１は、スレッド制御ポリシーに応じて、スレッド管理テーブル１４２に登録されているスレッドの優先度を所定の順序で繰り返し変更（上下）することで複数のスレッドを所定の順序で実行させる。なお、複数のスレッドが実行される所定の順序を複数種類用意することで、複数のスレッド制御ポリシーが設定される。
【００８０】
次に、図８を参照して、上記したスレッド制御ポリシーに応じたスレッド制御用スレッド１４１による処理（図６に示す処理）について具体的に説明する。
【００８１】
ここでは、不具合発生プログラム１２を構成する複数のスレッドには、スレッドＡ、Ｂ及びＣが含まれるものとして説明する。
【００８２】
更に、図８に示すように、不具合発生プログラム１２を構成するスレッドＡ、Ｂ及びＣの本来のスレッド優先度は、それぞれ１０、５及び３であるものとする。なお、スレッド優先度は、例えば１〜１０までの１０段階であるものとして説明する。
【００８３】
まず、スレッド制御用スレッド１４１は、実行結果統計情報記録ＤＢ１３から上記したようなスレッド制御ポリシーをロードする。
【００８４】
このスレッド制御ポリシーにおいては、例えば不具合発生プログラム１２を構成する複数のスレッド（スレッドＡ、Ｂ及びＣ）を予め定められた順序（例えばスレッドＡ→Ｂ→Ｃの順）で実行させる旨（スケジュール方法）が定められているものとする。なお、スレッド制御ポリシーにおいて定められている順序を実行順序と表記する。
【００８５】
スレッド制御用スレッド１４１は、不具合発生プログラム１２を構成するスレッドＡ、Ｂ及びＣ（を識別するためのスレッドＩＤ）をスレッド管理テーブル１４２に登録する。このとき、スレッド制御用スレッド１４１は、スレッドＡ、Ｂ及びＣに対応付けて当該スレッドＡ、Ｂ及びＣの優先度（スレッド優先度）を例えば「５（中）」に設定する。また、スレッド制御用スレッド１４１のスレッド優先度は、上記したように当該スレッド制御用スレッド１４１が作成された際に、「１０（最高）」に設定されている（ステップＳ６１）。つまり、スレッド制御用スレッド１４１の処理が他のスレッドの処理に優先して行われる。
【００８６】
なお、不具合発生プログラム１２を構成する複数のスレッド（スレッドＡ、Ｂ及びＣ）のスレッド優先度は、スレッド制御用スレッド１４１のスレッド優先度より、例えば２段階以上低く設定される。
【００８７】
次に、スレッド制御用スレッド１４１は、ロードされたスレッド制御ポリシーにおいて定められている実行順序（ここでは、スレッドＡ→Ｂ→Ｃ）により、スレッドＡを実行させるために当該スレッドＡのスレッド優先度を変更する。この場合、スレッド制御用スレッド１４１は、スレッド管理テーブル１４２においてスレッドＡに対応付けられているスレッド優先度を例えば「７（高）」に変更する（ステップＳ６２）。これにより、スレッドＡは、他のスレッドＢ及びＣに対しては優先的に実行されることになる。
【００８８】
ここで、スレッド優先度が「１０」であるスレッド制御用スレッド１４１は、自身の処理を譲る。これにより、他のスレッド（スレッドＢ及びＣ）よりスレッド優先度が高いスレッドＡが実行される。スレッドＡが実行されると、スレッド優先度が最も高いスレッド制御用スレッド１４１に処理が戻される。
【００８９】
スレッド制御用スレッド１４１に処理が戻されると、スレッド制御用スレッド１４１は、スレッド管理テーブル１４２においてスレッドＡに対応付けられている当該スレッドＡのスレッド優先度を「５」に戻す（ステップＳ６３）。
【００９０】
次に、スレッド制御用スレッド１４１は、ロードされたスレッド制御ポリシーにおいて定められている実行順序により、不具合発生プログラム１２にスレッドＢを実行させるために当該スレッドＢのスレッド優先度を変更する。この場合、スレッド制御用スレッド１４１は、スレッド管理テーブル１４２においてスレッドＢに対応付けられているスレッド優先度を「７」に変更する（ステップＳ６４）。これにより、スレッドＢは、他のスレッドＡ及びＣに対しては優先的に実行される。
【００９１】
ここで、スレッド優先度が「１０」であるスレッド制御用スレッド１４１は、自身の処理を譲る。これにより、他のスレッド（スレッドＡ及びＣ）よりスレッド優先度が高いスレッドＢが実行される。スレッドＢが実行されると、スレッド優先度が最も高いスレッド制御用スレッド１４１に処理が戻される。
【００９２】
スレッド制御用スレッド１４１は、スレッド管理テーブル１４２においてスレッドＢに対応付けられている当該スレッドＢのスレッド優先度を「５」に戻す（ステップＳ６５）。
【００９３】
以下、同様にして、不具合発生プログラム１２を構成する複数のスレッド（スレッドＡ、Ｂ及びＣ）を、スレッド制御ポリシーにおいて定められている実行順序（スレッドＡ→Ｂ→Ｃ→Ａ→Ｂ→Ｃ→…）で実行させる。
【００９４】
上記したようにして実行された結果（統計情報）は、スレッド制御ポリシー毎に実行結果統計情報記録ＤＢ１３に記録される。
【００９５】
具体的には、例えば実行順序が「スレッドＡ→Ｂ→Ｃ→Ａ→…」、「スレッドＣ→Ｂ→Ａ→Ｃ→…」及び「ランダム」である３つのスレッド制御ポリシーが設定（登録）されている場合には、当該３つのスレッド制御ポリシーの各々に応じて不具合発生プログラム１２が実行され、その実行結果が統計情報として実行結果統計情報記録ＤＢ１３に記録される。
【００９６】
これにより、この３つのスレッド制御ポリシーのうち、例えば最も現象発生頻度（現象再現率）の高いスレッド制御ポリシーがユーザに対して提示されることになる。なお、現象発生頻度が最も高いスレッド制御ポリシーのみでなく、現象発生頻度が上位ｎ（ｎは２以上）のスレッド制御ポリシーがユーザに対して提示される構成であっても構わない。更に、現象発生頻度が予め定められた値（閾値）以上のスレッド制御ポリシーのみがユーザに対して提示される構成であっても構わない。
【００９７】
上記したように本実施形態においては、タイミング依存の不具合が発生した不具合発生プログラム（アプリケーション）１２を構成する複数のスレッドのスケジュール方法（実行順序）を表す複数のスレッド制御ポリシーに応じて複数のスレッドが実行されることによって、当該スレッド制御ポリシー毎に当該実行結果を統計情報として実行結果統計情報記録ＤＢ１３に記録することができる。これにより、本実施形態においては、例えば不具合発生プログラム１２及びＯＳ環境等を変更することなく、実行結果統計情報記録ＤＢ１３に記録されている統計情報に基づいて、例えば最もタイミング依存の不具合（現象）の発生頻度が高いスレッド制御ポリシー（複数のスレッドのスケジュール方法）を特定する（統計的に見出す）ことが可能となる。また、本実施形態においては、統計的に見出された現象発生頻度の高いスレッド制御ポリシーをユーザに対して提示することができる。したがって、例えば不具合発生プログラム１２において発生した不具合の原因が特定できていない場合であっても、ユーザは提示されたスレッド制御ポリシーに応じて不具合発生プログラム１２を動作させることで、現象の再現環境の用意に苦労することなく、容易に現象の再現率を向上させることができる。
【００９８】
なお、本実施形態においては、例えば複数のスレッド制御ポリシーが設定され、当該複数のスレッド制御ポリシーのうち、現象発生頻度が高い１つまたは複数のスレッド制御ポリシーがユーザに対して提示されるものとして説明したが、例えば１つのスレッド制御ポリシーが設定され、当該スレッド制御ポリシーの現象発生頻度が予め定められた値（閾値）以上であれば当該スレッド制御ポリシーがユーザに対して提示される構成であっても構わない。
【００９９】
［第２の実施形態］
次に、図９を参照して、本発明の第２の実施形態について説明する。図９は、本実施形態に係る情報処理装置１００の機能構成を示すブロック図である。なお、前述した図１及び図２と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図１及び図２と異なる部分について主に述べる。以下の各実施形態についても同様にして重複した説明を省略する。
【０１００】
また、本実施形態においては、調査プログラム１１及び実行結果統計情報記録ＤＢ１３は前述した第１の実施形態と同様である。このため、図９においては、調査プログラム１１及び実行結果統計情報記録ＤＢ１３は省略されている。
【０１０１】
本実施形態においては、情報処理装置１００が複数のプロセッサ（例えば、プロセッサ１６〜１９）を備えるマルチプロセッサ環境を想定している。
【０１０２】
本実施形態においては、不具合発生プログラム１２を構成する複数のスレッドを実行させるためのスレッド制御ポリシー及び当該スレッド制御ポリシーに応じて複数のスレッドが実行されるための制御を行うスレッド制御用ＤＬＬ２０の動作が、前述した第１の実施形態とは異なる。
【０１０３】
図９に示すように、本実施形態に係る情報処理装置１００上では、スレッド制御用ＤＬＬ２０が実行される。スレッド制御用ＤＬＬ２０は、スレッド制御用スレッド２０１、ビジーループスレッド２０２〜２０４、スレッド管理テーブル２０５及び世代管理テーブル２０６を含む。
【０１０４】
なお、図９に示すように、不具合発生プログラム１２は、スレッド１２１〜１２４を含む複数のスレッドから構成されるものとする。
【０１０５】
スレッド制御用スレッド２０１は、情報処理装置１００に備えられる複数のプロセッサのうち１つのプロセッサ（例えば、プロセッサ１６）に割り当てられる（固定割当て）。このとき、スレッド制御用スレッド２０１のスレッド優先度は、「最高」に設定される。
【０１０６】
スレッド制御用スレッド２０１は、ビジーループスレッド２０２〜２０４を作成する。このとき、スレッド制御用スレッド２０１に割り当てられたプロセッサ以外のプロセッサの数（ここでは、３）のビジーループスレッドが作成される。スレッド制御用スレッド２０１によって作成されたビジーループスレッド２０２〜２０４は、それぞれプロセッサ１７〜１９に割り当てられる（固定割当て）。なお、このビジーループスレッド２０２〜２０４のスレッド優先度は、「最高」に設定される。つまり、ビジーループスレッド２０２〜２０４は、常にプロセッサ（ＣＰＵ）を使用し続ける。
【０１０７】
スレッド管理テーブル２０５には、不具合発生プログラム１２を構成するスレッド１２１〜１２４を含む複数のスレッドの各々（を識別するためのスレッドＩＤ）、当該スレッドの優先度（スレッド優先度）及び当該スレッドが割り当てられるプロセッサ（を識別するためのプロセッサＩＤ）が対応付けて保持される。
【０１０８】
図１０は、図９に示すスレッド管理テーブル２０５のデータ構造の一例を示す。図１０に示すように、スレッド管理テーブル２０５には、スレッドＩＤ、優先度及びプロセッサＩＤが対応付けて保持される。
【０１０９】
図１０に示す例では、スレッド管理テーブル２０５には、スレッドＩＤ「０ｘＡＡＢＢＣＣＤＤ」、優先度「中」及びプロセッサＩＤ「１」が対応付けて保持されている。これによれば、スレッドＩＤ「０ｘＡＡＢＢＣＣＤＤ」によって識別されるスレッドは、優先度が「中」であり、プロセッサＩＤ「１」によって識別されるプロセッサに割り当てられている（つまり、当該プロセッサにより実行される）ことが示される。このスレッドＩＤ「０ｘＡＡＢＢＣＣＤＤ」は、例えばスレッド１２１を識別するためのスレッドＩＤである。これにより、スレッド１２１は、プロセッサＩＤ「１」によって識別されるプロセッサ（例えば、プロセッサ１６）に対応する。
【０１１０】
同様に、スレッド管理テーブル２０５には、スレッドＩＤ「０ｘ１１２２３３４４」、優先度「中」及びプロセッサＩＤ「２」が対応付けて保持されている。このスレッドＩＤ「０ｘ１１２２３３４４」は、例えばスレッド１２２を識別するためのスレッドＩＤである。
【０１１１】
スレッド管理テーブル２０５には、スレッドＩＤ「０ｘ５５６６７７８８」、優先度「中」及びプロセッサＩＤ「３」が対応付けて保持されている。このスレッドＩＤ「０ｘ５５６６７７８８」は、例えばスレッド１２３を識別するためのスレッドＩＤである。
【０１１２】
スレッド管理テーブル２０５には、スレッドＩＤ「０ｘ９９ＡＡＢＢＣＣ」、優先度「中」及びプロセッサＩＤ「４」が対応付けて保持されている。このスレッドＩＤ「０ｘ９９ＡＡＢＢＣＣ」は、例えばスレッド１２４を識別するためのスレッドＩＤである。
【０１１３】
また、スレッド管理テーブル２０５には、スレッドＩＤ「０ｘＤＤＥＥＦＦ００」、優先度「中」及びプロセッサＩＤ「−」が対応付けて保持されている。この場合、スレッドＩＤ「０ｘＤＤＥＥＦＦ００」によって識別されるスレッドには、まだプロセッサが割り当てられていないことが示される。このスレッドは、例えば現在プロセッサＩＤ「１」〜「４」によって識別される各プロセッサに割り当てられている各スレッド（スレッド１２１〜１２４）が当該プロセッサによって実行された後に、いずれかのプロセッサに割り当てられることになる。
【０１１４】
上記したプロセッサＩＤ「１」、プロセッサＩＤ「２」、プロセッサＩＤ「３」及びプロセッサＩＤ「４」は、例えばそれぞれプロセッサ１６〜１９を識別するためのプロセッサＩＤであるものとする。
【０１１５】
また、世代管理テーブル２０６には、プロセッサを識別するためのプロセッサＩＤ、各プロセッサが共通で使用する世代番号（current）及び各プロセッサ（スレッド制御用スレッド２０１が割り当てられているプロセッサ１６以外のプロセッサ）に対応する世代番号（each）が対応付けて保持される。ここでは、各プロセッサが各スレッドの処理を１度実行することを１世代とする。
【０１１６】
図１１は、図９に示す世代管理テーブル２０６のデータ構造の一例を示す。図９に示す例では、世代管理テーブル２０６には、各プロセッサが共通で使用する世代番号（current）として「１１０」が保持されている。また、世代管理テーブル２０６には、プロセッサＩＤ「１」及び世代番号（each）「−」が対応付けて保持されている。上記したようにプロセッサＩＤ「１」はスレッド制御用スレッド２０１が割り当てられているプロセッサ１６を識別するためのプロセッサＩＤであるため、世代管理テーブル２０６には、プロセッサＩＤ「１」に対応付けて世代番号（each）は保持されない。
【０１１７】
また、世代管理テーブル２０６には、プロセッサＩＤ「２」及び世代番号（each）「１０９」が対応付けて保持されている。世代管理テーブル２０６には、プロセッサＩＤ「３」及び世代番号（each）「１１０」が対応付けて保持されている。世代管理テーブル２０６には、プロセッサＩＤ「４」及び世代番号（each）「１０９」が対応付けて保持されている。
【０１１８】
このように、世代番号（current）は各プロセッサに共通であり、世代番号（each）は各プロセッサについて保持される。
【０１１９】
なお、世代番号（current）のライト（write）権限は、スレッド制御用スレッド２０１のみが有する。一方、世代番号（each）のライト（write）権限は、当該世代番号（each）に対応付けられているプロセッサＩＤによって識別される各プロセッサに固定割当てされたビジーループスレッド２０２〜２０４のみが有する。
【０１２０】
世代管理テーブル２０６に保持される世代番号（current）及び世代番号（each）は、例えばスレッド制御用ＤＬＬ２０が不具合発生アプリケーション１２によってロードされた際に初期化される。初期化された場合、世代管理テーブル２０６には、世代番号（current）及び世代番号（each）として同一の値が保持（登録）される。
【０１２１】
以下、スレッド制御用スレッド２０１及びビジーループスレッド２０２〜２０４の各々の動作について説明する。
【０１２２】
スレッド制御用スレッド２０１は、スレッド管理テーブル２０５に登録されているスレッドのうち、各プロセッサ１６〜１９に１つずつスレッドを割り当てる。スレッド制御用スレッド２０１は、スレッド管理テーブル２０５に登録されているスレッド（スレッドＩＤ）に対応付けて当該スレッドに割り当てるプロセッサ（プロセッサＩＤ）を登録する。
【０１２３】
次に、スレッド制御用スレッド２０１は、スレッド管理テーブル２０５に登録されている各プロセッサ１６〜１９に割り当てられたスレッドの優先度（スレッド優先度）を「高」に設定する。つまり、スレッド制御用スレッド２０１は、スレッド管理テーブルに登録されているスレッドの優先度をプロセッサ数（ここでは、４）と同じ数だけ「高」に設定する。
【０１２４】
スレッド制御用スレッド２０１は、世代管理テーブル２０６に登録されている世代番号（current）の値を１つインクリメントし、自身の処理を譲る。これにより、スレッド制御用スレッド２０１が割り当てられているプロセッサ１６においては、当該プロセッサ１６に割り当てられたスレッド優先度が「高」であるスレッド（例えば、スレッド１２１）が実行される。プロセッサ１６によってスレッド優先度が「高」に設定されたスレッドが実行されると、スレッド優先度が「最高」であるスレッド制御用スレッド２０１に処理が戻される。このスレッド優先度が「高」に設定されたスレッドの処理は、スレッド制御用ＤＬＬ２０（スレッド制御用スレッド２０１）に割り込まれるまで実行される。
【０１２５】
一方、ビジーループスレッド２０２〜２０４は、世代管理テーブル２０６を随時参照する。ここで、ビジーループスレッド２０２〜２０４の各動作については、同一であるので、以下、ビジーループスレッド２０２の動作について主に説明する。
【０１２６】
ビジーループスレッド２０２は、世代管理テーブル２０６に登録されている世代番号（current）及び当該ビジーループスレッド２０２が割り当てられているプロセッサ１７のプロセッサＩＤ（ここでは、プロセッサＩＤ「２」）に対応付けられている世代番号（each）の値が同一であるか否かを判定する。同一である場合には、ビジーループスレッド２０２は、世代管理テーブル２０６の参照を繰り返す。
【０１２７】
一方、同一でない場合には、ビジーループスレッド２０２は、自身の処理を譲る。このとき、世代番号（current）及び世代番号（each）の大小関係は、世代番号（current）＞世代番号（each）となる。これにより、上記したスレッド制御用スレッド２０１によってスレッド優先度が「高」に設定されたスレッドであって、ビジーループスレッド２０２が割り当てられたプロセッサ１７に割り当てられているスレッドが、当該プロセッサ１７によって実行される。プロセッサ１７によってスレッド優先度が「高」に設定されたスレッドが実行されると、スレッド優先度が「最高」であるビジーループスレッド２０２に処理が戻される。
【０１２８】
処理が戻されると、ビジーループスレッド２０２は、当該ビジーループスレッド２０２が割り当てられているプロセッサ１７を識別するためのプロセッサＩＤ「２」に対応付けて世代管理テーブル２０６に登録されている世代番号（each）の値を１つインクリメントして、上記した世代管理テーブル２０６の参照を繰り返す。
【０１２９】
ビジーループスレッド２０２以外のビジーループスレッド２０３及び２０４においても、当該上記したビジーループスレッド２０２と同様の処理が実行される。
【０１３０】
また、スレッド制御用スレッド２０１は、処理が戻された後、上記したようにして各ビジーループスレッド２０２〜２０４によって世代管理テーブル２０６に登録されている世代番号（each）の値が更新されていることを確認し、「高」に設定されたスレッド優先度を「中」に戻す処理を行う。スレッド制御用スレッド２０１は、上記した処理を繰り返す。
【０１３１】
本実施形態においては、マルチプロセッサ環境において４つのプロセッサ（ＣＰＵ）の各々が、それぞれスレッド（例えば、スレッド１２１〜１２４）を同時に実行する。つまり、本実施形態におけるスレッド制御ポリシーは、複数のプロセッサ（例えば、プロセッサ１６〜１９）に複数のスレッド（例えば、スレッド１２１〜１２４）の各々を同時に実行させるスケジュール方法を表す。
【０１３２】
なお、本実施形態においては、不具合発生プログラム１２を構成する複数のスレッドのスケジュール方法（つまり、スレッド制御ポリシー）が異なるだけで、その他の点については前述した第１の実施形態と同様である。つまり、上記したように実行された結果は実行結果統計情報記録ＤＢ１３に記録される。
【０１３３】
上記したように本実施形態においては、マルチプロセッサ環境でスレッドの同時実行の確率が高まるスレッド制御ポリシーを適用して不具合発生プログラム１２を動作させ、当該実行結果を統計情報として実行結果統計情報記録ＤＢ１３に記録することができる。これにより、例えば実行結果統計情報記録ＤＢ１３に記録されている統計情報に基づいて算出された現象発生頻度が予め定められた値（閾値）以上である場合には、上記したマルチプロセッサ環境でスレッドの同時実行の確率が高まるスレッド制御ポリシーを現象発生頻度の高いスレッド制御ポリシーとして見出すことが可能となり、当該スレッド制御ポリシーをユーザに対して提示することができる。
【０１３４】
また、本実施形態においては、前述した第１の実施形態におけるスレッド制御ポリシーと、本実施形態に係るマルチプロセッサ環境でスレッドの同時実行の確率が高まるスレッド制御ポリシーとを組み合わせる（追加する）ことにより、当該複数のスレッド制御ポリシーのうち現象発生頻度が高いスレッド制御ポリシーを特定し、ユーザに対して提示することができる。したがって、前述した第１の実施形態と比較して、より現象発生頻度の高いスレッド制御ポリシーを見出し、ユーザに対して提示することができる。
【０１３５】
［第３の実施形態］
次に、図１２を参照して、本発明の第３の実施形態について説明する。図１２は、本実施形態に係る情報処理装置１１０の機能構成を示すブロック図である。なお、本実施形態においては、調査プログラム１１及び実行結果統計情報記録ＤＢ１３は前述した第１の実施形態と同様である。このため、図１２においては、調査プログラム１１及び実行結果統計情報記録ＤＢ１３は省略されている。
【０１３６】
前述した第１の実施形態においては、不具合発生プログラム１３を構成する複数のスレッドを予め定められた順序で実行させるというスレッド制御ポリシーに応じて当該不具合発生プログラム１３を動作させたが、本実施形態においては、当該複数のスレッド毎に当該スレッドが実行される（スレッドの処理が割り当てられる）頻度（処理割当頻度）が予め設定されたスレッド制御ポリシーに応じて当該不具合発生プログラム１３を動作させる点が、前述した第１の実施形態とは異なる。なお、この処理割当頻度には、例えば「高」、「中」及び「低」の３段階が含まれる。
【０１３７】
ところで、一般的に、各アプリケーション（プログラム）の実行においては、当該アプリケーションを構成する各スレッドを識別するためのスレッドＩＤが同じである保証はない。そこで、各スレッドについて、当該スレッドのメインルーチンとする関数のアドレス（関数アドレス）及びアプリケーション開始以来、当該関数をメインルーチンとする何番目のスレッドであるか（連番）の両方を記録する。この関数アドレス及び連番から定まるスレッドは、各アプリケーション実行において、同一である可能性が高い。なお、例えばスレッド生成後にスレッドの役目が任意に決められる過程があるようなアプリケーションの場合には同一でない。
【０１３８】
本実施形態においては、この性質を利用することで、上記した特定のスレッドの処理割当頻度を高めるスレッド制御ポリシーが設定される。
【０１３９】
図１２に示すように、本実施形態に係る情報処理装置１１０上では、スレッド制御用ＤＬＬ２１が実行される。スレッド制御用ＤＬＬ２１は、スレッド管理テーブル２１１及びスレッド制御用スレッド２１２を含む。本実施形態では、スレッド制御用ＤＬＬ２１を、スレッド生成関数を含むＤＬＬ（例えば、kernel32.dll）の互換ライブラリとして用意する。不具合発生プログラム１２の実行時には、スレッド生成関数１５１を含むＤＬＬとスレッド制御用ＤＬＬ２１とが置き換えて実行される。
【０１４０】
不具合発生プログラム１２が実行されると、当該不具合発生プログラム１２は前述した他のＤＬＬ１５のスレッド生成関数（例えば、Create Thread()等）１５１を呼び出す。スレッド生成関数１５１は、不具合発生プログラム１２を構成するスレッドを生成するために用いられる関数である。不具合発生プログラム１２は、スレッド生成関数１５１を呼び出すことにより、当該不具合発生プログラム１２を構成するスレッドを生成する。
【０１４１】
このとき、不具合発生プログラム１２は、生成されたスレッドのスレッドＩＤ、当該スレッドのメインルーチンとする関数のアドレス（関数アドレス）及び連番を１組としてスレッド管理テーブル２１１に登録する。この登録処理は、上記したスレッド生成関数１５１が呼び出されるタイミングで行われる。
【０１４２】
ここで、図１３は、図１２に示すスレッド管理テーブル２１１のデータ構造の一例を示す。図１３に示すように、スレッド管理テーブル２１１には、スレッドを識別するためのスレッドＩＤ、当該スレッドのメインルーチンとする関数のアドレス（関数アドレス）、連番、当該スレッドの優先度（スレッド優先度）及び予め定められた当該スレッドの処理割当頻度が対応付けて保持される。この連番は、各関数アドレス毎につけられる。
【０１４３】
図１３に示す例では、スレッド管理テーブル２１１には、スレッドＩＤ「０ｘＡＡＢＢＣＣＤＤ」、関数アドレス「０ｘ１２３４５６７８」、連番「１」、優先度「中」及び処理割当頻度「低」が対応付けて保持されている。
【０１４４】
また、スレッド管理テーブル２１１には、スレッドＩＤ「０ｘ１１２２３３４４」、関数アドレス「０ｘ１２３４５６００」、連番「１」、優先度「中」及び処理割当頻度「高」が対応付けて保持されている。スレッド管理テーブル２１１には、スレッドＩＤ「０ｘ５５６６７７８８」、関数アドレス「０ｘ１１１１１１１１」、連番「１」、優先度「中」及び処理割当頻度「高」が対応付けて保持されている。スレッド管理テーブル２１１には、スレッドＩＤ「０ｘ９９ＡＡＢＢＣＣ」、関数アドレス「０ｘ１１１１１１１１」、連番「２」、優先度「中」及び処理割当頻度「中」が対応付けて保持されている。スレッド管理テーブル２１１には、スレッドＩＤ「０ｘＤＤＥＥＦＦ００」、関数アドレス「０ｘ２２２２２２２２」、連番「１」、優先度「中」及び処理割当頻度「低」が対応付けて保持されている。
【０１４５】
なお、上記したスレッド管理テーブル２１１に対するスレッドＩＤ、関数アドレス及び連番の登録処理が実行されると、本来の例えばkernel32.dllの処理が実行される。また、他の関数１５２については、本来のkernel32.dllの処理が実行される。
【０１４６】
スレッド制御用スレッド２１２は、スレッド管理テーブル２１１に登録されている関数アドレス及び連番で特定される各スレッドに対応付けられている処理割当頻度をスレッド制御ポリシーの一部としてロードする。
【０１４７】
スレッド制御用スレッド２１２は、ロードされたスレッド制御ポリシーに応じて、スレッド管理テーブル２１１に登録されているスレッドを実行させるための制御を行う。スレッド制御用スレッド２１２は、前述した第１の実施形態と同様に、スレッド管理テーブル２１１に登録されているスレッドの優先度（スレッド優先度）を変更することにより複数のスレッドの各々をスレッド制御ポリシーに応じて実行させる。
【０１４８】
このとき、スレッド制御用スレッド２１２は、処理割当頻度が「高」のスレッドの優先度は高い頻度で変更し（つまり、高い頻度で実行させる）、一方、処理割当頻度が「低」のスレッドの優先度は低い頻度で変更する（つまり、低い頻度で実行させる）。スレッド制御用スレッド２１２は、例えば処理割当頻度「高」：「中」：「低」に応じて優先度の変更（上げ下げ）の頻度が３：２：１となるように制御する。
【０１４９】
なお、本実施形態においては、スレッド制御ポリシーは、スレッド管理テーブル２１１に登録されたスレッド数（例えば、５つ）と処理割当頻度（例えば、３段階）の組合せ分だけバリエーションがある。この場合、この組合せの１つ１つが異なるスレッド制御ポリシーとして扱われる。つまり、本実施形態においては、この組合せの全てについて不具合発生プログラム１２を実行させることによって、最も高頻度で現象を再現可能な組合せ（スレッド制御ポリシー）を見出すことができる。
【０１５０】
上記したように本実施形態においては、例えば不具合発生プログラム１２において発生した不具合が、特定のスレッド同士の処理タイミングで発生するものである場合に、当該特定のスレッドのみが交互に高頻度で処理される状況を当該不具合発生プログラム１２において作り出すことができるため、現象発生頻度の高いスレッド制御ポリシーを見出すことができる可能性を向上させることが可能となる。
【０１５１】
［第４の実施形態］
次に、図１４を参照して、本発明の第４の実施形態について説明する。図１４は、本実施形態に係る情報処理装置１２０の機能構成を示すブロック図である。なお、前述した図１２と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図１２と異なる部分について主に述べる。
【０１５２】
また、本実施形態においては、調査プログラム１１及び実行結果統計情報記録ＤＢ１３は前述した第１の実施形態と同様である。このため、図１４においては、調査プログラム１１及び実行結果統計情報記録ＤＢ１３は省略されている。
【０１５３】
本実施形態においては、例えば情報処理装置１２０上でスローダウンが発生した場合等にはスリープ関数（例えば、Sleep()等）が想定よりも長く実行される、または、相対的に他の処理（他のスレッドによる処理）が終了する前にスリープが完了してしまうという現象が起きる場合を想定している。このスリープは、例えば不具合発生プログラム１２を構成するスレッドが各処理間でタイミングを計るために行われる。
【０１５４】
よって、本実施形態においては、不具合発生プログラム１２において発生した不具合が、このような現象に起因するものであった場合の現象発生頻度を向上させるため、複数のスレッドの待機時間に一定の割合をかけた値（時間）を待機時間として変更し、本来のスリープ関数を呼び出す処理が行われる。ここで、待機とはスレッドがスリープ関数を呼び出すことであり、その引数として「待機時間」が指定される。
【０１５５】
つまり、本実施形態においては、不具合発生プログラム１２を構成する複数のスレッドの待機時間を変動させるスレッド制御ポリシーを用いて当該複数のスレッドが実行される点が、前述した第１の実施形態と異なる。
【０１５６】
図１４に示すように、本実施形態に係る情報処理装置１２０上では、スレッド制御用ＤＬＬ２２が実行される。スレッド制御用ＤＬＬ２２は、Sleep補正率管理部２２１及びスレッド制御用スレッド２２２を含む。
【０１５７】
Sleep補正率管理部２２１は、上記した待機時間に乗ずる値（以下、Sleep補正率と表記）を管理する。このSleep補正率は、予め定められており、例えば１２０％である。また、異なる割合のSleep補正率が複数設定されていても構わない。
【０１５８】
スレッド制御用スレッド２２２は、Sleep補正率管理部２２１において管理されているSleep補正率をスレッド制御ポリシーの一部としてロードする。
【０１５９】
不具合発生プログラム１２は、例えばスリープ関数１５３を呼び出す際に、スレッド制御用スレッド２２２によってロードされたSleep補正率（スレッド制御ポリシー）を本来の待機時間に乗ずる。このSleep補正率をかけた待機時間に基づいて、不具合発生プログラム１２を構成する複数のスレッドが実行される。
【０１６０】
上記したように本実施形態においては、スレッド制御ポリシーにおいて予め定められたSleep補正率を本来の待機時間に乗ずることにより、例えば不具合発生プログラム１２において発生した不具合がスリープ関数１５３に依存した処理タイミングで発生するものである場合に、同様の状況を当該不具合発生プログラム１２において作りだすことができるため、現象発生頻度の高いスレッド制御ポリシーを見出すことができる可能性を向上させることが可能となる。
【０１６１】
なお、本願発明は、上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記各実施形態に開示されている複数の構成要素の適宜な組合せにより種々の発明を形成できる。例えば、各実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組合せてもよい。
【図面の簡単な説明】
【０１６２】
【図１】本発明の第１の実施形態に係る情報処理装置の機能構成を示すブロック図。
【図２】図１に示す情報処理装置１０における処理の流れについて説明するための図。
【図３】スレッド制御用ＤＬＬ１４に含まれるスレッド管理テーブル１４２のデータ構造の一例を示す図。
【図４】調査プログラム１１の処理手順を示すフローチャート。
【図５】調査プログラム１１によって作成された新規スレッドの処理手順を示すフローチャート。
【図６】新規スレッドによって作成されたスレッド制御用スレッド１４１の処理手順を示すフローチャート。
【図７】不具合発生プログラム１２内で新たにスレッドが作成された際の当該スレッドの処理手順を示すフローチャート。
【図８】スレッド制御ポリシーに応じたスレッド制御用スレッド１４１による処理について具体的に説明するための図。
【図９】本発明の第２の実施形態に係る情報処理装置１００の機能構成を示すブロック図。
【図１０】図９に示すスレッド管理テーブル２０５のデータ構造の一例を示す図。
【図１１】図９に示す世代管理テーブル２０６のデータ構造の一例を示す図。
【図１２】本発明の第３の実施形態に係る情報処理装置１１０の機能構成を示すブロック図。
【図１３】図１２に示すスレッド管理テーブル２１１のデータ構造の一例を示す図。
【図１４】本発明の第４の実施形態に係る情報処理装置１２０の機能構成を示すブロック図。
【符号の説明】
【０１６３】
１０，１００，１１０，１２０…情報処理装置、１１…調査プログラム、１２…不具合発生プログラム（アプリケーション）、１３…実行結果統計情報記録データベース（ＤＢ）、１４，２０，２１，２２…スレッド制御用ＤＬＬ、１６，１７，１８，１９…プロセッサ、１４１，２０１，２１２，２２２…スレッド制御用スレッド、１４２，２０５，２１１…スレッド管理テーブル（管理手段）、２０２，２０３，２０４…ビジーループスレッド、２０６…世代管理テーブル、２２１…Sleep補正率管理部。
【図１】
2010003153.tif 000003
【図２】
2010003153.tif 000004
【図３】
2010003153.tif 000005
【図４】
2010003153.tif 000006
【図５】
2010003153.tif 000007
【図６】
2010003153.tif 000008
【図７】
2010003153.tif 000009
【図８】
2010003153.tif 000010
【図９】
2010003153.tif 000011
【図１０】
2010003153.tif 000012
【図１１】
2010003153.tif 000013
【図１２】
2010003153.tif 000014
【図１３】
2010003153.tif 000015
【図１４】
2010003153.tif 000016