JPWO2008114525A1 - 情報処理装置 - Google Patents

Abstract

本発明に係る情報処理装置に適用可能な携帯電話機においては、主制御部のＣＰＵは監視スレッド１乃至３を実行し、優先度が設けられた複数のスレッドからなるグループを、グループ内のスレッドの動作を監視するための複数の監視スレッドに対するキープアライブ動作によって監視し、複数の前記監視スレッドからの応答に基づいて、キープアライブ動作に対する応答がない前記監視スレッドが存在するか否かを判定し、キープアライブ動作に対する応答がない前記監視スレッドが存在すると判定された場合、キープアライブ動作に対する応答がない前記監視スレッドが監視するグループよりも優先度が高いグループへのイベントの配信を停止する。

Description

本発明は情報処理装置に係り、特に、複数のスレッドの処理を並行して行うマルチスレッド処理を実行することができるようにした情報処理装置に関する。

近年、情報処理装置としての携帯電話機には、単なる通話による通信機能だけでなく、アドレス帳機能、基地局やインターネットなどのネットワークを介したメール機能や、Ｗｅｂページなどを閲覧することが可能なブラウザ機能などの種々の機能が搭載されるようになってきている。

これに伴い、例えばパーソナルコンピュータだけでなく携帯電話機においても、ＯＳ（Operating System）にＴＳＳ（Time Sharing System）制御機能を搭載し、制御メモリ空間やＩ／Ｏ空間の資源などを共有しつつ、同一のプロセス内において複数のスレッドの処理を並行して行うマルチスレッド方式が提案されている（例えば特許文献１参照）。

特許文献１に提案されている技術によれば、ＯＳのＴＳＳスケジューラの実装に依存せずに、ＣＰＵを最大限に使用し、呼処理イベントの処理を実行することができる。
特開２００６−１８５３０３号公報

しかしながら、ラウンドロビン機能やＴＳＳ制御機能が搭載されていないＯＳ環境下では、発生したイベントを処理する場合、一般に、イベントドリブンに生成されたそれぞれのスレッドの優先度に従って処理するが、いくつかのスレッドによりＣＰＵの資源が占有されてしまうと、その他のスレッドの処理が実行されない状況が発生してしまう。

すなわち、優先度の高いスレッド間における処理が連続して行われると、優先度の高い複数のスレッドによりＣＰＵの資源が占有されてしまい、優先度の低いスレッドにＣＰＵの資源が回らず、その結果、優先度の低いスレッドの処理が実行されない状況が発生してしまう。このため、優先度の低いスレッドの処理がたまってしまい、システムが破綻してしまうという課題があった。

このような課題は、特許文献１に提案されている技術によっては解決することはできない。

発明の開示
本発明は、このような状況に鑑みてなされたものであり、ラウンドロビン機能やＴＳＳ制御機能を用いずにＯＳ上に構築されたアプリケーションプログラム群を効率よく制御することができる情報処理装置を提供することを目的とする。

本発明の情報処理装置は、上述した課題を解決するために、優先度が設けられた複数のスレッドからなるグループを、グループ内のスレッドの動作を監視するための複数の監視スレッドに対するキープアライブ動作によって監視する監視手段と、複数の監視スレッドからの応答に基づいて、キープアライブ動作に対する応答がない監視スレッドが存在するか否かを判定する第１の判定手段と、第１の判定手段によりキープアライブ動作に対する応答がない監視スレッドが存在すると判定された場合、キープアライブ動作に対する応答がない監視スレッドが監視するグループよりも優先度が高いグループへのイベントの配信を停止する第１の停止手段とを備えることを特徴とする。

本発明の情報処理装置は、上述した課題を解決するために、優先度が設けられた複数のスレッドからなるグループを、グループ内のスレッドの動作を監視するための複数の監視スレッドに対するキープアライブ動作によって監視する監視手段と、複数の監視スレッドからの応答に基づいて、キープアライブ動作に対する応答がない監視スレッドが存在するか否かを判定する第１の判定手段と、第１の判定手段によりキープアライブ動作に対する応答がない監視スレッドが存在すると判定された場合、キープアライブ動作に対する応答がない監視スレッドが監視するグループまたはそのグループよりも優先度が高いグループに含まれる少なくとも１つ以上のスレッドの優先度を変更する優先度変更手段とを備えることを特徴とする。

本発明の情報処理装置においては、優先度が設けられた複数のスレッドからなるグループが、グループ内のスレッドの動作を監視するための複数の監視スレッドに対するキープアライブ動作によって監視され、複数の監視スレッドからの応答に基づいて、キープアライブ動作に対する応答がない監視スレッドが存在するか否かが判定され、キープアライブ動作に対する応答がない監視スレッドが存在すると判定された場合、キープアライブ動作に対する応答がない監視スレッドが監視するグループよりも優先度が高いグループへのイベントの配信が停止される。

本発明の情報処理装置においては、優先度が設けられた複数のスレッドからなるグループが、グループ内のスレッドの動作を監視するための複数の監視スレッドに対するキープアライブ動作によって監視され、複数の監視スレッドからの応答に基づいて、キープアライブ動作に対する応答がない監視スレッドが存在するか否かが判定され、キープアライブ動作に対する応答がない監視スレッドが存在すると判定された場合、キープアライブ動作に対する応答がない監視スレッドが監視するグループまたはそのグループよりも優先度が高いグループに含まれる少なくとも１つ以上のスレッドの優先度が変更される。

本発明によれば、ラウンドロビン機能やＴＳＳ制御機能が搭載されていないＯＳ上に構築されたアプリケーションプログラム群を効率よく制御することができる。

は、本発明に係る情報処理装置に適用可能な携帯電話機の外観の構成を示す外観図である。 は、本発明に係る情報処理装置に適用可能な携帯電話機の他の外観の構成を示す外観図である。 は、本発明に係る情報処理装置に適用可能な携帯電話機の内部の構成を示すブロック図である。 は、優先度の低いスレッドの処理がたまることにより生じるシステムの破綻を説明するための説明図である。 は、スレッドのグループ分けの方法を説明するための説明図である。 は、図３の携帯電話機におけるイベント配信制御処理を説明するフローチャートである。 は、スレッドの優先度の変更の概念を説明する説明図である。 は、図３の携帯電話機におけるスレッド優先度変更処理を説明するフローチャートである。 は、スレッドの優先度の変更の概念を説明する説明図である。 は、図３の携帯電話機における他のスレッド優先度変更処理を説明するフローチャートである。 は、図３の携帯電話機における他のイベント配信制御処理を説明するフローチャートである。

以下、本発明の実施の形態について、図面を参照しながら説明する。図１は、本発明に係る情報処理装置として適用可能な携帯電話機１の外観の構成を表している。なお、図１（Ａ）は、携帯電話機１を約１８０度に見開いたときの正面から見た外観の構成を表しており、図１（Ｂ）は、携帯電話機１を見開いたときの側面から見た外観の構成を表している。

図１（Ａ）および（Ｂ）に示されるように、携帯電話機１は、中央のヒンジ部１１を境に第１の筐体１２と第２の筐体１３とがヒンジ結合されており、ヒンジ部１１を介して矢印Ｘ方向に折り畳み可能に形成される。携帯電話機１の内部の所定の位置には、送受信用のアンテナ（後述する図３のアンテナ４４）が設けられており、内蔵されたアンテナを介して基地局（図示せず）との間で電波を送受信する。

第１の筐体１２には、その表面に「０」乃至「９」の数字キー、発呼キー、リダイヤルキー、終話・電源キー、クリアキー、および電子メールキーなどの操作キー１４が設けられており、操作キー１４を用いて各種指示を入力することができる。

第１の筐体１２には、操作キー１４として上部に十字キーと確定キーが設けられており、ユーザが十字キーを上下左右方向に操作することにより当てられたカーソルを上下左右方向に移動させることができる。具体的には、第２の筐体１３に設けられた液晶ディスプレイ１７に表示されている電話帳リストや電子メールのスクロール動作、簡易ホームページのページ捲り動作および画像の送り動作などの種々の動作を実行する。

また、確定キーを押下することにより、種々の機能を確定することができる。例えば第１の筐体１２は、ユーザによる十字キーの操作に応じて液晶ディスプレイ１７に表示された電話帳リストの複数の電話番号の中から所望の電話番号が選択され、確定キーが第１の筐体１２の内部方向に押圧されると、選択された電話番号を確定して電話番号に対して発呼処理を行う。

さらに、第１の筐体１２には、十字キーと確定キーの左隣に電子メールキーが設けられており、電子メールキーが第１の筐体１２の内部方向に押圧されると、メールの送受信機能を呼び出すことができる。十字キーと確定キーの右隣には、ブラウザキーが設けられており、ブラウザキーが第１の筐体１２の内部方向に押圧されると、Ｗｅｂページのデータを閲覧することが可能となる。なお、十字キーと確定キーの左右隣に設けられた電子メールキーおよびブラウザキーは、液晶ディスプレイ１７に表示される画面により例えば「Yes」や「No」などの種々の機能をもつことが可能であるため、それぞれ、soft１キーおよびsoft２キーと呼ばれる。

また、第１の筐体１２には、操作キー１４の下部にマイクロフォン１５が設けられており、マイクロフォン１５によって通話時のユーザの音声を集音する。また、第１の筐体１２には、携帯電話機１の操作を行うサイドキー１６が設けられている。

なお、第１の筐体１２は、背面側に図示しないバッテリパックが挿着されており、終話・電源キーがオン状態になると、バッテリパックから各回路部に対して電力が供給されて動作可能な状態に起動する。

一方、第２の筐体１３には、その正面に液晶ディスプレイ１７（メインディスプレイ）が設けられており、電波の受信状態、電池残量、電話帳として登録されている相手先名や電話番号及び送信履歴等の他、電子メールの内容、簡易ホームページ、ＣＣＤ（Charge Coupled Device）カメラ（後述する図２のＣＣＤカメラ２０）で撮像した画像、外部のコンテンツサーバ（図示せず）より受信したコンテンツ、メモリカード（後述する図３のメモリカード４６）に記憶されているコンテンツを表示することができる。

また、液晶ディスプレイ１７の上部の所定の位置にはスピーカ１８が設けられており、これにより、ユーザは音声通話することが可能である。

図２は、本発明に係る情報処理装置として適用可能な携帯電話機１の他の外観の構成を表している。図２の携帯電話機１の状態は、図１の携帯電話機１の状態から矢印Ｘ方向に回動させた状態である。なお、図２（Ａ）は、携帯電話機１を閉じたときの正面から見た外観の構成を表しており、図２（Ｂ）は、携帯電話機１を閉じたときの側面から見た外観の構成を表している。

第２の筐体１３の上部には、ＣＣＤカメラ２０が設けられており、これにより、所望の撮影対象を撮像することができる。ＣＣＤカメラ２０の下部には、サブディスプレイ２１が設けられており、現在のアンテナの感度のレベルを示すアンテナピクト、携帯電話機１の現在の電池残量を示す電池ピクト、現在の時刻などが表示される。

サブディスプレイ２１の下部には、さらに、静電タッチパッド２３が設けられる。静電タッチパッド２２は、見かけ上一枚のタッチパッドになっているが、図示せぬセンサが複数個所に設けられており、ユーザがセンサの付近をタッチすると、センサがそれを検知し、巻戻し機能、早送り機能、音量ダウン動作、音量アップ動作、再生動作、および一時停止動作などが実行される。

図３は、本発明に係る情報処理装置として適用可能な携帯電話機１の内部の構成を表している。図３に示されるように、携帯電話機１は、第１の筐体１２及び第２の筐体１３の各部を統括的に制御する主制御部３１に対して、電源回路部３２、操作入力制御部３３、画像エンコーダ３４、カメラインタフェース部３５、ＬＣＤ（Liquid Crystal Display）制御部３６、多重分離部３８、変復調回路部３９、音声コーデック４０、記憶部４７、および音楽制御部４８がメインバス４１を介して互いに接続されるとともに、画像エンコーダ３４、画像デコーダ３７、多重分離部３８、変復調回路部３９、音声コーデック４０、および記録再生部４５が同期バス４２を介して互いに接続されて構成される。

主制御部３１は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、およびＲＡＭ（Random Access Memory）などからなり、ＣＰＵは、ＲＯＭに記憶されているプログラムまたは記憶部４７からＲＡＭにロードされた、オペレーティングシステム（ＯＳ）を含む各種のアプリケーションプログラムに従って各種の処理を実行するとともに、種々の制御信号を生成し、各部に供給することにより携帯電話機１を統括的に制御する。ＲＡＭは、ＣＰＵが各種の処理を実行する上において必要なデータなどを適宜記憶する。なお、主制御部３１には、現在の日付と時刻を正確に計測するタイマが内蔵されている。

携帯電話機１は、主制御部３１の制御に基づいて、音声通話モード時にマイクロフォン１５で集音した音声信号を音声コーデック４０によってディジタル音声信号に変換、圧縮し、これを変復調回路部３９でスペクトラム拡散処理し、送受信回路部４３でディジタルアナログ変換処理及び周波数変換処理を施した後にアンテナ４４を介して送信する。

また、携帯電話機１は、音声通話モード時にアンテナ４４で受信した受信信号を増幅して周波数変換処理及びアナログディジタル変換処理を施し、変復調回路部３９でスペクトラム逆拡散処理し、音声コーデック４０によって伸張し、アナログ音声信号に変換した後、変換されたアナログ音声信号をスピーカ１８を介して出力する。

携帯電話機１は、データ通信モード時に画像信号を送信する場合、ＣＣＤカメラ２０で撮像された画像信号をカメラインタフェース部３５を介して画像エンコーダ３４に供給する。

画像エンコーダ３４は、ＣＣＤカメラ２０から供給された画像信号を、例えばＭＰＥＧ（Moving Picture Experts Group）４などの所定の符号化方式によって圧縮符号化することにより符号化画像信号に変換し、変換された符号化画像信号を多重分離部３８に送出する。このとき同時に携帯電話機１は、ＣＣＤカメラ２０で撮像中にマイクロフォン１５で集音した音声を音声コーデック４０を介してディジタルの音声信号として多重分離部３８に送出する。

多重分離部３８は、画像エンコーダ３４から供給された符号化画像信号と音声コーデック４０から供給された音声信号とを所定の方式で多重化し、その結果得られる多重化信号を変復調回路部３９でスペクトラム拡散処理し、送受信回路部４３でディジタルアナログ変換処理及び周波数変換処理を施した後にアンテナ４４を介して送信する。これに対して、携帯電話機１では、データ通信モード時に、Ｗｅｂページのデータを受信することができる。

また、携帯電話機１は、データ通信モード時に例えばＷｅｂページなどにリンクされた動画像ファイルのデータを受信する場合、アンテナ４４を介して基地局（図示せず）から受信した受信信号を変復調回路部３９でスペクトラム逆拡散処理し、その結果得られる多重化信号を多重分離部３８に送出する。

多重分離部３８は、多重化信号を分離することにより符号化画像信号と音声信号とに分け、同期バス４２を介して符号化画像信号を画像デコーダ３７に供給すると共に音声信号を音声コーデック４０に供給する。画像デコーダ３７は、符号化画像信号をＭＰＥＧ４などの所定の符号化方式に対応した復号化方式でデコードすることにより再生動画像信号を生成し、生成された再生動画像信号をＬＣＤ制御部３６を介して液晶ディスプレイ１７に供給する。これにより、例えば、Ｗｅｂページなどにリンクされた動画像ファイルに含まれる動画像データが表示される。

このとき同時に音声コーデック４０は、音声信号をアナログ音声信号に変換した後、これをスピーカ１８に供給し、これにより、例えば、Ｗｅｂページなどにリンクされた動画像ファイルに含まる音声信号が再生される。

記憶部４７は、例えば、電気的に書換えや消去が可能な不揮発性メモリであるフラッシュメモリ素子やＨＤＤ（Hard Disc Drive）などからなり、主制御部３１のＣＰＵにより実行される種々のアプリケーションプログラムや種々のデータ群を格納している。

音楽制御部４８は、記憶部４７に記憶されているオーディオデータの再生動作および一時停止動作や、巻戻し機能、早送り機能、音量ダウン動作、音量アップ動作などの実行を制御する。

ところで、ラウンドロビン機能やＴＳＳ制御機能が搭載されていないＯＳ環境下では、発生したイベントを処理する場合、一般に、イベントドリブンに生成されたそれぞれのスレッドの優先度に従って処理するが、いくつかのスレッドにより主制御部３１のＣＰＵの資源が占有されてしまうと、その他のスレッドの処理が実行されない状況が発生してしまう。

すなわち、優先度の高いスレッド間における処理が連続して行われると、優先度の高い複数のスレッドにより主制御部３１のＣＰＵの資源が占有されてしまい、優先度の低いスレッドに主制御部３１のＣＰＵの資源が回らず、その結果、優先度の低いスレッドの処理が実行されない状況が発生してしまう。このために、優先度の低いスレッドの処理がたまってしまい、システムが破綻してしまう。

具体的には、例えば図４に示されるように、イベント配信制御スレッドが優先度が高い順からスレッドＡ、スレッドＢ、スレッドＣ、…のうちの一部のスレッドに対して制御している場合に、例えば、スレッドＣがソフトタイマを使用して周期的に時刻をスレッドＨから取得するスレッド（イベント配信制御スレッドによる制御を受けるスレッド）であり、スレッドＤはキーの入力を受け付けるスレッド（イベント配信制御スレッドによる制御を受けるスレッド）であり、スレッドＦは表示画面の更新及びその他のキーイベントに伴う処理を行うスレッド（イベント配信制御スレッドによる制御を受けるスレッド）であり、一方、スレッドＥは、スレッドＨが管理している音データを読み出して鳴動させるスレッド（イベント配信制御スレッドによる制御を受けないスレッド）であるケースを想定する。また、スレッドＦはキーの入力に伴うキータッチ音を鳴らすために、スレッドＥに鳴動依頼を通知し、鳴動依頼後応答を待たずに描画を行うことができるスレッドである。また、スレッドＥは、そのキー鳴動依頼を受けて、スレッドＨが管理しているキータッチ音の音データを読み出すことを行うスレッドである。

このようなアプリケーションプログラムのシステムにおいて、ユーザがキーの入力をすばやく連続的に押下すると、第１に、ユーザによるキーの押下によるキーの入力の割り込みが発生し、スレッドＤは発生したキーイベントをスレッドＦに供給する。第２に、スレッドＦは、キータッチ音を鳴音させるための鳴動依頼をスレッドＥに通知するとともに、その鳴動依頼の応答を待たずに、押下されたキーイベントを処理してそのイベントに対応する表示画面の書き換えを行う。第３に、スレッドＥは、スレッドＦからの鳴動依頼を受け取ると、音を鳴らすために必要な音データをスレッドＨに対して読み出す要求を行う。第４に、スレッドＨはスレッドＥから音データの読み出し要求を受け、スレッドＥに対して音データを送信する。第５に、スレッドＥは、音声コーデック４０とスピーカ１８を制御し、キータッチ音を鳴らさせる。

ところが、ユーザがキーの入力をすばやく長時間連続的に押下すると、ユーザによるキー押下が第３の処理であるスレッドＥによる読み出し処理の完了よりも早く行われてしまい、スレッドの優先度のためにスレッドＨが動作できず、第４、第５の処理が実行されない。一方、ユーザによるキー押下は連続的に行われるために、スレッドＤからスレッドＦへのイベントは行われるが、スレッドＦからスレッドＥへの鳴動依頼の通知処理は行われず、システム的にイベントがプールされてしまい、その結果、システムリソースが用い尽くされてしまうと、システムが破綻してしまう。換言すれば、スレッドＥによるキータッチ音が鳴らないにもかかわらず、スレッドＦによる表示画面の更新処理だけが行われてしまう。

勿論、スレッドＥにおいて受け付けるイベントの上限を予め決めておき、上限を超えて受け付けられたイベントを破棄する処理を追加するようにしてもよいが、結局、スレッドＤ乃至Ｆの処理により主制御部３１のＣＰＵの資源が占有されてしまう。さらには、スレッドＥにおいてイベント破棄処理を行うようにすると、画面遷移と音の鳴動にずれが生じてしまう。そこで、スレッドＤにおいて受け付けるイベントの上限を予め決めておくようにした場合も考えられるが、これも実際ＣＰＵの資源が占有されるのは音制御のスレッドＥであり、スレッドＤとスレッドＥとの関係を厳密に把握しない限り無駄なイベント破棄が行われてしまう可能性があり、妥当ではない。

また、スレッドＤ乃至Ｆの処理にＣＰＵの資源を占有される状態が継続すると、例えばユーザによる押下に伴うキー入力のイベントとは非同期の時刻変更処理を行っているスレッドＣは、スレッドＨから時刻を取得することができず、時刻変更処理が実行されず、時刻が更新されない。このような場合、システム的には破綻していなくても、ユーザにとって不便となってしまう。また、時刻変更処理ではなく、スレッドの網側との同期を行う処理であった場合には、網同期が外れてしまうことになる。

また、同様の状況は、例えばユーザが音楽制御部４８を用いてオーディオデータを聴きながら、例えば図示せぬ基地局などを介してブラウジングする際にも発生し得る。

そこで、スレッド動作を監視する監視スレッドを新たに設け、この監視スレッドによってスレッド動作を一定時間（例えば５秒間や１０秒間など）ごとに監視し、どの辺りのスレッド間において主制御部３１のＣＰＵの資源が占有されているか否かを判定するとともに、主制御部３１のＣＰＵの資源が占有されていると判定された場合、主制御部３１のＣＰＵの資源が占有されていると判定されたスレッド間へのイベントの配信を一時的に停止するようにする。

しかしながら、既存のアプリケーションプログラムが生成するスレッドの中には、例えば図４に示されるように、イベントの配信を制御することが可能なイベント配信制御対象のもの（例えばスレッドＡ、スレッドＣ、スレッドＤ、スレッドＦ、スレッドＧ、スレッドＩなど）と、イベントの配信を制御することができないイベント配信制御非対象のもの（例えばスレッドＢ、スレッドＥ、スレッドＨなど）の２種類が存在する。そのため、単純に、監視スレッドによってスレッド動作を一定時間ごとに監視しさえすれば、どの辺りのスレッド間において主制御部３１のＣＰＵの資源が占有されているか否かを容易に判定することができるわけではない。

