JPH0855036A

JPH0855036A - タスクスケジューリング方法

Info

Publication number: JPH0855036A
Application number: JP6210632A
Authority: JP
Inventors: Koichi Shibata; 巧一柴田; Mitsuo Asai; 光男浅井; Mikiko Satou; 未来子佐藤; Yoshihiro Takiyasu; 美弘滝安; Atsushi Saito; 温斉藤
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1994-08-11
Filing date: 1994-08-11
Publication date: 1996-02-27

Abstract

(57)【要約】【目的】マルチタスクで処理を行なう処理装置上でリア
ルタイム処理を実行する場合において、リアルタイム性
と、タスク移行のオーバーヘッド時間の削減とを両立す
るスケジューリング方法を提供することを目的とする。【構成】タスクの実行順序を決定するスケジューラと呼
ばれるタスクを設ける。スケジューラは、各タスクから
の要求をその終了デッドライン順に並べて表を作成し、
その順でタスクを実行すると仮定した場合の全タスクの
終了予想時刻と、直前に実行したタスクと連続性の高い
タスクを次に実行すると仮定した場合の終了予想時刻を
求める。後者の終了予想時刻の方が早く、且つ各タスク
のデッドラインを守ることができる場合に、連続性の高
いタスクに先に実行許可を与える。【効果】連続性の高いタスクが次々と優先的に選択され
るため、タスクの移行のオーバーヘッドが削減できる。
緊急のタスクの要求がある場合には、そのタスクが先に
実行されるため、デッドラインを守ることができる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、複数のタスクを擬似的
に同時に処理する情報処理装置において、限られた処理
装置資源を時分割で利用する場合の利用順序を決定する
タスクスケジューリング方法に関する。特に、処理する
べきタスクに明確な処理終了期限が存在するいわゆるリ
アルタイム処理を効率よく且つ終了期限を守って実行す
る装置に有効なものである。

【０００２】

【従来の技術】従来から、複数のタスクまたはプロセス
を擬似的に同時に処理するいわゆるマルチタスクの計算
機におけるタスクの実行順序を決定する方法つまりスケ
ジューリングについては、種々の検討がなされてきた。

【０００３】現在多くの計算機で行われているスケジュ
ーリング方式は、「多重レベル帰還型の巡回スケジュー
リング方式」と呼ばれるものである。この方式のアルゴ
リズムは、タスクそれぞれに優先度をもたせ、優先度の
高いタスクから順に実行し、同じ優先度を持つタスクに
ついては、それぞれ一定の時間づつ巡回的に実行時間を
与えるという方式である。

【０００４】しかしながらこの方式では、それぞれのタ
スクがいつ終了するかは予測不能であり、タスクに明確
な終了期限（その時点までに該タスクが処理が終了する
ことが必要な期限）いわゆる終了デッドラインがある場
合（いわゆるリアルタイム処理が必要な場合）には適用
不能である。このようなリアルタイム処理を必要とする
場合におけるスケジューリング方法については、別の方
法が必要である。また、タスクの順序によって効率に影
響が発生する点も考慮されるべきである。それらについ
て従来例を以下説明する。

【０００５】まず、リアルタイム処理に関するスケジュ
ーリングの従来例を説明する。第一の従来例としてレー
トモノトニック方式がある。この方式は、処理しようと
するタスクが周期的であり、且つその周期が比較的安定
している場合に、良好な結果が得られるとされている方
式である。この方式については、次の文献に紹介されて
いる。

【０００６】J.P.Lehoczky,L.Sha,and Y.Ding, "The ra
te-monotonic scheduling algorithm:Exact Characteri
zation and average case behavior",Department of St
atistic,Carnegie Mellon University,1987、および C.
L.Liu and J.W.Layland,"Scheduling algorithms for m
ultiprograming in a hard real time environment",Jo
urnal of the ACM,Vol.20,No.1,1973.

【０００７】この方式は、実行周期の最も短いタスクに
最高の優先順序を与えるという方式である。あらかじめ
投入されるタスクの内容がわかっている場合には、比較
的簡単にスケジュール可能性を判定可能のため、デッド
ラインを守ることが出来なくなる新たな要求を拒絶する
ことで、それぞれのタスクの実行時間を保証することが
できる。

【０００８】第二の従来例として、アーリエスト・デッ
ドライン・ファースト（Earliest Deadline First）方
式がある。これはデッドラインに最も近いタスクから順
に実行権を与える方式である。この方式については以下
の文献で紹介されている。

【０００９】Henn,"Feasible Processor Allocation in
a Hard-Real-Time Environment",The Journal of Real
-Time Systems, Vol.1, pp. 77-93, copyright 1989, K
luwer Academic Publishers.、および Xu and Parnas,
"Scheduling Process withRelease Times, Deadlines,
Precedence, and Exclusion Relations", IEEE Transa
ctions on on Software Engineering, Vol.16, No.3, M
arch 1990, pp.360-369.

【００１０】この方式は、各タスクがデッドラインを守
ることができるようにスケジューリングする方式として
は、最も直接的で確実である。しかしながら、スケジュ
ーリングそのものの処理量が大きいという問題がある。
この方式においてスケジューリングの処理量を削減する
方法については、例えば特開平5-274162号でも記述され
ている。ただし、本発明はスケジューリング処理量の削
減に関するものではない。

【００１１】また、この方式では、タスクの処理順序に
よって総合的な処理効率に大きい影響を与えることが多
い。これは、あるタスクから別のタスクへの移行時間い
わゆるオーバーヘッド時間が、タスクの順序によって大
きく異なることに起因する。例えば、ディスクの読出に
関するタスクにおいては、読み出す情報が格納されてい
る物理的位置が離れているほどタスク移行に必要なオー
バーヘッド時間が大きくなる。この点に着目して、より
効率の高いスケジューリングも考案されている。以下、
そのような例の一つである第三の従来例を示す。

【００１２】第三の従来例は、エレベータ型スケジュー
リングである。これは、第一の従来例および第二の従来
例とは異なり、磁気ディスクのアクセスのスケジューリ
ング方式であるが、本質的にはタスクスケジューリング
と同等の問題を持っている。この方式は、次の文献に紹
介されている。

【００１３】D.D.Kandlur and M.-S. Chen and Z.-Y.Sh
ae. "Design of aMultimedia Storage Server. IBM Res
earch Report, June 1991.

【００１４】この方式は、タスクの要求順にかかわら
ず、ディスクの内周から外周、あるいは外周から内周に
向かって、順にアクセスしてゆく方式である。この方式
によると、要求順と異なる順でアクセスされる可能性が
あるという不都合が生じる反面、ディスクのシークタイ
ムによるオーバーヘッド時間を削減できる。

【００１５】

【発明が解決しようとする課題】第一の従来例の問題点
として、周期的でないタスクいわゆる非周期タスクの取
り扱いが困難であることが指摘されている。この点は、
次の文献にも指摘され一つの解決案が提案されている。

【００１６】B.Sprunt,L.sha and J.P.Lehoczky, "Aper
iodic Task Scheduling for Hard-Real-Time Systems",
The Journal of Real-Time Systems,Vol.1,No.1,1989.

【００１７】ただしこの文献で示される解決策は、非周
期的タスクも一応反応よく扱うことが可能になる、とい
うことであり、当該非周期的タスクがデッドラインに間
に合うことを保証するものではない。つまり、非周期的
な要求に対してリアルタイム性は保証されない、という
問題が残る。

【００１８】第二の従来例の問題点として、連続性の高
いタスクの間に、必要以上に他のタスクが割り込む可能
性がある点が挙げられる。これによりタスクの移行のオ
ーバーヘッドが増加し、システムの性能を低下させる。
連続性の高いタスクを先に片づけた後で、もう一つのタ
スクを実行した方が、結果的に早くしかも両方のデッド
ラインを守ることが出来る場合も多い。

【００１９】第三の従来例の問題点は、タスク移行のオ
ーバーヘッドの削減は実現できるものの、各タスクのデ
ッドラインを保証出来ない点である。

【００２０】そこで本発明の目的は、各タスクの要求す
る終了デッドラインを満たしながら、連続するタスクは
なるべく連続して処理を行い、システムの平均性能とリ
アルタイム性を両立するスケジューリング方法を提供す
ることにある。

【００２１】

【課題を解決するための手段】実際の処理を行うタスク
とは独立に、各タスクの実行順序を決定するスケジュー
ラと呼ばれるタスクを設ける。スケジューラは、各タス
クからの実行開始要求を受け付け、その要求に含まれる
デッドラインに関する情報や、タスク間の連続性に関す
る情報からタスクの実行順序を定め、その順序に従って
タスクの実行を許可する。その決定時のアルゴリズムは
以下の通りである。

【００２２】スケジューラが起動されると、各タスクか
らの実行許可要求をその開始デッドライン（開始期限）
順に並べて保持する。基本的には、その開始期限順にタ
スクが実行許可される。一方、例えば、あるタスクが終
了して次に実行するタスクを選択する際には、開始期限
順に並べて保持してある実行許可要求から、現在実行中
または直前に実行したタスクと連続性の最も高いタスク
を次に実行する候補として選択する。そして、その候補
のタスクを先に実行してもよくかつそのようにした方が
全体の効率が向上する場合に、その候補のタスクに先に
実行許可を与えるようにする。

【００２３】候補のタスクを先に実行してよいかどうか
は、その候補のタスクを次に実行したと仮定してそれ以
降の各タスクを順に実行したときの各タスクそれぞれの
終了予定時刻を求め、それらの終了予定時刻が各タスク
の終了期限内であるかを確認することにより判別する。

【００２４】また、その候補のタスクを先に実行した場
合の全体の処理時間を求め、候補のタスクを先に実行す
ることなく開始期限順に各タスクを実行した場合の全体
の処理時間と比較し、処理時間が減少するときに、その
候補のタスクを先に実行許可するようにする。実行許可
を与えたらスケジューラは処理を終了し、他のタスクに
実行権を移す。

【００２５】なお、スケジューラは、次の場合の一つま
たは複数が生じた場合に起動される。・一定時間おき・他のタスクが終了したとき・タスクの実行要求が発生したとき・その他割り込み等でシステムの状態が変化したとき

【００２６】

【作用】本発明によれば、各タスクの終了デッドライン
が守られる限り、連続性の高いタスクが次々と選択され
るため、タスクの移行のオーバーヘッドが削減できる。
一方、緊急度の高いタスク実行要求がある場合には、終
了デッドラインの近いタスクが選択されるため、緊急度
の高いタスクが優先実行される。従って、そのデッドラ
インを守ることができる。

【００２７】

【実施例】以下、図面を用いて本発明の実施例を説明す
る。

【００２８】まず、本発明の一実施例を説明する前に、
本実施例の前提条件を説明する。本実施例では、一般的
な計算機において、一つの計算資源を複数のタスクが順
番待ちする場合について説明する。計算資源には、ＣＰ
Ｕ、ファイル装置、通信路、通信インターフェース装
置、主記憶装置、およびバス等がある。本実施例での前
提として、タスクスケジューリングの対象となる計算資
源は一つであるとするが、スケジューリング機構をそれ
ぞれに設けることにより容易に複数に拡張可能である。
ただしその場合は、一つのタスクが複数の計算資源を同
時には要求しないものとする。

【００２９】なお、本実施例ではスケジューリング処理
を計算機内の処理ステップの組み合わせで実現している
が、処理の一部分をハードウェアで置き換えることも可
能である。その他、本発明の一部に対し、その本質的機
能から逸脱しない範囲で、各種の変更を加えることもで
きる。

【００３０】本実施例が処理対象としているタスクの性
質について説明する。タスクで行われる処理は、比較的
小さな分割可能な単位に細分化されて時系列的に実行さ
れる。細分化された各処理をサブタスクと呼び、そのう
ちｎ番目に実行されるサブタスクを以下Ｐ（ｎ）で表
す。各サブタスクには、それぞれ終了期限デッドライン
Ｔｄ（Ｐ（ｎ））があるとする。また、各サブタスクＰ
（ｎ）の実行順序は可逆であるとする。

【００３１】一般的に、計算機での処理に要する時間
は、その処理そのものの大きさや複雑さから決まる処理
時間と、その処理を起動するまでに要するオーバーヘッ
ド時間との和である。オーバーヘッド時間は、処理の順
序に依存する場合が多く、特に直前の処理に大きく左右
される。本実施例では、処理に要する時間を処理時間と
オーバーヘッド時間からのみ構成されるとし、その他の
影響は無視できるほど小さいとする。オーバーヘッド時
間も直前の処理との関係のみで決まるものとし、その他
の影響は小さいとして無視する。

【００３２】以下、サブタスクＰ（ｎ）の処理時間をＴ
ｐ（Ｐ（ｎ））、サブタスクＰ（ｎ−１）からサブタス
クＰ（ｎ）に移行する場合のオーバーヘッド時間をＴｏ
（Ｐ（ｎ−１），Ｐ（ｎ））とする。このとき、サブタ
スク全体に要する時間は、Ｔｐ（Ｐ（ｎ））＋Ｔｏ（Ｐ
（ｎ−１），Ｐ（ｎ））となる。現在時刻をＴとした場
合に、終了予定時刻は、Ｔｅ（Ｐ（ｎ））＝Ｔ＋Ｔｐ
（Ｐ（ｎ））＋Ｔｏ（Ｐ（ｎ−１），Ｐ（ｎ））であ
る。これにより、各サブタスクの処理時間と処理順序が
決まれば、それぞれの終了予定時刻を求めることが出来
る。

【００３３】また、全サブタスク間に関してオーバーヘ
ッド時間Ｔｏ（Ｐ（ｎ−１），Ｐ（ｎ））を求めるため
には、サブタスクが互いの内部状態を必ずしも知る必要
は無く、多くの場合には各サブタスク独立のパラメータ
から求めることができる。例えばファイルアクセスの場
合には、各サブタスクにおいてアクセスする物理的位置
がわかれば、その間の移行にかかるオーバーヘッド時間
はおおよそ計算が可能である。本実施例ではこのような
場合を対象とし、オーバーヘッド計算に必要なパラメー
タを要求時に提示させる。一般的には、オーバーヘッド
時間は、サブタスクの数×サブタスクの数の正方行列の
形式（例えば、後述する図７）で表すことが出来る。

