JP2009217388A - 情報処理装置 - Google Patents

Abstract

【課題】親ＯＳの下で動作する子ＯＳの下で動作する子タスクが、親ＯＳの下で動作する親タスクと協調して動作することができるようにする。
【解決手段】子タスクであるゲーム部３５は、親タスクとの協調動作のため、親タスクの生成を子ＯＳである代行制御部３３に要求する。代行制御部３３は、その要求をツール制御部３１に送って、親タスクを生成させる。親ＯＳである制御部１１及び親タスクであるツール制御部３１のそれぞれが生成した親タスクは別に管理される。即ち、制御部１１が生成した親タスクは、遅く生成された親タスクが高い優先度を持ち、ツール制御部３１が生成した親タスクの優先度は、生成された時刻によらない。
【選択図】図２

Description

本発明は、情報処理装置に係り、特に、マルチタスクオペレーティングシステムの下で動作するタスクと、そのオペレーティングシステムの下で１つのタスクとして管理されるオペレーティングシステムの下で動作するタスクとの協調動作処理に関する。

１台の情報処理装置の中で、複数のオペレーティングシステム（以下、ＯＳと称する。）を動作させることがある。その一例は、あるマルチタスクＯＳ（以下、親ＯＳと称する。）を動作させ、親ＯＳの下で１つのタスクとして制御されるＯＳ（以下、子ＯＳと称する。）を動作させることである。そして、親ＯＳの下で動作するタスク（以下、親タスクと称する。）の動作と、子ＯＳの下で動作するタスク（以下、子タスクと称する。）の動作とによって、使用者に所定の機能を提供する。

ここで、親ＯＳは、マルチタスクＯＳであり、親ＯＳは、親タスクの中で、いずれのタスクにリソースを割り当てるかを制御する。特に、実行可能状態（ＣＰＵリソースを割り当てられれば動作が可能な状態、Ready 状態。）にある親タスクが複数ある場合、親ＯＳは、それらのタスクの中で最も優先度が高い親タスクを実行状態（ＣＰＵリソースが割り当てられて動作中の状態、Active 状態。）に置く。一方、子ＯＳがマルチタスクＯＳである場合、同様に、子ＯＳは、子タスクの中でいずれのタスクを実行させるかを制御する。

親ＯＳがリアルタイム型ＯＳである場合、親ＯＳは、通常、最も近い過去に生成された親タスクに最も高い優先度を与え、そのタスクを実行状態に置く。そのタスクの動作に、入力装置からの入力などの装置外に起因する割り込みなどのイベント、または、他のタスクからの通知イベントを要する場合、親ＯＳは、その親タスクを待ち状態（イベントを待つ状態、Waiting 状態。）に置き、そのタスクに次いで優先度が高い親タスクを実行状態に置く。

そして、親ＯＳは、イベントの発生の後、そのイベントを待っていた親タスクを実行可能状態に置いた上で、改めて実行可能状態または実行状態にある親タスクの中で最も優先度が高いタスクを実行状態に置く。そして、待ち状態に置かれたタスク及び実行状態に置かれたタスク以外のタスクをサスペンド状態（動作が一時停止されている状態、Suspend 状態。）に置く。

リアルタイム型ＯＳである親ＯＳは、装置外に起因するイベントへの対応を主な観点として、情報処理装置全体の適切な動作を目的とした制御を行うが、子ＯＳは、子タスクの制御を行うのみであるので、その子タスクの制御は、必ずしも情報処理装置全体の適切な動作を保証しない。そこで、情報処理装置全体の適切な動作のため、親ＯＳが、子タスクの優先度を制御することが知られており、例えば、親タスクの中で優先度が高いタスクと通信する子タスクに高い優先度を与える（例えば、特許文献１参照。）。
特開２００５−２３４６５８号公報（第２頁、図１）

しかしながら、上述した特許文献１に開示されている方法では、親ＯＳは、親タスクと通信する子タスクを制御することができるものの、子タスクは、親タスクの動作を制御できない問題点があった。この問題点は、例えば、子タスクが、親タスクと協調して動作する、即ち、その子タスクと、その親タスクとが交互に実行状態に置かれることを必要とする場合、顕著である。

本発明は上記問題点を解決するためになされたもので、親ＯＳの下で動作する子ＯＳの下で動作する子タスクが、親ＯＳの下で動作する親タスクと協調して動作する情報処理装置を提供することを目的とする。

上記目的を達成するために、本発明の情報処理装置は、タスクグループに含まれる第１種のタスクと、そのタスクグループに含まれない第１種のタスクとを制御する第１の制御手段からなり、前記タスクグループに含まれる第１種のタスクである情報処理管理タスクは、第２種のタスクと、その第２種のタスクを制御する第２の制御手段とを備え、前記第１の制御手段は、前記タスクグループに含まれない全ての第１種のタスクと、そのタスクグループに含まれる１つの第１種のタスクとの中の１つの第１種のタスクを実行状態に置くことを繰り返し、前記第１の制御手段は、前記実行状態に置かれた第１種のタスクが前記情報処理管理タスクである場合、前記第２種のタスクであって、前記第２の制御手段によって優先度が最も高いとされた第２種のタスクを実行状態に置き、前記実行状態に置かれた第２種のタスクは、前記第２の制御手段を介して前記タスクグループに含まれない第１種のタスクを生成することを特徴とする。

本発明によれば、親ＯＳの下で動作する子ＯＳの下で動作する子タスクが、親ＯＳの下で動作する親タスクと協調して動作することができる。

以下に、本発明による情報処理装置の実施の形態を、図面を参照して説明する。図１は、本発明の実施形態に係る情報処理装置が適用された移動通信装置の構成を示すブロック図である。

この移動通信装置は、移動通信網（図示せず）を介した通信等を行う装置であり、装置全体の制御を行う制御部１１と、動作状況記憶部１１−１と、基地局（図示せず）との間で電波の送受信を行うアンテナ１２ａと、通信部１２ｂと、送受信部１３と、通話用のスピーカ１４ａと、通話用のマイクロフォン１４ｂと、通話部１４ｃと、表示部１５と、入力装置１６とを備える。

この移動通信装置は、更に、待ち受け処理部２１と、通話処理部２２と、エディタ処理部２３と、ツール制御部３１と、第２の情報処理管理部３２とを備える。動作状況記憶部１１−１には、アプリ階層１１−１ａと、共通アプリ１１−１ｂとが記憶される。アプリ階層１１−１ａは、制御部１１によって生成されたタスクを示す。共通アプリ１１−１ｂとは、ツール制御部３１によって生成されたタスクを示す。

ここで、制御部１１及びツール制御部３１は、装置のタスクの管理を行うＯＳであり、待ち受け処理部２１と、通話処理部２２と、エディタ処理部２３と、ツール制御部３１と、第２の情報処理管理部３２とは、制御部１１の下で動作するタスクである。なお、制御部１１の少なくともＣＰＵリソースをタスクへ割り当てる部分はタスクではないが、制御部１１の一部はタスクとして動作しても良い。

図２は、第２の情報処理管理部３２の詳細な構成を示すブロック図である。第２の情報処理管理部３２は、第２の情報処理管理部３２の各部の制御を行う代行制御部３３と、第２の動作状況記憶部３３−１と、ダミー処理部３４と、ゲーム部３５とからなる。第２の動作状況記憶部３３−１には、第２のアプリ階層３３−１ａが記憶される。

第２のアプリ階層３３−１ａは、代行制御部３３によって管理されるタスクを示す。ここで、代行制御部３３は、第２の情報処理管理部３２内のタスクの管理を行うＯＳであり、ダミー処理部３４と、ゲーム部３５とは、代行制御部３３の下で動作するタスクである。

上記のように構成された、本発明の実施形態に係る情報処理装置の各部の動作を、図１及び図２を参照して説明する。

制御部１１は、装置のタスクにＣＰＵリソースを割り当てる。即ち、実行可能状態にあるタスクの１つにＣＰＵリソースを割り当てて、実行状態に置く。実行状態にあるタスクの他に実行可能状態にあるタスクがある場合、例えば、タイムスライシングによって、実行可能状態にあるタスクを順次実行状態に置く。

また、制御部１１は、実行のために装置外に起因するイベントを要するタスク、及び、実行のために他のタスクからの通知イベントを要するタスクを待ち状態に置く。更に、待ち状態にあるタスクにそのイベントが与えられた場合、そのタスクを実行可能状態に置く。なお、制御部１１は、実行状態に置くタスクに、ＣＰＵリソースと併せて、表示部１５への表示リソースと、入力装置１６からのキー操作リソースとを割り当てる。また、主記憶リソースは、タスクが生成された際に割り当てられ、主記憶リソースの競合は発生しない。

また、制御部１１は、タスクを生成し、優先度を制御し、また、タスクを消滅させる。なお、制御部１１は、第２の情報処理管理部３２内のタスクであるダミー処理部３４と、ゲーム部３５とを制御する際、第２の情報処理管理部３２を介して行う。

制御部１１は、装置の電源投入の際、入力装置１６の所定のキー操作が行われた際、または、制御部１１の下で動作するタスク１からの要求が受信された際、タスク２を生成する。ここで、制御部１１は、リアルタイム型のＯＳであり、制御部１１の下で動作するタスク２を生成する際、新たに生成されたタスク２に、そのタスク２の生成以前に制御部１１によって生成されていたタスクの優先度のいずれよりも高い優先度を付して、実行可能状態に置き、そのタスク２の生成以前に制御部１１によって生成されていたタスクをサスペンド状態に置く。最も優先度が高いタスクが消滅した場合、制御部１１によって生成されているタスク中で、最も優先度が高いタスクを実行可能状態に置く。

なお、制御部１１は、リアルタイム型のＯＳに限るものではない。その場合、タスクの生成を要求したタスク１の優先度は、新たに生成されたタスク２の優先度より低いと限るものではない。新たに生成されたタスク２を実行可能状態に置き、新たに生成されたタスク２の生成以前に制御部１１によって生成されていたタスクをサスペンド状態に置くことによって、同じ動作をさせることができる。

以下の説明では、タスク１がタスク２を制御するとの表現を取ることがある。これは、タスク１からの要求に従って制御部１１、ツール制御部３１、及び代行制御部３３の１つまたは複数がタスクの各種の制御することを意味し、制御部１１、ツール制御部３１、及び代行制御部３３の１つまたは複数を介することを省略して説明を簡明にするためである。

通信部１２ｂは、アンテナ１２ａが受信した高周波信号を送受信部１３へ出力し、また、送受信部１３から出力される高周波信号をアンテナ１２ａより送信する。

送受信部１３は、通信部１２ｂからの高周波信号を増幅、周波数変換及び復調し、それによって得られたディジタル音声信号を通話部１４ｃへ、また、制御信号を制御部１１に送る。更には、通話部１４ｃから出力されるディジタル音声信号、及び制御部１１から出力される制御信号を変調、周波数変換及び増幅し、高周波信号を得て、それを通信部１２ｂに送る。

通話部１４ｃは、送受信部１３から出力されるディジタル音声信号をアナログ音声信号に変換し、それを増幅してスピーカ１４ａに送る。また、マイクロフォン１４ｂから出力されるアナログ音声信号を増幅し、それをディジタル音声信号に変換して送受信部１３に送信する。

表示部１５は、制御部１１に制御されることで、カーソルを含む文字・数字を含む画像データの表示動作を行い、表示されているデータは、入力装置１６からの入力操作や着信信号に応答して制御部１１からの指示を受けることで切換わる。