そこで、どの辺りのスレッド間において主制御部３１のＣＰＵの資源が占有されているか否かを容易に判定することができるように、所定のアルゴリズムを用いて、存在するスレッドを予め複数のグループにグループ分けする。例えば図５に示されるように、非同期のイベントを受けて処理を行うスレッドとそのスレッドにより処理が発生するスレッド、あるいは、イベント配信制御対象のスレッドとイベント配信制御非対象のスレッドなどを複数のグループ（例えばグループ１乃至グループ３）などに分ける。

そして、各グループ（例えばグループ１乃至グループ３）におけるスレッド動作を監視するために、各グループの最低優先度のスレッドの下に監視用のスレッドである監視スレッド（例えば監視スレッド１乃至３）を配置し、配置された監視スレッド（例えば監視スレッド１乃至３）を用いて、グループごとにスレッド動作が回っているか否かを監視する。例えば、監視スレッド１乃至３がイベント配信制御スレッドに対して応答を返す動作を行うことによって、イベント配信制御スレッドは、それらの監視スレッドまでスレッド動作が回っているか否かを監視する。

ある１つのグループにおいてスレッド動作が回っていない（例えば、監視スレッド１からの応答はあるが監視スレッド２からの応答が無く、グループ１のスレッドの処理が回っているが、グループ２のスレッドの処理が回っていないと判断する）と判定された場合、その監視スレッドが監視するグループの１つ上の（１つ優先度の高い）グループ内の各スレッド（例えば監視スレッド１からの応答があり、監視スレッド２からの応答が無ければグループ１）に対してイベントを配信することを停止し、下位のグループに処理を回すようにする。

これにより、ラウンドロビン機能やＴＳＳ制御機能が搭載されていないＯＳ上に構築されたアプリケーションプログラム群を効率よく制御することが可能となる。以下、この方法を用いたイベント配信制御処理について説明する。

図６のフローチャートを参照して、図３の携帯電話機１におけるイベント配信制御処理について説明する。なお、このイベント配信制御処理に並行して、キープアライブ格納処理が実行される。具体的には、イベント配信制御スレッドからイベントが配信されるスレッドは、他のスレッドからの通信をイベント配信制御スレッドから受け取る。このとき、イベント配信制御において定期的に配信制御対象となるスレッドに対してイベントを配信する際に、イベント配信制御スレッドからのイベントキューの先頭にキープアライブに関するイベントを設定（格納）しておく。このような処理を「キープアライブ格納処理（キープアライブ動作）」と定義する。

イベントキューからイベントを取り出す処理をイベント配信制御スレッド側で提供するようにすれば、どのようなイベントが取り出されたか否かを把握することができることから、キープアライブに関するイベントを取り出すときに存在確認処理を行うとともに、このキープアライブに関するイベントを破棄するようにする。これにより、監視対象のスレッドに負荷をかけることなく、存在確認を行うことができる。すなわち、イベント配信制御において定期的に配信制御対象となるスレッドの配信イベントの先頭に特定のメッセージを含めておき、このメッセージが配信制御によって監視スレッド１乃至３に対する配信対象となったか否かにより、スレッドの処理が回っているかを判断することができる。主制御部３１のＣＰＵは、イベント配信制御スレッドを実行し、予め設定された所定の時間（例えば５秒間や１０秒間など）ごとに、監視スレッド（例えば監視スレッド１乃至３）の最初のイベントキュー（図示せず）にキープアライブのイベントを格納する。このとき、例えば監視スレッド１→監視スレッド２→監視スレッド３の順にキープアライブのイベントが格納される。なお、監視スレッド１、２、３に対して同時あるいはほぼ同時にイベントを格納するようにしてもよい。

ステップＳ１において、主制御部３１のＣＰＵは、イベント配信制御スレッドを実行し、キープアライブのイベント（キープアライブに関するイベント）の格納後から所定の時間（例えば５秒間や１０秒間）が経過するまで間に、いずれかの監視スレッド（例えば監視スレッド１乃至３）のうち、キープアライブに対する応答（キープアライブ動作に対する応答）がない監視スレッドが存在するか否かを判定し、キープアライブに対する応答がない監視スレッドが存在する判定するまで待機する。

例えば、上述したように、ユーザがキーの入力をすばやく長時間連続的に押下するとスレッドの優先度のためにスレッドＨが動作できず、第５の処理が実行されない一方、スレッドＤからスレッドＦへのイベントは行われるが、スレッドＦからスレッドＥへの鳴動依頼の通知処理は行われないことから、グループ２内のスレッドＤ乃至Ｆにより主制御部３１のＣＰＵの資源が占有されており、監視スレッド２は動作できない。そのため、監視スレッド２からキープアライブに対する応答がなされず、いずれかの監視スレッド（例えば監視スレッド１乃至３）のうち、キープアライブに対する応答がない監視スレッド（監視スレッド２）が存在すると判定される。

なお、ステップＳ１においていずれかの監視スレッド（例えば監視スレッド１乃至３）のうち、キープアライブに対する応答がない監視スレッドが存在しないと判定された場合、処理はステップＳ１に戻り、ステップＳ１以降の処理が繰り返し実行される。すなわち、再度、主制御部３１のＣＰＵによりイベント配信制御スレッドが実行され、予め設定された所定の時間（例えば５秒間や１０秒間など）ごとに、監視スレッド（例えば監視スレッド１乃至３）の最初のイベントキューにキープアライブのイベントが格納される。

ステップＳ１においていずれかの監視スレッド（例えば監視スレッド１乃至３）のうち、キープアライブに対する応答がない監視スレッドが存在すると判定された場合、主制御部３１のＣＰＵはステップＳ２で、イベント配信制御スレッドを実行し、キープアライブに対する応答がない監視スレッドが監視するグループの１つ上の（１つ前の）グループへのイベントの配信を停止する。

例えば、上述したように、グループ２内のスレッドＤ乃至Ｆにより主制御部３１のＣＰＵの資源が占有されており、監視スレッド２は動作できない場合、キープアライブに対する応答がない監視スレッド２が監視するグループ２の１つ上の（１つ前の）グループ１へのイベントの配信が停止される。

これにより、イベント配信制御対象スレッドによってイベント配信制御非対象スレッドの処理が阻害されている場合に、この阻害されている状況を解消することができる。

ステップＳ３において、主制御部３１のＣＰＵは、イベント配信制御スレッドを実行し、キープアライブに対する応答がない監視スレッドが監視するグループの１つ上の（１つ前の）グループへのイベントの配信が停止された後、キープアライブに対する応答がなかった監視スレッドからキープアライブに対する応答がくるようになったか（回復したか）否かを判定する。なお、この判定は、監視スレッドが監視するグループの１つ上のグループへのイベントの配信が停止されてから所定時間後、または、キープアライブのイベントを格納してから所定時間後に判定するようにすることが望ましい。

例えば、上述したように、グループ２内のスレッドＤ乃至Ｆにより主制御部３１のＣＰＵの資源が占有されており、監視スレッド２は動作できない場合に、キープアライブに対する応答がない監視スレッド２が監視するグループ２の１つ上の（１つ前の）グループ１へのイベントの配信が停止された後、キープアライブに対する応答がなかった監視スレッド２からキープアライブに対する応答がくるようになったか（回復したか）否かが判定される。