【００３４】図１は、本発明のタスクスケジューリング
方法を適用した一実施例である計算機システム内でのタ
スク構成例を示す。処理タスク１０１ａ，１０１ｂ，１
０１ｃは、それぞれ独立したリアルタイムタスクであ
る。また、スケジューラ１０２は、リアルタイムタスク
の活性化順序（実行順序）を決定する特殊なタスクであ
る。通常、時分割で利用する資源一つにつき一つのスケ
ジューラタスクを設ける。

【００３５】各処理タスク１０１ａ，１０１ｂ，１０１
ｃは、スケジューラ１０２に対し活性化許可要求（実行
許可要求）１０３ａ，１０３ｂ，１０３ｃを送り、活性
化許可フラグ１０８ａ，１０８ｂ，１０８ｃが立つまで
休止して待つ。活性化許可フラグ１０８ａ，１０８ｂ，
１０８ｃが（実行許可で）立つと、それぞれの処理タス
ク１０１ａ，１０１ｂ，１０１ｃは、処理のための資源
を確保し、処理を行った後、使用した資源を解放して終
了あるいは休止する。

【００３６】このときの処理タスクの動作例を、図２に
示すフローチャートを用いて説明する。なお、ここでは
図１の処理タスク１０１ａに着目してその動作を説明す
るが、処理タスク１０１ｂ，１０１ｃについても同様で
ある。

【００３７】他のタスクからタスク生成２０１される
と、スケジューリングの対象となる計算資源を要する処
理が必要かどうかをサブタスク必要性判定ステップ２０
２で判定する。必要ならば、活性化許可要求発生ステッ
プ２０３で、スケジューラ１０２に対し活性化許可要求
２０４（図１の活性化許可要求１０３ａに対応）を発生
し、再びサブタスク必要性判定ステップ２０２に戻り、
さらに計算資源を要するかどうか判定する。

【００３８】図３に、活性化許可要求２０４のパラメー
タ例を示す。３０１は、スケジューラ１０２に送られる
活性化許可要求２０４の具体的な構成を示す。活性化許
可要求３０１は、活性化を要求しているのかあるいは要
求を取り下げるのかを示すフラグ３０２、要求元のタス
クを識別するタスク識別子３０３、それぞれのタスクご
とのサブタスクを識別する要求番号３０４、そのサブタ
スクの完了時間期限を示す終了デッドライン３０５、そ
のサブタスクの処理に必要な予測処理時間３０６、およ
びタスク間の移行に伴うオーバーヘッド時間に関するパ
ラメータ３０７を含む。

【００３９】再び図２を参照して、必要な活性化許可要
求をすべて出し終わったら、サブタスク必要性判定ステ
ップ２０２から活性化許可待ちステップ２０５に進み、
休止して活性化されるのを待つ。

【００４０】スケジューラは、所定の処理を実行し（詳
しくは後述する）、活性化許可通知（実行許可通知）あ
るいは活性化不能通知（実行不能通知）２０７を送る。
この通知が、図１の活性化許可フラグ１０８ａに相当す
る。

【００４１】図２の処理タスクで、スケジューラからの
実行許可通知あるいは実行不能通知２０７を示す活性化
許可フラグ１０８ａを受けたら、ステップ２０５から要
求番号読みとりステップ２０８に進む。要求番号読みと
りステップ２０８で、受けとった活性化許可フラグ１０
８ａから要求番号３０４を読みとり、どのサブタスクに
ついての通知かを知る。活性化許可フラグには、どのサ
ブタスクに対する活性化許可（または活性化不能）通知
であるかを示す要求番号３０４が含まれているものとす
る。

【００４２】次に、その通知２０７が実行許可通知なの
かあるいは実行不能通知なのかを活性化不能判定ステッ
プ２０９で判定する。実行不能通知すなわち活性化不能
通知の場合は、処理不能時対応ステップ２１０で要求の
取り下げや再処理要求等の処理を行い、再びサブタスク
必要性判定ステップ２０２に戻る。実行許可通知すなわ
ち活性化許可通知の場合は、処理資源確保ステップ２１
１で、サブタスクに必要な資源の確保を試みる。次に、
確保出来たかどうかを確保成功判定ステップ２１２で確
認する。

【００４３】処理資源の確保に失敗した場合は、確保失
敗処理ステップ２１３で確保失敗に伴う再要求等の処理
を行った後、サブタスク必要性判定ステップ２０２に戻
る。ただし、本来スケジューラが活性化を許可したサブ
タスクについては、全ての資源は確保可能であるはずで
あり、順番待ちを伴うような資源であればスケジューラ
に管理されるべきである。つまりここで確保しようとす
る資源は、記憶領域等の確保成功がほぼ確実なものか、
待ってもスケジューリングに影響を与えないほど短時間
のものである。

【００４４】処理資源確保ステップ２１１で処理資源の
確保に成功した場合は、ステップ２１２で確保成功と判
断され、許可されたサブタスク本体２１４を実行する。
サブタスク本体２１４が終了すると、処理資源解放ステ
ップ２１５で一時的に確保した資源を解放し、サブタス
ク必要性判定ステップ２０２に戻る。

【００４５】サブタスク本体２１４の実行時にスケジュ
ーラからの時間切れ通知２１６を受けると、サブタスク
本体２１４は強制的に中断させられ、時間切れ割り込み
２１７を起こして、時間切れ処理ステップ２１８を開始
する。ここで処理の性質に応じて続行の要求や、要求の
取り下げ、再処理の要求等を行った後、サブタスク必要
性判定ステップ２０２に戻る。

【００４６】再び図１を参照して、スケジューラの動作
について説明する。スケジューラ１０２の起動するきっ
かけは、・一定時間おき・他のタスクが終了したとき・タスクの実行要求が発生したとき・その他割り込み等でシステムの状態が変化したときのうち一つ、あるいはいくつかが発生した時である。

【００４７】各処理タスクからの活性化許可要求１０３
ａ，１０３ｂ，１０３ｃは、活性化許可要求キュー１０
４で受け取られる。スケジューラ１０２が起動すると、
まず挿入並べ替えステップ１０５が動作する。挿入並べ
替えステップ１０５では、活性化許可要求キュー１０４
から、各処理タスクからの活性化許可要求１０３ａ，１
０３ｂ，１０３ｃを取り出して、タスク表１０６に挿入
する。

【００４８】図４は、挿入並べ替えステップ１０５の動
作を示すフローチャートである。図５は、タスク表１０
６の例である。

【００４９】タスク表１０６には、活性化許可要求３０
１に含まれる要求元タスク識別子３０３、要求番号３０
４、終了デッドライン３０５、予測処理時間３０６、オ
ーバーヘッド時間に関するパラメータ３０７と、スケジ
ューラ側で付加したサブタスク識別子、開始デッドライ
ン、終了予定時刻等が格納される。

【００５０】開始デッドラインとはそのタスクの開始期
限であり、そのタスクを終了デッドラインまでに終了す
るためにはいつまでに開始する必要があるか、そのデッ
ドラインを示す期限である。タスク表１０６に登録され
る各サブタスクＰ（０），Ｐ（１），…は、基本的に
は、開始デッドラインの昇順に並べられる。終了予定時
刻は、タスク表１０６に登録された順に各タスクを実行
した場合の各タスクの終了予定時刻を示す。

【００５１】以下、図４および図５を参照して、挿入並
べ替えステップ１０５の動作を説明する。

【００５２】スケジューラが起動４０１すると、まず活
性化要求キュー１０４を検索し、空であるかどうかをキ
ュー検索ステップ４０２で判定する。空である場合は、
挿入並べ替えステップ１０５は終了する。空でない場合
は、活性化許可要求読みとりステップ４０３で、活性化
許可要求キュー１０４から活性化許可要求３０１を読み
だす。

【００５３】次に、処理時間計算ステップ４０４で、予
想処理時間パラメータ３０６から予測処理時間（Ｔｐ）
を求める。さらに、開始デッドライン計算ステップ４０
５で、終了デッドライン３０５（Ｔｄ）と予測処理時間
（Ｔｐ）とから、そのサブタスクの開始デッドライン
（Ｔｄ−Ｔｐ）を求める。

【００５４】次に、挿入位置決定ステップ４０６で、タ
スク表１０６の中への挿入位置を決定する。タスク表１
０６ではすでに開始デッドラインの昇順に要求が並べ替
えられているため、バイナリサーチ等の手法により、開
始デッドラインの順序を守る様に挿入位置が決定され
る。以下、ここで挿入される位置がｎ番目と決定された
とし（ただし、まだ挿入は行なわない）、このサブタス
クをＰ（ｎ）とする。

【００５５】次に、移行オーバーヘッド時間計算ステッ
プ４０７で、オーバーヘッドに関するパラメータ３０７
を読み、直前のサブタスクＰ（ｎ−１）からサブタスク
Ｐ（ｎ）に移行するとしたときの移行オーバーヘッド時
間Ｔｏ（Ｐ（ｎ−１），Ｐ（ｎ））を計算する。本実施
例の前提として述べたように、移行オーバーヘッド時間
Ｔｏは、サブタスクＰ（ｎ）とＰ（ｎ−１）それぞれが
持つオーバーヘッドに関するパラメータ３０７から計算
できる。

【００５６】次に、直後オーバーヘッド時間計算ステッ
プ４０８で、当該サブタスクＰ（ｎ）から次のサブタス
クＰ（ｎ＋１）へ移行するとしたときのオーバーヘッド
時間Ｔｏ（Ｐ（ｎ），Ｐ（ｎ＋１））を求める。

【００５７】なお、この時点では、サブタスクＰ（ｎ）
をまだタスク表１０６に挿入してはいない。Ｐ（ｎ）を
ｎ番目の位置に挿入するときには、挿入前のｎ番目以降
のサブタスクＰ（ｎ），Ｐ（ｎ＋１），Ｐ（ｎ＋２），
…を１つずつ後ろにずらしてＰ（ｎ＋１），Ｐ（ｎ＋
２），Ｐ（ｎ＋３），…とし、空いたｎ番目の位置に当
該サブタスクＰ（ｎ）を挿入することになる。従って、
直後オーバーヘッド時間計算ステップ４０８でオーバー
ヘッド時間Ｔｏ（Ｐ（ｎ），Ｐ（ｎ＋１））を求める際
のＰ（ｎ＋１）とは、Ｐ（ｎ）挿入後にｎ＋１番目にな
るサブタスクを示しており、これは実際には挿入前の現
在のタスク表１０６のサブタスクＰ（ｎ）のことであ
る。

【００５８】これらの値を用いて、終了予定時刻更新ス
テップ４０９で、サブタスクＰ（ｎ）を当該ｎ番目の位
置に挿入した場合の、該サブタスクＰ（ｎ）以降のサブ
タスクの終了予定時刻を計算する。サブタスクＰ（ｎ）
挿入以前のｍ番目（ｍ≧ｎ）のサブタスクＰ（ｍ）の終
了予定時刻をＴｅ’（Ｐ（ｍ））とする。また、Ｐ
（ｎ）挿入後における、このサブタスクＰ（ｍ）の終了
予定時刻をＴｅ（Ｐ（ｍ））で表すものとする。

【００５９】なお、Ｐ（ｎ）挿入前にはｍ番目であった
サブタスクＰ（ｍ）は、Ｐ（ｎ）挿入後にはｍ＋１番目
にずれてサブタスクＰ（ｍ＋１）となるが、この時点で
は未だＰ（ｎ）をタスク表１０６に挿入していないの
で、「Ｐ（ｎ）挿入前にはｍ番目であってＰ（ｎ）挿入
後にはＰ（ｍ＋１）となるサブタスクの、Ｐ（ｎ）挿入
後における終了予定時刻」の意味でＴｅ（Ｐ（ｍ））と
表記するものとする。

【００６０】この終了予定時刻Ｔｅ（Ｐ（ｍ））は、Ｔｅ（Ｐ（ｍ））＝Ｔｅ’（Ｐ（ｍ））＋Ｔｏ（Ｐ（ｎ
−１），Ｐ（ｎ））＋Ｔｐ（Ｐ（ｎ））＋Ｔｏ（Ｐ
（ｎ），Ｐ（ｎ＋１））−Ｔｏ（Ｐ（ｎ−１），Ｐ（ｎ
＋１））で計算できる。

【００６１】この値を用いて、スケジュール可能性判定
ステップ４１０で、ｍ≧ｎの各ｍについてＴｅ（Ｐ
（ｍ））＜Ｔｄ（Ｐ（ｍ））であるかどうかを確認す
る。この判別式がｍ≧ｎである全サブタスクＰ（ｍ）に
ついて満たされればスケジュール可能であると判断し、
満たされないサブタスクが１つでもあればスケジュール
不能であると判断する。

【００６２】スケジュール可能性判定ステップ４１０で
スケジュール不能であると判断した場合は、新規に要求
したサブタスクＰ（ｎ）は活性化不能であるとし、活性
化不能通知ステップ４１１で、活性化許可フラグ１０８
ａを通じて要求元の処理タスク１０１ａに活性化不能通
知４１２を送る。なお、ここでは図１のタスク１０１ａ
からの活性化要求を例としているが、タスク１０１ｂ，
または１０１ｃからの活性化要求に対する処理も、活性
化許可フラグ１０８ｂ，または１０８ｃを用いる以外は
同様である。スケジュール不能であると判断した場合
は、各処理タスクの責任において、活性化が許可されな
かったことに対応する処理がなされなければならない。

【００６３】スケジュール可能性判定ステップ４１０で
スケジュール可能と判定された場合には、タスク表挿入
ステップ４１３で、新規に要求のあったサブタスクＰ
（ｎ）をタスク表のｎ番目の位置に挿入し、オーバーヘ
ッド時間とタスクの終了予定時刻を更新する。そしてキ
ュー検索ステップ４０２に戻る。

【００６４】以上の動作を活性化要求キュー１０４が空
になるまで繰り返す。

【００６５】次に、図１の実行タスク選択ステップ１０
７の動作について説明する。実行タスク選択ステップ１
０７は、例えば、何れかの処理タスクが終了して次にど
のタスクを実行するか選択するときに起動される。ここ
ではサブタスクＰ’（０）が終了した直後で、本実行タ
スク選択ステップ１０７が起動されたとする。

【００６６】なお、Ｐ’（０）は、実行許可を受ける直
前に、タスク表１０６にサブタスクＰ（０）として登録
されていたサブタスクであるとする。後述するように、
サブタスクＰ（０）が実行許可されるときには、タスク
表１０６からそのＰ（０）は削除され、Ｐ（１），Ｐ
（２），Ｐ（３），…がＰ（０），Ｐ（１），Ｐ
（２），…に前詰めされる。従って、実行されたサブタ
スクＰ’（０）はタスク表１０６からは既に削除されて
いるが、その削除された情報は別の領域に保持してある
ものとする。

【００６７】図６は、実行タスク選択ステップ１０７の
動作を示すフローチャートである。まず、オーバーヘッ
ド時間計算ステップ６０１で、タスク表１０６の全サブ
タスクＰ（ｋ）について、直前に実行していたサブタス
クＰ’（０）からの移行オーバーヘッド時間Ｔｏ（Ｐ’
（０），Ｐ（ｋ））を求める。最小オーバーヘッドサブ
タスク検索ステップ６０２で、オーバーヘッド時間Ｔｏ
（Ｐ’（０），Ｐ（ｎ））の最小値およびそのときのサ
ブタスクＰ（ｎ）を探す。これはサブタスクＰ’（０）
から高い連続性で移行できるサブタスクを探すというこ
とである。

【００６８】次に、処理時間計算ステップ６０３で、そ
のサブタスクＰ（ｎ）を次に活性化するとして順序を交
換した場合（現在タスク表１０６に登録されているＰ
（０）の前にＰ（ｎ）を活性化する場合）の処理にかか
る時間Ｔｏ（Ｐ’（０），Ｐ（ｎ））＋Ｔｐ（Ｐ
（ｎ））を計算する。さらに時間増計算ステップ６０４
で、サブタスクＰ（０）からＰ（ｎ−１）についての終
了予測時間のずれＴｄｅｌ＝Ｔｏ（Ｐ’（０），Ｐ（ｎ））＋Ｔｐ（Ｐ
（ｎ））＋Ｔｏ（Ｐ（ｎ），Ｐ（０））−Ｔｏ（Ｐ’
（０），Ｐ（０））を計算する。この値を利用して、デッドラインチェック
ステップ６０５で、サブタスクＰ（０）からＰ（ｎ−
１）がデッドラインを守っているかどうかを判定する。
具体的には、次の式で判定する。ただし、ｊ＝０〜ｎ−
１である。

【００６９】Ｔｅ（Ｐ（ｊ））＋Ｔｄｅｌ＜Ｔｄ（Ｐ（ｊ））

【００７０】この判別式は、先にサブタスクＰ（ｎ）を
活性化した場合にサブタスクＰ（ｊ）の終了予定時刻が
Ｔｄｅｌだけずれるので、Ｔｄｅｌを足した終了予定時
刻がデッドラインＴｄ（Ｐ（ｊ））より前であることを
確認するための判別式である。

【００７１】判定部６０６で、サブタスクＰ（０）から
Ｐ（ｎ−１）のうちデッドラインを超えるサブタスクが
一つでもあった場合には、サブタスクの順序変更は不可
とし、タスク表１０６の先頭のサブタスクＰ（０）を活
性化することに決定する。そして、サブタスク削除ステ
ップ６０７で、タスク表１０６からサブタスクＰ（０）
に関する情報を削除し、タスク活性化許可通知ステップ
６０８で、該当するタスク（例えば図１の１０１ａ，１
０１ｂ，または１０１ｃのうちいずれか）に対してタス
ク活性化許可フラグ（図１の１０８ａ，１０８ｂ，また
は１０８ｃ）を通じて通知６０９を送る。

【００７２】なお、サブタスクＰ（０）をタスク表１０
６から削除するときには、それ以後のサブタスクＰ
（１），Ｐ（２），Ｐ（３），…をＰ（０），Ｐ
（１），Ｐ（２），…に前詰めし、各フィールド情報の
更新を行なっておく。また、いま活性化を許可してタス
ク表１０６から削除したサブタスクＰ（０）は、これ以
降サブタスクＰ’（０）と呼ぶこととし、このＰ’
（０）に関する情報は別の領域に保持しておく。この
Ｐ’（０）が、次に実行タスク選択ステップ１０７が起
動されたときに、「直前に実行していたサブタスクＰ’
（０）」となる。

【００７３】その後、タイマセットステップ６１６で、
いま活性化を許可したサブタスクＰ’（０）の予想処理
時間Ｔｐ（Ｐ’（０））の値をインターバルタイマ１０
９にセットし、スケジューラ自身は休止６１７して、活
性化しようとするサブタスクに実行権を移して終了する
のを待つ。

【００７４】一方、判定部６０６でサブタスクの順序を
交換してもデッドラインを超えないと判定された場合に
は、順序の交換の効果があるかどうかをトータル処理時
間減少判定ステップ６１０で判定する。判定に用いる式
は次のものが使用できる。

【００７５】Ｔｏ（Ｐ’（０），Ｐ（ｎ））＋Ｔｏ（Ｐ
（ｎ），Ｐ（０））＋Ｔｏ（Ｐ（ｎ−１），Ｐ（ｎ＋
１））＜Ｔｏ（Ｐ’（０），Ｐ（０））＋Ｔｏ（Ｐ
（ｎ−１），Ｐ（ｎ））＋Ｔｏ（Ｐ（ｎ），Ｐ（ｎ＋
１））

【００７６】つまり、交換によってオーバーヘッド時間
の合計が減少するかどうかを判定する。上記式ではオー
バーヘッド時間の合計で比較しているが、これはＰ
（０）の前にＰ（ｎ）を持ってきた場合のトータルな処
理時間と、タスク表の通りにＰ（０）からの順で処理し
た場合のトータルな処理時間とを比較しているのと同じ
ことである。ステップ６１０でオーバーヘッド時間の合
計が減少しないと判定した場合は、順序を交換しないと
決定し、サブタスク削除ステップ６０７へ移る。以後の
処理はデッドラインを超えた場合と同等である。

【００７７】トータル処理時間減少判定ステップ６１０
で処理時間が減少すると判定された場合には、移行オー
バーヘッド時間の短かったサブタスクＰ（ｎ）に活性化
許可を与えると決定する。その後、サブタスク削除ステ
ップ６１１でそのサブタスクＰ（ｎ）をタスク表１０６
から削除し、タスク活性化許可通知ステップ６１２で該
当する要求元のタスク（例えば図１の１０１ａ，１０１
ｂ，１０１ｃのうちいずれか）に対してタスク活性化許
可フラグ（図１の１０８ａ，１０８ｂ，１０８ｃ）を通
じて通知６１３が送られる。この通知６１３の中には要
求識別子２０２に関する情報も含まれる。

【００７８】なお、いま活性化を許可してタスク表１０
６から削除したサブタスクＰ（ｎ）は、これ以降サブタ
スクＰ’（ｎ）と呼ぶこととし、このＰ’（ｎ）に関す
る情報は別の領域に保持しておく。なお、この例では、
直前に実行していたサブタスクＰ’（０）が終了して実
行タスク選択ステップ１０７が起動されたとして説明を
してきたが、サブタスクＰ’（ｎ）の終了により実行タ
スク選択ステップ１０７が起動される場合も同様であ
る。上述の説明で、「直前に実行していたサブタスク
Ｐ’（０）」の代わりにＰ’（ｎ）を用いればよい。

【００７９】次に、タスク表並べ替えステップ６１４
で、消去されたサブタスクの隙間を埋めて（すなわち、
Ｐ（ｎ＋１），Ｐ（ｎ＋２），…をＰ（ｎ），Ｐ（ｎ＋
１），…に前詰めする）サブタスク識別子の付け替えを
行い、終了予定時刻再計算ステップ６１５で、タスク表
の終了予定時刻を全サブタスクに関して更新する。その
後、サブタスク順序を交換しなかった場合と同様に、タ
イマセットステップ６１６で、いま活性化を許可したサ
ブタスクＰ’（ｎ）の予想処理時間Ｔｐ（Ｐ’（ｎ））
の値をインターバルタイマ１０９にセットし、スケジュ
ーラ自身は休止６１７して、活性化しようとするサブタ
スクに実行権を移して終了するのを待つ。

【００８０】サブタスクが終了すると、タイマ解除ステ
ップでインターバルタイマ１０９の動作を停止し、スケ
ジューラの動作を終了６１９する。このとき、サブタス
クの動作が申告した予想処理時間Ｔｐ（Ｐ’（０））ま
たはＴｐ（Ｐ’（ｎ））よりも遅れた場合、インターバ
ルタイマ１０９が動作してタイマ割り込み６２０を発生
する。これを受けた場合には、時間切れ通知ステップ６
２１で、時間切れの通知６２２を要求元のタスク（例え
ば図１の１０１ａ，１０１ｂ，または１０１ｃのうちい
ずれか）に対してタスク活性化許可フラグ（図１の１０
８ａ，１０８ｂ，１０８ｃのいずれか）を通じて送る。

【００８１】要求元タスクでは、前述の様に処理を中断
し資源を解放する。これにより、あるタスクで生じた予
想外の出来事に対し、他のタスクのスケジュールに影響
を及ぼすことを防止することができる。中断されたタス
クに関する情報は、再び実行許可要求キュー１０４を経
由して、再び挿入並べ替えステップ１０５によってタス
ク表１０６に加えられようとする。しかし、このときス
ケジュール不能とされ、実行許可フラグ（図１の１０８
ａ，１０８ｂ，または１０８ｃ）を通して各処理タスク
（図１の１０１ａ，１０１ｂ，１０１ｃ）に伝えられる
場合もある。この場合も、各タスクの責任において対応
を処理されなければならない。

【００８２】本発明の動作例を、特にサブタスク順序の
交換の効果に重点を置いて説明する。タスク表１０６に
は既に図５に示されたサブタスクが登録されており、現
在Ｐ（０）の終了直後であり、次のサブタスクを選択し
ようとしている状態であるとする。また、タスク移行の
オーバーヘッド時間は、図７に示す行列で表されるとす
る。

【００８３】なお、上述したように、サブタスクが実行
されるに連れてタスク表は更新されていくが、説明の便
宜のため、以下では図５の状態におけるＰ（０），Ｐ
（１），…の記号で説明するものとする。

【００８４】図８は、順序を入れ替えずにデッドライン
順に実行した場合のタイムチャートの例である。横軸が
時間推移、縦軸はタスク移行のオーバーヘッド時間を示
している。いまタスク表１０６に示すように、実行中の
サブタスクＰ（０）８０１の他に、サブタスクＰ（１）
８０２，Ｐ（ｎ−１）８０３，Ｐ（ｎ）８０４，Ｐ（ｎ
＋１）８０５が登録されている。

【００８５】サブタスクＰ（０）８０１の終了デッドラ
インを８０６、サブタスクＰ（１）の終了デッドライン
を８０７、サブタスクＰ（ｎ）の終了デッドラインを８
０８ａ、サブタスクＰ（ｎ）の終了デッドラインを８０
９、サブタスクＰ（ｎ＋１）の終了デッドラインを８１
０で表す。この例では各サブタスクの予想処理時間が等
しい場合を扱っているため、終了デッドラインの順がそ
のまま開始デッドラインの順となるが、一般的には異な
る場合もある。

【００８６】本発明ではタスク順序を交換しない場合に
は開始デッドライン順に活性化する。この場合は、タス
ク表１０６の順序に従ってサブタスクは活性化される。
従って、サブタスクＰ（０）８０１の次はサブタスクＰ
（１）８０２、その次はサブタスクＰ（ｎ−１）８０
３、サブタスクＰ（ｎ）８０４、サブタスクＰ（ｎ＋
１）８０５と活性化される予定である。

【００８７】この図８の中で、例えばサブタスクＰ（ｎ
−１）からＰ（ｎ）への移行のオーバーヘッド時間Ｔｏ
（Ｐ（ｎ−１），Ｐ（ｎ））は８１１で、サブタスクＰ
（ｎ）８０４の処理時間Ｔｐ（Ｐ（ｎ））は８１２で、
サブタスクＰ（ｎ）８０４の終了予測時刻Ｔｅ（Ｐ
（ｎ））は８１３で、全サブタスクの終了予測時刻Ｔｅ
（Ｐ（ｎ＋１））は８１４ａで表される。この図８に示
されるように、開始デッドライン順にサブタスクを活性
化することにより、それぞれのサブタスクの終了デッド
ラインを満たすことが容易となる。

【００８８】図９に、同様な条件で実行順序を入れ替え
て実行した場合のタイムチャートを示す。この場合は、
各サブタスクＰ（ｋ）のオーバーヘッド時間Ｔｏ（Ｐ
（０），Ｐ（ｋ））のうち、ｋ＝ｎが最小となる。従っ
て、サブタスクＰ（１）８０４の前にサブタスクＰ
（ｎ）８０４を実行する。この場合の全タスクの終了予
測時刻８１４ｂは、順序を入れ替えずにデッドライン順
に実行した場合の全タスクの終了予測時刻８１４ａと比
較して早くなることがわかる。また、全サブタスクにつ
いて、それぞれの終了デッドラインは満たしている。こ
れはリアルタイム性を持ったままの処理効率の向上を意
味する。従って、本発明によれば、この例の条件におい
ては図９の順序が選択される。

【００８９】図１０に、同様な条件で実行順序を入れ替
えられない場合のタイムチャートを示す。図９の条件と
異なるのは、サブタスクＰ（ｎ−１）８０３のデッドラ
イン８０８ｂが図９の場合の終了デッドライン８０８ａ
より早いことである。この場合は、サブタスクＰ（ｎ−
１）８０３はデッドライン８０８ｂを満たすことができ
ないため、サブタスクの順序の交換は不可能である。こ
の場合でも、図８に示す順序に実行すれば、全タスクに
ついてその終了デッドラインを満たすことが可能であ
る。

【００９０】上記の実施例の変形例について説明する。

【００９１】上記の実施例では、サブタスクの順序の交
換の候補は、最もオーバーヘッドの短くなるもの一つで
あったが、交換するサブタスク候補を複数個選び、それ
ぞれについて順序を入れ替えたと仮定した場合に、終了
デッドラインを満たすかどうかの判定と、全サブタスク
の終了予定時刻の計算を行い、デッドラインを満たした
上で終了予定時刻の最も早いものを選択することによ
り、さらに適した順序を探すことも可能である。

【００９２】上記の実施例では、次に活性化するサブタ
スクを選択するのみであるが、さらにその次やその次の
サブタスクについても移行オーバーヘッドの小さいサブ
タスクと順序を交換したと仮定し、全タスクの終了予定
時刻を計算して、最も終了予定時刻の短い組み合わせと
なる場合の、次のサブタスクを選択することも可能であ
る。

【００９３】さらには、現在タスク表に登録されている
サブタスクの考えられる全ての順序を仮定し、最短の全
サブタスク終了時刻を得る順序を選択し、その先頭のサ
ブタスクを次に実行することも可能である。ただし、こ
の場合は、登録されているサブタスクの数がｎ個の場合
はｎ！に比例する処理時間が必要となり、適用範囲が限
られる。

【００９４】上記の実施例では、各タスク１０１ａ，１
０１ｂ，１０１ｃから発生した活性化許可要求１０３
ａ，１０３ｂ，１０３ｃを一時的に活性化要求キュー１
０４に蓄える。この代わりに、各タスク１０１ａ，１０
１ｂ，１０１ｃが要求を発生した時点で、スケジューラ
１０２内の挿入並べ替えステップ１０５が起動し、要求
をタスク表１０６内にすぐに挿入することも可能であ
る。これにより、活性化許可要求キュー１０４が不要と
なる。

【００９５】あるサブタスクの活性状態でタスクのスケ
ジューリング要求が発生した場合、活性状態であったサ
ブタスクに、タイマ割り込み時と同様に時間切れの通知
を送って強制中断させ、そのサブタスクを再度タスク表
に挿入し更新し、タスクスケジューリングを再度実行す
ることにより、緊急的な要求が発生した場合にその要求
を優先実行させることも可能である。

【００９６】上記の実施例では活性化許可要求において
予想処理時間３０６を申告させたが、処理の複雑さやス
テップ数などの間接的な値を申告させ、処理装置の能力
の違いを吸収することも可能である。

【００９７】上記の実施例では一度タスク表１０６に登
録されたサブタスクを撤回することには触れなかった
が、活性化許可要求と同様に、サブタスク撤回要求を活
性化許可要求パラメータ３０１に定義することにより、
不要となった処理を取り下げさせることも可能である。
この場合は、サブタスク撤回要求を受けた挿入並べ替え
ステップ１０５において、タスク表１０６から該当サブ
タスクを削除し、終了予測時刻を更新する。

【００９８】次に、上記で説明したスケジューリング方
法を、装置に適用した場合の実施例を説明する。

【００９９】本発明をＣＰＵ処理時間のスケジューリン
グに適用する場合は、ＯＳ（オペレーティングシステ
ム）のスケジューリング機構に組み込む。例えば、子プ
ロセスの生成時に活性化許可要求パラメータと同様な値
を申告させることにより、ＯＳはその子プロセスの実行
順序を本発明の方法で決定する。

【０１００】この場合のタスク移行のオーバーヘッド時
間は、主に各プロセスの持つ記憶領域の移動に伴う時間
である。例えば、ＣＰＵ内部のレジスタからメモリへ、
キャッシュメモリから主記憶へ、主記憶からディスク装
置へ、といった情報の移動が発生する。従って、オーバ
ーヘッド時間の予測は、該当プロセスの管理する記憶領
域が物理的にどの位置に存在するか、またその大きさは
どの程度か、から求められる。複数のＣＰＵで計算する
場合には、さらにどのＣＰＵの管理する記憶領域に移動
するかもオーバーヘッド時間に影響する。

【０１０１】本発明をファイル装置のスケジューリング
に適用する場合は、ファイル装置内部の制御装置に組み
込むか、あるいは接続する計算機のファイル装置制御ソ
フトウェア（いわゆるドライバ）に組み込むのが妥当で
ある。

【０１０２】ファイル装置の場合のタスク移行のオーバ
ーヘッド時間は、アクセスする情報の記憶場所の物理的
な距離による。ディスク装置の場合は、ヘッドの移動時
間や回転待ち時間、いわゆるシーク時間が主なオーバー
ヘッドとなる。またテープ装置の場合は、送りや巻き戻
しの時間が大きなオーバーヘッドとなる。さらに媒体が
異なる場合には、媒体の装着や取り外しの時間もオーバ
ーヘッド時間である。従って、タスクがアクセスしよう
とする情報の物理的位置に関する情報をスケジューラに
申告することにより、スケジューラはタスク間の移行の
オーバーヘッド時間を予測することが可能である。

【０１０３】本発明をファイル装置に適用することで、
例えばある程度以上の読み出し速度で周期的に読み出す
ことが必要なファイルの読み出しなどにおける性能の向
上が期待できる。近年では動画データなどをファイルと
して計算機で取り扱うことも多いが、これらはある一定
の速度で読み出さないと動画が止まるなどの不都合が起
こる。本発明では連続性の高いデータ読み出しはできる
だけ連続的の行なうとともに、読み出しの終了デッドラ
インは守るようにできるので、そのような動画データを
格納するファイル装置などに適用して好適である。

【０１０４】本発明を通信インターフェース装置のスケ
ジューリングに適用する場合は、計算機の通信インター
フェース制御ソフトウェアに組み込むのが妥当である。
一般的に通信インターフェースにおいては、同じチャネ
ルの情報を連続で扱う方がオーバーヘッドは小さい。チ
ャネルの順序によりオーバーヘッドが異なることは少な
い。従ってオーバーヘッドの計算は、同じチャネルに属
するかどうかで簡単に計算できることが多い。

【０１０５】本発明を計算機内部の共有バスのスケジュ
ーリングに適用する場合は、一般的には専用のハードウ
ェアが必要となる。バスを利用しようとする機器は、バ
スのスケジューリングを制御するハードウェアに対し、
活性化許可要求パラメータ３０１と同様なパラメータを
送り、活性化許可フラグに相当する信号を待つ。そして
許可された順にバスを利用する。

【０１０６】

【発明の効果】以上の通り本発明によれば、各タスクの
要求する終了デッドラインを満たしながら、連続するタ
スクはなるべく連続して処理を行なうようにできる。す
なわち、マルチタスクの処理システム上における本来相
反する二つの課題、システム全体の平均性能とそのシス
テム上で動作する各タスクのリアルタイム性との両者を
両立して向上させることができるスケジューリング方法
が提供される。例えば、本発明をディスク装置に適用し
た場合には、反応速度を保ったまま全体の読出速度を５
０％から１００％向上することが可能である。

【図面の簡単な説明】

【図１】本発明の一実施例に係る計算機のタスク構成例
を示す図

【図２】処理タスクのフローチャート例を示す図

【図３】活性化許可要求パラメータの例を示す図

【図４】挿入並べ替えステップのフローチャート例を示
す図

【図５】タスク表の例を示す図

【図６】実行タスク選択ステップのフローチャート例を
示す図

【図７】オーバーヘッド時間の例を示す図

【図８】デッドラインの順に実行した場合のタイムチャ
ートの例を示す図

【図９】実行順序を入れ替えて実行した場合のタイムチ
ャートの例を示す図

【図１０】実行順序を入れ替えられない場合のタイムチ
ャートの例を示す図

【符号の説明】

１０１ａ，１０１ｂ，１０１ｃ…処理タスク、１０２…
スケジューラ、１０３ａ，１０３ｂ，１０３ｃ…活性化
許可要求、１０４…活性化許可要求キュー、１０５…挿
入並べ替えステップ、１０６…タスク表、１０７…実行
タスク選択ステップ、１０８ａ，１０８ｂ，１０８ｃ…
タスク活性化許可フラグ、１０９…インターバルタイ
マ。

───────────────────────────────────────────────────── フロントページの続き (72)発明者滝安美弘東京都国分寺市東恋ケ窪一丁目280番地株式会社日立製作所中央研究所内 (72)発明者斉藤温東京都国分寺市東恋ケ窪一丁目280番地株式会社日立製作所中央研究所内

Claims

【特許請求の範囲】

【請求項１】複数のタスクを擬似的に同時に実行するマ
ルチタスクの処理装置上において、終了期限が決められ
ている複数のタスクの実行順序を決定して実行許可する
タスクスケジューリング方法であって、タスクの実行許可要求を受け取り、その実行許可要求を
開始期限順に並べ替えて保持するステップと、次に実行すべきタスクを決定する際には、前記保持して
ある実行許可要求から次に実行許可するタスクの候補を
選択するステップと、前記選択した候補を、前記開始期限順に並べられ保持さ
れている実行許可要求の先頭にある実行許可要求のタス
クより先に実行すると仮定し、各タスクを順に実行した
場合の各タスクそれぞれの終了予定時刻を求めるステッ
プと、前記各タスクの終了予定時刻がそれぞれ各タスクの終了
期限内であり、かつ、前記選択した候補を先に実行した
方が前記開始期限順に実行するよりも全体の処理時間が
少ないという条件を満たすときは、前記選択した候補の
タスクを先に実行許可し、前記条件を満たさないときは
前記開始期限順に実行許可していくステップとを備えた
ことを特徴とするタスクスケジューリング方法。
【請求項２】前記候補を選択するステップは、直前に実
行されていたタスクから移行するオーバーヘッド時間の
短いタスクを、先に実行する候補として選択する請求項
１に記載のタスクスケジューリング方法。
【請求項３】前記候補を選択するステップは、直前に実
行されていたタスクから移行するオーバーヘッド時間の
短いタスクを、該オーバーヘッド時間が短い方から複数
個選んで先に実行する候補として選択し、前記各候補について、次に実行する予定であった前記開
始期限順の先頭のタスクより先に前記候補のタスクを実
行すると仮定して、全実行許可要求の終了予定時刻を計
算し、最も全体の終了予定時刻が早くなる候補のタスク
を選択して実行許可する請求項１に記載のタスクスケジ
ューリング方法。
【請求項４】複数のタスクを擬似的に同時に実行するマ
ルチタスクの計算機上において、終了期限が決められて
いる複数のタスクの実行順序を決定して実行許可するタ
スクスケジューリング方法であって、一定時間ごと、他のタスクが終了したとき、タスクの実
行許可要求が発生したとき、またはその他割り込み等で
システムの状態が変化したときの一つまたは複数が生じ
た場合に、タスクの実行許可要求を受け取りその実行許可要求を開
始期限順に並べ替えて保持する挿入並べ替えステップ
と、次に実行すべきタスクを選択する実行タスク選択ス
テップとを実行するとともに、前記挿入並べ替えステップは、受け取った実行許可要求について処理時間および開始期
限を計算するステップと、前記受け取った実行許可要求を既に開始期限順に並べて
保持されている実行許可要求の中に開始期限順になるよ
うに挿入する場合の挿入位置を決定するステップと、前記挿入位置に前記受け取った実行許可要求を挿入した
と仮定して、その直前のタスクから挿入したタスクへ移
行する際の移行オーバヘッド時間、および挿入したタス
クから直後のタスクへ移行する際の移行オーバヘッド時
間を計算するステップと、該計算結果を用いて、前記挿入位置以降のすべてのタス
クの終了予定時刻を計算するステップと、前記挿入位置以降のすべてのタスクについて、前記終了
予定時刻がそのタスクの終了期限内である場合は前記受
け取った実行許可要求を既に開始期限順に並べて保持さ
れている実行許可要求の中に開始期限順になるように挿
入し、前記終了予定時刻がそのタスクの終了期限以上で
ある場合は当該タスクに実行不能通知を発行するステッ
プとを備え、前記実行タスク選択ステップは、前記保持してあるすべての実行許可要求のタスクについ
て、直前に実行していたタスクから移行する際の移行オ
ーバヘッド時間を計算するステップと、計算した移行オーバヘッド時間が最小となる実行許可要
求のタスクを選び出し、次に実行許可するタスクの候補
とするステップと、前記候補を次に実行するとした場合に現在開始期限順に
保持してある実行許可要求のタスクの終了予定時刻がど
れだけずれるか、そのずれ分を計算するステップと、計算したずれ分と各タスクの終了予定時刻との和が各タ
スクの終了期限内であり、かつ、前記候補を次に実行す
る方が全体の処理時間が少なくなるかを判定するステッ
プと、前記判定結果が肯定であるときは前記候補のタスクを先
に実行許可し、前記判定結果が否定であるときは前記開
始期限順に実行許可していくステップとを備えたことを
特徴とするタスクスケジューリング方法。
【請求項５】前記実行許可要求は、前記開始期限順に実
行される予定の実行許可要求を表形式で表したタスク表
に登録され保持される請求項１または４に記載のタスク
スケジューリング方法。
【請求項６】前記実行許可要求を受け取ったとき、即時
に前記タスク表を更新する請求項５に記載のタスクスケ
ジューリング方法。
【請求項７】前記実行許可要求を受け取ったとき、前記
タスク表を即時に更新せずに、受け取った実行許可要求
を一時的に蓄えておき、次にタスクスケジューリングの
要求が発生したときに前記タスク表を更新する請求項５
に記載のタスクスケジューリング方法。
【請求項８】あるタスクが実行されている状態で別のタ
スクのスケジューリング要求が発生した場合、実行状態
であったタスクを再度前記タスク表に挿入し更新した上
でそのタスクを休止させ、タスクスケジューリングを再
度実行する請求項１または４に記載のタスクスケジュー
リング方法。
【請求項９】あるタスクに実行許可を与えたとき、その
タスクの処理の終了予定時刻をタイマにセットしてお
き、その時刻までにそのタスクの処理が終了しなかった
場合には、該タスクを強制休止させるステップを有する
請求項１または４に記載のタスクスケジューリング方
法。
【請求項１０】請求項１または４に記載のタスクスケジ
ューリング方法により一つおよび複数のＣＰＵの使用時
間、およびタスクのＣＰＵへの割り当てを決定する計算
機。
【請求項１１】請求項１または４に記載のタスクスケジ
ューリング方法によりファイル装置の使用順序を決定す
る情報蓄積装置。
【請求項１２】請求項１または４に記載のタスクスケジ
ューリング方法により通信路および通信インターフェー
ス装置の使用順序を決定する情報通信装置。
【請求項１３】請求項１または４に記載のタスクスケジ
ューリング方法により内部のバスの使用権を決定する計
算機。
【請求項１４】請求項１または４に記載のタスクスケジ
ューリング方法の処理の一部または全部を、専用のハー
ドウェア装置にて行うことを特徴とするタスクスケジュ
ーリング方法。