JPH0793168A - タスク管理方式 - Google Patents

Abstract

(57)【要約】 【目的】 本発明は階層化されたソフトウェアの各層が
バッファをもち、バッファ内のデータが同じ層に属する
タスクによって処理されるシステムにおいて、バッファ
の容量不足によるシステムの性能低下の問題を解消し、
データの取りこぼしやシステムのデッドロックを回避す
ることを目的とする。 【構成】 監視タスクが一定周期で各バッファの使用量
を読み出しバッファ上限値と比べることにより、バッフ
ァの容量不足を直ちに検出することができ、さらにこの
とき、そのバッファ内のデータを処理するタスクの実行
優先順位を他のタスクより高くすることによって、溜ま
ったデータを優先的に処理し、システムの性能低下を回
避することができる方式である。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は計算機や制御用装置な
ど、オペレーティングシステムやモニタによって資源の
使用権を与えられる処理の基本単位であるタスクの管理
方式に係り、特に各タスクの実行優先順位を動的に制御
するタスク管理方式に関する。

【０００２】

【従来の技術】今日、計算機や制御用装置等の大規模な
制御システムにおいて、制御機能の多様化に伴って複雑
な内部構造を持つソフトウェアを管理する為、あるいは
ソフトウェアの標準化に対応する為、これらのソフトウ
ェアをいくつかの階層に分けて実装している。例えば、
各種通信制御やデータ通信を行う通信用ソフトウェアも
プロトコル等の階層化に対応してそれぞれ異なった実行
優先順位が付加されたタスクを各層別に処理し、さらに
各層間のインタフェースをとることにより総合的な機能
を実現している。この階層化された通信用ソフトウェア
の一般的な構成を図５に示す。

【０００３】同図において、上位層、中位層、下位層は
各プロトコルのレベルの相違に基づいた階層構造を成し
ている。また、各層には他の層から転送されてきたデー
タを処理中のデータとして一時的に格納する専用のバッ
ファが割り当てられている。そして、各層のバッファの
容量はシステム動作時の性能や効率等を考慮に入れて最
適な値が層別に設定されている。

【０００４】タスクＡ、タスクＢ、タスクＣはそれぞれ
上位層、中位層、下位層に属し、例えばそれぞれ異なる
プロトコルによる通信機能に関する処理を各々のタスク
に付加された実行優先順位である実行レベルに従って行
う。実行レベルは通常各層に属するタスクの効率的な処
理に最も適した値が決められており、タスク生成時に主
記憶装置内に設けられる、例えばタスク制御ブロックに
格納される。

【０００５】ここで、各タスクの実行順位は、従来以下
の方式により設定されている。すなわち、システム初期
化時に層別に実行レベルを指定し、この値を静的に固定
して運用するものである。例えば、図５の例で説明する
と、同図ではタスクＡに実行レベル１を付加し、タスク
Ｂに実行レベル２を付加し、タスクＣに実行レベル３を
付加している。そして、数値が大きいほど実行優先順位
が高く、この実行レベルは固定的である。つまり、タス
クＣが一番実行優先順位が高く、従って最初にスケジュ
ーラからＣＰＵ（中央処理装置）等の使用権が与えら
れ、タスクＣが処理された後、二番目の実行優先順位で
あるタスクＢが実行され、最後に一番実行優先順位が低
いタスクＡが実行される。尚、各層のバッファ間の矢印
は、処理が終ったデータのやりとりを示し、これは各バ
ッファの容量に応じて行われる。

【０００６】

【発明が解決しようとする課題】しかしながら、上述の
タスク管理方法では、バッファの使用状況に依らず一定
の実行優先順位を固定的に付加する方式である為、円滑
な処理を妨げ、システム全体の性能を低下させることが
ある。例えば、このことを上述の図５の例で説明する。

