JP3961301B2 - デジタル機器、タスク管理方法及びそのプログラム - Google Patents
デジタル機器、タスク管理方法及びそのプログラム Download PDFInfo
- Publication number
- JP3961301B2 JP3961301B2 JP2002011585A JP2002011585A JP3961301B2 JP 3961301 B2 JP3961301 B2 JP 3961301B2 JP 2002011585 A JP2002011585 A JP 2002011585A JP 2002011585 A JP2002011585 A JP 2002011585A JP 3961301 B2 JP3961301 B2 JP 3961301B2
- Authority
- JP
- Japan
- Prior art keywords
- task
- function
- forced termination
- attribute information
- executed
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、デジタル機器、タスク管理方法及びそのプログラムに関し、詳しくは、マルチタスクオペレーションシステムにてタスクの強制終了を管理するデジタル機器、タスク管理方法及びそのプログラムに関する。
【０００２】
【従来の技術】
従来では、例えばＳＴＢ（set-top box：ケーブルTVのコントロールボックス等、家庭用テレビに接続して追加機能を提供するデバイスの一般名称）や携帯電話等、主にソフトウェアを用いて様々な機能を実現する製品の場合、当該ソフトウェアは上記製品に、ＯＳ（オペレーションシステム）及び各機能を実現するプログラムを予め格納した、いわゆる組込ＯＳという形で提供される。上記組込ＯＳを備えた製品を提供するメーカーは、当該組込ＯＳの各機能の動作を十分に検証し、様々な動作状態におけるデバッグを行うことができるため、安定動作する信頼性の高い製品を提供することが可能である。
【０００３】
又、近年では、製品によってはライフタイムが短く、又新機能の追加・変更サイクルも短くなっている。このため、当該機能追加・変更に柔軟に対応するべく、上記組込ＯＳに替えて汎用ＯＳを用いるケースが増えている。さらにネットワークの発達（多様化）やＪａｖａ（Ｒ）に代表されるネットワークに適した多機能なインタプリタ言語の普及により、機能追加・変更に伴うプログラムのダウンロードが容易になってきている点も、上記組込ＯＳの汎用ＯＳ化を促進する要因となっている。
【０００４】
以下に上記汎用ＯＳを用いた際の一般的なタスクの実行形態を説明する。尚、上述したような汎用ＯＳは通常マルチタスクとして動作するため、該マルチタスクを含めた説明を行う。
【０００５】
マルチタスクＯＳでは、図５（ａ）に示すように、ＯＳ５０１上で例えば複数のプロセス１、２（５０２、５０３）が実行される。又、上記プロセス１（５０２）の管理下にて、さらに例えばスレッド１（５０４）、スレッド２（５０５）、上記プロセス２（５０３）の管理下では例えばスレッド４（５０６）という様に、複数のスレッドが実行される。尚、例えば上記プロセス１（５０２）は、実行時に上記ＯＳ５０１よりメモリ空間やＩ／Ｏ（Input／Output）空間等のリソース（資源）が割り当てられ、当該リソースは上記スレッド１（５０４）及びスレッド２（５０５）にて共有される。
【０００６】
ここで、上記プロセスとは、プログラムの一実行単位を指す。即ち、上記リソース等を独立して所有すると共に、切り替え時（マルチタスクＯＳによるプロセスの切り替え時）においてＣＰＵレジスタの内容をすべて保存し、次に制御を切り替えるプロセスのためのレジスタ値をロードすることにより各実行単位の独立を保障している単位である。又、上記スレッドもプログラムの一実行単位であり、同一プロセス内でのマルチタスク処理を可能にしたものである。尚、上記プロセスやスレッドという単位は、ＯＳにより扱いが異なるが本質はプログラムの一実行単位であり、関数の集合ということができる。このため以降、適宜プロセスとスレッドを使い分けて説明するが、双方ともタスクであり、プログラムの一実行単位である。さらに、アプリケーションも広義のタスクである。
【０００７】
次に、上述したタスク（プロセス及びスレッド）の構造について簡単に説明する。上記タスクは一般的に、関数の集合により構成されており、例えば所定の関数が別の関数に引数を渡し、該別の関数が当該引数を用いて計算した戻り値を再度上記所定の関数に渡し、上記所定の関数は該戻り値を用いて続く処理を実行する、といった手順で実行される。例えば図６を用いて説明すると、タスク（スレッド１）６０１は、ユーザーが開発したアプリケーション関数ａ（６０２）をメインルーチン（メイン関数）とし、当該メインルーチンの処理の過程で、アプリケーション関数ｂ（６０３）を呼び出している。当該アプリケーション関数ｂ（６０３）は、さらに必要に応じてシステムライブラリ関数として提供されるシステムライブラリ関数ａ（６０４）を読み出し、さらに当該システムライブラリ関数ａ（６０４）はアプリケーション関数ｃ（６０５）を呼び出している。上記処理の過程で呼び出された関数は、それぞれ呼び出し時に与えられた引数を用いて算出した戻り値を返し、それに応じて呼び出した関数は続く処理を実行する。
【０００８】
以上のように、タスクを構成する複数の関数がそれぞれ処理されることにより、所定のタスク（メインルーチン）の処理が完了する。ここに、上記アプリケーション関数とは、例えば当該タスクをプログラミングした者が必要に応じて作成した関数であり、システムライブラリ関数とは、予め提供されている基本的な関数等である。尚、上記アプリケーション関数及びシステムライブラリ関数共、例えば数十から数千のステップ（命令）にて構成されている。
【０００９】
さて、上述した各スレッド１（５０４）及びスレッド２（５０５）は、図５（ｂ）に示すように、上記ＯＳ５０１にて順次割り当てられた処理時間において実行される。即ち、ＯＳ５０１は、タイマー処理にてスレッド１とスレッド２（ここではスレッド３の処理は考慮しないものとする）それぞれに処理時間５０７〜５１０を与える。ここでは、例えば、まず処理時間５０７がＯＳ５０１により割り当てられた時にスレッド１が実行され、続いて割り当てられる処理時間５０８には、スレッド２が実行される。このように、ＯＳが処理時間を複数のスレッド（タスク）に順次与えることにより、複数の処理を並列に実行することが可能となり、即ちマルチタスクＯＳを実現可能となる。尚、上記スレッド（タスク）の切り替えをディスパッチという。
【００１０】
以上に説明した汎用ＯＳを用い、さらにネットワークの発達（多様化）や多機能なインタプリタ言語の普及等により、様々な製品への新たな機能追加等を柔軟に行うことが可能になっている。
【００１１】
尚、新たな機能追加等によるシステムの変更後には、当該新機能を組み合わせた様々な使用形態が考えられる。このような状態では、通常、リソースが大量に消費されてしまい、後に実行されるプログラムにリソースを割り当てることができず、このため新たなプログラムを起動できなくなる。このような状態を回避するために、従来では、上記タスク（プロセスやスレッド）は、例えば他のタスクの処理を終了させる命令、即ち強制終了命令を発行することが可能である。当該強制終了命令により、異なるタスクのリソースを開放し、新たなプログラムを起動することが可能となる。上記リソースの不足は、ある程度機能が限定されている製品（例えば上記ＳＴＢ、携帯電話等）においては、リソースを十分に備えていないことが多く、汎用のパーソナルコンピュータとは異なり起こりやすいといえる。
【００１２】
但し、むやみに他のタスクの処理を強制終了可能とすると、当該他のタスクがデータの書き込み等の重要な処理を行いっている最中に終了してしまうといったことが考えられる。このため、特開平１０−６９３９２号公報に記載の技術では、所定の処理区間に対して「強制終了禁止区間（アボート禁止区間）」を設定可能とすることにより当該処理区間における強制終了の禁止を可能としている。
【００１３】
以下図７を用いて、タスクの処理を終了させる命令の発行の仕組み及び、強制終了禁止区間の設定について説明する。
【００１４】
図７において、スレッド１（６０１）、及びスレッド２（７０１）がＯＳ上にて独立したタスクとして起動しているものとする。尚、上記スレッド１（６０１）及びスレッド２（７０１）は、上述したマルチタスク処理にて、随時切り替えられながら処理を実行しており、例えばスレッド１（６０１）に割り当てられた処理時間が終了すると、次にスレッド２（７０１）が動作する。
【００１５】
ここで、スレッド１（６０１）におけるシステムライブラリ関数ａ（６０４）の実行時７０２に処理が上記スレッド２（７０１）に切り替えられた場合、スレッド２（７０１）は例えばアプリケーション関数ｄ（７０３）から処理を実行する。
【００１６】
続いてスレッド２（７０１）におけるアプリケーション関数ｅ（７０４）の処理の所定のポイント７０５にて、スレッド２（７０１）が、スレッド１（６０１）に強制終了命令を発行し、アプリケーション関数ｄ（７０３）の所定のポイント７０６にてスレッド１（６０１）に処理が切り替わったと仮定する。この場合には、例えばスレッド１（６０１）におけるシステムライブラリ関数ａ（６０４）実行時に強制終了命令を受け付けることになり、当該システムライブラリ関数ａ（６０４）実行中（上記実行時７０２直後）にスレッド１（６０１）が例えばＯＳにより強制終了されることになる。尚、上記各関数（６０２〜６０５）による処理が強制終了されると、全体の処理に大きな影響を与える場合等には以下のような強制終了禁止区間が設けられる。
【００１７】
即ち、スレッド１（６０１）におけるアプリケーション関数ａ（６０２）の所定のポイント７０７にて、当該アプリケーション関数ａ（６０２）は強制終了禁止命令７０８を発行する。当該強制終了禁止命令は、例えばＯＳにおける所定の処理にて認識され、記憶される。次に、上記同様、所定のポイント７０５にてスレッド２（７０１）より強制終了命令が発行され、処理がスレッド１（６０１）に切り替えられると、例えばＯＳが、上記強制終了禁止命令が発行されているか否かを判定し、ここでは強制終了禁止命令が発行されているため強制終了せずに通常の処理を継続する。
【００１８】
続いてアプリケーション関数ａ（６０２）が所定のポイント７０９にて、強制終了許可命令７１０を発行すると、当該強制終了許可命令は例えばＯＳにおける所定の処理にて認識され、強制終了禁止命令７０８発行時から強制終了許可命令７１０の発行時までの区間、即ち、強制終了禁止区間が終了する。
【００１９】
上記強制終了禁止区間が終了すると、例えばＯＳは、上記所定のポイント７０５にてスレッド２（７０１）により発行された強制終了命令を反映し、アプリケーション関数ａ（６０２）における所定のポイント７０９にてスレッド１（６０１）の強制終了を行う。
【００２０】
以上により、タスク間（スレッド間）にて強制終了命令を発行することで、例えば他のタスクが使用しているリソースを解放させることが可能となる。又、システムに影響を与えるような重要な処理（例えば共有リソースに対する操作）を行っている場合には、他のタスクによる強制終了を禁止することで、当該重要な処理の正常終了を可能としている。
【００２１】
【発明が解決しようとする課題】
しかしながら、上記従来技術を用いた場合には以下のような問題が生じる。即ち、上述したように、ネットワークを用いて例えば新機能を備えたプログラム（ソフトウェア）を汎用ＯＳにダウンロードして実行した場合には、組込ＯＳと異なり、各機器により異なる複数のプログラムが実行されている等、ユーザー環境が多岐に渡るため正常動作しないことが考えられる。このような場合には、上記プログラムを強制終了させる必要があるが、上述した強制終了禁止区間が設定されてしまうと、強制終了することができないといった問題が起こる。
【００２２】
又、特にインターネットを介して第三者が作成したプログラムをダウンロードする場合には、当該プログラムは必ずしも善意の基に作成されたものとは限らないため、当該プログラムを実行するには危険が伴う。
【００２３】
即ち、例えば図７に示したスレッド１（６０１）が悪意を持ったプログラムであった場合、具体的には、例えばアプリケーション関数ｂ（６０３）内にて無限ループし、かつ同様のアプリケーション関数ｂ（６０３）を持ったスレッドを生成するプログラムであった場合が考えられる。このような場合には、上記悪意を持ったプログラムを実行してしまうと、スレッドが増殖し、さらに当該スレッドに対する強制終了命令も、上述した強制終了禁止区間の設定により無効になってしまう。こうなると、上記プログラムを実行した端末（製品）は、ＯＳの制御が効かなくなり、最終的には電源のオフ等が必要になってしまう。
【００２４】
このような現象は、汎用ＯＳを用いて特定の機能を提供する製品に限らず、一般的な汎用ＯＳであるＷｉｎｄｏｗｓ（Ｒ）やＵＮＩＸ（Ｒ）でも考えられることである。
【００２５】
そこで本発明は、上記従来の事情に基づいて提案されたものであって、システムに障害をもたらす可能性のあるタスク、例えば共有リソースの操作中には、当該タスクを強制終了させないタスク管理方法を提供することを目的とする。
【００２６】
【課題を解決するための手段】
本発明のタスク管理装置は、
アプリケーション関数とシステムライブラリ関数とにより構成され一実行単位として管理される第１のタスクと、上記第１のタスク１を強制終了させる第２のタスクとをプログラム実行手段にて複数並列に実行するオペレーティングシステムを備えたタスク管理装置において、
上記第１のタスク内において実行される関数が強制終了禁止命令を発行すると、上記第１のタスクが強制終了禁止区間にあることを設定するタスク状態設定手段と、
上記第１のタスク内において実行される関数が切り替わる度に、切り替わった後の関数の属性が、予めオペレーションシステムにより提供されている上記システムライブラリ関数か又はそれ以外の上記アプリケーション関数かを示す属性情報を記憶するタスク属性情報記憶手段と、
上記第２のタスクが発行した上記第１のタスクに対する強制終了命令を上記第１のタスクが受信した際に、上記第１のタスクが上記強制終了禁止区間か否かを判定するタスク実行判定手段と、
上記第１のタスクの状態が強制終了禁止区間と判定した場合、上記タスク属性情報記憶手段に基づいて上記第１のタスクにおいて実行中の関数の属性情報を判定するカレント関数実行判定手段と、
上記第１のタスクの属性情報がアプリケーション関数である場合には当該第１のタスクを強制終了し、システムライブラリ関数である場合には当該タスクを強制終了させないプログラム実行手段とを具備することを特徴とする。
【００２７】
以上の構成では、関数の呼び出し時、及び処理が戻った時に、タスク内において実行される関数が切り替わる度に、タスク属性情報記憶手段には、現在実行されているタスクの種類が常時格納され、このため、カレント関数判定手段は、タスク属性情報記憶手段に格納されている、現在のタスクにて実行されている関数の属性情報を参照・判定可能となる。従って、強制終了禁止区間であっても、所定の関数を実行している場合には、強制終了可能とし、一方でシステムに障害をもたらす可能性のある別の関数の実行時には、当該タスクを強制終了させないといった強制終了についての柔軟な制御が可能である。
【００２８】
又、上記関数の属性に関する情報を実行されている関数の名称とし、カレント関数判定手段を構成するタスク属性認識手段が、上記名称に基づいて上記実行されている関数の属性を判定する構成もある。
【００２９】
この構成では、言語によっては、当該言語の仕様により関数の属性を判断し、直接上記タスク属性認識手段に通知することが困難な場合があるが、このような場合でも実行している関数の属性を確認することができる。
【００３０】
尚、上記一実行単位であるタスクは、プロセスである場合や、スレッドである場合がある。
【００３１】
さらに、タスク属性情報記憶手段が、タスクを構成する関数の属性に代えてタスク自体の属性を格納することにより、タスクの属性に基づいた強制終了の制御を可能とすることができる。
【００３２】
尚、プログラム及びプログラム記録媒体は、コンピュータにて上記各手段の機能を実現する構成である。
【００３３】
【発明の実施の形態】
以下、添付図面を参照して、本発明の実施の形態につき説明し、本発明の理解に供する。尚、以下の実施の形態は、本発明を具体化した一例であって、本発明の技術的範囲を限定する性格のものではない。
【００３４】
〔実施の形態１〕
本発明の実施の形態１におけるデジタル機器１００について図１、図２、図４を参照し説明する。ここに、上記デジタル機器１００とは、例えばＳＴＢ、携帯電話、家電、パーソナルコンピュータ等であって、外部からのアプリケーション（プログラム）を付加（追加）等することにより、所定機能の追加・変更・修正が可能である機器を示す。
【００３５】
まず、上記デジタル機器１００は、例えばインターネット等のネットワーク１０１を介して所定のアプリケーション（プログラム：１０２）を取得し、記憶手段１０３に記憶する。ここに、当該アプリケーション１０２は、例えば上記デジタル機器１００に新たな機能を追加するためのインタプリタ言語にて記述されたプログラムであり、実行時には、図２に示すタスク２０１を生成して処理を実行するものとする。尚、上記アプリケーション１０２の取得は、必ずしもネットワーク１０１を介する必要は無く、メモリーカード等の記憶媒体を介して得るものであってもよい。
【００３６】
次に、上記アプリケーション１０２は、実行時には例えばローダー等により、ＲＡＭ（Random Access Memory）等の一時記憶手段１０５に読み出される（図４：Ｓ４０１）。尚、上記アプリケーション１０２は、図２のタスク２０１に示すように、アプリケーション関数ａ（２０３）、アプリケーション関数ｂ（２０４）、アプリケーション関数ｃ（２０６）より構成される。さらに、上記アプリケーション１０２は、実行時にシステムライブラリ関数である、システムライブラリ関数ａ（２０５）を呼び出すため、例えば上記ローダーにて読み出される際に、同時に上記記憶手段１０３に格納されているシステムライブラリ１０４から、システムライブラリ関数１０７が上記一時記憶手段１０５に読み出される。
【００３７】
続いて、上記アプリケーション１０２のメイン関数であるアプリケーション関数ａ（２０３）がプログラム実行手段１０８に読み出されると、ＯＳ１３０は、アプリケーション関数ａ（２０３）に対応するタスク２０１を生成すると共に、当該タスクにリソースを割り当てる（図４：Ｓ４０２）。以後上記アプリケーション１０２は、タスク２０１として管理される。
【００３８】
さらに、上記タスクの生成時に上記ＯＳ１３０は、後述するタスク状態記憶手段１１０、強制終了情報記憶手段１１４、及びタスク属性情報記憶手段１１７に当該タスク２０１に対応するタスクフラグ１１８を作成し、作成したフラグエリアに例えば“０”を格納する（図４：Ｓ４０３）。又、例えばプログラム実行手段は、タスク属性認識手段１１６に対して、現在タスク２０１にて実行されている関数がアプリケーション関数である旨を通知する（図４：Ｓ４０４）。当該タスク２０１にて実行されている関数がアプリケーション関数である旨の通知を受信すると、上記タスク属性認識手段１１６は、タスク属性情報記憶手段１１７のタスク２０１に対応するタスクフラグ１１８に、例えばアプリケーション関数が実行されていることを示す“１”を格納する。ここで、例えばＯＳより提供されるアプリケーションによりタスクが作成された場合、通常、メイン関数はシステムライブラリ関数であるため、上記タスク属性情報記憶手段１１７のタスク２０１に対応するタスクフラグ１１８には“０”が格納される。
【００３９】
以後、上記タスク２０１のアプリケーション関数ａ（２０３）の先頭のコマンド（命令）より順次実行される。又、必要に応じてアプリケーション関数ｂ（２０４）等の他の関数がプログラム実行手段１０８に読み出される。尚、上記コマンドが例えば１つ実行されるに際して、当該タスク（ここではタスク２０１）に強制終了命令が送信されているか否かをタスク実行判断手段１１１に問い合わせるが詳細は後述する。
【００４０】
以上が、新規アプリケーションが実行された際に行われる処理（図４における初期処理４００）である。尚、理解に供するために、プログラム実行手段１０８では、アプリケーション関数ｄ（２０８）及びアプリケーション関数ｅ（２０９）により構成されるタスク２０２も実行されるものとする。
【００４１】
次に、タスク内において実行されている関数が、強制終了禁止命令を発行した際の、タスク状態設定手段１０９の処理の詳細について説明する。
【００４２】
例えば、アプリケーション関数ａ（２０３）の処理中の所定のポイント２１３にて、タスク２０１からＯＳ１３０に対して強制終了禁止命令２１４が送信されると、当該強制終了禁止命令２１４はタスク状態設定手段１０９にて受信される。上記強制終了禁止命令２１４を受信したタスク状態設定手段１０９は、タスク状態記憶手段１１０内の、タスク２０１に対応するフラグエリア１２１に例えば“１”を格納する。当該フラグエリア１２１に格納される“１”は、タスク２０１が現在強制終了禁止区間にある（強制終了禁止である）ということを意味するものである。
【００４３】
又、例えばアプリケーション関数ａ（２０３）の処理中の所定のポイント２１５にて、タスク２０１からＯＳ１３０に対して強制終了許可命令２１６が送信されると、当該強制終了許可命令２１６は上記タスク状態設定手段１０９にて受信される。上記強制終了許可命令２１６を受信したタスク状態設定手段１０９は、タスク状態記憶手段１１０内の、タスク２０１に対応するフラグエリア１２１に例えば“０”を格納する。当該フラグエリア１２１に格納される“０”は、現在実行されているタスク２０１が、現在強制終了禁止区間に無い（強制終了禁止ではない）ということを意味するものである。
【００４４】
以上のように、タスク状態記憶手段１１０には、各タスクの状態が強制終了禁止（フラグ“１”）であるか、強制終了可能（フラグ“０”）であるかの情報が常時格納される。以後、例えばタスク実行判断手段１１１よりタスク状態記憶手段１１０内の各タスクフラグの内容について問い合わせがあると、タスク状態設定手段１０９は当該タスクフラグに格納されている値を読み出し、上記タスク実行判断手段１１１に返信する。
【００４５】
次に、タスク内において実行されている関数が変わる際の、タスク属性認識手段１１６の処理の詳細について説明する。
【００４６】
アプリケーション関数ａ（２０３）が例えばアプリケーション関数ｂ（２０４）を呼び出し、当該タスク２０１における処理がアプリケーション関数ｂ（２０４）に切り替わった場合、上記タスク２０１はタスク属性認識手段１１６に対して、現在タスク２０１にて実行されている関数が、アプリケーション関数である旨を通知する。ここで、上記タスク属性認識手段１１６は、タスク２０１に対応するフラグエリア１１９に“１”を格納する。
【００４７】
又、アプリケーション関数ｂ（２０４）がシステムライブラリ関数ａ（２０５）を呼び出した際にも、タスク２０１は上記タスク属性認識手段１１６に通知を行うが、この場合、タスク２０１にて実行される関数はシステムライブラリ関数であるため、上記フラグエリア１１９には“０”を格納する。尚、上記同様、システムライブラリ関数ａ（２０５）がアプリケーション関数ｃ（２０６）を呼び出した際には、上記フラグエリア１１９には“１”が格納される。
【００４８】
尚、アプリケーション関数ｃ（２０６）の処理が終了し、システムライブラリ関数ａ（２０５）に処理が戻った場合にも、上記呼び出した際と同様に、以後実行される関数（処理が戻った後の関数：ここでは“０”）に対応するフラグ“０”又は“１”がフラグエリア１１９に格納される。
【００４９】
以上のように、関数の呼び出し時、及び処理が戻った時に、タスクがタスク属性認識手段に以後実行される関数の種類を通知することで、タスク属性情報記憶手段には、現在実行されているタスクの種類が常時格納されることになる。以後、例えばタスク実行判断手段１１１よりタスク属性情報記憶手段１１７内の各タスクフラグの内容について問い合わせがあると、タスク属性認識手段１１６は当該タスクフラグに格納されている値を読み出し、上記タスク実行判断手段１１１に返信する。
【００５０】
さて、現在上記プログラム実行手段１０８においては、タスク２０１及びタスク２０２が実行されていることは上述したとおりである。ここで、タスク２０２は、上記タスク２０１に対して強制終了命令２１１を発行するタスクであるものとする。上記強制終了命令２１１が発行されるタイミング（ポイント）は、ＯＳ１３０によるタスクの切り替えのタイミングによって異なるため、各タイミングでの詳細な処理は後述するものとし、ここでは、上記強制終了命令２１１が発行された際の、強制終了設定手段１１３の処理の詳細について説明する。
【００５１】
まず、所定のポイント（例えば図２に示したポイント２０７）にて、タスク２０１からタスク２０２に処理が切り替わったものと仮定する。当該タスクの切り替えは、従来技術にて説明したものである。
【００５２】
ここで、タスク２０２がタスク２０１に対して強制終了命令２１１を発行した場合、具体的には、例えばアプリケーション関数ｄ（２０８）にて呼び出されたアプリケーション関数ｅ（２０９）が、所定のポイント２１０にて発行した強制終了命令２１１は、強制終了設定手段１１３にて受信される。当該強制終了設定手段１１３は、上記強制終了命令２１１を受信すると、強制終了情報記憶手段１１４の、タスク２０１に対応するフラグエリア１２０に“１”を格納する。該フラグエリア１２０に格納される“１”は、フラグエリア１２０に対応するタスク２０１が強制終了命令を受けた状態であることを意味する。以後、例えばタスク実行判断手段１１１より強制終了情報記憶手段１１４内の各タスクフラグの内容について問い合わせがあると、強制終了設定手段１１３は当該タスクフラグに格納されている値を読み出し、上記タスク実行判断手段１１１に返信する。
【００５３】
以上のように、例えば他のタスクからの強制終了命令は、強制終了設定手段１１３を介して強制終了情報記憶手段１１４内の、該当するタスク（終了命令を受けるタスク）のフラグにて示される。
【００５４】
以上がタスク状態設定手段１０９、タスク属性認識手段１１６、及び強制終了設定手段１１３における各処理である。
【００５５】
次に、上述したタスク状態設定手段１０９、タスク属性認識手段１１６、及び強制終了設定手段１１３の各処理を踏まえた上で、新規アプリケーションが実行された後に行われる処理の詳細について説明する。
【００５６】
図４に示した初期処理４００を完了した後、プログラム実行手段１０８は、上記タスク２０１のアプリケーション関数ａ（２０３）の先頭のコマンド（命令）を順次実行する（図４：Ｓ４０５）。ここで、上記プログラム実行手段１０８は、コマンドが例えば１つ実行されるに際して、当該タスク（ここではタスク２０１）に強制終了命令が送信されているか否かを、例えばＯＳ１３０の機能として提供されているタスク実行判断手段１１１に問い合わせる。上記タスク実行判断手段１１１は、上記問い合わせを受け取ると、上記強制終了設定手段１１３に対して強制終了情報記憶手段１１４のタスク２０１フラグ（１２０）の内容を問い合わせる。尚、当該タスクフラグの内容は上述したとおりである。
【００５７】
ここで、タスク２０１フラグ（１２０）が“１”ではないと上記強制終了設定手段１１３より返信があった場合、上記タスク２０１は強制終了命令を発行されていないことを示し、上記タスク実行判定手段１１１はプログラム実行手段１０８に対しその旨を通知することで、当該プログラム実行手段１０８は次のコマンドを実行する（図４：Ｓ４０６Ｎｏ→Ｓ４０５）。尚、次のコマンドが例えばアプリケーション関数ｂ（２０３）を呼び出すコマンドである場合等には、タスク属性情報記憶手段１１７のタスク２０１フラグ（１１９）の書き換えを随時行うのは上述したとおりである。
【００５８】
又、タスク２０１フラグ（１２０）が“１”であると上記強制終了設定手段１１３より返信があった場合、上記タスク２０１は強制終了命令を発行されていることを示し、さらに上記タスク実行判断手段１１１は、タスク状態設定手段１０９に対してタスク状態記憶手段１１０のタスク２０１フラグ（１２１）の内容を問い合わせる（図４：Ｓ４０６Ｙｅｓ→Ｓ４０７）。
【００５９】
ここで、タスク２０１フラグ（１２１）が“１”ではないと上記タスク状態設定手段１０９より返信があった場合、上記タスク２０１は強制終了禁止区間でない、即ち、当該タスク２０１を終了してもシステム全体に影響を及ぼさない（共有リソースに対して操作を行っていない）ことを表している。従って、上記タスク実行判定手段１１１はプログラム実行手段１０８に対しその旨を通知することで、当該プログラム実行手段１０８は、実行している関数（例えばアプリケーション関数ｃ（２０６））及び当該関数を呼び出した関数（例えばアプリケーション関数ａ（２０３）、アプリケーション関数ｂ（２０４）、システムライブラリ関数ａ（２０５））をすべて終了し、タスク２０１を終了する（図４：Ｓ４０７Ｎｏ→Ｓ４０８→Ｅｎｄ）。
【００６０】
又、タスク２０１フラグ（１２１）が“１”であると上記タスク状態設定手段１０９より返信があった場合、上記タスク２０１は強制終了禁止区間であり、即ち、当該タスク２０１を終了するとシステム全体に影響を及ぼす可能性がある（共有リソースに対して操作を行っている等）ことを表している。この場合にはさらに、上記タスク実行判断手段１１１を構成するカレント関数実行判定手段１１２が、タスク属性認識手段１１６に対して、タスク属性情報記憶手段１１７のタスク２０１フラグ（１１９）の内容を問い合わせる（図４：Ｓ４０７Ｙｅｓ→Ｓ４０９）。
【００６１】
ここで、タスク２０１フラグ（１１９）が“１”ではない（“０”である）と上記タスク属性認識手段１１６より返信があった場合、上記タスク２０１は現在システムライブラリ関数を実行していることを意味し、即ち、当該システムライブラリ関数を終了するとシステム全体に影響を及ぼす可能性がある（共有リソースに対して操作を行っている等）ため、当該システムライブラリ関数の実行を強制終了させること無く、次のコマンドの処理に移る（図４：Ｓ４０９Ｎｏ→Ｓ４０５）。
【００６２】
又、タスク２０１フラグ（１１９）が“１”であると上記タスク属性認識手段１１６より返信があった場合、上記タスク２０１は現在アプリケーション関数を実行していることを意味し、当該アプリケーション関数を終了してもシステム全体に影響を及ぼす可能性が無い（低い）ため、当該実行している関数を終了する（図４：Ｓ４０９Ｙｅｓ→Ｓ４１０）。尚、当該実行している関数がメイン関数であった場合には、強制終了するとシステム全体に影響を及ぼす可能性があるためタスク２０１を終了する（図４：Ｓ４１０→Ｓ４０５→Ｅｎｄ）。
【００６３】
以上のように、本実施の形態においては、強制終了情報記憶手段に格納されている強制終了情報（強制終了命令受信の有無）と、タスク状態記憶手段に格納されているタスク状態（強制終了禁止区間であるか否か）に加えて、タスク属性情報記憶手段に格納されている、現在のタスクにて実行されている関数の属性情報（アプリケーション関数か、システムライブラリ関数か）を参照・判定している。従って、強制終了禁止区間であっても、アプリケーション関数を実行している場合には、強制終了（当該アプリケーション関数の中断）を可能とし、一方でシステムに障害をもたらす可能性のあるシステムライブラリ関数の実行時には、当該タスクを強制終了させないといった強制終了についての柔軟な制御が可能である。
【００６４】
続いて、図３、図４を用いて、強制終了命令を受けた各ポイントによって異なる処理の詳細を説明する。尚、当該各処理は、上記図４のフローチャートを場合分けして表すものであって、上記フローチャートと同一内容である。
【００６５】
まず、強制終了命令をアプリケーション関数ａの強制終了禁止区間設定前後に受けた場合（強制終了命令３０１、３０９）、アプリケーション関数ａを終了し、即ちタスク２０１を終了する（図４：Ｓ４０７Ｎｏ→Ｓ４０８）。
【００６６】
強制終了命令をアプリケーション関数ａ実行時の強制終了禁止区間設定後に受けた場合（強制終了命令３０２、３０８）、アプリケーション関数ａを終了し、即ちタスク２０１を終了する（図４：Ｓ４０７Ｙｅｓ→Ｓ４０９→Ｓ４１０→Ｓ４０５→Ｅｎｄ）。
【００６７】
強制終了命令をアプリケーション関数ｂ実行時に受けた場合（強制終了命令３０３、３０７）、アプリケーション関数ｂを終了し、アプリケーション関数ａに処理が戻るが、アプリケーション関数ａも直ちに終了することになり、即ちタスク２０１を終了する（図４：Ｓ４０７Ｙｅｓ→Ｓ４０９Ｙｅｓ→Ｓ４１０→Ｓ４０５を２回繰り返してＥｎｄへ）。
【００６８】
強制終了命令をシステムライブラリ関数ａ実行時に受けた場合（強制終了命令３０４、（強制終了命令３０６を含む））、当該システムライブラリ関数ａの実行を終了せずに、アプリケーション関数ｃを呼び出す。ここで、当該アプリケーション関数ｃは直ちに終了するため（後述する強制終了命令３０５のケース）再度ポイント３２０よりポイント３２１までシステムライブラリ関数ａを実行し、アプリケーション関数ｂに処理を戻す。続く当該アプリケーション関数ｂ及びアプリケーション関数ａは直ちに終了し、即ちタスク２０１が終了する（図４：Ｓ４０７Ｙｅｓ→Ｓ４０９Ｎｏ→Ｓ４０５→Ｓ４０６Ｙｅｓ→Ｓ４０７Ｙｅｓ→Ｓ４０９Ｙｅｓ→Ｓ４１０（アプリケーション関数ｃ終了）→Ｓ４０５→・・・→４０９Ｎｏ→Ｓ４０５・・・（システムライブラリ関数ａ終了後）→Ｓ４０９Ｙｅｓ→Ｓ４１０（アプリケーション関数ｂ終了）→Ｓ４０５→・・・→Ｓ４１０（アプリケーション関数ａ終了）→Ｅｎｄへ）。
【００６９】
強制終了命令をアプリケーション関数ｃ実行時に受けた場合（強制終了命令３０５）、アプリケーション関数ｃを終了し、システムライブラリ関数ａのポイント３２０に処理が戻り、ポイント３２１まで処理が実行された後、アプリケーション関数ｂ、アプリケーション関数ａに処理が戻ると共に直ちに処理が終了し、即ちタスク２０１が終了する（図４：Ｓ４０７Ｙｅｓ→Ｓ４０９Ｙｅｓ→Ｓ４１０（アプリケーション関数ｃ終了）→Ｓ４０５→・・・→Ｓ４０９Ｎｏ→Ｓ４０５→・・・→４０９Ｎｏ→Ｓ４０５・・・（システムライブラリ関数ａ終了後）→Ｓ４０９Ｙｅｓ→Ｓ４１０（アプリケーション関数ｂ終了）→Ｓ４０５→・・・→Ｓ４１０（アプリケーション関数ａ終了）→Ｅｎｄへ）。
【００７０】
以上が本実施の形態１における処理である。但し、本実施の形態１において、強制終了禁止区間を設定可能である場合の処理について説明したが、必ずしも強制終了禁止区間の判定は必要ではない。即ち、強制終了禁止区間であるか否かの判定をすることなく、現在実行されている関数の属性情報のみに基づいて強制終了の可否を判定してもよい。この場合には、図４に示したＳ４０７及びＳ４０８の処理を除くのみでよい。
【００７１】
又、上記関数の属性として、アプリケーション関数とシステムライブラリ関数を例にあげたが、特に上記２つに限定する必要は無く、使用する言語によってさらに異なった関数の場合分けが可能である場合には、当該異なる関数の属性の情報を判断基準として加えてもよい。
【００７２】
〔実施の形態２〕
次に、実施の形態２では、図１を用いてタスク属性記憶手段のタスクフラグに情報を格納する際の処理について説明する。
【００７３】
上記実施の形態１では、プログラム実行手段１０８が現在実行している関数の属性（アプリケーション関数、システムライブラリ関数）を、直接タスク属性認識手段１１６に通知することにより、タスク属性情報記憶手段１１７の各タスクフラグに当該属性を格納していた。
【００７４】
本実施の形態２では、プログラム実行手段１０８は、現在実行している関数が変更になった場合、当該変更になった関数名（これから実行する関数の名称）を上記タスク属性認識手段１１６に送信する。当該タスク属性認識手段１１６は、上記関数名を受信すると、一時記憶手段１０５に格納されているアプリケーション関数１０６やシステムライブラリ関数１０７を参照することで、当該関数がアプリケーション関数かシステムライブラリ関数かを判断する。上記関数の属性を判断したタスク属性認識手段１１６は、当該関数の種類を該当するタスクフラグに格納する。
【００７５】
以上により、直接プログラム実行手段より関数属性をタスク属性認識手段１１６に送信できない場合であっても、タスク属性情報記憶手段は、該当するタスクフラグに現在実行されている関数の属性を格納することが可能になる。
【００７６】
ところで、上記実施の形態１、及び実施の形態２においては、強制終了を実行する判断の基準に、タスク内で現在実行されている関数の属性を用いている。しかしながら、上記判断の基準を必ずしも関数の属性のみに限定する必要は無い。即ち、マルチタスクＯＳでは、ＯＳの機能の一部を独立したタスクとして実行することが可能であり、これをシステムタスク（システムプロセス、システムスレッド等）と呼ぶ。又、これに対して、ユーザーが起動したタスクがアプリケーションタスク（ユーザープロセス、アプリケーションスレッド等）である。
【００７７】
上記システムタスクとアプリケーションタスクは、タスク属性ということが可能であり、当該２つのタスク属性を比較した場合には以下のようなことが言える。
【００７８】
即ち、上記システムタスクは、ＯＳの機能として提供されているために信頼性（安全性）が高く、一方上記アプリケーションタスクは悪意を持った処理を行う可能性があり、上記システムタスクに比較して信頼性が低い。さらに、上記システムタスクは強制終了されるとシステムに障害をもたらす可能性が高いが、上記アプリケーションタスクは当該タスクがシステムライブラリ関数を利用しているものであったとしても、一般的に強制終了された場合の影響は当該アプリケーションタスク内で完結するものである。
【００７９】
従って、以上のことを考慮すると、上記判断の基準を関数の属性ではなく、タスクの属性で判断することができるといえる。即ち、上記タスク属性情報記憶手段が記憶するフラグエリア（タスクフラグ）に、関数の属性ではなくタスクの属性を格納するのである。当該格納する処理は、タスクが起動した時の上記初期処理時に、プログラム実行手段がタスク属性認識手段に対し一回だけ行うのみでよい。格納する値は、例えばシステムタスクの場合には“０”であり、アプリケーションタスクの場合には“１”である。以後、タスク属性情報記憶手段内の該当するタスクフラグのチェックは同様である。
【００８０】
以上のように、関数の属性に替えてタスクの属性を管理し、当該タスクに対する強制終了の処理の実行を判断することで、強制終了についての柔軟な制御が可能である。
【００８１】
【発明の効果】
以上のように、本発明によれば、タスク内において実行される関数が切り替わる度に、タスク属性情報記憶手段には、現在実行されているタスクの種類が常時格納される構成としている。このため、カレント関数判定手段は、タスク属性情報記憶手段に格納されている、現在のタスクにて実行されている関数の属性情報を参照・判定可能となり、従って、強制終了禁止区間であっても、所定の関数を実行している場合には、強制終了可能とし、一方でシステムに障害をもたらす可能性のある別の関数の実行時には、当該タスクを強制終了させないといった強制終了についての柔軟な制御が可能である。
【００８２】
又、タスク属性情報記憶手段が、関数の属性に代えてタスクの属性を格納することにより、タスクの属性に基づいた強制終了の制御が可能である。
【図面の簡単な説明】
【図１】本発明に係るデジタル機器における概略機能ブロック図。
【図２】本発明に係るタスク間にわたる強制終了命令発行時のイメージ図。
【図３】各関数実行時における強制終了命令受信のポイントを示す図。
【図４】タスク実行時の強制終了命令処理に関するフローチャート。
【図５】従来技術におけるプロセス、スレッド及びＯＳのイメージを示す図。
【図６】タスク内の関数構造の一例を示す図。
【図７】従来技術におけるタスク間にわたる強制終了命令発行時のイメージ図。
【符号の説明】
１００ デジタル機器
１０１ ネットワーク
１０２ アプリケーション
１０３ 記憶手段
１０４ システムライブラリ
１０５ 一時記憶手段
１０６ アプリケーション関数
１０７ システムライブラリ関数
１０８ プログラム実行手段
１０９ タスク状態設定手段
１１０ タスク状態記憶手段
１１１ タスク実行判断手段
１１２ カレント関数実行判定手段
１１３ 強制終了設定手段
１１４ 強制終了情報記憶手段
１１６ タスク属性認識手段
１１７ タスク属性情報記憶手段
１１８ タスクフラグ
１１９、１２０、１２１ フラグエリア
１３０ ＯＳ（ＯＳ機能）
【発明の属する技術分野】
本発明は、デジタル機器、タスク管理方法及びそのプログラムに関し、詳しくは、マルチタスクオペレーションシステムにてタスクの強制終了を管理するデジタル機器、タスク管理方法及びそのプログラムに関する。
【０００２】
【従来の技術】
従来では、例えばＳＴＢ（set-top box：ケーブルTVのコントロールボックス等、家庭用テレビに接続して追加機能を提供するデバイスの一般名称）や携帯電話等、主にソフトウェアを用いて様々な機能を実現する製品の場合、当該ソフトウェアは上記製品に、ＯＳ（オペレーションシステム）及び各機能を実現するプログラムを予め格納した、いわゆる組込ＯＳという形で提供される。上記組込ＯＳを備えた製品を提供するメーカーは、当該組込ＯＳの各機能の動作を十分に検証し、様々な動作状態におけるデバッグを行うことができるため、安定動作する信頼性の高い製品を提供することが可能である。
【０００３】
又、近年では、製品によってはライフタイムが短く、又新機能の追加・変更サイクルも短くなっている。このため、当該機能追加・変更に柔軟に対応するべく、上記組込ＯＳに替えて汎用ＯＳを用いるケースが増えている。さらにネットワークの発達（多様化）やＪａｖａ（Ｒ）に代表されるネットワークに適した多機能なインタプリタ言語の普及により、機能追加・変更に伴うプログラムのダウンロードが容易になってきている点も、上記組込ＯＳの汎用ＯＳ化を促進する要因となっている。
【０００４】
以下に上記汎用ＯＳを用いた際の一般的なタスクの実行形態を説明する。尚、上述したような汎用ＯＳは通常マルチタスクとして動作するため、該マルチタスクを含めた説明を行う。
【０００５】
マルチタスクＯＳでは、図５（ａ）に示すように、ＯＳ５０１上で例えば複数のプロセス１、２（５０２、５０３）が実行される。又、上記プロセス１（５０２）の管理下にて、さらに例えばスレッド１（５０４）、スレッド２（５０５）、上記プロセス２（５０３）の管理下では例えばスレッド４（５０６）という様に、複数のスレッドが実行される。尚、例えば上記プロセス１（５０２）は、実行時に上記ＯＳ５０１よりメモリ空間やＩ／Ｏ（Input／Output）空間等のリソース（資源）が割り当てられ、当該リソースは上記スレッド１（５０４）及びスレッド２（５０５）にて共有される。
【０００６】
ここで、上記プロセスとは、プログラムの一実行単位を指す。即ち、上記リソース等を独立して所有すると共に、切り替え時（マルチタスクＯＳによるプロセスの切り替え時）においてＣＰＵレジスタの内容をすべて保存し、次に制御を切り替えるプロセスのためのレジスタ値をロードすることにより各実行単位の独立を保障している単位である。又、上記スレッドもプログラムの一実行単位であり、同一プロセス内でのマルチタスク処理を可能にしたものである。尚、上記プロセスやスレッドという単位は、ＯＳにより扱いが異なるが本質はプログラムの一実行単位であり、関数の集合ということができる。このため以降、適宜プロセスとスレッドを使い分けて説明するが、双方ともタスクであり、プログラムの一実行単位である。さらに、アプリケーションも広義のタスクである。
【０００７】
次に、上述したタスク（プロセス及びスレッド）の構造について簡単に説明する。上記タスクは一般的に、関数の集合により構成されており、例えば所定の関数が別の関数に引数を渡し、該別の関数が当該引数を用いて計算した戻り値を再度上記所定の関数に渡し、上記所定の関数は該戻り値を用いて続く処理を実行する、といった手順で実行される。例えば図６を用いて説明すると、タスク（スレッド１）６０１は、ユーザーが開発したアプリケーション関数ａ（６０２）をメインルーチン（メイン関数）とし、当該メインルーチンの処理の過程で、アプリケーション関数ｂ（６０３）を呼び出している。当該アプリケーション関数ｂ（６０３）は、さらに必要に応じてシステムライブラリ関数として提供されるシステムライブラリ関数ａ（６０４）を読み出し、さらに当該システムライブラリ関数ａ（６０４）はアプリケーション関数ｃ（６０５）を呼び出している。上記処理の過程で呼び出された関数は、それぞれ呼び出し時に与えられた引数を用いて算出した戻り値を返し、それに応じて呼び出した関数は続く処理を実行する。
【０００８】
以上のように、タスクを構成する複数の関数がそれぞれ処理されることにより、所定のタスク（メインルーチン）の処理が完了する。ここに、上記アプリケーション関数とは、例えば当該タスクをプログラミングした者が必要に応じて作成した関数であり、システムライブラリ関数とは、予め提供されている基本的な関数等である。尚、上記アプリケーション関数及びシステムライブラリ関数共、例えば数十から数千のステップ（命令）にて構成されている。
【０００９】
さて、上述した各スレッド１（５０４）及びスレッド２（５０５）は、図５（ｂ）に示すように、上記ＯＳ５０１にて順次割り当てられた処理時間において実行される。即ち、ＯＳ５０１は、タイマー処理にてスレッド１とスレッド２（ここではスレッド３の処理は考慮しないものとする）それぞれに処理時間５０７〜５１０を与える。ここでは、例えば、まず処理時間５０７がＯＳ５０１により割り当てられた時にスレッド１が実行され、続いて割り当てられる処理時間５０８には、スレッド２が実行される。このように、ＯＳが処理時間を複数のスレッド（タスク）に順次与えることにより、複数の処理を並列に実行することが可能となり、即ちマルチタスクＯＳを実現可能となる。尚、上記スレッド（タスク）の切り替えをディスパッチという。
【００１０】
以上に説明した汎用ＯＳを用い、さらにネットワークの発達（多様化）や多機能なインタプリタ言語の普及等により、様々な製品への新たな機能追加等を柔軟に行うことが可能になっている。
【００１１】
尚、新たな機能追加等によるシステムの変更後には、当該新機能を組み合わせた様々な使用形態が考えられる。このような状態では、通常、リソースが大量に消費されてしまい、後に実行されるプログラムにリソースを割り当てることができず、このため新たなプログラムを起動できなくなる。このような状態を回避するために、従来では、上記タスク（プロセスやスレッド）は、例えば他のタスクの処理を終了させる命令、即ち強制終了命令を発行することが可能である。当該強制終了命令により、異なるタスクのリソースを開放し、新たなプログラムを起動することが可能となる。上記リソースの不足は、ある程度機能が限定されている製品（例えば上記ＳＴＢ、携帯電話等）においては、リソースを十分に備えていないことが多く、汎用のパーソナルコンピュータとは異なり起こりやすいといえる。
【００１２】
但し、むやみに他のタスクの処理を強制終了可能とすると、当該他のタスクがデータの書き込み等の重要な処理を行いっている最中に終了してしまうといったことが考えられる。このため、特開平１０−６９３９２号公報に記載の技術では、所定の処理区間に対して「強制終了禁止区間（アボート禁止区間）」を設定可能とすることにより当該処理区間における強制終了の禁止を可能としている。
【００１３】
以下図７を用いて、タスクの処理を終了させる命令の発行の仕組み及び、強制終了禁止区間の設定について説明する。
【００１４】
図７において、スレッド１（６０１）、及びスレッド２（７０１）がＯＳ上にて独立したタスクとして起動しているものとする。尚、上記スレッド１（６０１）及びスレッド２（７０１）は、上述したマルチタスク処理にて、随時切り替えられながら処理を実行しており、例えばスレッド１（６０１）に割り当てられた処理時間が終了すると、次にスレッド２（７０１）が動作する。
【００１５】
ここで、スレッド１（６０１）におけるシステムライブラリ関数ａ（６０４）の実行時７０２に処理が上記スレッド２（７０１）に切り替えられた場合、スレッド２（７０１）は例えばアプリケーション関数ｄ（７０３）から処理を実行する。
【００１６】
続いてスレッド２（７０１）におけるアプリケーション関数ｅ（７０４）の処理の所定のポイント７０５にて、スレッド２（７０１）が、スレッド１（６０１）に強制終了命令を発行し、アプリケーション関数ｄ（７０３）の所定のポイント７０６にてスレッド１（６０１）に処理が切り替わったと仮定する。この場合には、例えばスレッド１（６０１）におけるシステムライブラリ関数ａ（６０４）実行時に強制終了命令を受け付けることになり、当該システムライブラリ関数ａ（６０４）実行中（上記実行時７０２直後）にスレッド１（６０１）が例えばＯＳにより強制終了されることになる。尚、上記各関数（６０２〜６０５）による処理が強制終了されると、全体の処理に大きな影響を与える場合等には以下のような強制終了禁止区間が設けられる。
【００１７】
即ち、スレッド１（６０１）におけるアプリケーション関数ａ（６０２）の所定のポイント７０７にて、当該アプリケーション関数ａ（６０２）は強制終了禁止命令７０８を発行する。当該強制終了禁止命令は、例えばＯＳにおける所定の処理にて認識され、記憶される。次に、上記同様、所定のポイント７０５にてスレッド２（７０１）より強制終了命令が発行され、処理がスレッド１（６０１）に切り替えられると、例えばＯＳが、上記強制終了禁止命令が発行されているか否かを判定し、ここでは強制終了禁止命令が発行されているため強制終了せずに通常の処理を継続する。
【００１８】
続いてアプリケーション関数ａ（６０２）が所定のポイント７０９にて、強制終了許可命令７１０を発行すると、当該強制終了許可命令は例えばＯＳにおける所定の処理にて認識され、強制終了禁止命令７０８発行時から強制終了許可命令７１０の発行時までの区間、即ち、強制終了禁止区間が終了する。
【００１９】
上記強制終了禁止区間が終了すると、例えばＯＳは、上記所定のポイント７０５にてスレッド２（７０１）により発行された強制終了命令を反映し、アプリケーション関数ａ（６０２）における所定のポイント７０９にてスレッド１（６０１）の強制終了を行う。
【００２０】
以上により、タスク間（スレッド間）にて強制終了命令を発行することで、例えば他のタスクが使用しているリソースを解放させることが可能となる。又、システムに影響を与えるような重要な処理（例えば共有リソースに対する操作）を行っている場合には、他のタスクによる強制終了を禁止することで、当該重要な処理の正常終了を可能としている。
【００２１】
【発明が解決しようとする課題】
しかしながら、上記従来技術を用いた場合には以下のような問題が生じる。即ち、上述したように、ネットワークを用いて例えば新機能を備えたプログラム（ソフトウェア）を汎用ＯＳにダウンロードして実行した場合には、組込ＯＳと異なり、各機器により異なる複数のプログラムが実行されている等、ユーザー環境が多岐に渡るため正常動作しないことが考えられる。このような場合には、上記プログラムを強制終了させる必要があるが、上述した強制終了禁止区間が設定されてしまうと、強制終了することができないといった問題が起こる。
【００２２】
又、特にインターネットを介して第三者が作成したプログラムをダウンロードする場合には、当該プログラムは必ずしも善意の基に作成されたものとは限らないため、当該プログラムを実行するには危険が伴う。
【００２３】
即ち、例えば図７に示したスレッド１（６０１）が悪意を持ったプログラムであった場合、具体的には、例えばアプリケーション関数ｂ（６０３）内にて無限ループし、かつ同様のアプリケーション関数ｂ（６０３）を持ったスレッドを生成するプログラムであった場合が考えられる。このような場合には、上記悪意を持ったプログラムを実行してしまうと、スレッドが増殖し、さらに当該スレッドに対する強制終了命令も、上述した強制終了禁止区間の設定により無効になってしまう。こうなると、上記プログラムを実行した端末（製品）は、ＯＳの制御が効かなくなり、最終的には電源のオフ等が必要になってしまう。
【００２４】
このような現象は、汎用ＯＳを用いて特定の機能を提供する製品に限らず、一般的な汎用ＯＳであるＷｉｎｄｏｗｓ（Ｒ）やＵＮＩＸ（Ｒ）でも考えられることである。
【００２５】
そこで本発明は、上記従来の事情に基づいて提案されたものであって、システムに障害をもたらす可能性のあるタスク、例えば共有リソースの操作中には、当該タスクを強制終了させないタスク管理方法を提供することを目的とする。
【００２６】
【課題を解決するための手段】
本発明のタスク管理装置は、
アプリケーション関数とシステムライブラリ関数とにより構成され一実行単位として管理される第１のタスクと、上記第１のタスク１を強制終了させる第２のタスクとをプログラム実行手段にて複数並列に実行するオペレーティングシステムを備えたタスク管理装置において、
上記第１のタスク内において実行される関数が強制終了禁止命令を発行すると、上記第１のタスクが強制終了禁止区間にあることを設定するタスク状態設定手段と、
上記第１のタスク内において実行される関数が切り替わる度に、切り替わった後の関数の属性が、予めオペレーションシステムにより提供されている上記システムライブラリ関数か又はそれ以外の上記アプリケーション関数かを示す属性情報を記憶するタスク属性情報記憶手段と、
上記第２のタスクが発行した上記第１のタスクに対する強制終了命令を上記第１のタスクが受信した際に、上記第１のタスクが上記強制終了禁止区間か否かを判定するタスク実行判定手段と、
上記第１のタスクの状態が強制終了禁止区間と判定した場合、上記タスク属性情報記憶手段に基づいて上記第１のタスクにおいて実行中の関数の属性情報を判定するカレント関数実行判定手段と、
上記第１のタスクの属性情報がアプリケーション関数である場合には当該第１のタスクを強制終了し、システムライブラリ関数である場合には当該タスクを強制終了させないプログラム実行手段とを具備することを特徴とする。
【００２７】
以上の構成では、関数の呼び出し時、及び処理が戻った時に、タスク内において実行される関数が切り替わる度に、タスク属性情報記憶手段には、現在実行されているタスクの種類が常時格納され、このため、カレント関数判定手段は、タスク属性情報記憶手段に格納されている、現在のタスクにて実行されている関数の属性情報を参照・判定可能となる。従って、強制終了禁止区間であっても、所定の関数を実行している場合には、強制終了可能とし、一方でシステムに障害をもたらす可能性のある別の関数の実行時には、当該タスクを強制終了させないといった強制終了についての柔軟な制御が可能である。
【００２８】
又、上記関数の属性に関する情報を実行されている関数の名称とし、カレント関数判定手段を構成するタスク属性認識手段が、上記名称に基づいて上記実行されている関数の属性を判定する構成もある。
【００２９】
この構成では、言語によっては、当該言語の仕様により関数の属性を判断し、直接上記タスク属性認識手段に通知することが困難な場合があるが、このような場合でも実行している関数の属性を確認することができる。
【００３０】
尚、上記一実行単位であるタスクは、プロセスである場合や、スレッドである場合がある。
【００３１】
さらに、タスク属性情報記憶手段が、タスクを構成する関数の属性に代えてタスク自体の属性を格納することにより、タスクの属性に基づいた強制終了の制御を可能とすることができる。
【００３２】
尚、プログラム及びプログラム記録媒体は、コンピュータにて上記各手段の機能を実現する構成である。
【００３３】
【発明の実施の形態】
以下、添付図面を参照して、本発明の実施の形態につき説明し、本発明の理解に供する。尚、以下の実施の形態は、本発明を具体化した一例であって、本発明の技術的範囲を限定する性格のものではない。
【００３４】
〔実施の形態１〕
本発明の実施の形態１におけるデジタル機器１００について図１、図２、図４を参照し説明する。ここに、上記デジタル機器１００とは、例えばＳＴＢ、携帯電話、家電、パーソナルコンピュータ等であって、外部からのアプリケーション（プログラム）を付加（追加）等することにより、所定機能の追加・変更・修正が可能である機器を示す。
【００３５】
まず、上記デジタル機器１００は、例えばインターネット等のネットワーク１０１を介して所定のアプリケーション（プログラム：１０２）を取得し、記憶手段１０３に記憶する。ここに、当該アプリケーション１０２は、例えば上記デジタル機器１００に新たな機能を追加するためのインタプリタ言語にて記述されたプログラムであり、実行時には、図２に示すタスク２０１を生成して処理を実行するものとする。尚、上記アプリケーション１０２の取得は、必ずしもネットワーク１０１を介する必要は無く、メモリーカード等の記憶媒体を介して得るものであってもよい。
【００３６】
次に、上記アプリケーション１０２は、実行時には例えばローダー等により、ＲＡＭ（Random Access Memory）等の一時記憶手段１０５に読み出される（図４：Ｓ４０１）。尚、上記アプリケーション１０２は、図２のタスク２０１に示すように、アプリケーション関数ａ（２０３）、アプリケーション関数ｂ（２０４）、アプリケーション関数ｃ（２０６）より構成される。さらに、上記アプリケーション１０２は、実行時にシステムライブラリ関数である、システムライブラリ関数ａ（２０５）を呼び出すため、例えば上記ローダーにて読み出される際に、同時に上記記憶手段１０３に格納されているシステムライブラリ１０４から、システムライブラリ関数１０７が上記一時記憶手段１０５に読み出される。
【００３７】
続いて、上記アプリケーション１０２のメイン関数であるアプリケーション関数ａ（２０３）がプログラム実行手段１０８に読み出されると、ＯＳ１３０は、アプリケーション関数ａ（２０３）に対応するタスク２０１を生成すると共に、当該タスクにリソースを割り当てる（図４：Ｓ４０２）。以後上記アプリケーション１０２は、タスク２０１として管理される。
【００３８】
さらに、上記タスクの生成時に上記ＯＳ１３０は、後述するタスク状態記憶手段１１０、強制終了情報記憶手段１１４、及びタスク属性情報記憶手段１１７に当該タスク２０１に対応するタスクフラグ１１８を作成し、作成したフラグエリアに例えば“０”を格納する（図４：Ｓ４０３）。又、例えばプログラム実行手段は、タスク属性認識手段１１６に対して、現在タスク２０１にて実行されている関数がアプリケーション関数である旨を通知する（図４：Ｓ４０４）。当該タスク２０１にて実行されている関数がアプリケーション関数である旨の通知を受信すると、上記タスク属性認識手段１１６は、タスク属性情報記憶手段１１７のタスク２０１に対応するタスクフラグ１１８に、例えばアプリケーション関数が実行されていることを示す“１”を格納する。ここで、例えばＯＳより提供されるアプリケーションによりタスクが作成された場合、通常、メイン関数はシステムライブラリ関数であるため、上記タスク属性情報記憶手段１１７のタスク２０１に対応するタスクフラグ１１８には“０”が格納される。
【００３９】
以後、上記タスク２０１のアプリケーション関数ａ（２０３）の先頭のコマンド（命令）より順次実行される。又、必要に応じてアプリケーション関数ｂ（２０４）等の他の関数がプログラム実行手段１０８に読み出される。尚、上記コマンドが例えば１つ実行されるに際して、当該タスク（ここではタスク２０１）に強制終了命令が送信されているか否かをタスク実行判断手段１１１に問い合わせるが詳細は後述する。
【００４０】
以上が、新規アプリケーションが実行された際に行われる処理（図４における初期処理４００）である。尚、理解に供するために、プログラム実行手段１０８では、アプリケーション関数ｄ（２０８）及びアプリケーション関数ｅ（２０９）により構成されるタスク２０２も実行されるものとする。
【００４１】
次に、タスク内において実行されている関数が、強制終了禁止命令を発行した際の、タスク状態設定手段１０９の処理の詳細について説明する。
【００４２】
例えば、アプリケーション関数ａ（２０３）の処理中の所定のポイント２１３にて、タスク２０１からＯＳ１３０に対して強制終了禁止命令２１４が送信されると、当該強制終了禁止命令２１４はタスク状態設定手段１０９にて受信される。上記強制終了禁止命令２１４を受信したタスク状態設定手段１０９は、タスク状態記憶手段１１０内の、タスク２０１に対応するフラグエリア１２１に例えば“１”を格納する。当該フラグエリア１２１に格納される“１”は、タスク２０１が現在強制終了禁止区間にある（強制終了禁止である）ということを意味するものである。
【００４３】
又、例えばアプリケーション関数ａ（２０３）の処理中の所定のポイント２１５にて、タスク２０１からＯＳ１３０に対して強制終了許可命令２１６が送信されると、当該強制終了許可命令２１６は上記タスク状態設定手段１０９にて受信される。上記強制終了許可命令２１６を受信したタスク状態設定手段１０９は、タスク状態記憶手段１１０内の、タスク２０１に対応するフラグエリア１２１に例えば“０”を格納する。当該フラグエリア１２１に格納される“０”は、現在実行されているタスク２０１が、現在強制終了禁止区間に無い（強制終了禁止ではない）ということを意味するものである。
【００４４】
以上のように、タスク状態記憶手段１１０には、各タスクの状態が強制終了禁止（フラグ“１”）であるか、強制終了可能（フラグ“０”）であるかの情報が常時格納される。以後、例えばタスク実行判断手段１１１よりタスク状態記憶手段１１０内の各タスクフラグの内容について問い合わせがあると、タスク状態設定手段１０９は当該タスクフラグに格納されている値を読み出し、上記タスク実行判断手段１１１に返信する。
【００４５】
次に、タスク内において実行されている関数が変わる際の、タスク属性認識手段１１６の処理の詳細について説明する。
【００４６】
アプリケーション関数ａ（２０３）が例えばアプリケーション関数ｂ（２０４）を呼び出し、当該タスク２０１における処理がアプリケーション関数ｂ（２０４）に切り替わった場合、上記タスク２０１はタスク属性認識手段１１６に対して、現在タスク２０１にて実行されている関数が、アプリケーション関数である旨を通知する。ここで、上記タスク属性認識手段１１６は、タスク２０１に対応するフラグエリア１１９に“１”を格納する。
【００４７】
又、アプリケーション関数ｂ（２０４）がシステムライブラリ関数ａ（２０５）を呼び出した際にも、タスク２０１は上記タスク属性認識手段１１６に通知を行うが、この場合、タスク２０１にて実行される関数はシステムライブラリ関数であるため、上記フラグエリア１１９には“０”を格納する。尚、上記同様、システムライブラリ関数ａ（２０５）がアプリケーション関数ｃ（２０６）を呼び出した際には、上記フラグエリア１１９には“１”が格納される。
【００４８】
尚、アプリケーション関数ｃ（２０６）の処理が終了し、システムライブラリ関数ａ（２０５）に処理が戻った場合にも、上記呼び出した際と同様に、以後実行される関数（処理が戻った後の関数：ここでは“０”）に対応するフラグ“０”又は“１”がフラグエリア１１９に格納される。
【００４９】
以上のように、関数の呼び出し時、及び処理が戻った時に、タスクがタスク属性認識手段に以後実行される関数の種類を通知することで、タスク属性情報記憶手段には、現在実行されているタスクの種類が常時格納されることになる。以後、例えばタスク実行判断手段１１１よりタスク属性情報記憶手段１１７内の各タスクフラグの内容について問い合わせがあると、タスク属性認識手段１１６は当該タスクフラグに格納されている値を読み出し、上記タスク実行判断手段１１１に返信する。
【００５０】
さて、現在上記プログラム実行手段１０８においては、タスク２０１及びタスク２０２が実行されていることは上述したとおりである。ここで、タスク２０２は、上記タスク２０１に対して強制終了命令２１１を発行するタスクであるものとする。上記強制終了命令２１１が発行されるタイミング（ポイント）は、ＯＳ１３０によるタスクの切り替えのタイミングによって異なるため、各タイミングでの詳細な処理は後述するものとし、ここでは、上記強制終了命令２１１が発行された際の、強制終了設定手段１１３の処理の詳細について説明する。
【００５１】
まず、所定のポイント（例えば図２に示したポイント２０７）にて、タスク２０１からタスク２０２に処理が切り替わったものと仮定する。当該タスクの切り替えは、従来技術にて説明したものである。
【００５２】
ここで、タスク２０２がタスク２０１に対して強制終了命令２１１を発行した場合、具体的には、例えばアプリケーション関数ｄ（２０８）にて呼び出されたアプリケーション関数ｅ（２０９）が、所定のポイント２１０にて発行した強制終了命令２１１は、強制終了設定手段１１３にて受信される。当該強制終了設定手段１１３は、上記強制終了命令２１１を受信すると、強制終了情報記憶手段１１４の、タスク２０１に対応するフラグエリア１２０に“１”を格納する。該フラグエリア１２０に格納される“１”は、フラグエリア１２０に対応するタスク２０１が強制終了命令を受けた状態であることを意味する。以後、例えばタスク実行判断手段１１１より強制終了情報記憶手段１１４内の各タスクフラグの内容について問い合わせがあると、強制終了設定手段１１３は当該タスクフラグに格納されている値を読み出し、上記タスク実行判断手段１１１に返信する。
【００５３】
以上のように、例えば他のタスクからの強制終了命令は、強制終了設定手段１１３を介して強制終了情報記憶手段１１４内の、該当するタスク（終了命令を受けるタスク）のフラグにて示される。
【００５４】
以上がタスク状態設定手段１０９、タスク属性認識手段１１６、及び強制終了設定手段１１３における各処理である。
【００５５】
次に、上述したタスク状態設定手段１０９、タスク属性認識手段１１６、及び強制終了設定手段１１３の各処理を踏まえた上で、新規アプリケーションが実行された後に行われる処理の詳細について説明する。
【００５６】
図４に示した初期処理４００を完了した後、プログラム実行手段１０８は、上記タスク２０１のアプリケーション関数ａ（２０３）の先頭のコマンド（命令）を順次実行する（図４：Ｓ４０５）。ここで、上記プログラム実行手段１０８は、コマンドが例えば１つ実行されるに際して、当該タスク（ここではタスク２０１）に強制終了命令が送信されているか否かを、例えばＯＳ１３０の機能として提供されているタスク実行判断手段１１１に問い合わせる。上記タスク実行判断手段１１１は、上記問い合わせを受け取ると、上記強制終了設定手段１１３に対して強制終了情報記憶手段１１４のタスク２０１フラグ（１２０）の内容を問い合わせる。尚、当該タスクフラグの内容は上述したとおりである。
【００５７】
ここで、タスク２０１フラグ（１２０）が“１”ではないと上記強制終了設定手段１１３より返信があった場合、上記タスク２０１は強制終了命令を発行されていないことを示し、上記タスク実行判定手段１１１はプログラム実行手段１０８に対しその旨を通知することで、当該プログラム実行手段１０８は次のコマンドを実行する（図４：Ｓ４０６Ｎｏ→Ｓ４０５）。尚、次のコマンドが例えばアプリケーション関数ｂ（２０３）を呼び出すコマンドである場合等には、タスク属性情報記憶手段１１７のタスク２０１フラグ（１１９）の書き換えを随時行うのは上述したとおりである。
【００５８】
又、タスク２０１フラグ（１２０）が“１”であると上記強制終了設定手段１１３より返信があった場合、上記タスク２０１は強制終了命令を発行されていることを示し、さらに上記タスク実行判断手段１１１は、タスク状態設定手段１０９に対してタスク状態記憶手段１１０のタスク２０１フラグ（１２１）の内容を問い合わせる（図４：Ｓ４０６Ｙｅｓ→Ｓ４０７）。
【００５９】
ここで、タスク２０１フラグ（１２１）が“１”ではないと上記タスク状態設定手段１０９より返信があった場合、上記タスク２０１は強制終了禁止区間でない、即ち、当該タスク２０１を終了してもシステム全体に影響を及ぼさない（共有リソースに対して操作を行っていない）ことを表している。従って、上記タスク実行判定手段１１１はプログラム実行手段１０８に対しその旨を通知することで、当該プログラム実行手段１０８は、実行している関数（例えばアプリケーション関数ｃ（２０６））及び当該関数を呼び出した関数（例えばアプリケーション関数ａ（２０３）、アプリケーション関数ｂ（２０４）、システムライブラリ関数ａ（２０５））をすべて終了し、タスク２０１を終了する（図４：Ｓ４０７Ｎｏ→Ｓ４０８→Ｅｎｄ）。
【００６０】
又、タスク２０１フラグ（１２１）が“１”であると上記タスク状態設定手段１０９より返信があった場合、上記タスク２０１は強制終了禁止区間であり、即ち、当該タスク２０１を終了するとシステム全体に影響を及ぼす可能性がある（共有リソースに対して操作を行っている等）ことを表している。この場合にはさらに、上記タスク実行判断手段１１１を構成するカレント関数実行判定手段１１２が、タスク属性認識手段１１６に対して、タスク属性情報記憶手段１１７のタスク２０１フラグ（１１９）の内容を問い合わせる（図４：Ｓ４０７Ｙｅｓ→Ｓ４０９）。
【００６１】
ここで、タスク２０１フラグ（１１９）が“１”ではない（“０”である）と上記タスク属性認識手段１１６より返信があった場合、上記タスク２０１は現在システムライブラリ関数を実行していることを意味し、即ち、当該システムライブラリ関数を終了するとシステム全体に影響を及ぼす可能性がある（共有リソースに対して操作を行っている等）ため、当該システムライブラリ関数の実行を強制終了させること無く、次のコマンドの処理に移る（図４：Ｓ４０９Ｎｏ→Ｓ４０５）。
【００６２】
又、タスク２０１フラグ（１１９）が“１”であると上記タスク属性認識手段１１６より返信があった場合、上記タスク２０１は現在アプリケーション関数を実行していることを意味し、当該アプリケーション関数を終了してもシステム全体に影響を及ぼす可能性が無い（低い）ため、当該実行している関数を終了する（図４：Ｓ４０９Ｙｅｓ→Ｓ４１０）。尚、当該実行している関数がメイン関数であった場合には、強制終了するとシステム全体に影響を及ぼす可能性があるためタスク２０１を終了する（図４：Ｓ４１０→Ｓ４０５→Ｅｎｄ）。
【００６３】
以上のように、本実施の形態においては、強制終了情報記憶手段に格納されている強制終了情報（強制終了命令受信の有無）と、タスク状態記憶手段に格納されているタスク状態（強制終了禁止区間であるか否か）に加えて、タスク属性情報記憶手段に格納されている、現在のタスクにて実行されている関数の属性情報（アプリケーション関数か、システムライブラリ関数か）を参照・判定している。従って、強制終了禁止区間であっても、アプリケーション関数を実行している場合には、強制終了（当該アプリケーション関数の中断）を可能とし、一方でシステムに障害をもたらす可能性のあるシステムライブラリ関数の実行時には、当該タスクを強制終了させないといった強制終了についての柔軟な制御が可能である。
【００６４】
続いて、図３、図４を用いて、強制終了命令を受けた各ポイントによって異なる処理の詳細を説明する。尚、当該各処理は、上記図４のフローチャートを場合分けして表すものであって、上記フローチャートと同一内容である。
【００６５】
まず、強制終了命令をアプリケーション関数ａの強制終了禁止区間設定前後に受けた場合（強制終了命令３０１、３０９）、アプリケーション関数ａを終了し、即ちタスク２０１を終了する（図４：Ｓ４０７Ｎｏ→Ｓ４０８）。
【００６６】
強制終了命令をアプリケーション関数ａ実行時の強制終了禁止区間設定後に受けた場合（強制終了命令３０２、３０８）、アプリケーション関数ａを終了し、即ちタスク２０１を終了する（図４：Ｓ４０７Ｙｅｓ→Ｓ４０９→Ｓ４１０→Ｓ４０５→Ｅｎｄ）。
【００６７】
強制終了命令をアプリケーション関数ｂ実行時に受けた場合（強制終了命令３０３、３０７）、アプリケーション関数ｂを終了し、アプリケーション関数ａに処理が戻るが、アプリケーション関数ａも直ちに終了することになり、即ちタスク２０１を終了する（図４：Ｓ４０７Ｙｅｓ→Ｓ４０９Ｙｅｓ→Ｓ４１０→Ｓ４０５を２回繰り返してＥｎｄへ）。
【００６８】
強制終了命令をシステムライブラリ関数ａ実行時に受けた場合（強制終了命令３０４、（強制終了命令３０６を含む））、当該システムライブラリ関数ａの実行を終了せずに、アプリケーション関数ｃを呼び出す。ここで、当該アプリケーション関数ｃは直ちに終了するため（後述する強制終了命令３０５のケース）再度ポイント３２０よりポイント３２１までシステムライブラリ関数ａを実行し、アプリケーション関数ｂに処理を戻す。続く当該アプリケーション関数ｂ及びアプリケーション関数ａは直ちに終了し、即ちタスク２０１が終了する（図４：Ｓ４０７Ｙｅｓ→Ｓ４０９Ｎｏ→Ｓ４０５→Ｓ４０６Ｙｅｓ→Ｓ４０７Ｙｅｓ→Ｓ４０９Ｙｅｓ→Ｓ４１０（アプリケーション関数ｃ終了）→Ｓ４０５→・・・→４０９Ｎｏ→Ｓ４０５・・・（システムライブラリ関数ａ終了後）→Ｓ４０９Ｙｅｓ→Ｓ４１０（アプリケーション関数ｂ終了）→Ｓ４０５→・・・→Ｓ４１０（アプリケーション関数ａ終了）→Ｅｎｄへ）。
【００６９】
強制終了命令をアプリケーション関数ｃ実行時に受けた場合（強制終了命令３０５）、アプリケーション関数ｃを終了し、システムライブラリ関数ａのポイント３２０に処理が戻り、ポイント３２１まで処理が実行された後、アプリケーション関数ｂ、アプリケーション関数ａに処理が戻ると共に直ちに処理が終了し、即ちタスク２０１が終了する（図４：Ｓ４０７Ｙｅｓ→Ｓ４０９Ｙｅｓ→Ｓ４１０（アプリケーション関数ｃ終了）→Ｓ４０５→・・・→Ｓ４０９Ｎｏ→Ｓ４０５→・・・→４０９Ｎｏ→Ｓ４０５・・・（システムライブラリ関数ａ終了後）→Ｓ４０９Ｙｅｓ→Ｓ４１０（アプリケーション関数ｂ終了）→Ｓ４０５→・・・→Ｓ４１０（アプリケーション関数ａ終了）→Ｅｎｄへ）。
【００７０】
以上が本実施の形態１における処理である。但し、本実施の形態１において、強制終了禁止区間を設定可能である場合の処理について説明したが、必ずしも強制終了禁止区間の判定は必要ではない。即ち、強制終了禁止区間であるか否かの判定をすることなく、現在実行されている関数の属性情報のみに基づいて強制終了の可否を判定してもよい。この場合には、図４に示したＳ４０７及びＳ４０８の処理を除くのみでよい。
【００７１】
又、上記関数の属性として、アプリケーション関数とシステムライブラリ関数を例にあげたが、特に上記２つに限定する必要は無く、使用する言語によってさらに異なった関数の場合分けが可能である場合には、当該異なる関数の属性の情報を判断基準として加えてもよい。
【００７２】
〔実施の形態２〕
次に、実施の形態２では、図１を用いてタスク属性記憶手段のタスクフラグに情報を格納する際の処理について説明する。
【００７３】
上記実施の形態１では、プログラム実行手段１０８が現在実行している関数の属性（アプリケーション関数、システムライブラリ関数）を、直接タスク属性認識手段１１６に通知することにより、タスク属性情報記憶手段１１７の各タスクフラグに当該属性を格納していた。
【００７４】
本実施の形態２では、プログラム実行手段１０８は、現在実行している関数が変更になった場合、当該変更になった関数名（これから実行する関数の名称）を上記タスク属性認識手段１１６に送信する。当該タスク属性認識手段１１６は、上記関数名を受信すると、一時記憶手段１０５に格納されているアプリケーション関数１０６やシステムライブラリ関数１０７を参照することで、当該関数がアプリケーション関数かシステムライブラリ関数かを判断する。上記関数の属性を判断したタスク属性認識手段１１６は、当該関数の種類を該当するタスクフラグに格納する。
【００７５】
以上により、直接プログラム実行手段より関数属性をタスク属性認識手段１１６に送信できない場合であっても、タスク属性情報記憶手段は、該当するタスクフラグに現在実行されている関数の属性を格納することが可能になる。
【００７６】
ところで、上記実施の形態１、及び実施の形態２においては、強制終了を実行する判断の基準に、タスク内で現在実行されている関数の属性を用いている。しかしながら、上記判断の基準を必ずしも関数の属性のみに限定する必要は無い。即ち、マルチタスクＯＳでは、ＯＳの機能の一部を独立したタスクとして実行することが可能であり、これをシステムタスク（システムプロセス、システムスレッド等）と呼ぶ。又、これに対して、ユーザーが起動したタスクがアプリケーションタスク（ユーザープロセス、アプリケーションスレッド等）である。
【００７７】
上記システムタスクとアプリケーションタスクは、タスク属性ということが可能であり、当該２つのタスク属性を比較した場合には以下のようなことが言える。
【００７８】
即ち、上記システムタスクは、ＯＳの機能として提供されているために信頼性（安全性）が高く、一方上記アプリケーションタスクは悪意を持った処理を行う可能性があり、上記システムタスクに比較して信頼性が低い。さらに、上記システムタスクは強制終了されるとシステムに障害をもたらす可能性が高いが、上記アプリケーションタスクは当該タスクがシステムライブラリ関数を利用しているものであったとしても、一般的に強制終了された場合の影響は当該アプリケーションタスク内で完結するものである。
【００７９】
従って、以上のことを考慮すると、上記判断の基準を関数の属性ではなく、タスクの属性で判断することができるといえる。即ち、上記タスク属性情報記憶手段が記憶するフラグエリア（タスクフラグ）に、関数の属性ではなくタスクの属性を格納するのである。当該格納する処理は、タスクが起動した時の上記初期処理時に、プログラム実行手段がタスク属性認識手段に対し一回だけ行うのみでよい。格納する値は、例えばシステムタスクの場合には“０”であり、アプリケーションタスクの場合には“１”である。以後、タスク属性情報記憶手段内の該当するタスクフラグのチェックは同様である。
【００８０】
以上のように、関数の属性に替えてタスクの属性を管理し、当該タスクに対する強制終了の処理の実行を判断することで、強制終了についての柔軟な制御が可能である。
【００８１】
【発明の効果】
以上のように、本発明によれば、タスク内において実行される関数が切り替わる度に、タスク属性情報記憶手段には、現在実行されているタスクの種類が常時格納される構成としている。このため、カレント関数判定手段は、タスク属性情報記憶手段に格納されている、現在のタスクにて実行されている関数の属性情報を参照・判定可能となり、従って、強制終了禁止区間であっても、所定の関数を実行している場合には、強制終了可能とし、一方でシステムに障害をもたらす可能性のある別の関数の実行時には、当該タスクを強制終了させないといった強制終了についての柔軟な制御が可能である。
【００８２】
又、タスク属性情報記憶手段が、関数の属性に代えてタスクの属性を格納することにより、タスクの属性に基づいた強制終了の制御が可能である。
【図面の簡単な説明】
【図１】本発明に係るデジタル機器における概略機能ブロック図。
【図２】本発明に係るタスク間にわたる強制終了命令発行時のイメージ図。
【図３】各関数実行時における強制終了命令受信のポイントを示す図。
【図４】タスク実行時の強制終了命令処理に関するフローチャート。
【図５】従来技術におけるプロセス、スレッド及びＯＳのイメージを示す図。
【図６】タスク内の関数構造の一例を示す図。
【図７】従来技術におけるタスク間にわたる強制終了命令発行時のイメージ図。
【符号の説明】
１００ デジタル機器
１０１ ネットワーク
１０２ アプリケーション
１０３ 記憶手段
１０４ システムライブラリ
１０５ 一時記憶手段
１０６ アプリケーション関数
１０７ システムライブラリ関数
１０８ プログラム実行手段
１０９ タスク状態設定手段
１１０ タスク状態記憶手段
１１１ タスク実行判断手段
１１２ カレント関数実行判定手段
１１３ 強制終了設定手段
１１４ 強制終了情報記憶手段
１１６ タスク属性認識手段
１１７ タスク属性情報記憶手段
１１８ タスクフラグ
１１９、１２０、１２１ フラグエリア
１３０ ＯＳ（ＯＳ機能）
Claims (6)
- アプリケーション関数とシステムライブラリ関数とにより構成され一実行単位として管理される第１のタスクと、上記第１のタスクを強制終了させる第２のタスクとをプログラム実行手段にて複数並列に実行するオペレーティングシステムを備えたタスク管理装置において、
上記第１のタスク内において実行される関数が強制終了禁止命令を発行すると、上記第１のタスクが強制終了禁止区間にあることを設定するタスク状態設定手段と、
上記第１のタスク内において実行される関数が切り替わる度に、切り替わった後の関数の属性が、予めオペレーションシステムにより提供されている上記システムライブラリ関数か又はそれ以外の上記アプリケーション関数かを示す属性情報を記憶するタスク属性情報記憶手段と、
上記第２のタスクが発行した上記第１のタスクに対する強制終了命令を上記第１のタスクが受信した際に、上記第１のタスクが上記強制終了禁止区間か否かを判定するタスク実行判定手段と、
上記第１のタスクの状態が強制終了禁止区間と判定した場合、上記タスク属性情報記憶手段に基づいて上記第１のタスクにおいて実行中の関数の属性情報を判定するカレント関数実行判定手段と、
上記第１のタスクの属性情報がアプリケーション関数である場合には当該第１のタスクを強制終了し、システムライブラリ関数である場合には当該タスクを強制終了させないプログラム実行手段とを具備することを特徴とするタスク管理装置。 - 上記カレント関数実行判定手段を構成するタスク属性認識手段は、実行されている関数の名称に基づいて上記実行されている関数の属性を判定する請求項１に記載のタスク管理装置。
- 上記一実行単位として管理されるタスクは、プロセスである請求項１に記載のタスク管理装置。
- 上記一実行単位として管理されるタスクは、スレッドである請求項１に記載のタスク管理装置。
- アプリケーション関数とシステムライブラリ関数とにより構成され一実行単位として管理される第１のタスクと、上記第１のタスクを強制終了させる第２のタスクとを複数並列に実行するオペレーティングシステムを用いたタスク管理方法であって、
上記第１のタスク内において実行される関数が強制終了禁止命令を発行すると、上記第１のタスクが強制終了禁止区間にあることを設定するタスク状態設定ステップと、
上記第１のタスク内において実行される関数が切り替わる度に、切り替わった後の関数の属性が、予めオペレーションシステムにより提供されている上記システムライブラリ関数か又はそれ以外の上記アプリケーション関数かを示す属性情報を記憶するタスク属性情報記憶ステップと、
上記第２のタスクが発行した上記第１のタスクに対する強制終了命令を上記第１のタスクが受信した際に、上記第１のタスクが上記強制終了禁止区間か否かを判定するタスク実行判定ステップと、
上記第１のタスクの状態が強制終了禁止区間と判定した場合、上記タスク属性情報記憶ステップに基づいて上記第１のタスクにおいて実行中の関数の属性情報を判定するカレント関数実行判定ステップと、
上記第１のタスクの属性情報がアプリケーション関数である場合には当該第１のタスクを強制終了し、システムライブラリ関数である場合には当該タスクを強制終了させないプログラム実行ステップとを具備することを特徴とするタスク管理方法。 - アプリケーション関数とシステムライブラリ関数とにより構成され一実行単位として管理される第１のタスクと、上記第１のタスクを強制終了させる第２のタスクとを複数並列に実行するオペレーティングシステムを用いてコンピュータに実行させるためのタスク管理プログラムを記録した記録媒体であって、
上記第１のタスク内において実行される関数が強制終了禁止命令を発行すると、上記第 １のタスクが強制終了禁止区間にあることを設定するタスク状態設定ステップと、
上記第１のタスク内において実行される関数が切り替わる度に、切り替わった後の関数の属性が、予めオペレーションシステムにより提供されている上記システムライブラリ関数か又はそれ以外の上記アプリケーション関数かを示す属性情報を記憶するタスク属性情報記憶ステップと、
上記第１のタスクが、上記第２のタスクが発行した上記第１のタスクに対する強制終了命令を受信した際に、上記第１のタスクが上記強制終了禁止区間か否かを判定するタスク実行判定ステップと、
上記第１のタスクの状態が強制終了禁止区間と判定した場合、上記タスク属性情報記憶ステップに基づいて上記第１のタスクにおいて実行中の関数の属性情報を判定するカレント関数実行判定ステップと、
上記第１のタスクの属性情報がアプリケーション関数である場合には当該第１のタスクを強制終了し、システムライブラリ関数である場合には当該タスクを強制終了させないプログラム実行ステップとを具備することを特徴とするタスク管理プログラムを記録した記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002011585A JP3961301B2 (ja) | 2001-01-25 | 2002-01-21 | デジタル機器、タスク管理方法及びそのプログラム |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001-16601 | 2001-01-25 | ||
| JP2001016601 | 2001-01-25 | ||
| JP2002011585A JP3961301B2 (ja) | 2001-01-25 | 2002-01-21 | デジタル機器、タスク管理方法及びそのプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002297402A JP2002297402A (ja) | 2002-10-11 |
| JP3961301B2 true JP3961301B2 (ja) | 2007-08-22 |
Family
ID=26608264
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002011585A Expired - Fee Related JP3961301B2 (ja) | 2001-01-25 | 2002-01-21 | デジタル機器、タスク管理方法及びそのプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3961301B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006146678A (ja) | 2004-11-22 | 2006-06-08 | Hitachi Ltd | 情報処理装置におけるプログラム制御方法、情報処理装置、及びプログラム |
| KR100714710B1 (ko) * | 2006-02-22 | 2007-05-04 | 삼성전자주식회사 | 입출력 작업에 의해 블로킹된 스레드를 강제 종료하는 장치및 방법 |
| JP2009199166A (ja) * | 2008-02-19 | 2009-09-03 | Nec Corp | 情報処理装置、その制御方法及びプログラム |
| JP7067232B2 (ja) * | 2018-04-20 | 2022-05-16 | コニカミノルタ株式会社 | サービス提供装置およびプログラム |
-
2002
- 2002-01-21 JP JP2002011585A patent/JP3961301B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002297402A (ja) | 2002-10-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9201693B2 (en) | Quota-based resource management | |
| JP5137781B2 (ja) | 移動機及びアプリケーションの切替方法 | |
| JP4834566B2 (ja) | 入出力作業によってブロッキングされたスレッドを強制終了する装置および方法 | |
| CN111414256B (zh) | 基于麒麟移动操作系统的应用程序进程派生方法、系统及介质 | |
| US20140033208A1 (en) | Method and device for loading application program | |
| CN110955499B (zh) | 处理器核心配置方法、装置、终端及存储介质 | |
| CN109491759B (zh) | 基于虚拟文件系统的进程调试方法、装置和计算机设备 | |
| CN109697112B (zh) | 分布式集约化一站式作业系统和实现方法 | |
| CN115858083A (zh) | 容器cpu资源调度与隔离方法和装置、存储介质及电子设备 | |
| CN113342554B (zh) | Io多路复用方法、介质、设备和操作系统 | |
| CN107391274A (zh) | 离线消息的处理方法及装置 | |
| JP3961301B2 (ja) | デジタル機器、タスク管理方法及びそのプログラム | |
| CN111200651A (zh) | 定时调用微服务的方法、系统、设备和介质 | |
| CN111294377A (zh) | 一种依赖关系的网络请求发送方法、终端装置及存储介质 | |
| KR100803290B1 (ko) | 무선 센서 네트워크 환경에서 프로그램을 변경하기 위한확장 가능한 가상 머신 및 이를 이용한 리프로그래밍 방법 | |
| US7191443B2 (en) | Digital device, task management method and program therefor | |
| KR100857824B1 (ko) | 모바일 플랫폼 기반의 램 상주 어플리케이션 실행 관리방법 | |
| US20040025007A1 (en) | Restricting access to a method in a component | |
| JP2000056982A (ja) | 非持続メモリ内にオブジェクトを作成する方法および装置、ならびにオブジェクトへのアクセス可能性を維持する方法 | |
| US20160004576A1 (en) | Apparatus for managing application program and method therefor | |
| CN110502354B (zh) | 一种Java智能卡及其应用程序接口的调用方法 | |
| CN115328528A (zh) | Flutter引擎管理方法、系统、介质及原生端 | |
| CN116166394A (zh) | 任务执行方法、装置、系统、存储介质及处理器 | |
| WO2024037553A1 (zh) | 一种生命周期调度的方法、装置及电子设备 | |
| CN111221535B (zh) | 线程分配方法、服务器及计算机可读存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041213 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20061219 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070105 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070228 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070420 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070516 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 3961301 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110525 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110525 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120525 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120525 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130525 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130525 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |