JP2002351678A - 連続メディアストリーム処理におけるスケジューリング方法 - Google Patents

Abstract

(57)【要約】 【構成】 ＣＰＵ１２は、タスクが処理すべきメッセー
ジが到着すると、そのタスクを起動し、メッセージを処
理させる。メッセージ処理が完了すると、タスクにおけ
る実効未処理メッセージ数（メッセージ数）が取得され
る。次に、ＣＰＵ１２は、隣接する２つのタスクにおけ
る先行タスクのメッセージ数が後続タスクのメッセージ
数よりも多い場合には、先行タスクの処理遅延が大きい
と判断し、先行タスクの処理速度が速くされる。逆の場
合には、先行タスクの処理遅延が少ないと判断し、すな
わち後続タスクの処理遅延が大きいと判断し、先行タス
クの処理速度を遅くする。このように、隣接するタスク
間で処理遅延を均一化することにより、全タスクの処理
遅延が均等にされる。つまり、処理が遅いタスクに依存
してシステム全体の処理遅延を防止し、ＣＰＵを有効に
利用している。 【効果】 効率よくタスクをスケジューリングすること
ができる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は連続メディアストリー
ム処理におけるスケジューリング方法に関し、特にたと
えばマルチメディアタスクをＶＢＲ(Variable Bit Rat
e) ストリーム処理に適応する、連続メディアストリー
ム処理におけるスケジューリング方法に関する。

【０００２】ここで、ＶＢＲストリーム処理とは、動画
データや音声データのような圧縮／伸長或いは差分処理
に見られるような可変量を有する連続メディアデータを
パイプラインモデルにより順次処理することをいう。

【０００３】

【従来の技術】近年、動画や音声などの連続メディア情
報を処理環境に適応した品質で送受信する研究が盛んに
行われている。それらの多くは、ネットワーク環境に適
応したＱｏＳの研究、またはアプリケーション特性に適
応したＱｏＳの研究である。また、エンド−エンドで処
理環境に適応した品質を提供するためには、実行タスク
のコンピューティング資源要求特性に適応したスケジュ
ーリング方式を提供する必要がある。現在のオペレーテ
ィングシステム（以下、単に「ＯＳ」という。）は、ビ
ジネスアプリケーションを実行目的とする商用ＯＳとリ
アルタイムアプリケーションを実行目的とするリアルタ
イムＯＳとの２つに大別できる。

【０００４】

【発明が解決しようとする課題】しかし、前者のスケジ
ューリング方式では、動的な資源要求に対応している
が、資源要求の時間特性を考慮していなかった。また、
後者のスケジューリング方式では、資源要求の時間特性
を考慮しているが、既知の処理環境でのみ使用可能であ
った。さらに、両者のスケジューリング方式では、資源
要求に対して実行タスク間の協調／抑制（通信依存関
係）が考慮されていなかった。したがって、上述のよう
な実行環境では、任意のタスクが任意の時間に生成お
よび消滅する。タスク間に依存関係がある。タスク
の資源要求は周期的特性を持つ。といった連続メディア
情報を扱うマルチメディアアプリケーションを正確に実
行できないという問題があった。

【０００５】これに対して、周期タスク処理に適してい
るリアルタイムスケジューラとして、たとえば、Ｅａｒ
ｌｉｅｓｔ Ｄｅａｄｌｉｎ Ｆｉｒｓｔ（ＥＤＦ）と
Ｒａｔｅ Ｍｏｎｏｔｏｎｉｃ（ＲＭ）とがある。ＥＤ
ＦとＲＭとで用いられる周期タスクモデルは、固定周期
と周期内の実行時間とから構成され、数１に示すよう
に、タスクの時間属性が定義される。

【０００６】

【数１】

【０００７】このような周期タスクモデルとタスクの最
悪実行時間とに基づき、ＣＰＵの利用率（ＣＰＵ利用率
Ｕ_n ）の予約を行うシステムには、リアルタイムｍａｃ
ｈなどがあり、そのＣＰＵ利用率Ｕ_n は数２のように定
義される。

【０００８】

【数２】

【０００９】しかし、ＶＢＲストリーム処理において、
多くのデータの処理時間は最悪実行時間より短い。すな
わち、数２で定義されるＣＰＵ利用率Ｕ_n は、過渡な予
約量となる。このため、システム全体としてのＣＰＵ利
用率Ｕ_n が大きく低下していた。

【００１０】それゆえに、この発明の主たる目的は、効
率よくタスクをスケジューリングすることができる、Ｖ
ＢＲストリーム処理するためのスケジューリング方法を
提供することである。

【００１１】

【課題を解決するための手段】この発明は、マルチメデ
ィアタスクをＶＢＲストリーム処理するための連続メデ
ィアストリーム処理におけるスケジューリング方法であ
って、(a) メッセージが到着したときにメッセージを処
理すべきタスクを起動するステップ、(b) タスクでメッ
セージの処理が終了した後タスクの実効未処理メッセー
ジ数を取得するステップ、および(c) 実効未処理メッセ
ージ数に応じて適応デッドラインを設定するステップを
含む、スケジューリング方法である。

【００１２】

【作用】この発明のマルチメディアタスクをＶＢＲスト
リーム処理するスケジューリング方法では、タスクが処
理すべきデータ（メッセージ）が到着すると、そのタス
クが起動される。したがって、タスクによってメッセー
ジが処理され、メッセージが処理されると、タスクが処
理すべきメッセージであり、たとえばバッファメモリに
保持されている処理されていない（処理待ち）のメッセ
ージの数（実効未処理メッセージ数）が取得される。こ
の実効未処理メッセージ数からタスクの処理速度を他の
タスクとの関係において知ることができ、したがって実
効未処理メッセージ数に応じて適応デッドラインが設定
（再設定）されることによって、処理遅延時間が調整さ
れる。このような処理を各タスクについて実行すること
により、各タスクの処理遅延時間が調整され、全タスク
の処理遅延を均一にすることができる。このため、処理
の遅いタスクによって、システム全体の処理が遅延する
ようなことがなくなり、結果的に、ＣＰＵを有効に使用
することができる。

【００１３】たとえば、適応デッドラインは、少なくと
もタスクの重要度に従って設定或いは再設定されるの
で、マルチメディア情報を扱う動的な環境に適応するこ
とができる。

【００１４】したがって、タスクを実行する毎に重要度
を更新すれば、適応デッドラインも更新される。

【００１５】具体的には、重要度は隣接する２つのタス
クの重要度が同じにされ、他のタスクにおいても上述し
たような処理が実行され、他のタスクにおける実効未処
理メッセージ数が取得される。そして、隣接する２つの
タスクにおいて、先行するタスク（先行タスク）の実効
未処理メッセージ数が後続するタスク（後続タスク）の
実効未処理数よりも多い場合には、先行タスクの処理が
後続タスクよりも遅いと判断し、先行タスクの重要度が
高くされる。逆に、先行タスクの実効未処理メッセージ
数が後続タスクの実効未処理メッセージ数より少ない場
合には、先行タスクの処理が後続タスクよりも速い、す
なわち後続タスクの処理が遅いと判断し、先行タスクの
重要度が低くされる。このように、隣接するタスク間で
処理遅延を均一化することにより、システム全体の処理
遅延を均等にすることができる。

【００１６】また、メッセージ処理完了後に実測された
処理遅延時間が推定デッドライン時刻を満たさない場合
には、大きく処理遅延が発生していると判断し、処理を
速めるため、重要度が高くされる。

【００１７】さらに、メッセージ処理完了後に実測され
た処理遅延時間がメッセージ処理に要したＣＰＵ使用時
間に対する予約したＣＰＵ利用率の比より小さい場合に
は、処理が速いと判断して、重要度が低くされる。

【００１８】このようなＣＰＵ使用率は、最悪実行時間
よりも短いＣＰＵ使用時間を用いて設定されるので、過
渡なＣＰＵ利用率を予約してしまうのを防止することが
できる。すなわち、ＣＰＵを有効利用することができ
る。

【００１９】たとえば、タスクに加えられる力の和が正
であれば、重要度が高くされ、力の和が負であれば、重
要度が低くされる。

【００２０】また、タスクに加えられる力には、外部入
力バイアスが含まれるので、処理環境の変化に適応する
ことができる。

【００２１】この外部入力バイアスはタスクにおける実
効未処理メッセージ数を含むので、未処理メッセージ数
の変化すなわち処理環境の変化をタスクの重要度に反映
することができる。

【００２２】また、たとえばネットワークの状態が準安
定状態と不安定状態との間で移動するように重要度が更
新されるので、短い周期で実行状況が変動する処理環境
に対して適応することができる。

【００２３】具体的には、ネットワークの状態に関する
パラメータを制御すれば、２つの状態間を移動させるこ
とができる。

【００２４】たとえば、パラメータは、ネットワークの
安定状態との距離によるネットワークの安定状態に向か
う確率である。

【００２５】

【発明の効果】この発明によれば、ＣＰＵを有効に使用
することができるので、スケジューリング可能性の低下
を防止することができる。つまり、効率よくスケジュー
リングすることができる。

【００２６】この発明の上述の目的，その他の目的，特
徴および利点は、図面を参照して行う以下の実施例の詳
細な説明から一層明らかとなろう。