【０００７】例えば、タスクＢの実行により中位層での
処理を完了したデータが上位層に転送される場合を考え
ると、上位層のバッファに十分な空きがあれば直ちに転
送が行われる。しかし、空きがない場合、上位層のバッ
ファ内のデータが処理、又は他に転送されて上位層のバ
ッファに空き領域ができるまで、タスクＢは処理を停止
し、実行状態から待ち状態へと移行する。この為、次に
高い実行レベルを持つタスクＡは実行可能状態から実行
状態に移り上位層のバッファのデータを処理し、例えば
中位層等へ転送する。これにより上位層のバッファに空
きができ、タスクＡより実行レベルの高いタスクＢがタ
スクＡの処理を中断させ、待ち状態であったデータ転送
処理を再開する。

【０００８】このようにタスクの実行レベルを固定的に
設定し、優先順位に基づいて処理を実行することは、上
述した様に上位層のバッファが大量のデータを抱え込む
ことになり、例えば、上述の様にタスクＡとタスクＢが
互いに処理の実行と中断を繰り返し、システムの処理効
率を低下させる。さらに、最悪の場合には、各層のバッ
ファに空き領域がなくなり、データを取りこぼし、シス
テムがデッドロックを起こす危険性もある。

【０００９】本発明は、実行レベルの比較的低い層のバ
ッファが大量のデータを抱え込んだ場合でもシステム全
体の効率を損なわず、データの取りこぼしやシステムの
デッドロックを回避するタスク管理方式を提供すること
を目的とする。

【００１０】

【課題を解決するための手段】本発明は、実行レベルの
異なる階層化された複数のタスクと、該複数のタスクに
より処理されるデータを格納するために各層毎に設けら
れたバッファと、該バッファの使用量の閾値を設定する
閾値設定手段と、該閾値設定手段が設定した閾値を外れ
た時前記タスクの実行優先順位を変更する変更制御手段
とで構成されている。

【００１１】また、上記閾値設定手段は、例えばバッフ
ァ容量に応じたバッファ上限値と下限値を設定し、変更
制御手段はバッファ使用量を一定周期で読み出し、その
値に応じてタスクの実行レベルを管理する監視タスクで
構成され、監視タスクは処理実行中の各タスクのバッフ
ァ使用量を監視し、バッファ使用量が上記バッファ上限
値、又は下限値を外れた時、タスクの実行優先順位を変
更する。

【００１２】例えば、あるバッファのバッファ使用量
が、そのバッファ上限値を越えることにより、上記監視
タスクは当該バッファが大量のデータを格納しており、
空きがわずかであることを認識し、タスクの実行優先順
位を上げる。また、あるバッファのバッファ使用量が、
バッファ下限値より低い時、当該バッファに対応するタ
スクの実行レベルを引き下げる。

【００１３】さらに、各タスクの現在の実行レベルであ
るカレント実行レベル、前記初期化時の実行レベル、そ
のタスクの属する層のバッファの前記バッファ上限値、
バッファ下限値、バッファ使用量等を格納するタスク監
視テーブルを設け、前記監視タスクが当該タスク監視テ
ーブルの各パラメータを随時変更することにより、効率
よくタスクの管理を行う方式とすることもできる。

【００１４】

【作用】監視タスクが定期的にバッファ使用量とバッフ
ァ上、下限値を比較することにより、例えば比較的実行
レベルの低い層においてバッファが大量のデータを抱え
込み、容量をオーバーしそうな場合、これを事前に察知
し、初期化時に層別に指定されたタスクの実行レベルを
バッファ使用量に応じて変更し、例えば容量がオーバー
しそうになったバッファのデータを優先的に処理するこ
とができる。監視タスクが実行レベルの低い層の使用バ
ッファ量を監視し、その使用量に応じてタスクの実行レ
ベルを変更するので、各層におけるデータバッファの使
用量の片寄を解消する。この処理により、タスクの実行
を中断することなく、システム全体の性能を向上させる
ことができ、さらにバッファの容量オーバーによるデー
タの取りこぼしや、システムのデッドロック等の最悪の
事態を回避することができる。

【００１５】

【実施例】以下、本発明の一実施例について、図面を参
照しながら説明する。図１は本実施例のタスク管理方式
を説明する概略構成図である。同図において、上位層、
中位層、下位層は通信用ソフトウェアにおいて、例えば
通信機能等の相違により階層化された各ソフトウェア層
であり、処理が完了していないデータを格納しておくた
めに、それぞれバッファ１−１、バッファ１−２、バッ
ファ１−３を有する。各々のバッファには、システムの
初期化時にバッファ上限値とバッファ下限値が設定さ
れ、監視タスクがタスクの実行レベルを変更する際に閾
値として用いられる。具体的には、タスクＡ、タスク
Ｂ、タスクＣはそれぞれ上位層、中位層、下位層に属
し、例えば上位層はユーザレベルプロトコルであり、通
信処理におけるオペレータとの処理手順のプロトコルで
ある。また、中位層は例えばネットワークレベルプロト
コルであり、通信処理におけるコンピュータ間の処理手
順のプロトコルである。さらに、下位層は例えばデータ
リンクレベルプロトコルであり、通信処理におけるデー
タ処理手順を示す。

【００１６】また、各層には初期化時、実行レベルとし
て実行レベル１、実行レベル２、実行レベル３がそれぞ
れ付加されている。すなわち、タスクＡは実行レベル１
であり、タスクＢは実行レベル２であり、タスクＣは実
行レベル３である。また、監視タスクは最も高い優先順
位で実行できるよう、例えば実行レベル６が付与されて
いる。

【００１７】尚、各バッファの斜線部分は現在のバッフ
ァ使用量を表し、各バッファ間の矢印は必要に応じてデ
ータの転送が行われることを表す。監視タスクは一定時
間毎にバッファ１−１及びバッファ１−２のバッファ使
用量を読み出し、それぞれのバッファ上限値と比較する
構成である。

【００１８】また、図１の状態は、バッファ１−１のバ
ッファ使用量がバッファ上限値を越えているため、この
まま放置すれば、さらに他層からデータが転送されるこ
とによって、バッファ使用量がバッファ容量に達してし
まう状態を示す。尚、バッファ１−３のバッファ使用量
が読み出しの対象となっていないのは、タスクＣの初期
化時の実行レベルが他の層よりも高く、バッファ１−３
のデータが常時優先的に処理されるからである。勿論、
バッファ１−３のバッファ使用量を読み出すことにより
タスクＣの実行レベルを変更する方式としてもよいこと
は言うまでもない。

【００１９】また、図２は上述の監視タスクが効率よく
タスクの実行レベルを管理するために主記憶装置内に設
けられたタスク監視テーブルの一例である。同図におい
て、「初期化時の実行レベル」は、システム初期化時に
オペレーティングシステムやモニタにより指定された各
層の実行レベルであり、各タスクの生成時に付加される
静的な固定値である。また、「バッファ上限値」と「バ
ッファ下限値」も初期化時に設定される定数値であるが
必要に応じて監視タスクにより変更できる。

【００２０】「バッファオーバー検出回数上限値」と
「実行レベル変更回数上限値」はバッファの使用量がバ
ッファ上限値を越える頻度を評価するための閾値でタス
クの生成時に設定される。尚、「実行レベル変更回数上
限値」は固定値であり、「バッファオーバー検出回数上
限値」は監視タスクにより変更できる場合もある。

【００２１】一方、「カレント実行レベル」はバッファ
使用量読み出し時に対応する動的な実行レベルであり、
「バッファオーバー検出回数」はバッファ使用量がバッ
ファ上限値を越えた回数を示し、「実行レベル変更回
数」は監視タスクによりカレント実行レベルが引き上げ
られた回数を示す。

【００２２】これらのパラメータはタスクＡ、タスク
Ｂ、タスクＣのみならず監視タスクの監視対象となるタ
スクが他にあれば、そのタスクについても同様に設定さ
れる。尚、図２に示す具体的な数値については後述す
る。

【００２３】以下、本実施例の動作を説明する。図３は
上述した一実施例の監視タスクの詳細な処理内容を示す
フローチャートである。監視タスクは一定周期で起動
し、各層のタスク毎にステップＳ１からステップＳ１６
までの処理を逐次行い、初期化時の実行レベルが最も高
い下位層を除く全ての層についての処理が終わると終了
する。

【００２４】まずステップＳ１において対象とするタス
クが使用しているバッファのバッファ使用量を読み出
し、タスク監視テーブルに格納する。次に、Ｓ２におい
てバッファ使用量をタスク生成時に既に格納されている
バッファ上限値と比較し、これがバッファ上限値を越え
ている場合Ｓ３に進み、越えていなければＳ１１に進
む。

【００２５】Ｓ３においては、前回の監視タスク終了時
にタスク監視テーブルに格納されていたカレント実行レ
ベルを他の層のタスクのカレント実行レベルと比較し、
もしより高いカレント実行レベルをもつタスクが他にあ
れば、Ｓ４に進んでバッファオーバー検出回数に１を加
え、そうでなければＳ１６へ進む。尚、タスク生成時に
おいてはカレント実行レベルは初期化時の実行レベルに
一致し、バッファオーバー検出回数は０に設定されてい
る。Ｓ３でカレント実行レベルが他のタスクより高いと
きＳ１６に移行するのは、既にバッファ内のデータが優
先的に処理されており、それ以上実行レベルを引き上げ
る必要がないからである。

【００２６】Ｓ４において変更されたバッファオーバー
検出回数は、Ｓ５においてバッファオーバー検出回数上
限値と比較され、これを越えている場合バッファ内のデ
ータの処理が滞っているものと判断し、Ｓ６に進んでカ
レント実行レベルを他の層のタスクより高くする。これ
により該当するタスクの処理を優先させ、バッファ使用
量の減少を促進することができる。一方、バッファオー
バー検出回数上限値を越えていない場合は、次回の監視
までにバッファ使用量が減少するかも知れないので、今
回はカレント実行レベルの引き上げを見合わせＳ１６へ
進む。

【００２７】Ｓ６においてカレント実行レベルを引き上
げた後Ｓ７において実行レベル変更回数に１を加え、そ
の結果をＳ８において実行レベル変更回数上限値と比較
する。これは、同一タスクに対してカレント実行レベル
が頻繁に引き上げられたかどうか、すなわち、処理すべ
きデータがバッファに溜まりバッファ使用量が頻繁にバ
ッファ上限値を越えたかどうかを評価するためである。
あまりにも高い頻度でカレント実行レベルを引き上げる
時、つまり、実行レベル変更回数が実行レベル変更回数
上限値を越えた時は、そのタスクに負荷が集中している
か、又はバッファ上限値が小さすぎることが考えられ、
Ｓ９に進んでタスク監視テーブルのパラメータを変更す
る必要がある。一方、実行レベル変更回数上限値を越え
ない時はＳ１６に進む。尚、実行レベル変更回数はタス
ク生成時に０に設定されている。

【００２８】Ｓ９において、例えばバッファオーバー検
出回数上限値を現行の値より小さくすることにより、次
回以後カレント実行レベルの引き上げをさらに促進し、
データの処理をさらに速めることができる。このバッフ
ァオーバー検出回数上限値は最終的に０まで下げること
ができ、この場合バッファ使用量が一度でもバッファ上
限値を越えるとＳ６に進み、カレント実行レベルが引き
上げられる。

【００２９】一方、Ｓ９において、又は現行のバッファ
上限値をそのタスクにとってより適正な値に引き上げる
ことにより、バッファオーバー検出回数の増加を抑制す
ることができ、無駄なカレント実行レベルの引き上げを
防止することができる。

【００３０】また、Ｓ９がＹＥＳの場合、カレント実行
レベル引き上げのための判断基準（諸条件）が変わった
わけであるから、Ｓ１０において実行レベル変更回数を
クリアし、０に戻してＳ１６へ進む。

【００３１】一方、バッファ使用量がもともと少ない
か、又はデータの処理が進んで少なくなり、Ｓ２からＳ
１１に進んだ場合、Ｓ１１においてバッファ使用量をバ
ッファ下限値と比較する。もしこれがバッファ下限値以
下の場合はＳ１２に進み、そうでなければＳ１６に進
む。

【００３２】Ｓ１２においては、カレント実行レベルを
初期化時の実行レベルと比較し、初期化時の実行レベル
より高ければＳ１３に進んでバッファオーバー検出回数
より１を減じる。これは前回の監視タスク終了時以前に
Ｓ６により少なくとも一度はカレント実行レベルが引き
上げられたことがある場合に相当し、バッファオーバー
検出回数はＳ１２において０より大きい値を持っている
はずである。もし一度もカレント実行レベルが引き上げ
られたことがなければ、そのタスクのカレント実行レベ
ルは初期化時の実行レベルに一致しているわけであるか
らＳ１５の処理を必要としないので直ちにＳ１６へ進
む。

【００３３】Ｓ１４においては、バッファオーバー検出
回数が０になったかどうかを判定し、０であればデータ
の処理が進んでバッファ使用量がバッファ下限値を下回
る状態が続いていると判断し、Ｓ１５に進んでカレント
実行レベルを初期化時の実行レベルに戻す。こうして対
応するバッファに抱え込まれていた大量のデータの処理
がほぼ終わった時、より高い初期化時の実行レベルをも
つ他の層のタスクに優先順位を譲るわけである。バッフ
ァオーバー検出回数が０でなければ、引き続き優先的に
データ処理を行うためカレント実行レベルを保持しＳ１
６へ進む。

【００３４】以上、Ｓ１からＳ１５までの処理をタスク
Ａ、タスクＢのそれぞれについて行い、Ｓ１６において
全ての層のタスクについて処理が終了したと判定したと
き監視タスクを終了する。

【００３５】この実施例の監視タスクはタスクのバッフ
ァ上限値、バッファオーバー検出回数上限値と共に、カ
レント実行レベルを動的に制御することを特徴としてい
る。次に、タスクＡ、タスクＢに対する上述の処理を、
図２に示す具体的な数値を用いて説明する。尚、本実施
例ではタスクＣのバッファ使用量を読み出していないた
め、図２のタスクＣについては、初期化時の実行レベル
とカレント実行レベルのみが格納されている。

【００３６】まず、タスクＡについてはカレント実行レ
ベルは初期化時の実行レベルに等しく１のままである
が、バッファオーバー検出回数は前回までの監視タスク
により、例えば３まで増加しているものとする。Ｓ１に
おいて読み出されたバッファ１−１のバッファ使用量は
同図に示すように、例えば８０となっており、タスクＡ
のバッファ上限値７０より大きいことがわかる。また、
Ｓ３の時点ではカレント実行レベルはタスクＢ、タスク
Ｃのカレント実行レベルより低いわけであるから、Ｓ４
にてバッファオーバー検出回数に１を加えこれを４とす
る。Ｓ５においてバッファオーバー検出回数が先に設定
されたバッファオーバー検出回数上限値、例えば３を越
えていると判定され、Ｓ６において、カレント実行レベ
ルがタスクＣより高い４に引き上げられる。これにより
タスクＡは以後Ｓ１５で初期化時の実行レベルに戻され
るまで最優先で処理されることになる。このときＳ７に
より実行レベル変更回数は１となる。Ｓ８で実行レベル
変更回数上限値は１０であるからＳ９には進まず処理を
終える。Ｓ１６においてタスクＢに対する処理がまだで
あるからＳ１に戻る。

【００３７】次にタスクＢが処理するバッファ１−２の
バッファ使用量は図２に示されているように、例えば４
０であり、バッファ上限値７０より小さくバッファ下限
値３０より大きい。この場合はカレント実行レベル等の
パラメータは変更を受けず、直ちにＳ１６へ進み監視タ
スクを終了する。

【００３８】その後何回か定期的に監視タスクが起動さ
れた後、バッファ１−１のデータ処理が進んでバッファ
使用量が、例えば２０のようなバッファ下限値３０以下
の値になった時、Ｓ１３にてタスクＡのバッファオーバ
ー検出回数が減じられ、さらに３回連続してその傾向が
続けばバッファオーバー検出回数が０となるので、Ｓ１
５にてカレント実行レベルは４から１に引き下げられ
る。

【００３９】こうした動作を繰り返し１１回目のカレン
ト実行レベルの引き上げが行われると、Ｓ８においてタ
スクＡの実行レベル変更回数が実行レベル変更回数上限
値１０を越えるので、Ｓ９に進みパラメータの変更が行
われ、Ｓ１０にて実行レベル変更回数がクリアされる。
Ｓ９では、例えばバッファオーバー検出回数上限値が２
に下げられたり、或いはバッファ上限値が８０に引き上
げられたりする。

【００４０】ここで、特に監視タスクがＳ６において、
カレント実行レベルを引き上げる処理を図４（ａ）、
（ｂ）に示す。タスクのカレント実行レベルは、主記憶
装置内の実行レベル管理ブロックにより管理されてい
る。実行レベル管理ブロックには各実行レベル毎にター
ミナルが用意され、タスクの起動要求があると、オペレ
ーティングシステムやモニタがそのタスクのタスク制御
ブロックを対応する実行レベルのターミナルに連結す
る。タスク制御ブロックには現在のタスク状態や割込み
禁止状態等を頻繁に参照できる情報が格納されており、
タスク管理ブロックのターミナルに連結されることによ
りタスク状態は実行可能状態へと移行する。

【００４１】図４(a) はタスクＡ、タスクＢ、タスクＣ
のカレント実行レベルがそれぞれの初期化時の実行レベ
ルに一致している時、これらのタスク制御ブロックが対
応する各ターミナルに連結されている様子を示してい
る。このまま各タスクが起動さされると、スケジューラ
は実行レベル管理ブロック内のより高い実行レベルのタ
ーミナルに連結されているタスクから順に実行する。同
図(a) ではタスクＣ制御ブロックが実行レベル３のター
ミナルに連結されているので、タスクＣが最初に実行さ
れ、完了するとタスクＣ制御ブロックはターミナルから
切り離される。次に、破線で示される如くタスクＢ、タ
スクＡの順に実行されていく。

【００４２】ところが、タスクＣよりも高い実行レベル
６を持つ監視タスクが、タスクＡの処理対象であるバッ
ファ１−１のデータ処理が滞っていること、つまりバッ
ファ使用量がバッファ上限値を越えていることを検出す
ると、このとき監視タスクはＳ６において、タスクＡ制
御ブロックを実行レベル１ターミナルから切り離し、実
行レベル４ターミナルに連結する。この状態を示す図が
同図（ｂ）であり、これを受けてタスクＡには優先的に
実行権が与えられ、バッファ１−１のデータを処理す
る。タスクＣ、タスクＢの処理は、Ｓ１５にてタスクＡ
制御ブロックが実行レベル４のターミナルから切り離さ
れた後となる。

【００４３】以上詳述したように、本実施例によれば監
視タスクによる実行レベルの引き上げ操作により、初期
化時において比較的小さな実行レベルを与えられた層の
バッファにデータが溜まった場合でも、これを優先的に
処理させることができる。またタスク監視テーブルのパ
ラメータを変更することにより、実行レベルの引き上げ
頻度を調節することができる。

【００４４】

【発明の効果】本発明によれば、階層化されたソフトウ
ェアの各層がバッファをもつシステムにおいて、実行優
先順位の比較的低い層のバッファが大量のデータを抱え
込んだ場合にも、監視タスクがバッファ上限値を基準に
してタスクの実行レベルを動的に制御するタスク管理方
式により、システム全体の性能を損なわずに溜まったデ
ータの処理を促進し、データの取りこぼしやシステムの
デッドロックを回避することができる。

【図面の簡単な説明】

【図１】一実施例の階層化された通信用ソフトウェアの
一般的な構成図である。

【図２】一実施例のタスク監視テーブルである。

【図３】一実施例の監視タスクによる処理フローチャー
トである。

【図４】一実施例の監視タスクによる実行レベル引き上
げ操作の説明図である。

【図５】従来の通信用ソフトウェアの一般的な構成図で
ある。

【符号の説明】

１−１，１−２，１−３ バッファ

Claims (1)

【特許請求の範囲】
1. 【請求項１】 実行レベルの異なる階層化された複数の
   タスクと、 該複数のタスクにより処理されるデータを格納するため
   に各層毎に設けられたバッファと、 該バッファの使用量の閾値を設定する閾値設定手段と、 該閾値設定手段が設定した閾値を外れた時、前記タスク
   の実行優先順位を変更する変更制御手段と、 を有することを特徴とするタスク管理方式。