ステップＳ３においてキープアライブに対する応答がなかった監視スレッドからキープアライブに対する応答がくるようになったと判定された場合、主制御部３１のＣＰＵはステップＳ４で、キープアライブに対する応答がなかった監視スレッドにより監視されるグループ内のスレッド動作が回るように改善され、キープアライブに対する応答がなかった監視スレッドの動作が改善されたと認識し、キープアライブに対する応答がなかった監視スレッドが監視するグループの１つ上の（１つ前の）グループへのイベントの配信の停止を解除する。

例えば、キープアライブに対する応答がない監視スレッド２が監視するグループ２の１つ上の（１つ前の）グループ１へのイベントの配信が停止された場合、キープアライブに対する応答がなかった監視スレッド２からキープアライブに対する応答がくるようになったと判定されると、グループ１へのイベントの配信の停止が解除される。

ステップＳ３においてキープアライブに対する応答がなかった監視スレッドからキープアライブに対する応答が依然としてくるようになっていないと判定された場合、主制御部３１のＣＰＵはステップＳ５で、イベント配信制御スレッドを実行し、キープアライブに対する応答がない監視スレッドが監視するグループへのイベントの配信を停止する。

例えば、上述したように、グループ２内のスレッドＤ乃至Ｆにより主制御部３１のＣＰＵの資源が占有されており、監視スレッド２が動作できず、グループ１へのイベントの配信が停止されたにもかかわらず、監視スレッド２からキープアライブに対する応答が依然としてくるようになっていないと判定されると、監視スレッド２が監視するグループ２へのイベントの配信が停止される。

これにより、スレッドＤ乃至Ｆにすでに配信されているイベントの処理が行われるとともに、スレッドの優先度のために保留されていたスレッドＨの動作が開始され、第４の処理であるキータッチ音の鳴音処理が実行される。

しかし、イベント配信制御スレッドによる所定の監視時間よりも、保留されていたスレッドＨの動作の処理時間の方が長い場合、今度は、グループ３内のスレッド動作を監視する監視スレッドの動作ができなくなる。そこで、再度、キープアライブに対する応答がない監視スレッドが存在するか否かを判定する。

ステップＳ６において、主制御部３１のＣＰＵは、イベント配信制御スレッドを実行し、キープアライブのイベントの格納後から所定の時間（例えば５秒間や１０秒間）が経過するまで間に、いずれかの監視スレッド（例えば監視スレッド１乃至３）のうち、キープアライブに対する応答がない監視スレッドが存在するか否かを判定する。

例えばイベント配信制御スレッドによる所定の監視時間よりも、保留されていたスレッドＨの動作の処理時間の方が長い場合、今度は、グループ３内のスレッド動作を監視する監視スレッド３の動作ができなくなることから、監視スレッド３は動作できないために監視スレッド３からキープアライブに対する応答がなされず、いずれかの監視スレッド（例えば監視スレッド１乃至３）のうち、キープアライブに対する応答がない監視スレッドが存在すると判定される。

一方、例えばイベント配信制御スレッドによる所定の監視時間よりも、保留されていたスレッドＨの動作の処理時間の方が短い場合、保留されていたスレッドＨの動作の処理後に、グループ３内のスレッド動作を監視する監視スレッド３の動作ができることから、監視スレッド３からキープアライブに対する応答がなされ、いずれかの監視スレッド（例えば監視スレッド１乃至３）のうち、キープアライブに対する応答がない監視スレッドが存在しないと判定される。

ステップＳ６においてキープアライブに対する応答がない監視スレッドが存在しないと判定された場合、処理はステップＳ１に戻り、ステップＳ１以降の処理が繰り返される。

これにより、再度、同じような状況が発生したとしても、同様にアプリケーションプログラムのシステム上の輻輳を解消することができる。

一方、ステップＳ６においてキープアライブに対する応答がない監視スレッドが存在すると判定された場合、処理はステップＳ５に戻り、ステップＳ５において主制御部３１のＣＰＵによりイベント配信制御スレッドが実行され、キープアライブに対する応答がない監視スレッドが監視するグループへのイベントの配信が停止される。

その後、処理はステップＳ６以降の処理が繰り返され、予め配置されたすべての監視スレッド（例えば監視スレッド１乃至３など）が動作できるようになった後、すべてのスレッドに対してイベントが適宜に配信される。換言すれば、最低優先度のグループ（図５の場合、グループ３）を監視する監視スレッド３の動作が確認できるまで、同様の処理が順次繰り返され、最低優先度のグループを監視する監視スレッド３の動作が確認できた後、すべてのスレッドに対してイベントが適宜に配信される。

なお、本発明の実施形態においては、説明を簡略化するために、複数のスレッドを大きく３つのグループ（例えばグループ１乃至３）に分けた上で、イベント配信制御処理を行うようにしたが、このような場合に限られず、２または４つ以上のグループ分けを行うようにしてもよい。また、１つのグループ中のイベント配信制御非対象のスレッドを１つのスレッドとして扱うようにしてもよい。

本発明の実施形態においては、各グループの最低優先度のスレッドの下に監視用のスレッドである監視スレッド（例えば監視スレッド１乃至３）を配置し、配置された監視スレッド（例えば監視スレッド１乃至３）を用いて、グループごとにスレッド動作が回っているか否かを監視し、キープアライブのイベントの格納後から所定の時間（例えば５秒間や１０秒間）が経過するまで間に、いずれかの監視スレッド（例えば監視スレッド１乃至３）のうち、キープアライブに対する応答がない監視スレッドが存在するか否かを判定するとともに、キープアライブに対する応答がない監視スレッドが存在すると判定された場合、キープアライブに対する応答がない監視スレッドが監視するグループの１つ上の（１つ前の）グループへのイベントの配信を停止することができる。

そして、キープアライブに対する応答がない監視スレッドが監視するグループの１つ上の（１つ前の）グループへのイベントの配信が停止された後、キープアライブに対する応答がなかった監視スレッドからキープアライブに対する応答がくるようになったか（回復したか）否かを判定し、そのグループへのイベントの配信が停止された後、キープアライブに対する応答がなかった監視スレッドからキープアライブに対する応答がくるようになった（回復した）と判定された場合、そのグループへのイベントの配信の停止を解除する一方、そのグループへのイベントの配信が停止された後、キープアライブに対する応答がなかった監視スレッドからキープアライブに対する応答がくるようになっていない（回復していない）と判定された場合、キープアライブに対する応答がない（回復していない）監視スレッドが監視するグループへのイベントの配信を停止することができる。

さらに、キープアライブに対する応答がない監視スレッドが監視するグループへのイベントの配信を停止した後、再度繰り返して、キープアライブのイベントの格納後から所定の時間（例えば５秒間や１０秒間）が経過するまで間に、いずれかの監視スレッド（例えば監視スレッド１乃至３）のうち、キープアライブに対する応答がない監視スレッドが存在するか否かを判定し、キープアライブに対する応答がない監視スレッドが存在すると判定された場合、キープアライブに対する応答がない監視スレッドが監視するグループへのイベントの配信を停止することができる。これにより、優先度の高いスレッドに対するイベントの配信を停止するとともに、下位のグループに処理を回すようにすることができる。従って、ラウンドロビン機能やＴＳＳ制御機能が搭載されていないＯＳ上に構築されたアプリケーションプログラム群を効率よく制御することができる。

また、タスクの切り替えの際のオーバーヘッドを少なくするとともに、アプリケーションプログラムのシステム上の輻輳を効率よく判定することができる。

