JP4476193B2 - 情報処理方法および情報処理装置 - Google Patents

Description

本発明は、情報処理技術に関し、特に複数のスレッドを並列処理する情報処理方法、およびそれを利用した情報処理装置に関する。

近年、情報処理装置の分野では、アプリケーションソフトウェアに対応するタスクをスレッドと呼ばれる複数の実行単位に分割し、それらをプロセッサのタイムスライスに割り当て、順番に処理することによって複数の処理を並行して行う、マルチスレッドシステムの技術が提供されている。スレッドはタスクと比較するとその管理情報の量が小さいため、切り替えに要する処理が少なく、オーバーヘッドを軽減することができる。

マルチスレッドシステムにおいて、複数のスレッドは、情報処理装置の基本的な制御を行うＯＳ（Operation System）によって各タイムスライスに対してスケジューリングされ、それに基づいてプロセッサが処理を行う。あるスレッドに割り当てられたタイムスライスが満了したときは、ＯＳはそれまでのスレッド処理に用いてきたレジスタ類の内容を一旦メインメモリに退避して、そのスレッドを待機状態とし、プロセッサが次にスケジューリングされたスレッドの処理を開始する。

一方、アプリケーションソフトウェアを製品化するためには、ソフトウェアの不具合を検出しプログラムを修正するデバッグ作業が不可欠である。不具合の検出からプログラムの適正な修正に至るためには、アプリケーションソフトウェアを実際の実行環境で動作させて不具合を発生させ、各スレッドが関与しているメモリ、レジスタ、スタックなどの内容を逐一確認し、演算結果たる変数などに問題が発生するタイミングを取得し、それに対応するプログラムの箇所を抽出する必要がある。

デバッグ作業は上述のとおり、実際の実行環境でリアルタイムに変数などを観察することが望ましいため、例えばプログラムのある単位ごとに処理を停止させ変数を確認したり、あるブレークポイントを設けてそのポイントまで進捗した時点で処理を停止し、変数を確認したりする。しかし、上述のようなマルチスレッドシステムでは、ＯＳによる制御のもと、複数のスレッドが処理順やレジスタ、メモリの使用などについて相互干渉しながら、処理が進捗するため、ひとつのスレッドのみを停止させ、変数などを確認するようにすると、実際の実行環境とは異なってしまい、デバッグ作業の求めるリアルタイムな確認が困難な場合があることを本発明者は認識した。

本発明はこのような課題に鑑みてなされたものであり、その目的はマルチスレッドシステムにおいて、実際の実行環境に即したデバッグを行うことのできる技術を提供することにある。

本発明のある態様は情報処理方法に関する。この方法は、確認対象スレッドに係る内部情報の確認要求信号を受け付けるステップと、確認要求信号の入力があった旨のフラグ情報を各スレッドの状態情報を記録するテーブルに、確認対象スレッドに対応させて書き込むステップと、確認要求信号に応じて内部情報を出力するステップと、を含み、スレッドの処理開始前にテーブルを参照し、確認要求信号の入力があった旨のフラグ情報を検出した際、当該スレッドの処理に所定の制限を設けることを特徴とする。

「スレッド」とは、ある目的を達成するためにプログラムされたアプリケーションまたはそれに含まれる情報処理の内容をいい、アプリケーションと対応してもよいし、入出力制御やユーザが指定したコマンドなどアプリケーションよりも小さい単位と対応してもよく、何らかの処理または機能の単位に対応すればよい。また「内部情報」とは、スレッドの処理途上で発生した変数や、複数のスレッドの処理順、情報処理装置に接続された入出力装置に対するアクセス待ち順、スレッドの状態など、情報処理装置における処理の状態を表す情報のいずれでもよい。