入力装置１６は、通信相手の電話番号などを指定し、また、トグル式の入力方式によってひらがな文字、アルファベット文字及び記号文字を入力するための数字キーと、カーソル移動キーやスクロールキーを含む複数の機能キーとを含むキーからなる。

そして、入力装置１６のキーが押下されると、そのキーの識別子が制御部１１に通知され、制御部１１の制御に基づいて、その識別子が通知された装置内の各部の処理により、表示部１５に文字として表示されたり、キーの押下及び解放に基づく制御が行われたりする。

待ち受け処理部２１は、装置の電源が投入された際に生成され、所定の待ち受け画面を表示部１５に表示する。ここで、待ち受け画面は、静止画像であっても良く、動画像であっても良い。そして、待ち受け処理部２１は、装置の電源の切断に至るまで消滅しない。

通話処理部２２は、通話を行う処理部であり、入力装置１６の所定のキーが操作された際、及び、アドレス帳（図示せず）に含まれる電話番号が表示され、入力装置１６の所定のキーが操作された際に待ち受け処理部２１の要求によって生成され、通信部１２ｂ、送受信部１３及び通話部１４ｃを生成して、発信処理及び通話処理をさせ、所定の画像を表示部１５に表示する。

また、通話処理部２２は、送受信部１３によって通話着信信号が受信されると制御部１１によって生成され、通信部１２ｂ、送受信部１３及び通話部１４ｃを生成して、着信処理及び通話処理をさせ、所定の画像を表示部１５に表示する。通話中に入力装置１６の所定のキーが操作された際、通話処理部２２は、動作を終了し、タスクは消滅される。

エディタ処理部２３は、文字列の編集を行う処理部である。そして、処理部からの要求に従って、生成され、入力装置１６の文字を示すキーが操作された場合、そのキーによって識別される文字をエディタ処理部２３内に記憶して、表示部１５に表示する。

エディタ処理部２３は、生成を要求した処理部に編集された文字列を通知し、更に、生成を要求した処理部からの要求を受けることによって、また、入力装置１６の所定のキーが操作された場合、動作を終了し、タスクは消滅される。

ツール制御部３１は、制御部１１の下で動作するタスクを生成し、また、そのタスクを消滅させる。ツール制御部３１は、タスクを生成する際、新たに生成されたタスクを実行可能状態、または、待ち状態に置く。しかし、制御部１１によるタスクの生成と異なり、その生成の前に生成されていたタスクの状態を変更しない。

代行制御部３３は、第２の情報処理管理部３２内のタスクを制御する。即ち、制御部１１からの指示に従って、第２の情報処理管理部３２内のタスクを生成し、優先度を制御し、また、タスクを消滅させる。更に、第２の情報処理管理部３２内のタスクの実行を中断し、また、再開する。

以下の説明では、代行制御部３３は、ダミー処理部３４のタスクと、ゲーム部３５のタスクを、最多で１個ずつ生成し、即ち、それぞれを複数個生成することはなく、更に、いずれか一方を実行可能状態に置き、他方は、生成されていない、または、サスペンド状態に置く。ここで、サスペンド状態に置かれたタスクは、他方のタスクの優先度より低い優先度のタスクとして記憶され、管理される。なお、実行可能状態に置かれたタスクは、第２の情報処理管理部３２が制御部１１の制御によって実行状態に置かれることにより、実行状態に置かれる。また、制御部１１の制御によって待ち状態に置かれる。

この状況によって、代行制御部３３は、優先度が高く、実行可能状態または実行状態に置かれたタスクと、優先度が低く、サスペンド状態に置かれたタスクとに関し、お互いの優先度の高低を逆転させ、任意のタスクを実行可能状態に置き、ひいては実行状態に置かせることができる。なお、優先度が高いタスクはイベントを待って、待ち状態に置かれることがある。

ダミー処理部３４は、装置の電源投入に伴って生成され、装置の電源切断に至るまで、終了されることはない。即ち、タスクが消滅されることはない。ダミー処理部３４は、実行状態にある場合、即ち、ゲーム部３５が生成されていない、または、ゲーム部３５より高い優先度が付され、かつ、第２の情報処理管理部３２が制御部１１の制御によって実行状態にある場合、表示部１５への表示リソースが与えられるが、表示部１５への表示を行わない。

この表示を行わないことによって、ダミー処理部３４が実行状態に置かれる前の表示を表示部１５に維持させる。また、ダミー処理部３４は、実行状態にある場合、入力装置１６のキー操作リソースが与えられるが、このキー操作に依存した動作を行わない。

ゲーム部３５は、入力装置１６の所定のキー操作によって、制御部１１から代行制御部３３を介して生成され、実行状態に置かれる。そして、ゲーム部３５内に含まれる複数のゲームの一覧を表示部１５に表示する。表示されたゲームの中で、入力装置１６の所定のキー操作によって選択されたゲームを実行する。ゲーム部３５は、その動作の一環として、所定のイベントを待ち、即ち、待ち状態に置かれる。そして、その所定のイベントが与えられると、実行可能状態に置かれる。

この、待ち状態を経て実行可能状態に戻る一例は、ゲーム部３５がエディタ処理部２３を介した文字入力を行う場合である。更に、ゲーム部３５は、入力装置１６の所定のキー操作によって、動作を終了し、タスクは消滅される。

以下、本実施形態に係る移動通信装置における処理部の制御処理、特に、制御部１１によって制御されるタスクと、代行制御部３３によって制御されるタスクとの協調動作の制御を説明する。

図３は、動作状況記憶部１１−１に記憶されるアプリ階層１１−１ａ及び共通アプリ１１−１ｂならびに第２の動作状況記憶部３３−１に記憶される第２のアプリ階層３３−１ａの第１の例を示す。アプリ階層１１−１ａは、制御部１１によって生成されたタスクが順序付けられたタスクグループからなる。共通アプリ１１−１ｂは、ツール制御部３１によって生成されたタスクからなる。また、第２のアプリ階層３３−１ａは、制御部１１によって代行制御部３３を介して生成されたタスクが順序付けられたタスクグループからなる。