【００２７】

【実施例】図１を参照して、この実施例のパーソナルコ
ンピュータ（以下、単に「ＰＣ」という。）１０は、Ｃ
ＰＵ１２を含む。ＣＰＵ１２は、バス１４を介してハー
ドディスクドライブ（ＨＤＤ）１６、ＲＡＭ１８および
インターフェイス２０に接続される。なお、ＰＣ１０
は、インターフェイス２０を介して、他のＰＣなどのマ
ルチメディア（図示せず）に接続される。ＨＤＤ１６に
は、周期タスクのスケジューリングのためのソフトおよ
び他の複数のアプリケーションソフトがプログラミング
（またはインストール）されており、ＣＰＵ１２の指示
に従って処理が実行される。また、ＲＡＭ１８は、ＣＰ
Ｕ１２のワーキングメモリとして使用され、さらに他の
マルチメディアからのデータ等を一時記録するためのバ
ッファメモリとしても使用される。

【００２８】この実施例では、図１で示される構成で処
理される周期タスク（以下、単に「タスク」という。）
のスケジューリング方法は、以下に列挙するように定義
される。

【００２９】第１に、予想最長処理時間（最悪実行時
間）より短い時間を用いてＣＰＵ利用率を予約する。第
２に、各タスクのメッセージ処理に必要なＣＰＵ使用時
間はランダム（可変量）である。第３に、各タスクは、
動画データや音声データのような連続メデイアデータを
図２に示すようなパイプラインモデルにより処理する。
第４に、連続メディアデータはそのパイプラインモデル
に示す入出力装置（連続メディアデータ入力装置および
連続メディアデータ出力装置）でＶＢＲ或いは固定周期
で生成および消費される。第５に、複数のストリーム処
理が混在する。

【００３０】ここで、連続メディアデータは、上述のと
おり、動画データ或いは音声データなどの圧縮／伸長お
よび差分処理に見られるように可変量であるため、ＶＢ
Ｒデータであると言える。

【００３１】また、この実施例では、ストリーム処理モ
デルとしての連続メディア資源モデル（Linear Bounded
Arrival Process: ＬＢＡＰ) に連続メディアデータす
なわちＶＢＲデータ（以下、単に「データ」という。）
を処理するための変更を加えたモデルを用い、Ｐａｒａ
ｌｌｅｌ Ｄｉｓｔｒｉｂｕｔｅｄ Ｐｒｏｃｅｓｓｉ
ｎｇモデル（以下、「ＰＤＰモデル」という。）と熱力
学モデルとを動作メカニズムとしている。これにより、
データに対して動的に適応するタスクスケジューリング
が可能となる。以下、具体的に説明する。

【００３２】この実施例の周期タスクモデルでは、デー
タ到着が周期的であることを想定している。しかし、図
２で示したようなパイプラインモデルによるＶＢＲスト
リーム処理においては、処理されるデータが可変量であ
り、処理遅延も可変するため、データ到着は周期性を失
う。具体的には、図３に示すように、タスクｎに周期的
にデータが到着したとしても、データ毎に処理時間が異
なるため、タスクｎの後続のタスクｎ＋１では、データ
の到着時間間隔ｔｉにばらつきが発生する。このため、
周期的なタスク到着とデータの到着とが同期せず、従っ
てタスクにデータ未到着による待ち時間が発生する。こ
の待ち時間は、優先度逆転に陥る可能性を高め、スケジ
ュール可能性を低下させる要因となる。

【００３３】これを回避するためには、タスク到着時刻
以前にデータが到着する必要がある。すなわち、パイプ
ライン上の各タスクは、隣接する前方の（先行する）タ
スクとの間に十分な初期位相が必要である。周期タスク
モデルによるＶＢＲストリーム処理において、従来のよ
うに、すなわち数２で示したように、最悪実行時間を用
いてＣＰＵ利用率を予約すると、連続メディアデータ出
力装置（以下、単に「出力装置］という。）の時間制約
を満たすのに必要なタスクの初期位相は、数３のように
示される。

【００３４】

【数３】

【００３５】したがって、出力装置の時間制約を保証す
る場合すなわち数３を満たすためには、大きなエンド−
エンドの遅延時間が必要となる。

【００３６】次に、ＬＢＡＰおよびそれに基づく従来の
処理モデルを説明した上で、ＶＢＲストリーム処理のモ
デルをＬＢＡＰに基づいて定義する。