本発明の別の態様も情報処理方法に関する。この方法は、確認対象スレッドに係る内部情報の確認要求信号を受け付けるステップと、前記確認対象スレッドのプロセッサによる処理開始への状態移行を監視するステップと、処理開始への状態移行が検出されない確認対象スレッドに係る内部情報を出力するステップと、処理開始への状態移行が検出された確認対象スレッドを停止状態とするステップと、を含むことを特徴とする。

本発明のさらに別の態様は情報処理装置に関する。この装置は、複数のスレッドをプロセッサにより処理する情報処理装置であり、各スレッドの状態情報テーブルを格納する記憶部と、ユーザによる確認対象スレッドに係る内部情報の確認要求信号の入力を受け付ける要求受信部と、確認要求信号の入力があった旨のフラグ情報を確認対象スレッドに対応させて状態情報テーブルに書き込む情報更新部と、スレッドの処理開始前に状態情報テーブルを参照し、フラグ情報に基づき当該スレッドの処理開始の是非を決定する処理許可部と、確認要求信号に応じて内部情報を出力する状況出力部と、を含むことを特徴とする。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、所望のスレッドに係る内部情報を効率よく確認することができる。

図１は、本実施の形態に係る情報処理装置１０００の構成を示すブロック図である。情報処理装置１０００は、プロセッサ１００、メインメモリ２００、入出力ユニット３００を含み、それらがバス５０によって接続されている。入出力ユニット３００は、二次記憶装置４００、表示装置５００、キーボードなどの入力装置６００と接続されている。図１などにおいて、様々な処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、ＣＰＵ、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、メモリにロードされた予約管理機能のあるプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。

この情報処理装置１０００では、情報処理装置１０００を効率よく使用するための機能、環境を提供し、装置全体を統括的に制御するＯＳが実行される。そのＯＳ上で複数のアプリケーションソフトウェア（以下、単にアプリケーションという）が実行される。

プロセッサ１００は、情報処理装置１０００が実行するアプリケーションより生成された複数のスレッドの処理を、処理時間や優先度などに基づきＯＳが生成したスケジュールに基づいて行う。処理が行われるスレッドは、プロセッサ１００内にあるレジスタ１０を一時記憶領域として用い、演算結果などを一時的に格納する。

メインメモリ２００は、ＤＲＡＭ(Dynamic Random Access Memory)などで構成され、実行されるアプリケーションに対応するマシンコードプログラムやデータを格納する記憶領域である。またメインメモリ２００は、プロセッサ１００によって処理が行われるスレッドが使用するスタックを格納したり、待機状態にあるスレッドが処理されていたときに使用していたレジスタ１０の内容を一時的に退避したりするのに用いられる。

入出力ユニット３００はハードディスク、ＣＤ−ＲＯＭなどの二次記憶装置４００や表示装置５００などの装置に対するデータの出力を、プロセッサ１００の制御のもとで行う。また、二次記憶装置４００や入力装置６００からのデータや信号の入力を受け付け、プロセッサ１００やメインメモリ２００へ渡す。

つぎに、以上のように構成された情報処理装置１０００において、生成された複数のスレッドが処理される手順について説明する。

図２はスレッドの状態遷移を模式的に示している。「処理状態」はスレッドが実際にプロセッサ１００によって処理されている状態である。一方、「準備状態」は処理が可能で、「処理状態」への遷移の順番待ちをしている状態である。さらに「待機状態」は、メインメモリ２００へのアクセス権取得のための順番待ちの状態など、プロセッサ１００による処理の順番待ち以外の待ち状態である。「停止状態」は、何らかの原因によってスレッドが処理のループから抜け、停止している状態である。スレッドがどの状態にあるかは、メインメモリ２００に格納された管理情報テーブルに、各スレッドの識別情報と関連付けて記述されている。ＯＳは管理情報テーブルを参照することにより各スレッドの状態を判断し、さらに当該スレッドの優先度や処理時間などの情報に基づき適宜スレッドの状態遷移の制御を行う。