なお、ツール制御部３１及び代行制御部３３は、制御部１１の制御により装置の電源投入と共に生成され、装置の電源切断まで消滅されないタスクであるが、デーモン（Daemon）であり、アプリ階層１１−１ａ、共通アプリ１１−１ｂ、及び第２のアプリ階層３３−１ａのいずれにも記憶されない。なお、ツール制御部３１及び代行制御部３３はデーモンであると限るものではなく、タスクでない、即ち、主記憶装置に常駐するプログラムによっても良い。

図３に示すアプリ階層１１−１ａは、待ち受け処理部２１が生成されていることを示す。また、図３に示す第２のアプリ階層３３−１ａは、ダミー処理部３４が生成されていることを示す。更に、共通アプリ１１−１ｂは、生成されていないことを示す。即ち、これらは、装置は待ち受け状態にあり、ゲーム部３５は動作していないことを示している。

図４は、動作状況記憶部１１−１に記憶されるアプリ階層１１−１ａ及び共通アプリ１１−１ｂならびに第２の動作状況記憶部３３−１に記憶される第２のアプリ階層３３−１ａの第２の例を示す。

図４に示すアプリ階層１１−１ａは、待ち受け処理部２１と、第２の情報処理管理部３２とが生成されていることを示す。また、第２のアプリ階層３３−１ａは、ダミー処理部３４と、ゲーム部３５とが生成されていることを示す。ここで、アプリ階層１１−１ａで、上に記載された処理部ほど後に生成された、優先度が高いタスクを示す。また、第２のアプリ階層３３−１ａで、上に記載された処理部ほど優先度が高いタスクを示す。

アプリ階層１１−１ａにおいて最も優先度が高いことは、実行状態、または、実行可能状態に置かれているタスクであることを意味する。また、第２のアプリ階層３３−１ａにおいて最も優先度が高いことは、実行状態、または、実行可能状態に置かれているタスクであることを意味する。

即ち、図４に示すアプリ階層１１−１ａ及び第２のアプリ階層３３−１ａは、例えば、待ち受け処理部２１の生成の後に第２の情報処理管理部３２が生成され、ゲーム部３５が生成されていることを示す。更に、共通アプリ１１−１ｂは、生成されていないことを示す。これらは、例えば、装置が待ち受け状態にある際に、ゲーム部３５が生成され、動作中である場合の情況を示す。

図５は、動作状況記憶部１１−１に記憶されるアプリ階層１１−１ａ及び共通アプリ１１−１ｂならびに第２の動作状況記憶部３３−１に記憶される第２のアプリ階層３３−１ａの第３の例を示す。

図５に示すアプリ階層１１−１ａは、待ち受け処理部２１と、第２の情報処理管理部３２とが生成されていることを示す。また、共通アプリ１１−１ｂは、エディタ処理部２３が生成されていることを示す。更に、第２のアプリ階層３３−１ａは、ダミー処理部３４と、ゲーム部３５とが生成されていることを示す。

即ち、図５に示すアプリ階層１１−１ａ、共通アプリ１１−１ｂ、及び第２のアプリ階層３３−１ａは、例えば、装置が待ち受け状態にある際に、ゲーム部３５が生成され、そのゲーム部３５によってエディタ処理部２３が生成されている場合の情況を示す。

図６は、動作状況記憶部１１−１に記憶されるアプリ階層１１−１ａ及び共通アプリ１１−１ｂならびに第２の動作状況記憶部３３−１に記憶される第２のアプリ階層３３−１ａの第４の例を示す。

図６に示すアプリ階層１１−１ａは、待ち受け処理部２１と、通話処理部２２とが生成されていることを示す。また、第２のアプリ階層３３−１ａは、ゲーム部３５と、ダミー処理部３４とが生成されていることを示す。更に、共通アプリ１１−１ｂは、生成されていないことを示す。

即ち、図６に示すアプリ階層１１−１ａ、共通アプリ１１−１ｂ、及び第２のアプリ階層３３−１ａは、例えば、装置が待ち受け状態にある際に、ゲーム部３５が生成され、動作中に通話着信があり、ゲーム部３５がサスペンド状態に置かれ、通話処理部２２が生成されている場合の情況を示す。

次に、代行制御部３３によって制御されるタスク（一例としてゲーム部３５。）と、制御部１１によって制御されるタスク（一例としてエディタ処理部２３。）との協調動作を説明する。

まず、制御部１１によるＣＰＵリソース割り当て動作を説明する。制御部１１は、アプリ階層１１−１ａに最も優先度が高いと記憶されているタスクと、共通アプリ１１−１ｂに記憶されている全タスクとを対象に、１つのタスクを選択してＣＰＵリソースを割り当てる。なお、共通アプリ１１−１ｂに記憶されているタスクは、０個の場合、１つの場合、更に、複数の場合がある。

なお、アプリ階層１１−１ａに第２の情報処理管理部３２が最も優先度が高いと記憶されている場合に限り、制御部１１は、第２のアプリ階層３３−１ａに優先度が最も高いと記憶されているタスクと、共通アプリ１１−１ｂに記憶されている全タスクとを対象に、１つのタスクを選択してＣＰＵリソースを割り当てる。

なぜなら、第２のアプリ階層３３−１ａに記憶される処理部は、代行制御部３３によって制御される子タスクに対応する。子タスクは、第２の情報処理管理部３２が実行状態にある場合に限り、ＣＰＵリソースを割り当ての対象とされるからである。

次に、ゲーム部３５と、エディタ処理部２３とが協調して動作する一例として、ゲーム部３５が、エディタ処理部２３を生成して、生成されたエディタ処理部２３を介して文字を入力する動作を説明する。図７は、上記動作におけるゲーム部３５の動作のフローチャートを示す。