【００３７】ＬＢＡＰでは、処理すべきデータを以下の
３つのパラメータにより特徴付けたデータ（メッセー
ジ）のストリームとしている。 ＜パラメータ（１）＞ Ｒ^max :maximum message rate(messages/second) Ｗ^max :maximum workahead messages(messages) Ｓ^max :maximum message size(bytes) また、ＬＢＡＰでは、時間間隔ｔにおいて到着する最大
のメッセージ数はＲ^{ma x} ＋Ｗ^max であると定義してい
る。すなわち、長期的なデータ処理レートはＲ^{ma x} Ｓ
^max 以下であるが、パラメータＷ^max により示されるバ
ースト的なデータ到着により、データ処理レートはＲ
^max Ｓ^max を短期間だけ超えることを許容している。こ
のバースト的なデータ到着に伴う処理されていない (処
理待ち）メッセージ数（以下、「未処理メッセージ数」
という。）は、数４に示すように定義される。

【００３８】

【数４】ｗ_n （ｍ₀ ）＝０ ｗ_n （ｍ_i ）＝ｍａｘ（０，ｗ_n （ｍ_i-1 ）−（ａ
_n （ｍ_i ）−ａ_n （ｍ_i-1 ））Ｒ^max ＋１） ただし、ｗ_n （ｍ_i ）はタスクｎにおけるｉ番目のメッ
セージ到着時の未処理メッセージ数、ａ_n （ｍ_i ）はタ
スクｎにおけるｉ番目のメッセージ到着時刻である。し
たがって、タスクｎにおける未処理メッセージ数の最大
値Ｗ^max は数５のように定義される。

【００３９】なお、括弧内の“，”は“または”という
意味である。以下、この実施例において同じである。

【００４０】

【数５】

【００４１】ここで、到着したメッセージは、処理され
ていないメッセージ（未処理メッセージ）をすべて処理
完了した後に、初めて処理対象となる。したがって、Ｌ
ＢＡＰでは、メッセージが処理対象となる論理的な時刻
（論理的時刻）は、タスクｎにおけるｉ番目のメッセー
ジが到着する論理的時刻（メッセージ論理到着時刻）ｌ
_n （ｍ_i ）として数６に示すように定義される。

【００４２】

【数６】 ｌ_n （ｍ_i ）＝ａ_n （ｍ_i ）＋ｗ_n （ｍ_i ）／Ｒ^max ｌ_n （ｍ₀ ）＝ａ_n （ｍ₀ ） ｌ_n （ｍ_i ）＝ｍａｘ（ａ_n （ｍ_i ），ｌ_n （ｍ_i-1 ）
＋１／Ｒ^max ） また、ＬＢＡＰでは、タスクｎにおけるｉ番目のメッセ
ージにおける処理遅延時間Ｄ^a （ｍ_i ）、論理的な処理
遅延時間（論理処理遅延時間）Ｄ^l （ｍ_i ）およびデッ
ドライン時刻ｄ_n （ｍ_i ）は、メッセージ到着時刻とメ
ッセージ論理到着時刻とを用い、図４に示すＬＢＡＰの
時間属性から数７、数８および数９のように、それぞれ
定義される。

【００４３】なお、図４に示すＬＢＡＰの時間属性で
は、ｉ番目のメッセージｍ_i がタスクｎで処理された後
にタスクｎ＋１に渡され、タスクｎ＋１で処理されるタ
イミングが示される。

【００４４】

【数７】

【００４５】

【数８】

【００４６】

【数９】

【００４７】

【数１０】

【００４８】ＬＢＡＰでは、このように特徴付けられた
メッセージストリームの処理において、以下に列挙する
ようにタスクが定義される。第１に、タスクの実行順
は、タスクのデッドライン時刻に基づき、ＥＤＦにより
決定される。第２に、第１のように定義されたタスクが
パイプラインモデルにより複数接続される。第３に、タ
スクはメッセージの到着時刻に起動される。すなわち、
メッセージ到着時にタスクがスケジューリング対象とな
る。第４に、タスクは、メッセージ処理完了時刻に未処
理メッセージがある場合、処理完了したメッセージのデ
ッドライン時刻を待たずに直ちに起動する。

【００４９】上述したように、従来の方式では、ストリ
ームデータを一定のメッセージの到着レートと最悪実行
時間とにより特徴付け、ＣＰＵ利用率を予約している。
すなわち、各タスクの時間制約を満たすために、すべて
のメッセージ処理時間が最悪実行時間である場合でも、
十分に処理できるＣＰＵ利用率を予約している。したが
って、従来の方式は、最悪実行時間に基づいたＣｏｎｓ
ｔａｎｔ Ｂｉｔ Ｒａｔｅ（以下、「ＣＢＲ」とい
う。）ストリーム処理として考えられる。このようなＣ
ＢＲストリーム処理を、ＬＢＡＰのパラメータを用いて
表すと、次のようになる。 ＜パラメータ（２）＞ Ｒ^c :constant message rate(messages/second) Ｗ^max :maximum workahead messages(messages) Ｃ^max :maximum processing time for a message(secon
ds/message) これにより、ＬＢＡＰを用いた最悪実行時間に基づくＣ
ＢＲストリーム処理モデルにおける未処理メッセージ数
およびメッセージの諭理到着時刻（メッセージ論理到着
時刻）は、それぞれ、数１１および数１２のように定義
される。

【００５０】

【数１１】ｗ_n （ｍ₀ ）＝０ ｗ_n （ｍ_i ）＝ｍａｘ（（０，ｗ_n （ｍ_i-1 ）−ａ
_n （ｍ_i ）−ａ_n （ｍ_i-1 ））Ｒ^c ＋１）

【００５１】

【数１２】 ｌ_n （ｍ_i ）＝ａ_n （ｍ_i ）＋ｗ_n （ｍ_i ）／Ｒ^c さらに、この数１２からメッセージ論理到着時刻は、数
１３のようになる。

【００５２】

【数１３】ｌ_n （ｍ₀ ）＝ａ_n （ｍ₀ ） ｌ_n （ｍ_i ）＝ｍａｘ（ａ_n （ｍ_i ），ｌ_n （ｍ_i-1 ）
＋１／Ｒ^c ） その他の定義については、上述の場合と同様である。つ
まり、数５および数７〜数１０の定義および第１〜第４
のタスクに関する定義がそのまま適用される。このよう
に定義された時間属性において、パラメータＣ^max とＲ
^c とによりＣＰＵ利用率を予約する場合に、出力装置の
時間制約を保証するには、周期タスクモデル（パラメー
タ（１）を設定した場合）と同様に、隣接するタスク間
に十分な初期位相が必要である。その初期位相は、数１
４のようになる。

【００５３】

【数１４】

【００５４】つまり、最悪実行時間に基づくＣＢＲスト
リーム処理モデルにおいても、過度なＣＰＵ予約量とな
り、システム全体でのＣＰＵ利用率が低下する。

【００５５】これを回避するため、この実施例では、メ
ッセージ処理時間は最悪実行時間Ｃ ^max より短い任意の
時間Ｃ^req に設定される。以下、Ｃ^req を含むパラメー
タを用いて、ＣＰＵ利用率を予約する場合のＶＢＲ処理
モデルについて検討する。 ＜パラメータ（３）＞ Ｒ^c :constant message rate(messages/second) ｂ :actual workahead messages(messages) Ｃ^req :request processing time for a message(secon
ds/message) タスクｎにおいて、レートＲ^c で最悪実行時間より短い
時間Ｃ^req を用いてＣＰＵ利用率を予約する場合、すべ
てのメッセージの処理時間が１／Ｒ^c 以下であることは
保証されない。したがって、数９〜数１１で定義したよ
うに、未処理メッセージ数およびメッセージ論理到着時
刻を予測することは困難である。

【００５６】そこで、ＶＢＲデータ処理モデルおける時
間属性は、変動する処理時間を考慮して定義することに
する。具体的には、未処理メッセージ数は、ｗ
_n （ｍ_i ）に代えて、任意の時刻に実測された未処理メ
ッセージ数を用いる。つまり、タスクｎにおいて、時刻
ｔに実測された未処理メッセージ数をｂ_n （ｔ）と表記
し、実効未処理メッセージ数と呼ぶことにする。

【００５７】また、メッセージ論理到着時刻ｌ
_n （ｍ_i ）に代えて、メッセージ実効到着時刻ｅ_n （ｍ
_i ）を定義する。つまり、メッセージ論理到着時刻ｌ_n
（ｍ_i ）は、メッセージが初めて処理対象になると予測
される論理時刻である。このことから、メッセージ実効
到着時刻ｅ_n （ｍ_i ）は、タスクｎにおいて、ｉ番目の
メッセージが初めて処理対象になった実際の時刻とし、
数１５のように定義する。

【００５８】

【数１５】ｅ_n （ｍ₀ ）＝ａ_n （ｍ₀ ） ｅ_n （ｍ_i ）＝ｍａｘ（ａ_n （ｍ_i ），ｆ
_n （ｍ_i-1 ）） ただし、ｆ_n （ｍ_i-1 ）は、タスクｎにおけるｉ−１番
目のメッセージの処理完了時刻である。

【００５９】続いて、デッドライン時刻について検討す
る。デッドライン時刻を算出するために、諭理処理遅延
時間を知る必要がある。しかし、時刻ｅ_n （ｍ_i ）にお
いて、ｉ番目のメッセージは処理を完了していないた
め、論理処理遅延時間を知ることができない。

【００６０】そこで、パイプラインモデルにおいて隣接
するタスクｎとタスクｎ＋１とについて考える。タスク
ｎ＋１におけるｉ番目のメッセージが処理対象となる時
刻は、タスクｎ＋１におけるｉ−１番目のメッセージの
処理完了時刻ｆ_n+1 （ｍ_i-1）である。すなわち、タス
クｎは、ｉ番目のメッセージ処理を、タスクｎ＋１にお
けるｉ−１番目のメッセージの処理完了時刻ｆ_n+1 （ｍ
_i-1 ）までに完了すればよいと考えられる。したがっ
て、タスクｎにおけるｉ番目のメッセージのデッドライ
ン時刻は、数１６のように考えられる。

【００６１】

【数１６】ｄ_n （ｍ_i ）＝ｆ_n+1 （ｍ_i-1 ） しかし、時刻ｅ_n （ｍ_i ）において、ｆ_n+1 （ｍ_i-1 ）
は、上述の論理処理遅延時間と同様に不明である。この
ため、時刻ｅ_n （ｍ_i ）におけるタスクｎ＋１の実効未
処理メッセージ数からｆ_n+1 （ｍ_i-1 ）を数１７で示す
ように想定（推測）する。なお、数１７おけるｆ_n+1 上
のバー（横棒）は、推測値であることを意味する。

【００６２】

【数１７】

【００６３】この推定値を用いて、デッドライン時刻ｄ
_n （ｍ_i ）は、数１８に示すように定義される。

【００６４】

【数１８】ｄ_n （ｍ_i ）＝ｅ_n （ｍ_i ）＋ｂ_n+1 （ｅ_n
（ｍ_i ））／Ｒ^c ただし、その他の特性は上述した場合と同じである。つ
まり、数５および数７〜数１０の定義およびタスクの定
義がそのまま適用される。

【００６５】次に、ＶＢＲストリーム処理モデルにおい
て、最悪実行時間より短い処理時間に基づき、ＣＰＵ利
用率を予約する場合におけるＶＢＲストリーム処理モデ
ルの特性に関して検討する。具体的には、定理１〜３を
定義し、それぞれについて証明する。

【００６６】［定理１］ＶＢＲストリーム処理モデルに
おいて、最悪実行時間より短い時間すなわちパラメータ
Ｃ^req とＲ^c とによりＣＰＵ利用率を予約する場合、メ
ッセージの処理完了時刻は、数１９で示される条件で、
デッドライン時刻を満たす。

【００６７】

【数１９】

【００６８】［証明］メッセージの処理完了時刻が、デ
ッドライン時刻を満たすためには、数２０で示すような
条件となる。

【００６９】

【数２０】ｆ_n ≦ｄ_n （ｍ_i ） 数２０を数１５で示したメッセージ実効到着時刻の定義
に従い、ａ_n （ｍ_i ）がｆ_n （ｍ_i-1 ）より大きい場合
と、そうでない場合とに分けて考える。

【００７０】まず、ａ_n （ｍ_i ）≧ｆ_n （ｍ_i-1 ）の場
合には、ｅ_n （ｍ_i ）はａ_n （ｍ_i）となるので、数１
５により、数２０は数２１のようになる。

【００７１】

【数２１】ｆ_n （ｍ_i ）≦ａ_n （ｍ_i ）＋ｂ_n+1 （ｅ_n
（ｍ_i ））／Ｒ^c また、メッセージ処理完了時刻ｆ_n （ｍ_i ）は、メッセ
ージ到着時刻ａ_n （ｍ _i ）に処理遅延時間を加えた時刻
である。したがって、数２１は数２２のようになる。

【００７２】

【数２２】

【００７３】したがって、ａ_n （ｍ_i ）≧ｆ
_n （ｍ_i-1 ）の条件下で、数２２を満たす場合には、処
理モデルはデッドライン時刻を満たす。

【００７４】次に、ａ_n （ｍ_i ）＜ｆ_n （ｍ_i-1 ）の場
合について考える。この場合、ｅ_n（ｍ_i ）はｆ_n （ｍ
_i-1 ）となるので、数１５により、数２０は数２３のよ
うにる。

【００７５】

【数２３】ｆ_n （ｍ_i ）≦ｆ_n （ｍ_i-1 ）＋ｂ_n+1 （ｅ
_n （ｍ_i ））／Ｒ^c パイプラインモデルにおいて、タスクｎのメッセージ処
理完了時刻ｆ_n （ｍ_i）は、タスクｎ＋１のメッセージ
処理完了時刻ａ_n+1 （ｍ_i ）と一致する。したがって、
数２３は数２４のようになる。

【００７６】

【数２４】ａ_n+1 （ｍ_i ）≦ａ_n+1 （ｍ_i-1 ）＋ｂ_n+1
（ｅ_n （ｍ_i ））／Ｒ^c すなわち、 ｂ_n+1 （ｅ_n （ｍ_i ））／Ｒ^c ≧ａ_n+1 （ｍ_i ）−ａ
_n+1 （ｍ_i-1 ） また、場合分けの条件（ｆ_n （ｍ_i ）＜ｆ
_n （ｍ_i-1 ））も同様に、数２５ののようになる。

【００７７】

【数２５】ａ_n （ｍ_i ）＜ａ_n+1 （ｍ_i-1 ） ここで、数２４の右辺の式、ａ_n+1 （ｍ_i ）−ａ
_n+1 （ｍ_i-1 ）について考える。この式を、処理遅延時
間を用いて表すと、数２６のようになる。

【００７８】

【数２６】

【００７９】数２６は、数２５によって、数２７のよう
になる。

【００８０】

【数２７】

【００８１】ただし、ｘは正の数である。

【００８２】このことから、数２５は数２８のようにな
る。

【００８３】

【数２８】

【００８４】したがって、ａ_n （ｍ_i ）＜ｆ
_n （ｍ_i-1 ）の条件下で、数２８を満たす場合には、処
理モデルはデッドライン時刻を満たす。

【００８５】以上のように説明した２つの条件（場合分
けの条件）下で、デッドラインを満たすためには、数２
２および数２８の両方を満たす必要がある。つまり、数
２９に示すようになる。

【００８６】

【数２９】

【００８７】したがって、定理１は成り立つ。

【００８８】［定理２］定理１を満たすＶＢＲストリー
ム処理モデルにおいて、数３０を満たすならば、メッセ
ージ処理に必要なＣＰＵ利用率は、予約したＣＰＵ利用
率を超えない。

【００８９】

【数３０】

【００９０】ただし、Ｃ_n （ｍ_i ）は、タスクｎにおけ
るｉ番目のメッセージ処理に使用するＣＰＵ時間（ＣＰ
Ｕ使用時間）である。

【００９１】［証明］タスクｎにおいて、１メッセージ
処理当たりに予約したＣＰＵ使用時間をＹとすると、Ｃ
ＰＵ予約量はＹＲ^c である。したがって、タスクｎにお
けるｉ番目のメッセージを処理するために使用（利用）
したＣＰＵ利用率Ｕ_n （ｍ_i）は、数３１のようにな
る。

【００９２】

【数３１】

【００９３】上述したように、処理モデルは定理１を満
たすことから、メッセージ処理完了時刻はデッドライン
時刻より小さい。したがって、数３１に示すａ
_n （ｍ_i ）とｄ_n （ｍ_i ）との時間間隔は、数３２のよ
うになる。

【００９４】

【数３２】

【００９５】この数３２を数３１に適用すると、ＣＰＵ
利用率Ｕ_n （ｍ_i ）は数３３のようになる。

【００９６】

【数３３】

【００９７】タスクｎにおいて、処理に必要なＣＰＵ利
用率Ｕ_n （ｍ_i ）が、予約したＣＰＵ利用率ＹＲ^c を越
えないためには、数３２を満たす必要がある。

【００９８】

【数３４】

【００９９】この数３４から数３５が成立する。

【０１００】

【数３５】

【０１０１】この数３５は、処理遅延時間は、ｉ番目の
メッセージ処理に要したＣＰＵ使用時間に対するＣＰＵ
利用率の比で表される時間以上であることを意味する。
さらに、定理１から数３５は、数３６のようになる。

【０１０２】

【数３６】

【０１０３】したがって、定理２が成り立つ。

【０１０４】［定理３］ＶＢＲストリーム処理モデルに
おいて、パラメータＣ^req とＲ^c とによりＣＰＵ利用率
を予約する場合、タスクｎの初期位相が数３７を満たす
ならば、出力装置の時間制約が満たされることが保証さ
れる。

【０１０５】

【数３７】

【０１０６】［証明］出力装置の時間制約を満たすため
には、出力装置は１／Ｒ^c 時間毎にメッセージを必要と
することから、数３８を成立させる必要がある。

【０１０７】

【数３８】 ａ_out （ｍ_i ）≦ａ_out （ｍ₀ ）＋ｉ／Ｒ^c ただし、ａ_out （ｍ_i ）は、出力装置におけるｉ番目の
メッセージ到着時刻である。

【０１０８】出力装置をパイプライン上における終端タ
スクｎの次のタスク、すなわちタスクｎ＋１として考え
ると、数３８は数３９のようになる。

【０１０９】

【数３９】 ａ_n+1 （ｍ_i ）−ａ_n+1 （ｍ₀ ）≦ｉ／Ｒ^c パイプラインモデルの隣接する２つのタスクにおいて、
メッセージ到着時刻ａ _n+1 （ｍ_i ）とメッセージ処理完
了時刻ｆ_n （ｍ_i ）とが一致することから、ａ _n+1 （ｍ
_i ）は数４０のようになる。

【０１１０】

【数４０】

【０１１１】この数４０をｎに関して展開すると、数４
１が得られる。

【０１１２】

【数４１】

【０１１３】この数４１のａ₀ （ｍ_i ）は、タスク０に
おけるメッセージ到着時刻であるが、タスク０はパイプ
ラインの先頭のタスクである。したがって、タスク０の
メッセージは連続メディアデータ入力装置（以下、単に
「入力装置」という。）から得られる。入力装置におけ
るメッセージの到着時刻は周期的であることから、ａ ₀
（ｍ_i ）は数４２のようになる。

【０１１４】

【数４２】ａ₀ （ｍ_i ）＝ａ₀ （ｍ₀ ）＋ｉ／Ｒ^c 以上より、ａ_n+1 （ｍ_i ）は、数４３のようになる。

【０１１５】

【数４３】

【０１１６】この数４３からａ_n+1 （ｍ_i ）−ａ
_n+1 （ｍ₀ ）を求めると、数４４のようになる。

【０１１７】

【数４４】

【０１１８】数４４を数３７に適用すると、数４５が得
られる。

【０１１９】

【数４５】

【０１２０】したがって、定理３が成り立つ。

【０１２１】このように定理１〜定理３で定義されるＶ
ＢＲストリーム処理を前提として、出力装置の時間制約
を満たすタスク制御について考え、この実施例のスケジ
ューリング方法について説明する。

【０１２２】上述した定理３により、タスクの初期位相
が数３５を満たすなら、最悪実行時間より短い時間を用
いてＣＰＵ利用率を予約する場合においても、出力装置
の時間制約が満たされる。しかし、出力装置の時間制約
を満たすためには、上述したように、各タスクに十分な
初期位相が必要であるため、エンド−エンドの処理遅延
時間が大きくなる。

【０１２３】しかし、たとえば、テレビ会議システムの
ようなライブによるシステムでは、エンド−エンドの処
理遅延時間が少ないことが要求される。したがって、十
分な初期位相がない場合において、出力装置の時間制約
を満たす可能性を高める制御について考える。

【０１２４】ここで、定理３で示した数３５を見直すこ
とにする。数３５に示したａ_n （ｍ _i ）に、パイプライ
ンモデル（ＶＢＲストリーム処理モデル）におけるメッ
セージ到着時刻と処理完了時刻との関係を適用すると、
数４６が得られる。

【０１２５】

【数４６】

【０１２６】ここで、（ａ₀ （ｍ₀ ）−ａ₀ （ｍ_i ））
は、タスク０のメッセージ到着時刻の差である。タスク
０はパイプラインの最初のタスクであるため、メッセー
ジの到着時刻は、入力装置からのメッセージ出力時刻で
ある。したがって、メッセ一ジの到着時刻は周期的であ
り、（ａ₀ （ｍ₀ ）−ａ₀ （ｍ_i ））は−ｉ／Ｒ^c であ
る。このことから、数４６は数４７のようになる。

【０１２７】

【数４７】

【０１２８】さらに、０番目のメッセージ到着時刻から
ｉ番目のメッセージ到着時刻までの時間間隔をメッセー
ジの到着間隔ごとに分割すると、数４７の括弧内は数４
８で示すようになる。

【０１２９】

【数４８】

【０１３０】したがって、数４７は、数４９に示すよう
になる。

【０１３１】

【数４９】

【０１３２】この数４９から分かるように、各タスクに
おいて、メッセージ間での処理遅延時間を均等にすると
（数４９の括弧内の演算結果を０にすると）、時間制約
が満たされる。しかし、各メッセージの処理遅延時間
は、そのメッセージ毎に変動するため、単一のタスク内
でメッセージ間の処理遅延時間を均等にすることは困難
である。そこで、各タスクのメッセージ間の処理遅延時
間の差異を、隣接する２つのタスク間で吸収することを
考える。まず、数４９をタスクｊに関して展開すると、
数５０のようになる。

【０１３３】

【数５０】

【０１３４】ここで、タスクｎにおけるｋ＋１番目のメ
ッセージ処理遅延時間は、タスクｎ＋１におけるｋ番目
のメッセージ処理遅延時間と比較されるべきであるが、
タスクｎ＋１は存在しない。しかし、タスクｎ＋１は出
力装置として考えられるので、メッセージ処理遅延時間
の比較対象は出力装置におけるｋ番目のメッセージ処理
遅延時間とする。同様に、タスク０におけるｋ番目のメ
ッセージ処理遅延時間は、入力装置におけるｋ＋１番目
のメッセージ処理遅延時間と比較する。したがって、数
５０は数５１のようになる。

【０１３５】

【数５１】

【０１３６】このように、隣接する２つのタスク間のメ
ッセージ処理遅延時間を均等にすることにより、出力装
置の時間制約を満たすことが可能となる。これを実現さ
せるため、次のような制御を行う。第１に、パイプライ
ン上のタスクの実行機会が同じになるように各タスクの
優先度を連動させる。第２に、メッセージ処理遅延時間
は実効未処理メッセージ数ｂ_n （ｔ）に依存することか
ら、タスクｎのｉ番目のメッセージの処理時における実
効未処理メッセージ数ｂ_n （ｅ_n （ｍ_i ））と後続のタ
スクｎ＋１のｉ番目のメッセージの処理時における実効
未処理メッセージ数ｂ_n+1 （ｅ_n （ｍ_i ））とを比較
し、前者の値が大きい場合には、タスクｎに大きな遅延
が発生することが予想されるので、タスクｎの優先度を
高め、処理を速める。一方、後者の値が大きい場合に
は、タスクｎの処理遅延は小さいことが予想されるの
で、タスクｎの優先度を低め、処理を遅らせる。

【０１３７】図５に示すように、タスク１〜タスク４が
パイプラインモデルに従って接続されているストリーム
処理を用いて具体的に説明する。このパイプラインモデ
ルでは、隣接するタスク１とタスク２とでは、バッファ
１に溜まっているメッセージすなわちデータの量（デー
タ量）がバッファ２に溜まっているデータ量よりも多い
ため、タスク１はタスク２より処理が速いと言える。ま
た、隣接するタスク２とタスク３とでは、バッファ２に
溜まっているデータ量がバッファ３に溜まっているデー
タ量よりも少ないため、タスク２はタスク３より処理が
遅いといえる。さらに、隣接するタスク３とタスク４と
では、バッファ３に溜まっているデータ量がバッファ４
に溜まっているデータ量よりも多いため、タスク３はタ
スク４より処理が速いといえる。

【０１３８】したがって、隣接する２つのタスクにおい
て、実効未処理データ数すなわちバッファに溜まってい
るデータ量を比較し、処理すべきデータのデータ量が多
いタスクについては処理を速めるように、重要度を高め
る。一方、処理すべきデータのデータ量が少ないタスク
については処理を遅くするように、重要度を低める。し
たがって、全てのタスクの処理遅延時間が均一化され、
処理が遅いタスクに依存して全体の処理が遅くなるのを
回避している。

【０１３９】さらに、第３に、メッセージ処理完了後
に、実測された処理遅延時間が定理１すなわち数２９
（数１９）を満たさないならば、処理遅延時間を小さく
するため、優先度を高める。第４にメッセージ処理完了
後に、実測された処理遅延時間が定理２すなわち数３５
（数３０）を満たさないならば、処理遅延時間を大きく
するため、優先度を低める。

【０１４０】以上のように制御することにより、予約し
たＣＰＵ利用率に基づいて、出力装置の時間制約を満た
し、かつエンド−エンドの処理遅延時間を小さくするこ
とが可能となる。

【０１４１】このようなＶＢＲストリーム処理するタス
クは、横取り可能なタスクである。横取り可能なタスク
とは、その実行中に、より高い優先度を持つタスクが到
着した場合、実行権をより高い優先度を持つタスクに引
き渡すことが可能なタスクをいう。

【０１４２】また、ＶＢＲストリーム処理するタスク
は、航空システムや原子力システムに見られる処理完了
時刻に厳密なハードリアルタイムタスクと異なり、その
処理完了時刻には許容される遅延幅があるソフトリアル
タイムタスクとして考えられる。したがって、デッドラ
インに許容遅延幅を持たせることによって、タスクの優
先度として用いるデッドライン時刻は、数１８で求めら
れる時刻に許容遅延幅内で、スケジュール可能性を高め
る制御による優先度の修正を行った時刻とする。この時
刻を適応デッドライン時刻と呼ぶことにする。

【０１４３】以上のように、スケジュール可能性を高め
る制御について説明したが、このような制御は、単一の
ストリーム処理における制御である。しかし、マルチメ
ディア環境においては、多地点のテレビ会議システムに
見られるように、複数のストリーム処理が混在する場合
が多い。すなわち、マルチメディア環境におけるストリ
ーム処理は、パイプラインモデルにより接続されたタス
ク群が複数混在するタスクセットとして考えられる。

【０１４４】このようなタスクセットでは、上述したよ
うな制御におけるスケジュールの問題は、複数のパイプ
ラインのタスク群で上述したような時間制約を同時に満
たすような状態を探し出す多重制約の問題（多重制約問
題）である。

【０１４５】この問題を回避するため、この実施例で
は、上述したように、ＰＤＰモデルを応用する。このＰ
ＤＰモデルでは、多くの単純な情報処理ユニットが相互
に結合し、それぞれが他のユニットから信号を受け取
る。その入力信号が正の値である場合には、ユニットの
状態値を高める。一方、入力信号が負の値である場合に
は、ユニットの状態値を低める。さらに、ユニットの状
態値に応じた信号を他のユニットに送る。この相互作用
をユニット毎に非同期に繰り返すことにより情報処理を
行う。

【０１４６】各ユニットの相互結合により構成されるネ
ットワークは、多重制約の構造を表している。このネッ
トワークに、何らかの外部条件を与え、各ユニットで非
同期に相互作用の繰り返し処理を行う。すると、各ユニ
ットはある状態に落ち着く。その状態がある条件での制
約を最大に充足した状態を表している。

【０１４７】以上のことから、複数のパイプラインのタ
スク群における制約を充足する状態を算出するために、
タスク間の依存関係をＰＤＰモデルの相互結合ネットワ
ーク（以下、単に「ネットワーク」という。）に次のよ
うに対応づける。

【０１４８】各ユニットの状態値（０から１までの連
続値）は、各タスクの重要度とする。タスクの重要度
は、最高値（１）を適応デッドライン時刻の最短時刻に
対応づけ、最低値（０）を適応デッドライン時刻の最長
時刻に対応づける。これにより、重要度から適応デッド
ライン時刻を算出する。

【０１４９】ユニット間の結合は、通信するタスク間
では、正の重みを持たせ、通信しないタスク間では、負
の重みを持たせる。したがって、正の重みを持つタスク
間の結合では、ユニットの状態値に比例した正の入力が
他のタスクに作用し、相互に近い状態値になる。一方、
負の重みを持つタスク間の結合では、ユニットの状態値
に比例した負の入力が他のタスクに作用し、互いに遠い
状態値になる。これにより、同一パイプライン上のタス
ク群の重要度が連動し、各タスクの実行機会を同じにす
ることができる。

【０１５０】各ユニットに与えられる外部条件は、変
動するタスク実行状況に対応してネットワークの動作を
修正する力とする。すなわち、外部条件は、各タスクの
変動する処理遅延時間に応じて、上述したような制御を
次のようにネットワークに作用させる。

【０１５１】（I)タスクｎのｉ番目のメッセージの処理
時における実効未処理メッセージ数ｂ_n （ｅ
_n （ｍ_i ））と後続するタスクｎ＋１のｉ番目のメッセ
ージの処理時における実効未処理メッセージ数ｂ
_n+1 （ｅ_n （ｍ_i ））とを比較し、前者の値が大きい場
合には、正の入力とする。また、後者の値が大きい場合
には、負の入力とする。