例えばＯＳは、処理時間や優先度などに基づき、「準備状態」にあるスレッドについて所定の方式でスケジューリングを行う。「処理状態」にあるスレッドが、割り当てられたタイムスライスを使い果たしたり、自発的に処理を中断したりして、プロセッサ１００を開放し、「処理状態」から「準備状態」または「待機状態」へと遷移すると（それぞれ遷移ｂ、遷移ｃ）、スケジューリングされた次に処理すべきスレッドが「準備状態」から「処理状態」へ遷移し（遷移ａ）、プロセッサ１００によって処理が行われる。

マルチスレッドシステムにおいては、同一プロセス内の複数のスレッドが共通のデータへアクセスすることが可能であるため、同時に同一のデータに対し読み書きが行われることによる不具合が発生しないように、ＯＳによって排他制御がなされる。そのため、あるスレッドによってロックされたユニットに他のスレッドがアクセスしようとした場合には、後者のスレッドはブロックされ、「待機状態」となる。具体的には、スレッドがメインメモリ２００や二次記憶装置４００、表示装置５００、入力装置６００などの入出力装置などプロセッサ１００以外のユニットへアクセスする際、他のスレッドによって当該ユニットがロックされている場合は、そのユニットが開放されるまで「待機状態」となる。このとき、さらに別のスレッドがそのユニットへのアクセスを必要とした場合は、「待機状態」の中に当該ユニットに対するアクセスの待ち行列が形成される。この機構は、マルチスレッドシステムに対応したＯＳによって提供されるミューテックスやセマフォなどの同期化機能によって実現される。

この他にも、他のスレッドや入出力装置からの応答信号待ちを行ったり、定期的なイベント発生によってスレッドを実行させる場合などにタイマによる期間の満了を待ったりする際に、スレッドは「待機状態」となる。同一ユニットへのアクセスと同様、同一の発信元からの応答信号を待って「待機状態」にある複数のスレッドは、信号待ち行列を形成することになる。

「待機状態」となったスレッドは、アクセスを所望するユニットが他のスレッドから開放されるなど、「待機状態」となった要因が解決された場合に、「準備状態」へと遷移し（遷移ｄ）、スケジューリングの対象となる。スレッドが待ち行列を形成していた場合は、行列の先頭スレッドからひとつずつ「準備状態」へと遷移することになる。

「処理状態」にあったスレッドが「待機状態」や「準備状態」に遷移する際は、コンテキストスイッチが行われ、スレッドの処理に使用していたレジスタ１０に格納された演算結果など、処理に係る情報（以降、コンテキストと呼ぶ）はメインメモリ２００に退避される。そして当該スレッドが再び「処理状態」となったときに、当該情報がメインメモリ２００から読み出されレジスタ１０など本来の記憶領域に格納されることにより、スレッドの再処理が可能となる。

ここで、あるスレッドを構成するソースコードのデバッグを行う場合を考える（以後、このスレッドを「確認対象スレッド」と呼ぶ）。従来のデバッグ手法においては、確認対象スレッドを「処理状態」、および「準備状態」からユーザの入力信号などにより強制的に「停止状態」へ遷移させることによって（それぞれ遷移ｆおよび遷移ｅ）、その確認対象スレッドが受け持つ変数など、コンテキストの内容を確認していた。これには一般的な割り込みの技術を適用する。すなわち割り込み信号によって、「処理状態」にあった確認対象スレッドの処理を停止させ、コンテキストをメインメモリ２００へ格納するなどして、「停止状態」へと遷移させる。その後、メインメモリ２００に格納されたソースコードやコンテキストを表示装置５００に表示させるなどの処理が行われ、ユーザによって不具合箇所の確認がなされる。ユーザの確認作業が終了すると、確認対象スレッドを「停止状態」から「処理状態」へと遷移させるとともに、保存されたコンテキストが復元され、処理が再開される。デバッグ手法にはこの他にも、ソースコード自体にブレークポイントを設けて、処理がそこまで進捗した時点で同様の処理にてスレッドを「停止状態」へと遷移させる場合などがある。

しかし、上述のような状態遷移のサイクルにある確認対象スレッドを「停止状態」とすることにより、実際の実行環境の保全が困難となる場合がある。例えば、「待機状態」にあって、あるユニットの開放を待つ行列中にあるスレッドのコンテキストを確認したい場合、当該スレッドを突然「停止状態」へと遷移させると、待ち行列の順番に変化が生じる。引き抜いた確認対象スレッドが「停止状態」にあるうちに、待ち行列の後続スレッドが、当該ユニットへのアクセス権を取得して「準備状態」または「処理状態」となってしまえば、確認対象スレッドを元の状態に戻すことができなくなる。同一プロセスに含まれる複数のスレッドは共通データへアクセスし、相互干渉しながら処理が進捗するため、待ち行列の順番の変化が他のスレッドの処理結果に影響を及ぼす場合がある。また待ち行列の順序が保存されないと、待ち行列自体の確認を行うことも困難になる。

「待機状態」や「準備状態」にあるスレッドは、上述のとおりコンテキストをメインメモリ２００へ退避しているため、スレッドを「停止状態」とせずに内容を確認することはできるが、確認作業中に待ちの原因が解決し、当該スレッドが「処理状態」へ遷移してしまうことが考えられる。このときコンテキストはレジスタ１０などへ復帰し、上書きされてしまうため、確認しているコンテキストはもはや古い情報となってしまう。さらにそのスレッドが再び「待機状態」や「準備状態」に遷移しようとすると、メインメモリ２００のコンテキスト退避領域へのアクセスが確認作業と競合してしまう。本発明者はこれらの問題を解決するため、以下に述べる実施の形態に想到した。

本実施の形態では、ユーザによって所定のスレッドにかかる情報確認の指示が発生した場合に、当該確認対象スレッドに対してストップフラグを立てる。さらにストップフラグの立っているスレッドが、「処理状態」にある場合、もしくは「処理状態」へ遷移しそうな場合に限り「停止状態」へと遷移させる（遷移ｆおよび遷移ｇ）。ここで、「準備状態」から「処理状態」への遷移途上（遷移ａ）にあるスレッドにストップフラグが立った場合は、当該スレッドが「処理状態」へと遷移した直後に上述の如く「停止状態」へと遷移させる（遷移ｆ）。「準備状態」や「待機状態」にあるスレッドにストップフラグが立った場合は、それらが「準備状態」から「処理状態」へと遷移するタイミングが到来した際に「停止状態」へと遷移させる（遷移ｇ）。

図３は本実施の形態において確認対象スレッドにかかる情報を表示する手順を示している。まずユーザはデバッガなどのソフトウェアを呼び出す。ソフトウェアは二次記憶装置４００に格納されているパッケージでもよいし、起動済みのＯＳのカーネルに含まれていてもよい。そして表示装置５００に表示されたスレッドリストから選択することによって、確認対象スレッドにかかる情報表示の指示を入力装置６００などに対して行う（Ｓ１０）。それに応じてＯＳは選択された確認対象スレッドに対してストップフラグを立てる（Ｓ１２）。ストップフラグは、カーネルがスレッドの状態などを把握し制御を行うためにメインメモリ２００に格納している管理情報テーブルを構成する構造体中の変数であり、通常の処理では「０」の値が代入されている。Ｓ１２ではこれに「１」を代入することによりフラグを立てる。管理情報テーブルの構造については後に述べる。