ゲーム部３５は、その動作の一環として、例えば、実行中のプログラムの記載に従って、エディタ処理部２３を介した文字入力動作を開始する（ステップＳ３５ａ）。続いて、ゲーム部３５は、エディタ処理部２３を生成して、文字入力させることを代行制御部３３に要求する（ステップＳ３５ｂ）。この要求の後、ゲーム部３５は、エディタ処理部２３によって入力された文字を要する処理を直ちに行うことはできず、エディタ処理部２３による文字入力を待って、長短の相違はあるものの待ち状態に置かれる。

しかし、その文字を要する以外の処理がある場合、例えば、送受信部１３を介して行う対戦型ゲームの相手方の通信装置（図示せず）との通信処理や、表示部１５に表示すべき動画像の表示処理がある場合、ゲーム部３５は、実行可能であり、エディタ処理部２３が実行状態に置かれていない場合、実行状態に置かれて、これらの処理を実行する。

なお、表示部１５に表示すべき動画像の表示処理は、表示部１５の全画面の表示リソースがエディタ処理部２３に割り当てられる場合であっても、ゲーム部３５は実行し、エディタ処理部２３の動作終了、即ち、エディタ処理部２３のタスクの消滅の際、適切な画像を表示部１５に表示させる。また、表示部１５の表示リソースが、マルチウィンドウシステムを介して、ゲーム部３５と、エディタ処理部２３とに割り当てられる場合、ゲーム部３５は、当然上記動画像の表示処理を実行する。

次に、ゲーム部３５は、代行制御部３３からエディタ処理部２３によって入力された文字を受信して（ステップＳ３５ｃ）、文字入力動作を終了して、エディタ処理部２３のタスクを消滅させる（ステップＳ３５ｄ）。ここで、入力された文字の数を問わない。なお、複数回に渡って入力された文字を受信する場合、ゲーム部３５は、ステップＳ３５ｃの文字受信の動作を繰り返す。また、代行制御部３３から入力された文字を受信する方法は、例えば、文字入力の終了をタスク間通信によって、または、共用メモリを介して通知され、入力された文字は、共用メモリを介して受信する。

また、共用メモリへのアクセスは、例えば、実装ＡＰＩ（Application Programming Interface）を介して行なう。実装ＡＰＩを用いることにより、代行制御部３３の動作のタイミングと、ゲーム部３５の動作のタイミングが一致しないことによって文字送受信が正常に行なわれない可能性がない。また、代行制御部３３及びゲーム部３５は、共用メモリの記憶構造を認識せずに文字送受信を行なうことができる。

図８は、ゲーム部３５が、エディタ処理部２３を生成して、生成されたエディタ処理部２３を介して文字を入力する際の、代行制御部３３の動作のフローチャートを示す。代行制御部３３は、ゲーム部３５の要求を受信して文字入力動作を開始する（ステップＳ３３ａ）。この動作開始の前に、動作状況記憶部１１−１に記憶されるアプリ階層１１−１ａ及び共通アプリ１１−１ｂならびに第２の動作状況記憶部３３−１に記憶される第２のアプリ階層３３−１ａは、図４に示す通りである。

続いて、代行制御部３３は、ツール制御部３１に要求して、エディタ処理部２３を生成させる（ステップＳ３３ｂ）。エディタ処理部２３が生成された後、動作状況記憶部１１−１に記憶されるアプリ階層１１−１ａ及び共通アプリ１１−１ｂならびに第２の動作状況記憶部３３−１に記憶される第２のアプリ階層３３−１ａは、図５に示す通りである。

次に、代行制御部３３は、エディタ処理部２３によって入力された文字をエディタ処理部２３から受信して（ステップＳ３３ｃ）、その文字をゲーム部３５に送信して（ステップＳ３３ｄ）、文字入力動作を終了する（ステップＳ３３ｅ）。文字入力動作の終了に伴い、代行制御部３３は、ツール制御部３１に要求して、エディタ処理部２３を消滅させる。なお、複数回に渡って入力された文字を送受信する場合、代行制御部３３は、ステップＳ３３ｃの文字受信の動作及びステップＳ３３ｄの文字送信の動作を繰り返す。

なお、代行制御部３３は、エディタ処理部２３によって入力された文字をゲーム部３５に送信する中継を行なうにあたり、その文字に所定の変形を行なっても良い。その変形の一例は、文字コードの変更である。また、別の一例は、文字の大きさ、書体（フォント）の種類、下線などの文字修飾などの追加、削除、または変更である。これらの変形は、エディタ処理部２３と、ゲーム部３５とが異なる経緯を経て開発されたプログラムを用いるタスクである場合、特に有効である。

次に、ゲーム部３５が、エディタ処理部２３と協調して動作する際に各部の間で行われる通信シーケンスのいくつかの例を制御部１１の制御動作及び代行制御部３３の制御動作を交えて説明する。図９は、ゲーム部３５が、エディタ処理部２３を生成して、エディタ処理部２３を介して文字を入力する際のシーケンスの一例を示し、縦軸は時刻であり、上が遅い時刻、下が早い時刻である。

この例は、図７及び図８を参照して説明した、ゲーム部３５の動作及び代行制御部３３の動作によって、ゲーム部３５がエディタ処理部２３を介して文字を入力する際のシーケンスを示す。

即ち、動作状況記憶部１１−１に記憶されるアプリ階層１１−１ａ及び共通アプリ１１−１ｂならびに第２の動作状況記憶部３３−１に記憶される第２のアプリ階層３３−１ａは、図４に示す通りであって、ゲーム部３５が実行状態に置かれ、エディタ処理部２３が生成されていない際に、ゲーム部３５がエディタ処理部２３の生成を代行制御部３３に要求する（ステップＴ１１）。