【０１５２】（II）実測された処理遅延時間が定理１を
満たすならば、正の入力とする。

【０１５３】（III)実測された処理遅延時間が定理２を
満たすならば、負の入力とする。

【０１５４】以上により、複数のパイプラインのタスク
群における制約を、ネットワークを動作させて処理す
る。

【０１５５】しかし、ＰＤＰモデルは、ネットワークを
動作させると、その状態は初期値に依存して或る制約充
足度の高い状態に至り、動作は静止する。一方、ストリ
ーム処理環境において、各タスクの処理遅延時間は、処
理するメッセージによって常に変化する。ネットワーク
は、この変化に応じて、１つの状態に静止することな
く、いくつかの制約充足度の高い状態間を移動する必要
がある。

【０１５６】このため、ＰＤＰモデルに熱力学的モデル
を加える。熱力学的モデルは、温度による物質の熱揺動
（高温では分子間の結合が弱まり不安定であり、低温で
は分子間の結合が強まり安定する性質）をＰＤＰモデル
の処理において擬似する。具体的には、焼き鈍し法が加
えられる。しかし、焼き鈍し法は、収束するのに時間が
かかるため、制約充足度の高い状態（安定状態）との距
離に応じて焼き鈍しの温度を制御する。すなわち、制約
充足度の高い状態から距離が離れている場合には温度を
高くし、制約充足度の高い状態に近い場合には温度を低
くする。すると、ネットワークワークは、制約充足度の
高い状態に素早く近づき、また外部条件の変化に敏感に
対応する。この温度による熱揺動制御により、ＰＤＰモ
デルを各タスクの変動する処理遅延時間に連続的に動作
するようにし、定理１と定理２とを満たし、かつタスク
間の処理遅延時間を均一にする適応デッドライン時刻を
探し続けることを可能とする。

【０１５７】以上のような考え方に基づいたアルゴリズ
ムで或るタスクの重要度の更新則（重要度更新則）につ
いて説明する。タスクの重要度は、ＰＤＰモデルにした
がって、他のタスクからの入力および外部条件としての
入力（外部入力）により決定する。しかし、その決め方
が焼き鈍し法により制御されるため、確率的に決定させ
る。この確率的な決定をＰＤＰモデルの状態更新則に加
え、タスクの重要度更新則とする。具体的には、タスク
の重要度は、数５２に従って決定される。

【０１５８】なお、これ以降では、ユニットをタスクに
対応づけるとともに、状態値を重要度に対応づけて説明
する。

【０１５９】

【数５２】

【０１６０】この数５２において、タスクの重要度を高
める方向へ更新する場合には、右辺の第２項の上式が採
用される。一方、タスクの重要度を低める方向経更新す
る場合には、右辺の第２項の下式が採用される。上下ど
ちらの式を採用するかは、後で詳細に説明する確率関数
（ボルツマン関数）によって決定される。すなわち、数
５２の右方に示した不当式によって決定される。

【０１６１】また、タスクへの総入力は、図６のように
示され、他のタスクからの入力（他のタスクの出力）の
総和と外部入力とにより構成される。このタスクへの総
入力は、数５３で示される。

【０１６２】

【数５３】

【０１６３】数５３から分かるように、他のタスクから
の入力は他のタスクの重要度とそのタスク間の結合重み
との積である。このため、正の結合重みを持つ、すなわ
ち通信するタスク（他のタスク）からはそのタスクの重
要度の高さに比例した正の入力が、入力を受けるタスク
に作用する。一方、負の結合重みを持つ、すなわち通信
しないタスク（他のタスク）からはそのタスクの重要度
の高さに比例した負の入力が、入力を受けるタスクに作
用する。

【０１６４】したがって、タスクへの総入力が大きな正
の値となると、重要度更新則は高い確率でタスクの重要
度を高める。逆の状態では、タスクへの総入力は大きな
負の値となり、重要度更新則は高い確率で重要度を低め
る。すなわち、相互通信するタスクの重要度は連動して
更新される可能性が高い。

【０１６５】この実施例では、接続要求を行うタスクと
その接続先のタスクとの間の結合を、正の重みを持つ結
合とする。また、接続関係のないタスク間の結合は負の
重みを持つ結合とする。これにより、タスク間の通信依
存関係を、相互結合ネットワークとして構築する。

【０１６６】また、上述したように、時刻ｅ_n （ｍ_i ）
におけるタスクｎの実効未処理メッセージ数とタスクｎ
＋１の実効未処理メッセージ数との比較結果、に基づい
てネットワークの動作を修正する必要がある。その修正
を外部入力として対応づけることができる。具体的に
は、数５４、数５５および数５６のように示される。

【０１６７】

【数５４】

【０１６８】

【数５５】

【０１６９】

【数５６】

【０１７０】数５４から分かるように、時刻ｅ
_n （ｍ_i ）おけるタスクｎの実効未処理メッセージ数が
タスクｎ＋１の実効未処理メッセージ数以上である場合
には、タスクｎにおいて処理遅延が発生し始めていると
判断する。このため、外部入力は、処理速度を速くする
ように適応デッドラインを算出するため、タスクｎの重
要度を高める正の入力とする。一方、時刻ｅ_n （ｍ_i ）
おけるタスクｎの実効未処理メッセージ数がタスクｎ＋
１の実効未処理メッセージ数より少ない場合には、タス
クｎにおける処理遅延が小さいと判断する。逆に、タス
クｎ＋１における処理遅延が発生し始めていると判断す
る。このため、外部入力は、処理速度を遅くするように
適応デッドラインを算出するため、タスクｎの重要度を
低める負の入力とする。

【０１７１】また、数５５から分かるように、処理遅延
時間が定理１を満たさない場合には、処理遅延時間を小
さくするように適応デッドラインを算出するため、タス
クｎの重要度を高める正の入力とする。

【０１７２】さらに、数５６から分かるように、処理遅
延時間が定理２を満たさない場合には、処理遅延時間を
大きくするように適応デッドラインを算出するため、タ
スクｎの重要度を低める負の入力とする。

【０１７３】数５３で示したように、数５４〜数５６の
総和が外部入力としてタスクに入力される。ただし、数
５５および数５６においては、処理遅延時間が定理１お
よび定理２をそれぞれ満たす場合には、適応デッドライ
ンを調整する必要がない。したがって、重要度を更新す
る必要がないので、０が入力されることになる。

【０１７４】なお、最初の周期では、タスクの実効未処
理メッセージ数は０であるため、数５５において外部入
力を０とすると、タスクの重要度は数５４の右辺の第１
項のみによって決定される。つまり、通信依存関係があ
るつまり協調関係にある他のタスクの重要度によってタ
スクの重要度が決定される。その結果として、通信する
タスクの実行開始時刻に近づけるように、タスクの適応
デッドラインを設定することができる。

【０１７５】さらに、上述したように、ＰＤＰモデルネ
ットワークは、初期値に依存して、ある制約充足度の高
い状態に至り、静止する。したがって、この実施例で
は、焼き鈍し法を加えることにより、これを回避してい
る。つまり、重要度を高めるかまたは低めるかを、数５
７で示すような確率関数で決定する。

【０１７６】

【数５７】

【０１７７】なお、通常の焼き鈍し法では、熱力学的モ
デルを応用し、ある固定の外部条件で温度を高い状態
（様々な状態を激しく移動する）からゆっくりと温度を
下げ、最も安定する状態を探す。しかし、この実施例で
想定する動的な環境では、外部条件（外部入力）である
実行未処理メッセージ数が短時間に変動するため、この
方法をそのまま用いることができない。そこで、短時間
に変動する外部条件に対応するため、適度な充足度とす
ることで収束を途中までとし、また外部変化に敏感に反
応するようにしている。これを実現するため、この実施
例では、制約充足度の高い状態（安定状態）からの距離
により焼き鈍しの温度を制御している。

【０１７８】たとえば、ＰＤＰモデルにおける制約充足
度は、数５８のように示される。

【０１７９】

【数５８】

【０１８０】ここで、制約充足度Ｇ(t) は、次のように
すると、最大となる。つまり、外部入力が０の場合に
は、相互に通信するタスク集合におけるすべてのタスク
の重要度を１にし、通信しないタスク集合におけるすべ
てのタスクの重要度を０にする。これは、相互に通信す
るタスクは重要度を同時に高くして処理速度を早め、そ
の他の（通信しない）タスクは処理速度を遅らすことを
意味している。このような状態が制約充足度を高くす
る。また、制約充足度の高い状態は、相互に通信するタ
スクの集合毎に存在する。

【０１８１】この実施例では、外部入力である実行未処
理メッセージ数があるため、上述した制約充足度の高い
状態とは一致しない可能性が高い。しかし、相互に通信
するタスクを近い時刻で実行すると、通信待ち時間が減
少することから、この近傍に制約充足度の高い状態が存
在していると考えられる。

【０１８２】また、この実施例では、制約充足度の高い
状態を、接続要求を行うタスク毎に設定する。その状態
は、接続要求を行うタスクおよびその接続先のタスクの
重要度が１となり、その他のタスクの重要度が０となる
ようにする。これにより、制約充足度の高い状態が比較
的多く設定される。したがって、制約充足度の高い状態
間の距離が短くなり、状態間の移動が容易になる。

【０１８３】したがって、焼き鈍し温度は、数５９に従
って制御される。

【０１８４】

【数５９】

【０１８５】数５９から分かるように、タスク間の相互
結合ネットワークの状態が制約充足度の高い状態に近い
場合には温度を低くする。その結果、確率関数は１に近
い値を出力し、タスクの重要度が制約充足度の高い状態
へ近づきすぎると、温度が小さな値となり、確率関数は
ほぼ１を出力し、タスクの重要度は制約充足度の高い特
定の状態に固定化する。

【０１８６】ただし、この実施例では、動的な環境であ
るため、制約充足度の高い状態は時間とともに変化す
る。そこで、焼き鈍し下限温度ＣＯＯＬにより、温度を
下げ止まりさせ、その近傍で小さく振動させる。したが
って、適度な制約充足と外部変化に敏感に反応する動作
を実現することができる。一方、距離が遠い場合には、
温度を高くし、大きく振動させ充足度の高い状態を発見
する可能性を高める。このように制御することにより、
タスクの重要度の初期値に依存することなく、外部環境
の変化に応じて複数の制約充足度の高い状態を移動する
ことができる。言い換えると、準安定状態と準安定状態
を探している状態（不安定状態）との２つの状態を移動
することができる。

【０１８７】このようなタスクの重要度更新則は、タス
クにおけるメッセージの実効到着時刻ｅ_n （ｍ_i ）にタ
スク毎に単独に適用する。これにより求められたタスク
の重要度α_n （ｔ）から数６０で示すように、デッドラ
インを修正する時刻を算出する。

【０１８８】

【数６０】 ｖ_n （ｍ_i ）＝ｈ_n −２ｈ_n α_n （ｅ_n （ｍ_i ）） ただし、ｈ_n はタスクｎにおける処理遅延許容幅、ｖ_n
（ｍ_i ）はタスクｎにおけるｉ番目のメッセージ処理に
おけるデッドライン時刻を修正する時間（−ｈ _n ≦ｖ_n
（ｍ_i ）≦ｈ_n ）である。

【０１８９】このｖ_n から、タスクエヌにおけるｉ番目
のメッセージ処理の適応デッドライン時刻を数６１によ
り求めることができる。

【０１９０】

【数６１】

【０１９１】この数６１によって算出された適応デッド
ライン時刻に基づいて、タスクの実効順をＥＤＦにより
求める。

【０１９２】具体的には、図１で示したＣＰＵ１２は、
タスク毎に、図７に示すデッドライン設定処理を実行
し、数６１に示した適応デッドラインを設定（更新）す
る。ただし、簡単のため、タスクｎについて処理した場
合を説明し、他のタスクについての説明は省略する。

【０１９３】ＰＣ１０でタスクをスケジューリングする
ためのソフトが起動されると、ＣＰＵ１２はデッドライ
ン設定処理を開始し、ステップＳ１でタスクｎが処理す
べきデータが到着したかどうかを判断する。ステップＳ
１で“ＮＯ”であれば、つまりタスクｎが処理すべきデ
ータが到着しなければ、そのままステップＳ１に戻っ
て、データが到着するのを待つ。一方、ステップＳ１で
“ＹＥＳ”であれば、つまりタスクｎが処理すべきデー
タが到着すれば、ステップＳ３でスケジューリング対象
のタスクｎを起動する。したがって、到着したデータが
処理される。

【０１９４】続くステップＳ５では、タスクｎの実効未
処理メッセージ数を取得し、ステップＳ７では、後で詳
細に説明する重要度更新処理を実効する。そして、ステ
ップＳ９では、ステップＳ７で更新された重要度に基づ
いて適応デッドラインを設定或いは再設定（更新）して
からステップＳ１に戻る。

【０１９５】図８を参照して、図７のステップＳ７の重
要度更新処理が開始されると、ＣＰＵ１２は、ステップ
Ｓ１１で、タスクｎとタスクｎ＋１との優先度を同じ
（均一）にする。続くステップＳ１３では、ｂ_n （ｅ_n
（ｍ_i ））がｂ_n+1 （ｅ_n （ｍ _i ））以上かどうかを判
断する。つまり、同じ時間ｅ_n （ｍ_i ）におけるタスク
ｎの実効未処理タスク数とタスクｎ＋１の実効未処理タ
スク数とを比較して、タスクｎに大きな遅延が発生する
かどうかを予想している。

【０１９６】なお、タスクｎ＋１における未実効処理タ
スク数は、タスクｎ＋１についての図７で示したデッド
ライン設定処理において取得される。

【０１９７】ステップＳ１３で“ＹＥＳ”であれば、つ
まりｂ_n （ｅ_n （ｍ_i ））がｂ_n+1（ｅ_n （ｍ_i ））以
上であれば、タスクｎに大きな遅延が発生すると判断
し、ステップＳ１５でタスクｎの重要度を高めてからス
テップＳ１９に進む。一方、ステップＳ１３で“ＮＯ”
であれば、つまりｂ_n （ｅ_n （ｍ_i ））がｂ_n+1 （ｅ_n
（ｍ_i ））より小さければ、タスクｎの処理遅延が小さ
いと判断し、ステップＳ１７でタスクｎの重要度を低め
てからステップＳ１９に進む。

【０１９８】ステップＳ１９では、処理遅延時間が数１
９を満たすかどうか、すなわち定理１を満たすかどうか
を判断する。ステップＳ１９で“ＹＥＳ”であれば、つ
まり定理１を満たす場合には、タスクｎにおけるメッセ
ージの処理完了時刻はデッドライン時刻を満たすと判断
し、そのままステップＳ２３に進む。

【０１９９】一方、ステップＳ１９で“ＮＯ”であれ
ば、つまり定理１を満たさない場合には、タスクｎにお
けるメッセージの処理完了時刻がデッドライン時刻を越
えてしまうと判断し、ステップＳ２１でタスクｎの重要
度を高めてからステップＳ２３に進む。

【０２００】ステップＳ２３では、処理遅延時間が数３
５を満たすかどうか、すなわち定理２を満たすかどうか
を判断する。ステップＳ２３で“ＹＥＳ”であれば、つ
まり定理２を満たす場合には、タスクｎにおけるメッセ
ージ処理に必要なＣＰＵ利用率が最悪実効時間より短い
時間を用いて予約したＣＰＵ利用率を越えないと判断
し、そのままリターンする。

【０２０１】一方、ステップＳ２３で“ＮＯ”であれ
ば、つまり定理２を満たさない場合には、タスクｎにお
けるメッセージ処理に必要なＣＰＵ利用率が予約したＣ
ＰＵ利用率を越えてしまうと判断し、ステップＳ２５で
タスクｎの重要度を低めてから処理を終了する。

【０２０２】このように、タスクｎの重要度を修正（高
めたり低めたり）することによって、適応デッドライン
を速くしたり、遅くらせたりすることができる。したが
って、タスクｎでの処理を速めたり遅らせたりすること
ができる。

【０２０３】この実施例によれば、実効未処理メッセー
ジ数に応じてタスクの重要度を修正して、隣接するタス
クにおける処理速度を調整するので、すべてのタスクに
おける処理遅延を均一化することができる。したがっ
て、処理の遅いタスクに依存してシステム全体の処理が
遅くなってしまうようなことがない。つまり、ＣＰＵを
有効に利用することができるので、効率よくタスクをス
ケジューリングすることができる。

【０２０４】また、最悪実行時間よりも短いＣＰＵ使用
時間を用いてＣＰＵ利用率を予約するので、予約量が過
負荷になることがなく、スケジューリング可能性を高め
ることができる。

【０２０５】このようなスケジューリング方法に従っ
て、本願発明者が行った評価実験の結果を以下に示す。
なお、このようなスケジューリング方法を、分散ＯＳの
構成法の研究のために開発しているマイクロカーネルSo
lelc（アルテミス）上に実装して、性能評価を行った。
また、性能評価の環境として、次に示すようなハードウ
ェアおよびソフトウェアを使用した。

【０２０６】ハードウェアの環境としては、使用機種は
エプソン社製の「Endeavor ATX-7000 」であり、プロセ
ッサが「Pentium-S 200MHz」であり、キャッシュメモリ
が512KB であり、主記憶（ＨＤＤ）が128MB である。

【０２０７】また、ソフトウェアの環境としては、上述
したように、ＯＳにはSolelcを使用した。今回の評価実
験では、Solelcのディスパッチ機能およびメッセージ通
信機能のみを使用し、スケジューリング分解能は１msec
とした。また、コンパイラはｇｃｃ（ｖｅｒｓｉｏｎ
ｅｇｃｓ−２．９１．６０）を使用した。

【０２０８】また、性能評価に使用するパイプライン
は、図２で示したパイプラインモデルに基づいて構成す
る。具体的には、周期的にメッセージを生成する入力装
置、周期的にメッセージを消滅する出力装置およびメッ
セージ毎に処理時間が変動する入力サーバタスク、出力
サーバタスク、アプリケーションタスクによって、パイ
プラインが構成される。

【０２０９】ここで、上述の実施例におけるスケジュー
リング方法では、複数のストリーム処理が混在すること
を想定しているため、評価に用いるタスクセット（評価
タスクセット）は、上述したようなパイプライン処理を
行うタスクの組を３組とし、ランダムな負荷を生成する
周期タスクにより構成する。

【０２１０】評価方法は、周期タスクモデルによる方
式、ＬＢＡＰによる方式および上述の実施例で示したス
ケジューリング方法による方式（実施例方式）の３つの
方式を、評価タスクセットの付加タスクとパイプライン
上のタスクのスケジューリング成功率で比較評価する。
また、各タスクの時間属性は表１のように設定した。た
だし、タスクの実行時間は、メッセージの処理毎に、最
大実行時間と最小実行時間との間をランダムに変動する
時間とした。

【０２１１】

【表１】

【０２１２】また、タスク重要度更新則のパラメータに
ついては、ネットワークの結合重みは通信関係がある場
合は５．０とし、通信関係がない場合は−５．０とし
た。温度制御パラメータにおいて、Ｄ はネットワーク
状態間の最大距離×０．２とし、Ｄ はネットワーク状
態間の最大距離×０．５とし、そして、ｒ１、ｒ２およ
びｒ３は、それぞれ、０．５、０．９および０．９とし
た。

【０２１３】このような評価タスクセットに関して、負
荷状況、初期位相状況を変動させ、スケジューリング成
功率を３つのスケジューリング方式について比較評価し
た。スケジューリングの成功率は、数６２のように定義
し、評価期間は１８０，０００ｍｓｅｃとした。

【０２１４】

【数６２】

【０２１５】ただし、Success(Load) はデッドライン時
刻までに処理を完了した負荷周期タスク数であり、Succ
ess(Msg）は出力装置の処理開始時刻までに出力装置に
到着したメッセージ数であり、Finish(Load)は処理完了
した負荷周期タスク数であり、そして、Finish(Msg) は
出力装置に到着したメッセージ数である。

【０２１６】負荷状況に応じたスケジューリングの成功
率が図９に示される。図９においては、縦軸にスケジュ
ーリング成功率を表し、横軸に負荷を表している。ただ
し、負荷は、すべての実行タスクにおける周期（１／Ｒ
^c ）に占める平均実行時間の割合の総和とした。また、
評価時の負荷量は、負荷周期タスクの最大実行時間と最
小実行時間により調整した。各タスク間の初期位相は、
各タスクの１周期分の時間とした。さらに、ＬＢＡＰに
よる方式の最大処理遅延時間は初期位相と同じ時間と
し、その最大処理遅延時間によりデッドライン時刻を設
定した。

【０２１７】図９から分かるように、実施例方式は、他
の方式よりスケジューリングの成功率が常に高い。ま
た、過負荷の状況においても、スケジューリングの成功
率が高い。これは、タスク間の初期位相により発生した
未処理メッセージ数をタスクかんで均一にするメカニズ
ムが各タスクの処理遅延時間を均等にすることにするこ
とで、タスクの負荷を分散させているからである。一
方、他の方式は、負荷が高まると急激にスケジューリン
グの成功率が低下する。このように、未処理メッセージ
数をタスク間で均一にするメカニズムが高負荷時にスケ
ジュール可能性を高めるのに有効であることが分かる。

【０２１８】続いて、初期位相に応じたスケジューリン
グの成功率を図１０に示す。図１０においては、縦軸に
スケジューリングの成功率を表し、横軸に初期位相を表
している。ただし、負荷は１．０３とし、初期位相は各
タスクの周期の倍数で設定した。

【０２１９】図１０から分かるように、実施例方式およ
びＬＢＡＰによる方式では、初期位相を大きくすると、
スケジューリングの成功率が改善されるが、周期タスク
モデルによる方式では、スケジューリングの成功率が改
善されない。これは、周期タスクモデルによる方式は、
大きな初期位相により発生した多くの未処理メッセージ
数を考慮していないため、隣接するタスクがメッセージ
を必要とする時刻までに余裕があるにも拘わらず、固定
のレートで処理を実行していることに起因している。す
なわち、余裕があるにも拘わらず、固定のレートで処理
を実行するため、負荷周期タスクの実行機会が増えな
い。したがって、スケジューリングの成功率が改善され
ない。

【０２２０】一方、ＬＢＡＰによる方式と実施例方式と
では、スケジューリングの成功率が改善されるが、両者
を比較すると、ＬＢＡＰによる方式はスケジューリング
の成功率を改善するためにおおきな初期位相を必要とす
る。これは、ＬＢＡＰによる方式が固定の処理遅延時間
に基づいてデッドライン時刻（優先度）を決めるため、
固定の処理遅延時間を越える未処理メッセージ数が発生
する場合、周期タスクモデルによる方式と同様の減少に
陥ることに起因する。この点、実施例方式は、変動する
処理遅延時間に適時対応してデッドライン時刻（優先
度）を決めるため、負荷周期タスクの時刻機会を増加さ
せることができる。このため、スケジューリングの成功
率が改善されている。

【０２２１】以上のことから、実施例方式は、従来の方
式と比較して、次のような特性を持つと言える。まず、
スケジューリング可能性が高く、特に高負荷時にその差
が著しい。したがって、ＣＰＵ利用率を高めることがで
きる。また、少ない初期位相でスケジューリング成功率
が改善される。したがって、少なエンド−エンド処理遅
延時間でスケジューリングすることが可能である。

【０２２２】なお、実施例方式では、その計算量がスケ
ジュール対象のタスク総数に比例する。したがって、ス
ケジューリングオーバヘッドは、タスク総数が増えるに
連れて高くなる。このオーバヘッドの評価結果につい
て、図１１のように、グラフで示す。この図１１に示す
グラフから分かるように、タスク総数に応じて、オーバ
ヘッドは直線的に高くなっている。たとえば、プロセッ
サが「Pentium-S 200MHz 」であれば、タスク総数が１
０である場合には、オーバヘッドは平均約７２μsec で
ある。現在の一般的なプロセッサのクロックは評価環境
の数倍であるため、一般的なＰＣでは、評価環境の２倍
のクロックを持つと仮定できる。したがって、タスク総
数が１０である場合には、約３６μsec の計算時間が必
要となる。ただし、この負荷は、タスクの重要度更新則
を適用するタスクの到着時のみに必要であり、それ以外
のコンテキストスイッチには不要である。

【０２２３】一方、マルチメディア環境で扱う音声、ア
ニメーションおよびビデオは、文献（B.Furth:Multimed
ia Systems:An Overview,IEEE Multimedia,Vol.1,No.1,
pp.47-59(1994)) によれば、最短周期が７５Hz、すなわ
ち約１３msecとなっている。この最短周期のタスクを１
０個スケジューリングする場合には、一般的なＰＣ環境
においては１周期のスケジューリング計算に必要となる
時間は、上述したように約３６μsec である。この時間
がタスクの周期を占める割合は、高々０．２８％に過ぎ
ず、タスクを１００個スケジューリングしたとしても
２．８％である。

【０２２４】以上のことから、実施例方式はタスク総数
に比例してオーバヘッドは高くなるが、タスクのスケジ
ューリング周期に占める割合は極微量であると言える。
したがって、実施例方式は、連続メディアをストリーム
処理するタスクのスケジューリングに十分に適用できる
と考えられる。

【図面の簡単な説明】

【図１】この発明方法を実施する際の構成の一実施例を
示す図解図である。

【図２】この発明方法が適用されるパイプラインモデル
の一例を示す図解図である。

【図３】周期タスクモデルにおけるメッセージ到着の非
周期性を示すためのタイミングチャートである。

【図４】ＬＢＡＰにおけるタスクの時間属性を示すタイ
ミングチャートである。

【図５】パイプラインモデルの各タスクにおけるメッセ
ージ処理の一例を示す概念図である。

【図６】タスクへの総入力の構成を示す模式図である。

【図７】図１に示すＣＰＵのデッドライン設定処理を示
すフロー図である。

【図８】図７に示すＣＰＵの重要度更新処理を示すフロ
ー図である。

【図９】評価タスクセットにおける評価実験の結果を示
すグラフである。

【図１０】評価タスクセットにおける他の評価実験の結
果を示すグラフである。

【図１１】タスク総数と実施例方式によるスケジューリ
ングのオーバヘッドとの関係を示すグラフである。

【符号の説明】

１０ …ＰＣ １２ …ＣＰＵ １４ …バス １６ …ＨＤＤ １８ …ＲＡＭ ２０ …インターフェイス

Claims (6)

【特許請求の範囲】
1. 【請求項１】マルチメディアタスクをＶＢＲストリーム
   処理するための連続メディアストリーム処理におけるス
   ケジューリング方法であって、 (a) メッセージが到着したときに前記メッセージを処理
   すべきタスクを起動するステップ、 (b) 前記タスクで前記メッセージの処理が終了した後前
   記タスクの実効未処理メッセージ数を取得するステッ
   プ、および(c) 前記実効未処理メッセージ数に応じて適
   応デッドラインを設定するステップを含む、スケジュー
   リング方法。
2. 【請求項２】前記ステップ(c) は、(c1)少なくとも前記
   タスクの重要度に従って適応デッドラインを設定するス
   テップを含む、請求項１記載のスケジューリング方法。
3. 【請求項３】前記ステップ(c1)は、(c2)前記重要度を更
   新するステップを含む、請求項２記載のスケジューリン
   グ方法。
4. 【請求項４】前記ステップ(c1)は、(c3)隣接する２つの
   前記タスクの前記重要度を同じにするステップ、および
   (c4)前記２つのタスクにおける先行する前記タスクにお
   ける前記実効未処理メッセージ数が後続の前記タスクの
   前記実効未処理メッセージ数よりも多い場合に前記重要
   度を高くし、少ない場合に前記重要度を低くするステッ
   プを含む、請求項２または３記載のスケジューリング方
   法。
5. 【請求項５】前記ステップ(c4)は、(c5)メッセージ処理
   完了後に実測された処理遅延時間が推定デッドライン時
   刻を満たさない場合に前記重要度を高めるステップを含
   む、請求項４記載のスケジューリング方法。
6. 【請求項６】前記ステップ(c4)は、(c6)メッセージ処理
   完了後に実測された処理遅延時間が前記メッセージ処理
   に要したＣＰＵ使用時間に対する予約したＣＰＵ使用率
   の比より小さい場合に前記重要度を低めるステップをさ
   らに含む、請求項４または５記載のスケジューリング方
   法。