次にストップフラグを立てた確認対象スレッドが現在「処理状態」または「処理状態」への遷移途上であるかどうかを、管理情報テーブルに記録されたスレッド状態を参照して確認する（Ｓ１４）。ここで「遷移途上」とは、確認対象スレッドが「準備状態」の待ち行列中、プロセッサ１００によって次に処理される順番となった場合で、プロセッサ１００によって処理されている前のスレッドがプロセッサ１００を開放した時点から、当該確認対象スレッドの処理開始のために、コンテキストのレジスタ１０への復帰を完了させる前までの状態である。確認対象スレッドが「処理状態」または「処理状態」への遷移途上にあった場合は（Ｓ１４のＹ）、コンテキストをメインメモリ２００に退避させ、当該スレッドを「停止状態」に遷移させる（Ｓ１８）。このとき、スレッドが「処理状態」にあった場合は、プロセッサ１００による当該スレッドの処理を停止させて「停止状態」へと遷移させる。スレッドが「処理状態」への遷移途上にあった場合は、コンテキストのレジスタ１０への復帰完了を待ってから「停止状態」へと遷移させる。

確認対象スレッドが「処理状態」または「処理状態」への遷移途上にない場合は（Ｓ１４のＮ）、そのスレッドが「処理状態」への遷移を開始するかどうかを確認する（Ｓ１６）。「処理状態」への遷移を開始する場合は（Ｓ１６のＹ）、コンテキストをレジスタ１０へ復帰させることなく、当該スレッドを「停止状態」へと遷移させる（Ｓ１８）。Ｓ１６は実際には、「処理状態」にあったスレッドがプロセッサ１００を開放する都度、次に「処理状態」へ遷移すべくスケジューリングされたスレッドのストップフラグを確認し、ストップフラグが立っていたら上述のように「停止状態」へ遷移するように制御してよい。

確認対象スレッドを「停止状態」へ遷移させた（Ｓ１８）後、および、確認対象スレッドが「待機状態」や「準備状態」にある場合（Ｓ１６のＮ）は、メインメモリ２００に退避した当該スレッドのコンテキストなどの情報を入出力ユニット３００へ読み出し、表示装置５００へ表示する（Ｓ２０）。ユーザによって入力装置６００へ終了指示信号が入力された場合など、確認作業の終了をＯＳが認識するまでは（Ｓ２２のＮ）、確認対象スレッドが「処理状態」へ遷移するかどうかを監視しながら、情報の表示を続行する。確認作業の終了が認識できたら（Ｓ２２のＹ）、確認対象スレッドのストップフラグに「０」値を代入する（Ｓ２４）。確認対象スレッドが以前、「処理状態」にあったり「処理状態」へ遷移しそうになったりして、確認のために「停止状態」へ遷移させていた場合は（Ｓ２６のＹ）、スレッドを「停止状態」から復活させる（Ｓ２８）。復活には、例えば確認対象スレッドに高優先度を与えて「準備状態」の待ち行列に戻すことにより（図２の遷移ｈ）、次回のプロセッサ１００開放時に「処理状態」へと遷移させるようにする。確認対象スレッドが「停止状態」以外の状態、すなわち「待機状態」か「準備状態」にあった場合は（Ｓ２６のＮ）、待ち行列中にあっても順序を保存したままスレッドの情報を表示しているため、そのまま確認処理を終了する。

図４は、本実施の形態におけるスレッドの管理情報テーブルの構造例を示している。管理情報テーブル７００は、識別番号欄７０２、命令ポインタ欄７０４、汎用レジスタ値欄７０６、スタックポインタ欄７０８、スレッド状態欄７１０、ストップフラグ欄７１２を含む。各スレッドは、識別番号欄７０２に記載された識別番号に基づき管理される。命令ポインタ欄７０４、汎用レジスタ値欄７０６、スタックポインタ欄７０８には、各スレッドが実行するマシンコード命令を格納するレジスタ１０のアドレス値を示すポインタ、現在の汎用レジスタの値、およびスレッドに割り当てられるスタック領域の中のアドレス値を示すポインタがそれぞれ記録され、コンテキストスイッチの際などに参照される。スレッド状態欄７１０には、「準備状態」、「処理状態」など、当該スレッドの現在の状態が、それぞれを識別できる文字列などで記録され、例えば図３のＳ１４やＳ１６において、ストップフラグを立てたスレッドの状態を確認する際などに参照される。ストップフラグ欄７１２には、上述のごとく確認対象スレッドには「１」が、それ以外のスレッドには「０」が設定される。