その結果、予めグループ分けされたスレッドによる柔軟な優先順位に基づく処理が実装可能となり、また、イベント配信制御対象とイベント配信制御非対象などを含むスレッドのグループ分けを工夫することで柔軟なアプリケーションプログラム群のシステムを構築することができ、既存のアプリケーションプログラムを含めた広範囲なシステムの構築に用いることができる。

ところで、図６のフローチャートを参照して説明したイベント配信制御処理においては、キープアライブに対する応答がない監視スレッド（例えば監視スレッド２など）が存在すると判定された場合、キープアライブに対する応答がない監視スレッド２が監視するグループの１つ上の（１つ前の）グループ（グループ１）へのイベントの配信を停止するようにして、イベント配信制御対象であるスレッドへのイベント配信自体を制御することで、動作ができなくなったスレッドの動作を優先度の高いものから順次完結させるようにした。そのため、動作ができなくなったスレッドの解消に所要の時間がかかり、リアルタイム性をある程度保障する必要がある他のスレッドの動作に影響を及ぼす可能性がある。特に、イベント配信制御非対象のスレッドも存在することから、たとえイベント配信制御対象スレッドに対してイベント配信を停止したとしても、動作ができなくなったスレッドの解消には多少なりともタイムラグが生じてしまう。そこで、ある１つのスレッドがイベント配信制御対象スレッドであるか制御非対象スレッドかに関係なく、そのスレッドが現在動作している最中に、他のスレッドに主制御部３１のＣＰＵの資源を割り当てるために、強制的に監視スレッド１の下の優先順位（優先度）に配置するようにするとともに、ＣＰＵの資源を割り当てたい他のスレッドの優先順位を相対的に上げるようにする。

具体的には、本発明においては、各アプリケーションプログラムが生成するスレッドに要求されるリアルタイム性に応じて、スレッドに優先順位をつけ、優先順位の高いスレッドから順次動作させるＯＳを想定している。例えば図７（Ａ）の場合、優先順位が最も高いスレッドにイベント配信制御スレッドが存在し、次に、グループ１に含まれるスレッドＡ乃至Ｃが優先順位２乃至４のスレッドとして存在する。そして、グループ１内のスレッドが動作できているか否かを監視する監視スレッド１が優先順位５のスレッドとして配置されている。

このとき、例えばグループ１内の優先順位２のスレッドＡがイベント配信制御スレッドから配信される１つのイベントによって例えば１秒間動作し、優先順位３のスレッドＢが１つのイベントごとに例えば０．５秒間動作するとした場合、スレッドＢがイベントに応じて動作しようとしても、スレッドＡによる動作によって主制御部３１のＣＰＵの資源が長時間占有されてしまうこともあり、スレッドＢの動作に支障をきたしてしまう。その結果、スレッドＢの動作はまわらなくなり、監視スレッド１からのキープアライブ動作に対応する応答がイベント配信制御スレッドに対してなされなくなる。

そこで、このような場合、図７（Ｂ）に示されるように、スレッドＡが現在動作しているにもかかわらず、所要の時間間隔（例えば０．１秒間隔など）で、強制的に監視スレッド１の下の優先順位に配置するようにする。これにより、イベント配信制御スレッド、スレッドＡ、スレッドＢ、スレッドＣ、および監視スレッド１の順の優先順位から、イベント配信制御スレッド、スレッドＢ，スレッドＣ、監視スレッド１、およびスレッドＡの順の優先順位に変更される。すなわち、スレッドＡの優先順位が２位から５位に変更されるとともに、スレッドＢとスレッドＣ、監視スレッド１の優先順位が２位、３位、４位にそれぞれ変更される。その結果、スレッドＡの動作により阻害されていたスレッドＢの動作が開始され、監視スレッド１からのキープアライブ動作に対応する応答がイベント配信制御スレッドに対してなされるようになる。従って、優先度の高いスレッドの動作を好適なタイミングで抑制することが可能となる。以下、この方法を用いたスレッド優先度変更処理について説明する。

なお、スレッドＢによる動作によって主制御部３１のＣＰＵの資源が長時間占有されている場合には、スレッドＡを監視スレッド１の下に配置するだけでは足りず、図７（Ｃ）に示されるように、イベント配信制御非対象のスレッドＢも監視スレッド１の下に配置されることとなる。すなわち、イベント配信制御スレッド、スレッドＡ、スレッドＢ，スレッドＣ、および監視スレッド１の順の優先順位から、イベント配信制御スレッド、スレッドＣ、監視スレッド１、スレッドＡ、およびスレッドＢの順の優先順位に変更される。

図８のフローチャートを参照して、図３の携帯電話機１のスレッド優先度変更処理について説明する。

ステップＳ１１において、主制御部３１のＣＰＵは、イベント配信制御スレッドを実行し、キープアライブのイベント（キープアライブに関するイベント）の格納後から所定の時間（例えば５秒間や１０秒間）が経過するまで間に、いずれかの監視スレッド（例えば監視スレッド１乃至３）のうち、キープアライブに対する応答（キープアライブ動作に対する応答）がない監視スレッドが存在するか否かを判定し、キープアライブに対する応答がない監視スレッドが存在する判定するまで待機する。

例えばグループ１内の優先順位２のスレッドＡがイベント配信制御スレッドから配信される１つのイベントによって例えば１秒間動作し、優先順位３のスレッドＢが１つのイベントごとに例えば０．５秒間動作するとした場合、スレッドＢがイベントに応じて動作しようとしても、スレッドＡによる動作によって主制御部３１のＣＰＵの資源が長時間占有されてしまうこともあり、スレッドＢの動作に支障をきたしてしまう。また、スレッドＢによる動作によって主制御部３１のＣＰＵの資源が長時間占有されている場合、スレッドＣの動作に支障をきたしてしまう。そのため、監視スレッド１からキープアライブに対する応答がなされず、いずれかの監視スレッド（例えば監視スレッド１乃至３）のうち、キープアライブに対する応答がない監視スレッド（監視スレッド２）が存在すると判定される。

なお、ステップＳ１においていずれかの監視スレッド（例えば監視スレッド１乃至３）のうち、キープアライブに対する応答がない監視スレッドが存在しないと判定された場合、処理はステップＳ１１に戻り、ステップＳ１１以降の処理が繰り返し実行される。すなわち、再度、主制御部３１のＣＰＵによりイベント配信制御スレッドが実行され、予め設定された所定の時間（例えば５秒間や１０秒間など）ごとに、監視スレッド（例えば監視スレッド１乃至３）の最初のイベントキューにキープアライブのイベントが格納される。

ステップＳ１１においていずれかの監視スレッド（例えば監視スレッド１乃至３）のうち、キープアライブに対する応答がない監視スレッドが存在すると判定された場合、主制御部３１のＣＰＵはステップＳ１２で、イベント配信制御スレッドを実行し、キープアライブに対する応答がない監視スレッドが監視するグループに含まれるスレッドの優先度を変更する。

例えば図７（Ｂ）に示されるように、スレッドＡが現在動作している最中であったとしても、所要の時間間隔（例えば０．１秒間隔など）で、強制的に監視スレッド１の下の優先順位に配置するようにする。これにより、イベント配信制御スレッド、スレッドＡ、スレッドＢ、スレッドＣ、および監視スレッド１の順の優先順位から、イベント配信制御スレッド、スレッドＢ，スレッドＣ、監視スレッド１、およびスレッドＡの順の優先順位に変更される。すなわち、スレッドＡの優先順位が２位から５位に変更されるとともに、スレッドＢとスレッドＣ、監視スレッド１の優先順位が２位、３位、４位にそれぞれ変更される。

