(57)【要約】【課題】タスクの異常を検出してタスクを効率よく処理可能なタスク制御方法、データ処理システム、タスク制御プログラム及びその記憶媒体を提供すること。【解決手段】中央処理装置１１の処理資源をスライスタイムの間、複数のタスクに割り当ててデータを処理するタスク制御方法において、タスク監視手段２５が、タスクによるデータ処理の仕事量を検出するステップ（Ｓ２）と、仕事量に基づき前記タスクの異常を検出するステップ（Ｓ４）と、タスクの異常が検出されない場合、処理待ちデータ量に基づきスライスタイムを延長するか否かを判定するステップ（Ｓ６）と、スライスタイムを延長すると判定された場合、スライスタイムを割り当てるシステム管理手段２１にスライスタイムの延長を要求するステップ（Ｓ７）と、を有することを特徴とする。【選択図】図４
2008129709.tif 000002
【特許請求の範囲】
【請求項１】
中央処理装置の処理資源をスライスタイムの間、複数のタスクに割り当ててデータを処理するタスク制御方法において、
タスク監視手段が、前記タスクによるデータ処理の仕事量を検出するステップと、
前記仕事量に基づき前記タスクの異常を検出するステップと、
前記タスクの異常が検出されない場合、データの処理状況に基づきスライスタイムを延長するか否かを判定するステップと、
スライスタイムを延長すると判定した場合、スライスタイムを割り当てるシステム管理手段にスライスタイムの延長を要求するステップと、
を有することを特徴とするタスク制御方法。
【請求項２】
前記タスクの異常を検出するステップでは、前記仕事量が過去の仕事量の平均よりも少ない場合に異常であると検出する、
ことを特徴とする請求項１記載のタスク制御方法。
【請求項３】
複数のタスクを中央処理装置が処理するデータ処理システムにおいて、
前記中央処理装置の処理資源をスライスタイムの間、複数の前記タスクに割り当てるシステム管理手段と、
前記タスクを監視するタスク監視手段と、を有し、
前記タスク監視手段は、前記タスクによるデータ処理の仕事量に基づき前記タスクの異常を検出し、異常が検出されない場合は、データの処理状況に基づき前記システム管理手段にスライスタイムの延長を要求する、
ことを特徴とするデータ処理システム。
【請求項４】
中央処理装置の処理資源が割り当てられて、スライスタイムの間データ処理するタスクの仕事量を検出するステップと、
前記仕事量に基づき前記タスクの異常を検出するステップと、
前記タスクの異常が検出されない場合、データの処理状況に基づきスライスタイムを延長するか否かを判定するステップと、
スライスタイムを延長すると判定された場合、スライスタイムを割り当てるシステム管理手段にスライスタイムの延長を要求するステップと、
をコンピュータにより実現することを特徴とするタスク制御プログラム。
【請求項５】
請求項４記載のプログラムを記憶したコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、中央処理装置の処理資源をスライスタイムの間、複数のタスクに割り当てタスクを処理するタスク制御方法、データ処理システム、タスク制御プログラム及びその記憶媒体に関し、特に、タスクの異常を検出して適切な処理を行うタスク制御方法、データ処理システム、タスク制御プログラム及びその記憶媒体に関する。
【背景技術】
【０００２】
複数のプログラムが１つの中央処理装置（ＣＰＵ）の処理資源を共有するマルチプログラミングでは、処理の１単位となるタスクがＣＰＵを占有する時間が極度に偏ることのないように適切なスライスタイムがタスクに割り当てられる。このスライスタイムが短いほど各タスクに均等に処理資源を供給しやすくなるが、あまり短くするとタスク切り替えのオーバーヘッドが生じ効率が低下してしまう。
【０００３】
また、スライスタイムをあまり長くすると特定のタスクがＣＰＵを占有する場合が生じ得るため好ましくない。そこで、適切なスライスタイムを設定し、スライスタイムの間に処理が終了すればタスク側からＣＰＵを開放するが、処理が間に合わずタスクが終了しない場合には、最大でそのスライスタイムまでＣＰＵを占有可能にして複数のタスクを処理している。図１はこの従来のタスク割り当ての概略図である。図１では、タスクＡとタスクＢがＯＳ（Operating System）により切り替えられて１つのＣＰＵにより処理される。当初、ＣＰＵはタスクＡを処理しているが、イベントが発生することでタスクＢに処理が切り替わる。そして、タスクＢの処理が終了すればタスクＢが処理資源を開放しタスクＡに切り替わる（図１のＥ１）が、処理が終了しなければスライスタイムを上限にＣＰＵを占有し、スライスタイムが経過するとＯＳが強制的にタスクＡに切り替える（Ｅ２）。
【０００４】
また、スライスタイムを可変に制御する技術が提案されている（例えば、特許文献１〜３参照。）。特許文献１記載の技術は、ＣＰＵのアイドル比率によりシステムの負荷状態を判定し、負荷が小さい場合にはスライスタイムを延長し負荷が大きい場合には短縮することで、処理効率を最適化するとしている。
【０００５】
また、特許文献２記載の技術は、一定期間中の各タスクに対するディスパッチ情報を記憶しておきディスパッチ情報から各タスクの特性を推定し、その推定結果に基づきスライスタイムを調整する。ディスパッチ情報は各タスクがスライスタイムを使い切ったか否かを示す情報を含むので、使い切り回数が少ないタスクはスライスタイムを短くし使い切り回数が多いタスクはスライスタイムを長くすることで、タスクの特性に応じたスライスタイムに調整しうるとしている。
【０００６】
また、特許文献３記載の技術では、各タスクにプライオリティを割り当てると共にこのプライオリティに従いＣＰＵの処理資源を割り当て、また、総計された負荷分散から決定される目標負荷分散に対し負荷が少ないタスクには割り当てる処理資源を低減することで、プライオリティの高いタスクに処理資源が割り当てられる頻度が高くなるようにしてタスクを処理する。
【特許文献１】特開平５−０６６９５４号公報
【特許文献２】特開平５−２４１８６０号公報
【特許文献３】特開平１１−２４９９１３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１〜３の技術はいずれも負荷の大きいタスクに対しスライスタイムを延長するものであるため、タスクの処理中に異常が生じた場合でもスライスタイムを延長させてしまうという問題がある。例えば、タスクが暴走した場合、データは処理されていないのにスライスタイムは最大まで延長され、また、その暴走も検知することができない。すなわち、特許文献１〜３の技術では、負荷等に応じてスライスタイムを増大させた場合でも効率的に処理しているとは限らず、また、効率的に処理されているか否かを検出することもできないという問題がある。
【０００８】
なお、システムの暴走を検知する手段として定期的なタイマ割り込みにより暴走していないことを検知しながらプログラムを実行するウォッチドッグタイマが知られているが、タスクが暴走していてもタイマ割り込みは発生するので、ウォッチドッグタイマではタスクの暴走を検知することはできない。
【０００９】
本発明は、上記課題に鑑み、タスクの異常を検出してタスクを効率よく処理可能なタスク制御方法、データ処理システム、タスク制御プログラム及びその記憶媒体を提供すること目的とする。
【課題を解決するための手段】
【００１０】
上記課題に鑑み、本発明は、中央処理装置の処理資源をスライスタイムの間、複数のタスクに割り当ててデータを処理するタスク制御方法において、タスク監視手段が、タスクによるデータ処理の仕事量を検出するステップと、仕事量に基づき前記タスクの異常を検出するステップと、タスクの異常が検出されない場合、処理待ちデータ量に基づきスライスタイムを延長するか否かを判定するステップと、スライスタイムを延長すると判定された場合、スライスタイムを割り当てるシステム管理手段にスライスタイムの延長を要求するステップと、を有することを特徴とする。
【００１１】
本発明によれば、タスクによるデータ処理の仕事量を検出するので、タスクの異常を検出することができ、これを利用してバグの洗い出しや異常動作の検知及び処理の限界値を定量的に知ることが可能になる。
【発明の効果】
【００１２】
タスクの異常を検出してタスクを効率よく処理可能なタスク制御方法、システム、タスク制御プログラム及びその記憶媒体を提供することができる。
【発明を実施するための最良の形態】
【００１３】
以下、本発明を実施するための最良の形態について、図面を参照しながら説明する。
始めに、本実施形態のタスク制御方法の概略を説明する。図２は本実施形態のスライスタイムの延長の概略図を示す。ＯＳ（Operating System）は当初、タスクＡを実行しているが、イベントが発生することで中央処理装置の処理資源をタスクＢに割り当てる（以下、単に「タスクＢに処理を切り替える」という。）。タスクＡは例えばネットワークからの入力や操作を待つインタラクティブな処理であり、そこで発生するイベントとはデータ受信やユーザの何らかの操作である。処理が切り替わったタスクＢは、受信したデータの保存や操作に応じたデータ処理を開始する。
【００１４】
本実施形態では、ＯＳはタスクＢの当初のスライスタイムとしてスライスタイムｍｉｎを割り当て、データの処理状況に応じてスライスタイムｍａｘを上限にスライスタイムを段階的に延長する。スライスタイムｍｉｎはタスクの切り替わり時に与えられる最短のスライスタイムであって、タスクＢの処理がスライスタイムｍｉｎの間に終了しない場合、データの処理状況が所定の条件を満たす場合にＯＳはスライスタイムを段階的に延長する。そしてスライスタイムｍａｘまで延長してもタスクＢの処理が終了しない場合には、ＯＳはタスクＡに処理を切り替える。このように、データの処理状況が所定の条件を満たすか否かを判定することで暴走などタスクＢの異常状態を検知できるため、正常にデータ処理が実行されている場合にのみスライスタイムを延長することができる。
【００１５】
図３は、本実施形態のタスク制御方法を実現するコンピュータ（特許請求の範囲のデータ処理システムに相当）１０のハードウェア構成図を示す。このコンピュータ１０は、例えば携帯型の電子機器に組み込まれるマイコンである。コンピュータ１０は、それぞれバスで相互に接続されているＣＰＵ１１、ＲＡＭ１２、ＲＯＭ１３、メモリ１４、入力装置１５、表示制御部１６及びメモリカード装着部１７を有するように構成される。
【００１６】
ＲＯＭ１３は、ＢＩＯＳ（Basic Input Output System）などＯＳを起動するためのプログラムやパラメータを記憶している。メモリ１４はフラッシュメモリなど不揮発性メモリであり、ＯＳやプログラム、データファイル等の各種ファイルが記憶されている。ＣＰＵ１１は、ＯＳやプログラムをメモリ１４から読み込んでして実行することで種々の機能を提供すると共に、コンピュータ１０が行う処理を統括的に制御する。ＲＡＭ１２は、ＣＰＵ１１がＯＳやプログラムを実行したりデータを一時保管するための作業領域である。入力装置１５はキーボードやタッチパネルなど、ユーザからの様々な操作指示を入力するために用いられる。表示制御部１６は、プログラムが指示する画面情報に基づき所定の解像度や色数等で液晶などのディスプレイに描画する。例えば、ＧＵＩ（Graphical User Interface）画面を形成し、操作に必要な各種ウィンドウやデータ等をディスプレイに表示する。メモリカード装着部１７は、フラッシュメモリなどの記憶媒体１８を装着して記憶媒体１８に記憶されたプログラムやデータファイルを読み出し、また、メモリ１４のプログラムやデータファイルを書き込むインターフェイスである。
【００１７】
本実施形態のタスク制御方法は、ＣＰＵ１１がタスク制御プログラムを実行することで実現されるものである。タスク制御プログラムは記憶媒体１８に記憶して配布されたりまた通信手段によりサーバからダウンロードされメモリ１４にインストールされる。
【００１８】
図４は、タスク制御プログラムが実行されたデータ処理システムの機能ブロック図を示す。ＣＰＵ１１がタスク制御プログラムを実行することでシステム管理手段２１、タスク監視手段２５及びタスクＢ２３（以下、単にタスクＢという）が実現される。システム管理手段２１は実行すべきタスクを決定しそのタスクの起動及び停止を制御する例えばディスパッチャでありＯＳの機能を利用できる。システム管理手段２１がタスクＢを起動する場合、タスクＢにスライスタイムＭｉｎを割り当てる。したがって、システム管理手段２１にとってタスクＢの処理開始時刻及び割り当て後の経過時間は既知である。
【００１９】
起動されたタスクＢはタスクＢの処理（例えば、データ圧縮、データ保存など）に供される処理待ちデータ２２を処理し、処理済データ２４を出力する。処理待ちデータ２２は作業エリアとしてＲＡＭ１２に一時記憶されデータバスのビット数に応じて順次ＣＰＵ１１に送出される。送出されたデータはＣＰＵ１１に処理されＲＡＭ１２に一時記憶されたのち最終的にメモリ１４に記憶される。したがって、ＲＡＭ１２又はメモリ１４の処理済データ２４を監視することでタスクＢのデータ処理量が検出される。
【００２０】
タスク監視手段２５はタスクＢのデータの処理状況を監視して、システム管理手段２１にタスクＢの異常を通知し、又は、スライスタイムの延長を要求するものである。
【００２１】
〔タスクの異常の検出処理及びスライスタイムの延長処理〕
タスク監視手段２５の処理について説明する。図５は、タスク監視手段２５の処理手順を示すフローチャート図である。
（Ｓ１）
タスク監視手段２５はタスクＢの起動をシステム管理手段２１から通知されるので、システム管理手段２１がタスクＢの処理を開始する際に、処理待ちデータ２２の処理待ちデータ量を取得しＲＡＭ１２に記憶する。
（Ｓ２）
また、タスク監視手段２５は、タスクＢの仕事量を算出する。タスク監視手段２５は、タスクＢの処理を開始してから終了するまでの間、処理済データ２４を監視して処理されたデータ量を計測している。処理されたデータ量はサイクル時間毎に検出されるので、例えば、サイクル時間毎に処理したデータ量を除算すれば、サイクル時間毎に単位時間当たりの仕事量が得られる。また、タスクＢが起動してからの経過時間は既知であるので、処理されたデータ量を経過時間で除算して単位時間当たりのタスクＢの仕事量を算出してもよい。
（Ｓ３）
そして、タスク監視手段２５は、サイクル時間毎に算出した単位時間当たりの仕事量の平均（以下、平均仕事量という）を算出する。タスク監視手段２５は随時更新される単位時間当たりの平均仕事量をＲＡＭ１２に記憶する。これにより、タスクＢに必要な平均的な仕事量を検出することができる。
（Ｓ４）  「異常判定」
異常判定は、タスクＢの処理が正常に進行しているか否かを判定するための処理である。異常判定をスライスタイムの延長処理に先立って行うことでスライスタイムを延長する前に異常検出が可能になりデータ処理システムの効率低下を防止できる。
【００２２】
タスク監視手段２５はタスクＢの仕事量が正常に処理していると推定される仕事量か否かを次の式により判定する。
【００２３】
平均仕事量−許容値Ｑ>現在の仕事量  …Ｉ
式Ｉは、現在の仕事量が平均仕事量に比べて異常と推定されるほど少ないか否かを判定するための式である。したがって、現在の仕事量がそれまでの平均仕事量に比べ極端に少なくなったような場合は、タスクＢに異常が生じているものと判定される。許容値Ｑは現在の仕事量の誤差を許容するための値であり、例えば、平均仕事量の数％〜数１０％の値や予め定められた値である。例えばタスクＢが暴走して異常が生じた場合、仕事量は極端に低下するので、式Ｉの判定によりタスクの異常を検出することができる。
【００２４】
（Ｓ５）
異常と判定された場合（Ｓ４のＹｅｓ）、タスク監視手段２５はタスク異常をシステム管理手段２１に通知する。システム管理手段２１は、タスク異常の通知を受け、タスクＢを停止し以降は起動を禁止すると共に、異常を知らせるコードやメッセージを出力する。また、タスクＢを初期化して最初から処理待ちデータ２２を処理してもよい。したがって、異常が検出された場合はタスク監視手段２５の処理はステップＳ５で終了し以降はシステム管理手段２１の処理に移行する。
【００２５】
（Ｓ６）
異常と判定されない場合（Ｓ４のＮｏ）、タスク監視手段２５は、スライスタイムを延長するか否かを判定する。
【００２６】
処理待ちデータ量>閾値  …II  
平均仕事量−許容値Ｐ<現在の仕事量  …III
式IIは、処理待ちデータ２２に記憶されているタスクＢの処理待ちデータ２２の量がスライスタイムを延長する必要があるほど残っているか否かを判定するための式である。式IIIは、現在の仕事量が平均仕事量に比べてスライスタイムを延長する必要があるほど多いか否かを判定するための式である。許容値Ｐは現在の仕事量の誤差を許容するための値であり、例えば、平均仕事量の数％〜数１０％の値や予め定められた値である。また、許容値Ｑと同じ値であってもよい。
【００２７】
なお、スライスタイムｍｉｎまではスライスタイムを延長する必要がないので、タスク監視手段２５はスライスタイムｍｉｎの直前になってから以降にのみ、スライスタイムを延長するか否かを判定してもよい。
（Ｓ７）
データの処理状況が式II及び式IIIの条件を満たす場合（Ｓ６のＹｅｓ）、タスク監視手段２５は、システム管理手段２１にスライスタイム変更を要求する。スライスタイム変更の要求を受けたシステム管理手段２１は現在のスライスタイムに所定時間ΔＴを加えた時間をスライスタイムとする。これにより、スライスタイムｍｉｎがΔＴ延長された。したがって、式II及び式IIIの条件を満たさない場合、タスク監視手段２５はシステム管理手段２１にスライスタイム変更を要求しない。
（Ｓ８）
データの処理状況が式II及び式IIIの条件を満たさない場合（Ｓ６のＮｏ）、又は、スライスタイムを延長した後、タスク監視手段２５はタスクＢの処理が終了したか否かを判定する。
【００２８】
タスクＢの処理が終了した場合、タスクＢはシステム管理手段２１に処理を戻す。なお、延長前又は延長後のスライスタイムが経過した場合、システム管理手段２１がタスクＢを停止する。したがって、これらの場合には、タスク監視手段２５の処理は終了し、システム管理手段２１がＣＰＵ１１の処理をタスクＡに切り替え、ＣＰＵ１１はタスクＡの処理を再開することになる。
【００２９】
タスクＢが終了していない場合（Ｓ８のＮｏ）、タスク監視手段２５はステップＳ１からの処理を繰り返す。したがって、スライスタイムをΔＴ延長しても処理待ちデータ２２が閾値より多く残っていて、かつ、現在の仕事量が「平均仕事量−許容値Ｐ」よりも多い場合にはステップＳ５により再度スライスタイムが延長される。
【００３０】
スライスタイムが延長されるほど式IIと式IIIによる処理状況の判定はＹｅｓになりにくいので、処理すべきデータ量が多いタスクほど優先的にスライスタイムが延長されることになりデータ処理システムの効率が向上する。
【００３１】
以上のように、本実施形態のタスク制御方法によれば、タスクＢの異常を検出した場合にはスライスタイムを延長することがない。したがって、異常によりスライスタイムを延長することがなく処理するデータ量が多いタスクのみスライスタイムを延長するので、データ処理システムの効率を向上することができる。
【００３２】
また、プログラムの開発段階であれば異常検出によりタスクに潜むバグの洗い出しが容易になり、システム開発の進捗速度が速くなる。また、プログラムの実用段階であればタスクが暴走した場合の検出が容易になり、異常検出後はシステム管理手段２１がタスクＢを制御するので他のタスクへ影響が及ぶことやデッドロックなどを防止してデータ処理システムへの影響を最小限にすることができる。また、タスク監視手段２５はタスクＢの仕事量を検出しているので、タスクＢの処理の限界値を定量的に知ることができる。
【図面の簡単な説明】
【００３３】
【図１】従来のスライスタイムの調整の概略図である。
【図２】本実施形態のスライスタイムの調整の概略図である。
【図３】本実施形態のタスク制御方法を実現するコンピュータのハードウェア構成図である。
【図４】タスク制御プログラムの機能ブロック図である。
【図５】タスク監視手段の処理手順を示すフローチャート図である。
【符号の説明】
【００３４】
１０    コンピュータ
１１    ＣＰＵ
１２    ＲＡＭ
１３    ＲＯＭ
１４    メモリ
１５    入力装置
１６    表示制御部
１７    メモリカード装着部
１８    記憶媒体
２１    システム管理手段
２２    処理待ちデータ
２３    タスクＢ
２４    処理済データ
２５    タスク監視手段
【図１】
2008129709.tif 000003
【図２】
2008129709.tif 000004
【図３】
2008129709.tif 000005
【図４】
2008129709.tif 000006
【図５】
2008129709.tif 000007