なお、管理情報テーブル７００の内容は図４に示された項目に限らない。例えば汎用レジスタ値として整数レジスタと浮動小数点レジスタの値を記録したり、機能設定レジスタなど使用するレジスタの値を記録したりしてよい。また、スタックポインタとしてカーネルスタックとユーザスタックのそれぞれのポインタを記録してよい。さらに、ストップフラグ以外でスレッド管理に用いるフラグ、例えばスレッドの終了時に他のスレッドと待ち合わせをするかどうか、当該スレッドが割り込みスレッドが通常スレッドか、または当該スレッドがカーネルスレッドかユーザスレッドか、などを示すフラグが含まれていてよい。

本実施の形態によれば、確認対象スレッドが「待機状態」にあっても、当該スレッドを「停止状態」に遷移させることなくコンテキストなどの情報確認ができるため、待ち行列の順序を変化させることなく、実際の実行状況下にあるスレッドの情報を取得することができる。さらに確認が終了したら待ち行列にかかる処理を続行させることができるため、実行環境に影響を与えることなく、次の確認段階まで処理を継続させることができる。また、メインメモリ２００に退避されたコンテキストなどを表示しているうちに、確認対象スレッドが「処理状態」へ遷移してしまうことがないため、実際の状況と表示された情報とに矛盾が生じるなどの不具合なく、安全に確認作業を行うことができる。また、確認中は「待機状態」や「準備状態」における待ち行列の順序が保存されているため、複数のスレッドの待ち行列の順序に関する情報自体を表示することが可能となる。これにより、実際の実行環境により近い環境でのスレッドにかかる情報を確認することができ、不具合箇所をより確実に検出することができ、デバッグ作業の効率化が実現できる。

以上、本発明を実施の形態をもとに説明した。上記実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

例えば本発明を実現するソフトウェアは、情報処理装置１０００とネットワークで接続された図示しないサーバに格納されていてもよく、図示しないネットワークを介して処理を行うようにしてもよい。これにより、デバッグを行うソフトウェアを実装しない情報装置などにおいても、実機によるデバッグ作業が上述のとおり効率的に行える。

また、複数のスレッドを同時に確認対象スレッドとしてストップフラグを立ててもよい。例えば生成された全スレッドにストップフラグを立てることにより、「準備状態」から「処理状態」へと遷移しようとするスレッドは全て「停止状態」へと遷移させられるため、確認終了時に「停止状態」へ遷移した順序で「準備状態」の待ち行列の先頭に戻せば、「処理状態」で処理される順序も保存したまま確認作業をおこなうことができ、実際の実行環境に近い環境でのデバッグ作業が行える。

本実施の形態に係る情報処理装置の構成を示すブロック図である。 スレッドの状態遷移を模式的に示した図である。 本実施の形態において確認対象スレッドにかかる情報を表示する手順を示すフローチャートである。 本実施の形態におけるスレッドの管理情報テーブルの構造例を示した図である。

符号の説明

１０ レジスタ、 １００ プロセッサ、 ２００ メインメモリ、 ３００ 入出力ユニット、 ４００ 二次記憶装置、 ５００ 表示装置、 ６００ 入力装置、 ７００ 管理情報テーブル、 １０００ 情報処理装置。

Claims (11)

1. プログラムを所定の実行単位に分割してなるスレッドを処理するステップと、
   前記スレッドのうち、確認対象スレッドに係る内部情報の確認要求信号を受け付けるステップと、
   前記確認対象スレッドが、処理状態および処理状態への遷移途上以外の状態にあった場合、前記確認要求信号に起因した状態変化を与えずに前記確認対象スレッドの状態遷移を監視するステップと、
   前記確認対象スレッドが処理状態または処理状態への遷移途上にあった場合に、当該スレッドの処理に所定の制限を設けるステップと、
   前記確認要求信号に応じて前記内部情報を出力するステップと、を含むことを特徴とする情報処理方法。
2. 前記確認要求信号を受け付ける時点において、プロセッサによる処理待ち状態、入出力装置へのアクセス待ち状態にあるスレッドを、前記確認対象スレッドとして受け付けることを特徴とする請求項１に記載の情報処理方法。
3. 前記所定の制限は、前記スレッドの処理開始の不許可を含むことを特徴とする請求項１または２に記載の情報処理方法。
4. 前記内部情報は確認対象スレッドを含む複数のスレッドの処理待ち行列の順序に係る情報を含むことを特徴とする請求項１または２に記載の情報処理方法。
5. 前記内部情報は確認対象スレッドを含む複数のスレッドの入出力装置へのアクセス待ち行列の順序に係る情報を含むことを特徴とする請求項１または２に記載の情報処理方法。
6. 前記確認要求信号の入力があった際、前記確認対象スレッドが処理中であった場合には、前記確認対象スレッドに係るコンテキストをメインメモリに退避させて処理を中断するステップをさらに含むことを特徴とする請求項１から５のいずれかに記載の情報処理方法。
7. プログラムを実行単位に分割してなる複数のスレッドをプロセッサにより処理する情報処理装置において、
   前記スレッドのうち、確認対象スレッドに係る内部情報の確認要求信号の入力をユーザより受け付ける要求受信部と、
   前記確認対象スレッドが、処理状態および処理状態への遷移途上以外の状態にあった場合、前記確認要求信号に起因した状態変化を与えずに前記確認対象スレッドの状態遷移を監視し、前記確認対象スレッドが処理状態または処理状態への遷移途上にあった場合に、当該スレッドの処理に所定の制限を設ける処理許可部と、
   前記確認要求信号に応じて前記内部情報を出力する状況出力部と、
   を含むことを特徴とする情報処理装置。
8. 前記要求受信部は、プロセッサによる処理待ち状態、入出力装置へのアクセス待ち状態にあるスレッドを、前記確認対象スレッドとして受け付けることを特徴とする請求項７に記載の情報処理装置。
9. 前記所定の制限は、前記スレッドの処理開始の不許可を含むことを特徴とする請求項７または８に記載の情報処理装置。
10. プログラムを所定の実行単位に分割してなるスレッドを処理する機能と、
    前記スレッドのうち、確認対象スレッドに係る内部情報の確認要求信号を受け付ける機能と、
    前記確認対象スレッドが、処理状態および処理状態への遷移途上以外の状態にあった場合、前記確認要求信号に起因した状態変化を与えずに前記確認対象スレッドの状態遷移を監視する機能と、
    前記確認対象スレッドが処理状態または処理状態への遷移途上にあった場合に、当該スレッドの処理に所定の制限を設ける機能と、
    前記確認要求信号に応じて前記内部情報を出力する機能と、
    をコンピュータに実現させることを特徴とするコンピュータプログラム。
11. プログラムを所定の実行単位に分割してなるスレッドを処理する機能と、
    前記スレッドのうち、確認対象スレッドに係る内部情報の確認要求信号を受け付ける機能と、
    前記確認対象スレッドが、処理状態および処理状態への遷移途上以外の状態にあった場合、前記確認要求信号に起因した状態変化を与えずに前記確認対象スレッドの状態遷移を監視する機能と、
    前記確認対象スレッドが処理状態または処理状態への遷移途上にあった場合に、当該スレッドの処理に所定の制限を設ける機能と、
    前記確認要求信号に応じて前記内部情報を出力する機能と、
    をコンピュータに実現させることを特徴とするコンピュータプログラムを記憶した記憶媒体。

Images