この要求に対して、代行制御部３３は、エディタ処理部２３の生成を要求する（ステップＴ１２）。なお、代行制御部３３がエディタ処理部２３を制御する際、全てツール制御部３１を介するが、ツール制御部３１を介することを省略して、簡明な説明とする。エディタ処理部２３が生成された後、動作状況記憶部１１−１に記憶されるアプリ階層１１−１ａ及び共通アプリ１１−１ｂならびに第２の動作状況記憶部３３−１に記憶される第２のアプリ階層３３−１ａは、図５に示す通りである。

即ち、ゲーム部３５は、上述したように実行状態または待ち状態に置かれる。また、エディタ処理部２３は、実行状態または待ち状態に置かれる。即ち、入力装置１６のキー操作がされている場合、実行状態に置かれ、その操作がされていない場合、待ち状態に置かれる。このように、ゲーム部３５と、エディタ処理部２３とが交互に実行状態に置かれることによって、ＣＰＵリソースを有効に用いた動作が行われる。

エディタ処理部２３による文字入力が終了すると、エディタ処理部２３は、入力された文字列と共に、文字入力の終了を代行制御部３３に通知して（ステップＴ１３）、自タスクは消滅される。

代行制御部３３は、エディタ処理部２３から通知された文字列をゲーム部３５に送信する（ステップＴ１４）。この時、エディタ処理部２３のタスクは消滅しているので、ゲーム部３５のタスクは実行状態に置かれ、上記文字列を受信することができる。そして、引き続き、ゲーム部３５のタスクは実行状態に置かれる。

なお、以上の説明は、文字列をエディタ処理部２３からゲーム部３５へ１回送信するものとしたが、これに限るものではない。任意長の文字列、例えば、１文字の文字列毎に送信するとしても良い。この場合、ステップＴ１３の通信の中で、文字列の通知のみと、ステップＴ１４の文字列の送信とを任意回数繰り返した後、ステップＴ１３の通信の中で、文字入力の終了の通知が行なわれるとすれば良い。

図１０は、ゲーム部３５が、エディタ処理部２３を生成して、エディタ処理部２３を介して文字を入力中に、通話着信があった結果、ゲーム部３５の動作が中断される、即ち、ゲーム部３５がサスペンド状態に置かれる際のシーケンスの一例を示し、縦軸は時刻であり、上が遅い時刻、下が早い時刻である。

この例は、ゲーム部３５の要求を契機としてエディタ処理部２３が文字入力中に、制御部１１の制御によって、ゲーム部３５をバックグラウンド状態とする、即ち、第２の情報処理管理部３２及びゲーム部３５によって、制御部１１によるアプリ階層１１−１ａを用いたタスク管理、表示部１５への表示制御、及び、入力装置１６のキー操作による入力制御に影響が及ぶことのないように制御する際のシーケンスを示す。

即ち、動作状況記憶部１１−１に記憶されるアプリ階層１１−１ａ及び共通アプリ１１−１ｂならびに第２の動作状況記憶部３３−１に記憶される第２のアプリ階層３３−１ａは、図５に示す通りであり、ゲーム部３５及びエディタ処理部２３は、それぞれ実行状態または待ち状態に置かれる際、制御部１１に、例えば通話着信の割り込みが発生した（ステップＴ２１）。

制御部１１は、第２の情報処理管理部３２の下の動作、即ち、ゲーム部３５の動作より通話処理部２２の動作を優先し、代行制御部３３にゲーム部３５をバックグラウンド状態とするように指示する（ステップＴ２２）。

代行制御部３３は、エディタ処理部２３に動作終了、即ち、タスクの消滅を指示する（ステップＴ２３）。この指示に応じて、エディタ処理部２３は、入力された文字列と、終了とを代行制御部３３に通知して（ステップＴ２４）、自タスクは消滅される。このステップＴ２４の通信は、図９のステップＴ１３の通信と同じである。

代行制御部３３は、通知された文字列をゲーム部３５に送信する（ステップＴ２５）。このステップＴ２５の通信は、図９のステップＴ１４の通信と同じである。続いて、代行制御部３３は、ゲーム部３５をサスペンド状態に置き（ステップＴ２６）、制御部１１に、ゲーム部３５をバックグラウンド状態とする動作を完了したことを通知する（ステップＴ２７）。制御部１１は、上記通知に応じて、通話処理部２２を生成して、通話着信割り込みへの対応をさせる（ステップＴ２８）。

ステップＴ２４で説明したエディタ処理部２３のタスクの消滅によって、動作状況記憶部１１−１に記憶される共通アプリ１１−１ｂのエディタ処理部２３は、消去される。また、ステップＴ２６で説明したゲーム部３５がサスペンド状態に置かれることに伴い、第２の動作状況記憶部３３−１に記憶される第２のアプリ階層３３−１ａで、ダミー処理部３４が、ゲーム部３５より高い優先度で記憶される。

更に、ステップＴ２６で説明したゲーム部３５がサスペンド状態に置かれることに伴い、動作状況記憶部１１−１に記憶されるアプリ階層１１−１ａの第２の情報処理管理部３２は、消去される。また、ステップＴ２８で、通話処理部２２が生成されることにより、アプリ階層１１−１ａに通話処理部２２が最も高い優先度として追加される。

これらの結果、動作状況記憶部１１−１に記憶されるアプリ階層１１−１ａ及び共通アプリ１１−１ｂならびに第２の動作状況記憶部３３−１に記憶される第２のアプリ階層３３−１ａは、図６に示す通りとなる。ここで、ゲーム部３５なる第２のアプリ階層３３−１ａは記憶されているものの、ダミー処理部３４が、ゲーム部３５より高い優先度で記憶されるため、ゲーム部３５は、実行状態に置かれることはなく、また、ゲーム部３５によって表示部１５への表示への影響、及び、入力装置１６のキー操作による入力への影響が生じることはない。

なお、以上の説明で、ゲーム部３５をバックグラウンド状態とすることにより、動作状況記憶部１１−１に記憶されるアプリ階層１１−１ａの第２の情報処理管理部３２は、消去されるとしたが、これに限るものではない。通話処理部２２の優先度より低い優先度として、記憶され続けるとしても良い。

また、エディタ処理部２３のタスクは消滅され、動作状況記憶部１１−１に記憶される共通アプリ１１−１ｂのエディタ処理部２３は、消去されるとしたが、これに限るものではない。エディタ処理部２３のタスクは消滅されず、動作状況記憶部１１−１に記憶される共通アプリ１１−１ｂのエディタ処理部２３は、消去されないとしても良い。この場合、制御部１１は、エディタ処理部２３をサスペンド状態に置き、実行状態に置かないことにより、エディタ処理部２３による通話処理部２２への影響を防ぐ。

このように、タスクを消滅させず、動作状況記憶部１１−１に記憶されるアプリ階層１１−１ａ及び共通アプリ１１−１ｂに変更を加えないことによれば、後述する、通話が終了し、ゲーム部３５及びエディタ処理部２３の動作を再開させる際の処理の減少の効果が得られる。

いずれにしても、制御部１１は、通話動作を優先して、ＣＰＵリソース、表示部１５への表示リソース、及び入力装置１６からのキー操作リソースを通話処理部２２へ割り当て、エディタ処理部２３をサスペンド状態に置くので、ゲーム部３５及びエディタ処理部２３の動作は中断される。

この後、通話が終了した、即ち、通話処理部２２の動作が終了し、通話処理部２２のタスクが消滅した場合、制御部１１は、入力装置１６の所定のキー操作に従って、または、そのキー操作を待たずに、第２の情報処理管理部３２を生成し、代行制御部３３を介してゲーム部３５の優先度をダミー処理部３４の優先度より高くさる。そして、代行制御部３３は、エディタ処理部２３の生成を要求する（図９のステップＴ１２を参照のこと。）ことによって、ゲーム部３５の動作及びエディタ処理部２３の動作が再開される（図示せず）。

図１１は、ゲーム部３５が、エディタ処理部２３を生成して、エディタ処理部２３を介して文字を入力中に、制御部１１からの指示により、ゲーム部３５が動作を終了、即ちタスクを消滅させる際のシーケンスの一例を示し、縦軸は時刻であり、上が遅い時刻、下が早い時刻である。

この例は、例えば、エディタ処理部２３が文字入力中に、入力装置１６の所定のキー操作を契機とした制御部１１の制御によって、ゲーム部３５の動作が終了される際のシーケンスを示す。

即ち、動作状況記憶部１１−１に記憶されるアプリ階層１１−１ａ及び共通アプリ１１−１ｂならびに第２の動作状況記憶部３３−１に記憶される第２のアプリ階層３３−１ａは、図５に示す通りであり、ゲーム部３５及びエディタ処理部２３は、それぞれ実行状態または待ち状態に置かれている際、制御部１１に、例えば入力装置１６のキー操作が入力された。そして、そのキー操作は、ゲーム部３５の動作終了、即ち、タスクの消滅を指示するものである（ステップＴ３１）。

制御部１１は、代行制御部３３にゲーム部３５の動作終了、即ち、タスクの消滅を指示する（ステップＴ３２）。この指示に応じて、代行制御部３３は、エディタ処理部２３に動作終了、即ち、タスクの消滅を指示する（ステップＴ３３）。この指示の際、代行制御部３３は、入力された文字の通知を指示しない。エディタ処理部２３は、動作終了、即ち、タスクの消滅を代行制御部３３に通知して（ステップＴ３４）、自タスクは消滅される。

続いて、代行制御部３３は、ゲーム部３５に動作終了、即ち、タスクの消滅を指示し（ステップＴ３５）、制御部１１に、ゲーム部３５の動作終了、即ち、タスクの消滅を通知する（ステップＴ３６）。ステップＴ３５の動作終了、即ち、タスクの消滅の指示に従い、ゲーム部３５は動作を終了し、自タスクは消滅される。

ステップＴ３４で説明したエディタ処理部２３のタスクの消滅によって、動作状況記憶部１１−１に記憶される共通アプリ１１−１ｂのエディタ処理部２３は、消去される。また、ステップＴ３５で説明したゲーム部３５のタスクの消滅によって、第２の動作状況記憶部３３−１に記憶される第２のアプリ階層３３−１ａのゲーム部３５は、消去される。更に、動作状況記憶部１１−１に記憶されるアプリ階層１１−１ａの第２の情報処理管理部３２は、制御部１１によってステップＴ３６で消去される。

これらの結果、動作状況記憶部１１−１に記憶されるアプリ階層１１−１ａ及び共通アプリ１１−１ｂならびに第２の動作状況記憶部３３−１に記憶される第２のアプリ階層３３−１ａは、図３に示す通りとなる。

以上の説明では、動作状況記憶部１１−１に記憶される共通アプリ１１−１ｂは、エディタ処理部２３であるとしたが、これに限るものではない。例えば、音楽再生部（図示せず）であっても良い。これによれば、ゲーム部３５は、動作を続けつつ、ゲームの進行に応じた音声を音楽再生部に再生させ、再生された音声を再生音声発生用の第２のスピーカ（図示せず）から発生させることができる。

また、第２の動作状況記憶部３３−１に記憶される第２のアプリ階層３３−１ａは、ダミー処理部３４及びゲーム部３５であるとしたが、これに限るものではない。任意の処理部であって良い。特に、本発明は、装置の使用者との対話型で動作する処理部を代行制御部３３の下で動作させることに好適である。即ち、リアルタイム型のＯＳである制御部１１の制御に拘らない動作をさせることに好適である。

以上の説明は、本発明を移動通信装置に適用した形態を例にとって行ったが、これに限るものではない。本発明は、あらゆる情報処理装置に適用することが当然に可能である。本発明は以上の構成に限定されるものではなく、種々の変形が可能である。

本発明の実施形態に係る移動通信装置の構成を示すブロック図。 本発明の実施形態に係る第２の情報処理管理部の詳細な構成を示すブロック図。 本発明の実施形態に係る動作状況記憶部に記憶されるアプリ階層及び共通アプリならびに第２の動作状況記憶部に記憶される第２のアプリ階層の第１の例を示す図。 本発明の実施形態に係る動作状況記憶部に記憶されるアプリ階層及び共通アプリならびに第２の動作状況記憶部に記憶される第２のアプリ階層の第２の例を示す図。 本発明の実施形態に係る動作状況記憶部に記憶されるアプリ階層及び共通アプリならびに第２の動作状況記憶部に記憶される第２のアプリ階層の第３の例を示す図。 本発明の実施形態に係る動作状況記憶部に記憶されるアプリ階層及び共通アプリならびに第２の動作状況記憶部に記憶される第２のアプリ階層の第４の例を示す図。 本発明の実施形態に係るゲーム部がエディタ処理部を介して文字を入力する動作のフローチャート。 本発明の実施形態に係る代行制御部がゲーム部からの要求に応じてエディタ処理部からの文字入力を中継する動作のフローチャート。 本発明の実施形態に係る制御部によって制御されるタスクと、代行制御部によって制御されるタスクとの協調動作の通信シーケンス（第１の例）。 本発明の実施形態に係る制御部によって制御されるタスクと、代行制御部によって制御されるタスクとの協調動作の通信シーケンス（第２の例）。 本発明の実施形態に係る制御部によって制御されるタスクと、代行制御部によって制御されるタスクとの協調動作の通信シーケンス（第３の例）。

符号の説明

１１ 制御部
１１−１ 動作状況記憶部
１１−１ａ アプリ階層
１１−１ｂ 共通アプリ
１５ 表示部
１６ 入力装置
２１ 待ち受け処理部
２２ 通話処理部
２３ エディタ処理部
３１ ツール制御部
３２ 第２の情報処理管理部
３３ 代行制御部
３３−１ 第２の動作状況記憶部
３３−１ａ 第２のアプリ階層
３４ ダミー処理部
３５ ゲーム部

Claims (6)

1. タスクグループに含まれる第１種のタスクと、そのタスクグループに含まれない第１種のタスクとを制御する第１の制御手段からなり、
   前記タスクグループに含まれる第１種のタスクである情報処理管理タスクは、第２種のタスクと、その第２種のタスクを制御する第２の制御手段とを備え、
   前記第１の制御手段は、前記タスクグループに含まれない全ての第１種のタスクと、そのタスクグループに含まれる１つの第１種のタスクとの中の１つの第１種のタスクを実行状態に置くことを繰り返し、
   前記第１の制御手段は、前記実行状態に置かれた第１種のタスクが前記情報処理管理タスクである場合、前記第２種のタスクであって、前記第２の制御手段によって優先度が最も高いとされた第２種のタスクを実行状態に置き、
   前記実行状態に置かれた第２種のタスクは、前記第２の制御手段を介して前記タスクグループに含まれない第１種のタスクを生成する
   ことを特徴とする情報処理装置。
2. タスクグループに含まれる第１種のタスクを生成する第１のタスク生成手段と、
   前記タスクグループに含まれない第１種のタスクを生成する第２のタスク生成手段と、
   前記タスクグループに含まれるか否かを問わず、第１種のタスクの状態を制御する第１の制御手段とからなり、
   前記第１のタスク生成手段によって生成される第１種のタスクである情報処理管理タスクは、第２種のタスクと、その第２種のタスクを制御する第２の制御手段とを備え、
   前記第１の制御手段は、前記タスクグループに含まれない全ての第１種のタスクと、そのタスクグループに含まれる１つの第１種のタスクとの中の１つの第１種のタスクを実行状態に置くことを繰り返し、
   前記第１の制御手段は、前記実行状態に置かれた第１種のタスクが前記情報処理管理タスクである場合、前記第２種のタスクであって、前記第２の制御手段によって優先度が最も高いとされた第２種のタスクを実行状態に置き、
   前記実行状態に置かれた第２種のタスクは、前記第２の制御手段を介して、前記第２のタスク生成手段に前記タスクグループに含まれない第１種のタスクを生成させる
   ことを特徴とする情報処理装置。
3. 前記第１の制御手段は、前記タスクグループに含まれる第１種のタスクの中で、最も近い過去に生成されたタスクを実行状態に置く
   ことを特徴とする請求項１または請求項２に記載の情報処理装置。
4. 前記第１の制御手段は、前記実行状態に置かれた第２種のタスク、または、その第２種のタスクに起因して生成された前記第１種のタスクを実行状態に置く
   ことを特徴とする請求項１または請求項２に記載の情報処理装置。
5. 前記第１の制御手段は、前記情報処理管理タスクが備える第２種のタスクの消滅を前記第２の制御手段に指示し、
   前記第２の制御手段は、前記第１の制御手段の指示に従って前記第２種のタスクを消滅させると共に、その第２種のタスクに起因して生成された前記第１種のタスクを消滅させる
   ことを特徴とする請求項１または請求項２に記載の情報処理装置。
6. 前記第１の制御手段は、前記情報処理管理タスクが備える第２種のタスクの動作の中断を前記第２の制御手段に指示し、
   前記第２の制御手段は、前記第１の制御手段の指示に従って前記第２種のタスクの動作を中断させると共に、その第２種のタスクに起因して生成された前記第１種のタスクを消滅させる
   ことを特徴とする請求項１または請求項２に記載の情報処理装置。

Images