これにより、スレッドＡの動作によりスレッドＢの動作が阻害されていた場合、阻害されていたスレッドＢの動作が開始され、監視スレッド１からのキープアライブ動作に対応する応答がイベント配信制御スレッドに対してなされるようになる。

ステップＳ１３において、主制御部３１のＣＰＵは、イベント配信制御スレッドを実行し、キープアライブに対する応答がない監視スレッドが監視するグループに含まれるスレッドの優先度が変更された後、キープアライブに対する応答がなかった監視スレッドからキープアライブに対する応答がくるようになったか（回復したか）否かを判定する。

ステップＳ１３においてキープアライブに対する応答がなかった監視スレッドからキープアライブに対する応答がくるようになったと判定された場合、主制御部３１のＣＰＵはステップＳ１４で、イベント配信制御スレッドを実行し、キープアライブに対する応答がなかった監視スレッドにより監視されるグループ内のスレッド動作ができるように改善され、キープアライブに対する応答がなかった監視スレッドの動作が改善されたと認識し、キープアライブに対する応答がなかった監視スレッドが監視するグループに含まれるスレッドの優先度を元に戻す（すなわち、ステップＳ１２の処理により優先度が変更されたスレッドの優先度を元に戻す）。

例えば図７（Ｂ）の場合、スレッドＡの優先順位が２位から５位に変更されるとともに、スレッドＢとスレッドＣ、監視スレッド１の優先順位が２位、３位、４位にそれぞれ変更されていることから、図７（Ａ）に示される元の状態に戻される。すなわち、イベント配信制御スレッド、スレッドＡ、スレッドＢ，スレッドＣ、および監視スレッド１の順の優先順位（優先度）に戻される。その後、処理はステップＳ１１に戻る。

一方、ステップＳ１３においてキープアライブに対する応答がなかった監視スレッドからキープアライブに対する応答がくるようになっていないと判定された場合（すなわち、スレッドＢによる動作によって主制御部３１のＣＰＵの資源が長時間占有され、スレッドＣによる動作が阻害されている場合）、処理はステップＳ１２に戻り、ステップＳ１２にてスレッドの優先度の変更処理が所要の時間間隔（例えば０．１秒間隔など）で行われる。すなわち、スレッドＢによる動作によって主制御部３１のＣＰＵの資源が長時間占有されている場合には、スレッドＣの動作が阻害されていることから、スレッドＡを監視スレッド１の下に配置するだけでは足りず、図７（Ｃ）に示されるように、スレッドＡを監視スレッド１の下に配置してから所要の時間（例えば０．１秒間など）経過後に、イベント配信制御非対象のスレッドＢも監視スレッド１の下に強制的に配置されることとなる。そして、イベント配信制御スレッド、スレッドＡ、スレッドＢ，スレッドＣ、および監視スレッド１の順の優先順位から、イベント配信制御スレッド、スレッドＣ、監視スレッド１、スレッドＡ、およびスレッドＢの順の優先順位に変更される。

その後、処理はステップＳ１４に進み、ステップＳ１３にてキープアライブに対する応答がくるようになったか否かが判定され、ステップＳ１３においてキープアライブに対する応答がなかった監視スレッドからキープアライブに対する応答がくるようになったと判定された場合、主制御部３１のＣＰＵはステップＳ１４で、キープアライブに対する応答がなかった監視スレッドが監視するグループに含まれるスレッドの優先度を元に戻す。すなわち、例えば図７（Ｃ）の場合、イベント配信制御スレッド、スレッドＣ、監視スレッド１、スレッドＡ、およびスレッドＢの順の優先順位（優先度）に変更されていることから、図７（Ａ）に示される元の状態に戻される。その後、処理はステップＳ１１に戻り、ステップＳ１１以降の処理が繰り返される。

これにより、優先度の高いスレッドの動作を一時的に抑制し、優先度の低いスレッドに処理を回すようにすることができる。従って、ラウンドロビン機能やＴＳＳ制御機能を用いず、ラウンドロビン機能やＴＳＳ制御機能が搭載されていないＯＳ上に構築されたアプリケーションプログラム群を効率よく制御することができる。また、タスクの切り替えの際のオーバーヘッドを少なくするとともに、アプリケーションプログラムのシステム上の輻輳を効率よく判定することができる。

なお、イベント配信制御非対象のスレッドＢがＵＩ（ユーザインタフェース）系のスレッドである場合に、１回で大量の描画処理を行うときには、スレッドＢの動作により主制御部３１のＣＰＵの資源が占有されてしまう。このとき、例えばグループ２のスレッドＤによる動作を０．５秒ごとに行う必要があるために、監視スレッド２からのキープアライブ動作に対応する応答がイベント配信制御スレッドに対してなされなくなったとする。このような場合、スレッドＢの動作によって主制御部３１のＣＰＵの資源が占有されているために、スレッドＤの動作が阻害されていると推定し、例えば図９（Ａ）および（Ｂ）に示されるように、グループ間を飛び越えて、グループ２の動作を監視する監視スレッド２の下の位置までスレッドＢの優先度を下げるようにする。これにより、優先度の高いスレッドの動作を一時的に抑制し、優先度の低いスレッドに処理を好適にかつ確実に回すようにすることができる。

ところで、図８のスレッド優先度変更処理においては、キープアライブに対する応答がなかった監視スレッドからキープアライブに対する応答がくるようになった場合に、主制御部３１のＣＰＵの資源を占有するスレッドの優先度を元に戻し、このスレッドの動作の一時的な抑制を解除するようにしたが、このような場合に限られず、タイマを用いて、このスレッドの優先度を変更することでスレッドの動作抑制を行ってからｎ時間（ｍｓ）経過後に動作の抑制を解除するようにしてもよい。

この方法を用いるケースとしては以下のような場合が想定される。すなわち、例えばイベント配信制御非対象のスレッドＢがＵＩ（ユーザインタフェース）系のスレッドである場合に、１回で大量の描画処理を行うときには、スレッドＢの動作により主制御部３１のＣＰＵの資源が占有されてしまうが、このとき、スレッドＣの動作が阻害されているためにスレッドＢの優先度を監視スレッド１よりも下げたままにしてしまうと、スレッドＢにてユーザによる操作キーを新たに受け付ける（例えば描画処理のキャンセルを受け付ける）ことができなくなってしまう。このような場合、動作が抑制されているスレッドＢを一旦元の優先度に復帰させ、スレッドＢの動作抑制を行ってからｎ時間（ｍｓ）経過後に動作の抑制を解除することで、スレッドＢにてユーザによる操作キーを新たに受け付けることができる。その後、依然としてスレッドＢの動作により主制御部３１のＣＰＵの資源が占有されている場合には、イベント配信制御スレッドの実行により、スレッドＢの動作を抑制してから所要の時間（例えば０．１秒間）後に再度スレッドＢの動作が抑制される。以下、この方法を用いたスレッド優先度変更処理について説明する。

図１０のフローチャートを参照して、図３の携帯電話機１における他のスレッド優先度変更処理について説明する。なお、図１０のステップＳ２１、Ｓ２２、ステップＳ２５、およびステップＳ２６の処理は、図８のステップＳ１１乃至Ｓ１４の処理と基本的には同様であり、その説明は繰り返しになるので省略する。

なお、このとき、ステップＳ２２において、主制御部３１のＣＰＵが、イベント配信制御スレッドを実行し、キープアライブに対する応答がない監視スレッドが監視するグループに含まれるスレッドＢの優先度を監視スレッド１の下に変更しているものとする。

ステップＳ２３において、主制御部３１のＣＰＵは、イベント配信制御スレッドを実行し、タイマを用いて、スレッドＢの動作抑制を行ってからｎ時間（ｍｓ）経過したか否かを判定し、スレッドＢの動作抑制を行ってからｎ時間（ｍｓ）経過したと判定するまで待機する。ステップＳ２３においてスレッドＢの動作抑制を行ってからｎ時間（ｍｓ）経過したと判定された場合、主制御部３１のＣＰＵはステップＳ２４で、イベント配信制御スレッドを実行し、動作が抑制されているスレッドＢを一旦元の優先度に復帰させ、スレッドＢの動作の抑制を解除する。これにより、優先度の高いスレッドの動作を一時的に抑制し、優先度の低いスレッドに処理を回すようにすることができるとともに、優先度が変更されたスレッドＢにてユーザによる操作キーを新たに受け付けることができる。

なお、図８および図１０のフローチャートを用いて説明したスレッド優先度変更処理を、図６のフローチャートを参照して説明したイベント配信制御処理と適宜組み合わせるようにしてもよい。この場合の処理の一例は、図１１に示される。なお、図１１のステップＳ３１に乃至Ｓ３４、およびステップＳ３７乃至Ｓ３８の処理は、図６のステップＳ１乃至Ｓ６の処理と基本的には同様である。

図１１に示されるように、例えばグループ１内のＵＩ系のスレッドＢにより主制御部３１のＣＰＵの資源が占有されており、その結果、監視スレッド２が動作できず、グループ１へのイベントの配信が停止されたにもかかわらず、監視スレッド２からキープアライブに対する応答が依然としてくるようになっていない場合に、ステップＳ３５において、主制御部３１のＣＰＵは、イベント配信制御スレッドを実行し、キープアライブに対する応答がない監視スレッド２が監視するグループ２の１つ上のグループ１に含まれるスレッドＢの優先度を変更し、監視スレッド２の下に配置する。これにより、グループ２のスレッドＤ乃至Ｆが順次動作できるようになる。なお、スレッドＢの優先度を変更しても、監視スレッド２からのキープアライブに対する応答がない場合には、ステップＳ３７にてグループ２へのイベントの配信も停止される。これにより、優先度の高いスレッドに対するイベントの配信を停止するとともに、下位のグループに処理をより好適に回すようにすることができる。従って、ラウンドロビン機能やＴＳＳ制御機能が搭載されていないＯＳ上に構築されたアプリケーションプログラム群をより効率よく制御することができる。なお、変更されたスレッドの優先度は、監視スレッド２からのキープアライブに対する応答が回復次第、イベント配信制御スレッドの実行により、元に戻される。

なお、本発明は、携帯電話機１以外にも、ＰＤＡ（Personal Digital Assistant）、パーソナルコンピュータ、携帯型ゲーム機、携帯型音楽再生機、携帯型動画再生機、その他の情報処理装置にも適用することができる。

また、本発明の実施形態において説明した一連の処理は、ソフトウェアにより実行させることもできるが、ハードウェアにより実行させることもできる。

さらに、本発明の実施形態では、フローチャートのステップは、記載された順序に沿って時系列的に行われる処理の例を示したが、必ずしも時系列的に処理されなくとも、並列的あるいは個別実行される処理をも含むものである。

Claims (10)

1. 優先度が設けられた複数のスレッドからなるグループを、グループ内のスレッドの動作を監視するための複数の監視スレッドに対するキープアライブ動作によって監視する監視手段と、
   複数の前記監視スレッドからの応答に基づいて、キープアライブ動作に対する応答がない前記監視スレッドが存在するか否かを判定する第１の判定手段と、
   前記第１の判定手段によりキープアライブ動作に対する応答がない前記監視スレッドが存在すると判定された場合、キープアライブ動作に対する応答がない前記監視スレッドが監視するグループよりも優先度が高いグループへのイベントの配信を停止する第１の停止手段とを備えることを特徴とする情報処理装置。
2. 前記第１の停止手段によるイベントの配信の停止後、キープアライブ動作による監視を再度行い、キープアライブ動作に対する応答がない前記監視スレッドが監視するグループ内のスレッドの動作が回復したか否かを判定する第２の判定手段と、
   前記第２の判定手段により前記グループ内のスレッドの動作が回復していないと判定された場合、スレッドの動作が回復していない前記グループへのイベントの配信を停止する第２の停止手段とをさらに備えることを特徴とする請求項１に記載の情報処理装置。
3. 前記第２の判定手段により前記グループ内のスレッドの動作が回復していない状態から動作が回復したと判定された場合、前記第１の停止手段によるイベントの配信の停止を解除する解除手段をさらに備えることを特徴とする請求項２に記載の情報処理装置。
4. 前記第２の停止手段によるイベントの配信の停止後、複数の前記監視スレッドのうち、前記所定の時間が経過するまでにキープアライブ動作に対する応答がない監視スレッドが存在するか否かを判定する第３の判定手段をさらに備え、
   前記第２の停止手段は、前記第３の判定手段により判定された、キープアライブ動作に対する応答がない前記監視スレッドが監視するグループへのイベントの配信を順次停止することを特徴とする請求項２に記載の情報処理装置。
5. それぞれの前記グループには、少なくとも、イベント配信制御対象とイベント配信制御非対象のスレッドが含まれることを特徴とする請求項１に記載の情報処理装置。
6. 前記キープアライブ動作においては、前記監視スレッドの先頭のイベントキューにキープアライブに関するイベントを格納することを特徴とする請求項１に記載の情報処理装置。
7. 優先度が設けられた複数のスレッドからなるグループを、グループ内のスレッドの動作を監視するための複数の監視スレッドに対するキープアライブ動作によって監視する監視手段と、
   複数の前記監視スレッドからの応答に基づいて、キープアライブ動作に対する応答がない前記監視スレッドが存在するか否かを判定する第１の判定手段と、
   前記第１の判定手段によりキープアライブ動作に対する応答がない前記監視スレッドが存在すると判定された場合、キープアライブ動作に対する応答がない前記監視スレッドが監視するグループまたはそのグループよりも優先度が高いグループに含まれる少なくとも１つ以上のスレッドの優先度を変更する優先度変更手段とを備えることを特徴とする情報処理装置。
8. 前記優先度変更手段は、キープアライブ動作に対する応答がない前記監視スレッドが監視するグループまたはそのグループよりも優先度が高いグループに含まれる少なくとも１つ以上のスレッドの優先度を、キープアライブ動作に対する応答がない前記監視スレッドの優先度よりも下に変更することを特徴とする請求項７に記載の情報処理装置。
9. 前記優先度変更手段によるスレッドの優先度の変更後、キープアライブ動作による監視を再度行い、キープアライブ動作に対する応答がない前記監視スレッドが監視するグループ内のスレッドの動作が回復したか否かを判定する第２の判定手段をさらに備え、
   前記第２の判定手段により前記グループ内のスレッドの動作が回復したと判定された場合、前記優先度変更手段は、変更されたスレッドの優先度を元に戻すことを特徴とする請求項７に記載の情報処理装置。
10. 前記優先度変更手段は、前記優先度変更手段によるスレッドの優先度の変更後であって、スレッドの動作抑制開始から所定の時間経過した後に、変更されたスレッドの優先度を元に戻すことを特徴とする請求項７に記載の情報処理装置。

Images