JP2006146937A - データのリアルタイム処理を行うための方法及びシステム - Google Patents

Abstract

【課題】マルチプロセッサシステムにおけるプロセッサの利用率を増加させるシステム及び方法を提供する。
【解決手段】データのリアルタイム処理を行うための方法は、マルチプロセッサコンピュータ処理システムにおける複数のプロセッサで１組のタスクを行うために使用される。この方法は、厳密リアルタイムスケジュールを実行するステップと、疑似リアルタイムスケジュールを実行するステップと、を具備する。この方法は、動作条件の主要なセットを評価し、動作条件の主要なセットの評価に基づいて厳密リアルタイムスケジュールまたは疑似リアルタイムスケジュールを交代的に選択する。
【選択図】図４

Description

本発明は、一般的にコンピュータシステムに関し、特に処理リソースの使用を改良してデータのリアルタイム処理を可能にするための、マルチプロセッサシステム中のタスクの処理をスケジュールするシステム及び方法に関する。

コンピュータ及びコンピュータ関連技術の開発が進むにつれて、これらの技術の応用も同様に急速なペースで進められている。コンピュータ技術の応用は、処理速度とコンピュータ処理パワーの増加を利用し、また更なる増加に対する要求を駆り立てている。速度及びパワーの増加に対する要求は、時には、単に付加的なリソースを設けることによって、及びそうでなければ既存のリソースを更に効率的にすることによって満たされる。

更に多くのコンピュータ処理パワーを提供するために使用される方法の１つは、コンピュータシステム中に多数のプロセッサを設けることである。所定のアプリケーションの種々のタスクを実行するように更に多くのプロセッサを利用可能にし、異なるタスクを実行させる複数のプロセッサを並列に設けることによって、アプリケーションは、そのタスクが同等の処理パワーを有する単一のプロセッサによって直列的に実行されなければならない場合よりも遥かに迅速に実行されることができる。

しかしながら、典型的には、これらのタスクを直列的に処理するのに対して並列的にアプリケーションのタスクを処理することは、より困難である。伝統的に、アプリケーション（コンピュータプログラム）は、直列の態様で構成される。換言すると、アプリケーションは、次々に実行される一連のプログラム命令からなる。多くの場合、１つのタスク（例えば１つのプログラム命令または一連の命令）は、そのタスクの結果が別のタスクで使用されることができるように終了されなければならない。それ故、アプリケーションは、典型的には、本質的に直列である。しかしながら、相互に独立しており、それ故並列に実行されることのできるタスクも存在する。

アプリケーション内の種々のタスクを可能な限り並列に行うことができるように、タスクを多数のプロセッサ間でどのように分配できるかを決定することは、多くの場合、非常に複雑で困難な仕事である。前述したように、煩雑さの１つは、何れのタスクが相互に独立し、それ故に並列に実行できるかを決定することを含むことである。別の煩雑さは、幾つかのタスクは、タスクが並列の態様で処理されると満足されるまたは満足されないであろう処理制約を有する可能性があることである。例えば、幾つかのタスクは、アプリケーションにとって重要であり、そのアプリケーションの全体的な性能は、これらのタスクが遅延されると（例えば、並列して実行するためにタスクをスケジュールする上で）、許容不能となる可能性がある。

アプリケーション内でのタスクの実行について制約がある状態の１例は、アプリケーションがビデオデータのようなデータのリアルタイム処理を行うことを意図する場合である。符号化されたビデオデータ処理では、データを復号してそれを（ビデオディスプレイの形態で）ユーザに示すことをリアルタイムで行うことが重要である。換言すると、固有のリアルタイムの速度を有するビデオイメージを表すビデオフレームのデータは、そのビデオイメージがこのリアルタイム速度で連続的な流れとしてユーザに提供されることができるように十分迅速に処理されなければならない。処理に遅延が存在するならば、ユーザに与えられるビデオデータ流は中断され、表示されるビデオに中断または不自然さ（artifacts）が生成される。このような中断または不自然さは許容できないものであり、従って、符号化されたビデオデータのリアルタイム処理を行うことが重要である。

符号化されたビデオのようなデータをリアルタイムで処理するため、マルチプロセッサコンピュータ処理システムのプロセッサは、必要とされる種々の処理タスクを処理するためにスケジュールされる。これらのタスクのスケジュールは、典型的には、２つの態様の一方、即ち静的または動的に行われる。これらの態様は夫々固有の利点と欠点を有する。

タスクの静的スケジュールは、通常、行われるべき特別なタスクを決定し、その後異なるプロセッサによってこれらのタスクの実行のスケジュールを決定することからなり、それによってスケジュールされたタスクは、最悪の場合のシナリオでさえもリアルタイムで実行されることができる。このスケジュールが決定されると、それは固定され、データの処理が開始されてからは変更されない。静的スケジュール態様の利点は、これらが、実行が比較的容易であり、予測可能であり、調整可能（scalable）であることである。静的スケジュール態様の主な欠点は、これらが、動的態様よりもプロセッサの利用率が低い可能性があることである。

タスクの動的スケジュールは、通常、混雑していないプロセッサを識別し、実行される次のタスクをそのプロセッサに割当てることからなる。換言すると、各プロセッサは、対応するタスクを割当てられ、特定のプロセッサがその割当てられたタスクを終了したときに、新しいタスクが実行されるようにそのプロセッサに割当てられる。動的態様を使用する利点は、プロセッサの利用率が、典型的には、静的スケジュール態様よりも高いことである。動的スケジュール態様の欠点は、それらが、典型的には、静的スケジュール態様よりも実行が難しく、（ディスパッチ時間、再スケジュール時間等に関して）静的態様のように予測が可能でなく、現状では、通常、容易に調整可能でないことである。

上述の課題は、本発明の様々な実施形態によって解消することが可能である。概略的には、本発明は、厳密リアルタイムスケジュール及び疑似リアルタイムスケジュールを規定し、プロセッサでタスクを実行するために厳密リアルタイムスケジュールと疑似リアルタイムスケジュールとの間で動的に切換えを行うことによって、マルチプロセッサシステムにおけるプロセッサの利用率を増加させるシステム及び方法を含む。１実施形態では、出力バッファを占有するエントリ数が監視される。その数が第１のしきい値に合致するかそれを超えるとき、疑似リアルタイムスケジュールが実行される。その数が第２のしきい値以下であるとき、厳密リアルタイムスケジュールが実行される。１実施形態では、漸近評価アルゴリズムを使用して疑似リアルタイムスケジュールが決定され、ここで、多数のプロセッサのスケジュールが組み合わされ、（潜在的には、多数回）負荷平衡化され、それによって厳密リアルタイムスケジュールよりも少ない処理リソースを使用するスケジュールが生成される。

１実施形態は、データのリアルタイム処理を行うためのマルチプロセッサコンピュータ処理システムで行われる方法を含む。この方法は、マルチプロセッサコンピュータ処理システムにおける複数のプロセッサで１組のタスクを行うために厳密リアルタイムスケジュール及び疑似リアルタイムスケジュールを実行するステップと、動作条件の主なセットを評価するステップと、動作条件の主なセットの評価に基づいて厳密リアルタイムスケジュールまたは疑似リアルタイムスケジュールを交代的に選択するステップとを含む。システム中のプロセッサは、その後、選択されたスケジュールに従って１組のタスクを実行する。１実施形態では、動作条件は、出力バッファを占有するエントリ数を含む。出力バッファ中の占有エントリの数が第１のしきい値よりも少ないならば、厳密リアルタイムスケジュールが選択される。出力バッファ中の占有エントリの数が第２のしきい値よりも大きいならば、疑似リアルタイムスケジュールが選択される。１実施形態では、疑似リアルタイムスケジュールは、漸近的評価アルゴリズムを使用して動的に選択される。この実施形態では、１以上の連続的な変更が厳密なリアルタイムスケジュールに対して行われることができる。その変更は、２以上のプロセッサにより行われるタスクのスケジュールの合併または負荷平衡化を含むことができる。各変更の後、変更されたスケジュールが、冗長なまたは冗長でないデータにおけるスケジュールされたタスクの実行を評価することによって、容認可能な疑似リアルタイム性能を有するか否かが決定される。性能が容認可能であるならば、変更されたスケジュールは、疑似リアルタイムスケジュールとして使用されることができる。

別の実施形態は、複数のプロセッサと、その複数のプロセッサに結合されたスケジュール管理装置とを含むシステムを具備する。スケジュール管理装置は、プロセッサによって実行されたデータ処理のリアルタイム進行を決定し、処理のリアルタイム進行に基づいて厳密リアルタイムスケジュールまたは疑似リアルタイムスケジュールのいずれかを選択するように構成される。プロセッサは、その後、選択されたスケジュールに従って１組のデータ処理タスクを実行する。

更に別の実施形態は、前述したように、コンピュータに１つの方法を実行させるように構成される１以上の命令を含むコンピュータで読取り可能な記憶媒体を有するソフトウェアプログラムプロダクトを含む。コンピュータで読取り可能な記憶媒体は、任意の数の記憶媒体、例えばＲＡＭ、ＲＯＭ、フラッシュメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、取外し可能なディスク、ＣＤ−ＲＯＭ、光媒体等を含むことができる。記憶媒体中に含まれている命令は、任意のタイプのデータプロセッサにより実行可能であり、個人用または汎用目的のコンピュータにより実行可能な命令に限定されない。

本発明の種々の実施形態は、保証されたデータのリアルタイム処理のような完全な静的スケジュールの利点に加えて、改良された処理リソースの使用のような完全に動的なスケジュールの利点を提供する。

多数の他の実施形態もまた可能である。本発明のその他の目的及び利点は以下の詳細な説明と、添付図面の参照により明白になるであろう。

本発明は様々な変形及び代替形態を取るが、その特定の実施形態を図面及び付随する詳細な説明によって例示する。しかしながら、図面及び詳細な説明は、本発明を説明した特定の実施形態に限定することを意図するものではないことを理解すべきである。即ち、この説明は、特許請求の範囲により規定される本発明の技術的範囲内に入る全ての変形、等価物、及び他の実施形態をカバーすることを意図する。

本発明の１以上の実施形態を以下に説明する。以下に説明するこれら及び任意の他の実施形態は例示であり、本発明の技術的範囲を限定するものではなく本発明の説明を意図するものであることに注意すべきである。

ここに記載されるように、本発明の種々の実施形態は、厳密リアルタイムスケジュール及び疑似リアルタイムスケジュールを規定し、プロセッサでタスクを実行するために厳密リアルタイムスケジュールと疑似リアルタイムスケジュールとの間で動的に切換えることによって、マルチプロセッサシステムにおけるプロセッサの利用率を増加させるシステム及び方法を含む。１実施形態では、出力バッファを占有するエントリの数が監視される。その数が第１のしきい値に合致するかそれを超えるとき、疑似リアルタイムスケジュールが実行される。その数が第２のしきい値以下であるとき、厳密リアルタイムスケジュールが実行される。１実施形態では、漸近評価アルゴリズムを使用して疑似リアルタイムスケジュールが決定され、ここで、多数のプロセッサに対するスケジュールが合併され、（潜在的には、多数回）負荷平衡化され、それによって厳密リアルタイムスケジュールよりも少ない処理リソースを使用するスケジュールが生成される。

１実施形態は、厳密リアルタイムスケジュール及び疑似リアルタイムスケジュールを規定し、プロセッサでタスクを実行するために厳密リアルタイムスケジュールと疑似リアルタイムスケジュールとの間で動的に切換えることによって、マルチプロセッサシステムにおけるプロセッサの利用率を増加させる方法である。この実施形態では、厳密または疑似リアルタイムスケジュールの選択は、進行ベースである。換言すると、データ処理がリアルタイムよりも高速度で進行するならば、十分なデータが処理され、システムが疑似リアルタイムスケジュールを使用することを可能にする。疑似リアルタイムスケジュールが破断するならば、システムが厳密リアルタイムスケジュールに戻す切換えを行うことを可能にするのに十分な処理されたデータが存在し、それによってデータのリアルタイム処理を行うことが保証される。

１実施形態では、データ処理の進行は、出力バッファを占有するエントリの数を監視することによって決定される。その数が第１のしきい値に合致するかそれを超えるとき、疑似リアルタイムスケジュールが実行される。その数が第２のしきい値以下であるとき、厳密リアルタイムスケジュールが実行される。１実施形態では、漸近評価アルゴリズムを使用して疑似リアルタイムスケジュールが決定され、ここで、多数のプロセッサに対するスケジュールが合併され、（潜在的には、多数回）負荷平衡化され、それによって厳密リアルタイムスケジュールよりも少ない処理リソースを使用するスケジュールが生成される。従って、厳密リアルタイムスケジュールは、静的の状態であるが、疑似リアルタイムスケジュールは、周期的に変更されることができる。

前述したように、マルチプロセッサコンピュータ処理システムにおけるプロセッサでリアルタイムタスクをスケジュールする従来技術の方法は、種々の利点と欠点とを有する。本発明の１以上の実施形態は、静的及び動的の両者のスケジュール態様の利点を提供し、これらの方法の１以上の対応する欠点を除去することを意図する。１実施形態では、利用可能なプロセッサを更に良好に使用する最適化されたスケジュールによって、時々置換されることのできる静的な最悪の場合のスケジュールを使用して、多数のプロセッサにおけるタスクをスケジュールする手段を提供することが望ましい。このスケジュール手段は、自己制御され、比較的容易に実行され、予測可能であり、調整可能であり、プロセッサの利用率に関する改良された効率を有する。

種々の実施形態の詳細を説明する前に、処理タスクと、スケジュールの決定のための基礎として情報が入手可能であることとを説明しておくことが有効である。この説明では、マルチプロセッサシステムにより実行されるリアルタイム処理の１例として、ＡＲＩＢデジタルテレビジョン復号モデルに従ってビデオデータの処理を使用する（ＡＲＩＢは、電波産業会であり、日本の標準方式の組織である）。この特定のタイプの処理は、本発明の実施形態を使用して実行されることのできる多数の異なるタイプのリアルタイム処理の単なる１例にすぎないことに注意すべきである。

図１を参照すると、デジタルテレビジョンデータの処理において実行されなければならない異なるタスクを示す例示的なタスクグラフが示される。この図面では、データは、最初にデジタルテレビジョンのチューナから受信される。処理における第１のタスクは、データのデマルチプレクスである（１１０）。これは、デジタルテレビジョンデータをその異なるコンポーネント部分に分割する。デジタルテレビジョンデータの各コンポーネントは、その後適切に処理されることができる。例えば、符号化されたオーディオデータは、オーディオ復号を受け（１２０）、符号化されたビデオデータは、ビデオ復号を受ける（１３０）等である。ビデオデータの復号後、データは、Ｉ／Ｐスケーリングを受ける（１４０）。最後に、デジタルテレビジョンデータの異なるコンポーネントでアルファブレンディングが行われ、それによってディスプレイを駆動するために適切な出力ビデオデータを生成する。表示されたテレビジョンデータ（イメージ）は、その後、ユーザによって観察されることができる。

タスクグラフは、デジタルテレビジョンデータの処理で実行される必要のある異なるタスク間の制約を説明する。例えば任意のデータが復号されることができる前に、デマルチプレクスされなければならない（１１０）。ビデオデータに関して、データは、アルファブレンドタスクで他のデータコンピュータと組み合わされることができる（１５０）前に、復号され（１３０）、Ｉ／Ｐ調整されなければならない（１４０）。

図１のタスクグラフで明確でない別の制約は、リアルタイム制約である。連続的なテレビジョンイメージをビデオディスプレイへ駆動するため、この連続的なテレビジョンイメージ流を維持するのに十分高い速度でデータを処理することが必要である。例えば、デジタルテレビジョンデータが毎秒６０フレームの速度で与えられ、毎秒６０フレームの速度で表示されることが意図されるならば、タスクは、少なくとも毎秒６０フレームで与えられる速度で行われなければならない（出力データがバッファされるので、データが処理される速度は、瞬間速度でなく平均速度である）。

前述したように、デジタルテレビジョンデータの処理に含まれるタスクを実行する１態様は、各連続的なタスクを次に利用可能なプロセッサへ動的にスケジュールすることである。各プロセッサは、先のタスクを終了したときに次のタスクの実行を開始するので、この動的なスケジュール態様は、プロセッサの利用率を非常に高くすることができる。

この開示の目的に対して、「完全な動的スケジュール化」は、プロセッサにより実行されるタスクが、プロセッサが利用可能になる前にスケジュールされるのでなく、特定のプロセッサで「オンザフライ（on-the-fly）」で実行されるようにスケジュールされることを意味する。

動的スケジュール化方法に対する一般的な代替方法は、前述の静的スケジュール化方法である。ここで説明した本発明の実施形態は、一般的な静的スケジュール化方法で使用されるスケジュールに類似する予め定められたスケジュールに基づくので、静的スケジュール化を以下の文節で詳細に説明する。この説明の目的に対して、以下使用される「完全な静的スケジュール化」は、いずれのプロセッサによっていずれのタスクが実行されるかを決定するために使用されるスケジュールが完全に静的であり、即ち変更されないスケジュール化方法を意味する。これらの完全な静的スケジュール化方法と対照的に、本発明の実施形態は、１つのスケジュールが別のスケジュールに切換えられ、または変更されることを可能にし、それによってプロセッサを更に良好に使用する。

図２を参照すると、特定のアプリケーションによりビデオデータの処理において実行される１組のタスクを示す図が示される。図２は、ビデオデータＡ、Ｂ、Ｃ、Ｄを処理するためにアプリケーション内で規定される４つのタスクを示す。アプリケーションにより受信されるデータは、タスクＡに従って処理され、次にタスクＢ、それからタスクＣに、最後にタスクＤに従って処理される。入力データの所定のピースに対しては、タスクＡ−Ｄはこの特定の順序で行われる。入力データはデータのピース流からなり、夫々この方法で処理されると仮定される。以下の説明の目的に対して、入力データのこれらのピースをデータのフレームと呼ぶ。

この技術用語は、入力データを通常「フレーム」でフォーマットされるタイプ（例えばビデオデータ）に限定するとして解釈するものでなく、特定の組の関連するタスクにより処理されるデータのブロックを参照するのに便宜であるためにここで単に使用することに注意すべきである。

図２は、最悪の場合のシナリオで各タスクを終了するのに必要な処理サイクル数を示す。この例では、タスクＡ−Ｄは、最悪の場合において夫々０．４、０．７、０．９、０．３サイクルを必要とすることが示される。これらの各タスクは、実際には、入力データの特定のフレームの処理で終了するためにより少数のサイクルしか必要としないが、完全な静的スケジュール化方法では、タスクのスケジュールされた実行を変更することができないので、最悪の場合のサイクル数を決定する必要がある。結果として、スケジュールが、特定のタスクに対して、ある数の処理時間サイクル（例えば０．５）だけに適応するが、タスクが時により多くのサイクル（例えば０．６）を必要とするならば、タスクはもはやリアルタイムでは処理されることができない。スケジュールがデータのリアルタイム処理を保証できないならば、最悪の場合のシナリオでは、これは「破断（broken）」する。

図２に示される最悪の場合の数に基づいて、２．３処理サイクルが４つの全てのタスクを終了するために必要とされる。しかしながら、各タスクは、単一のサイクル内で終了されなければならない。それ故、タスクは、順番に終了されなければならないので、またＡ及びＢも、Ｂ及びＣも、Ｃ及びＤも単一のサイクルで結合されることができないので、一見して、４つのサイクルは、これらのタスクを終了するために必要であるように見える。しかしながら、タスクＤは、次のデータフレームで実行されるとき、単一のサイクルでタスクＡと組み合わされ、従って、３つの処理サイクルだけが必要とされる。従って、一連の直列的なサイクルにおいて、次のようなタスク、即ち、Ｂ１；Ｃ１；Ｄ１＋Ａ２；Ｂ２；Ｃ２；Ｄ２＋Ａ３；．．．を行うことができる（ここで添え字は、タスクが行われる入力データのフレームを示す）。

入力情報の１つのフレームの処理は、３サイクルを必要とするが、３サイクル毎に１フレームよりも高いスループットを有することが必要である。高いスループットは、入力データ流を処理するために多数のプロセッサを使用することによって得られる。例えば、単位サイクル毎に１フレームのスループットが所望であるならば、３つのプロセッサが使用されることができる。更に高いスループットが所望であるならば、付加的なプロセッサが入力データ流の処理に割当てられることができる。

多数のプロセッサが入力データ流の処理に使用されるとき、処理タスクは、典型的には、動作並列スケジュール化構造、またはデータ並列スケジュール化構造の２つのうち１つの態様でプロセッサに割当てられる。これらの構造は、図３に示される。図３の上部は、動作並列構造を示し、図３の下部は、データ並列構造を示す。

動作並列構造とデータ並列構造の両者では、（データの第１のフレームに対する）タスクＡと（データの第２のフレームに対する）タスクＤが単一のフレームで単一のプロセッサにより処理され、一方、タスクＢとタスクＣは夫々個別的に処理される。動作並列スケジュール化構造の場合には、データの各フレームで行われる異なるタスク（動作）は、並列（異なる）プロセッサにより行われる。従って、データの単一フレームは、多数のプロセッサにより部分的に処理される。データ並列スケジュール化構造では、データの各フレームで実行される異なるタスク（動作）は、同一のプロセッサにより実行される。結果としてデータの単一フレームは、単一のプロセッサにより完全に処理される。同時にデータのこの第１のフレームは、第１のプロセッサにより処理され、１以上の付加的なフレームは、第１のフレームと並列に異なるプロセッサにより処理される。

図３の例を再度参照すると、入力データの各フレームは、タスクＡ、Ｂ、Ｃ、Ｄからなる処理を受ける。図面で各タスクにより処理される特定のフレームは、タスクの添え字により示される。例えば「Ａ１」は、タスクＡがフレーム１で行われることを示す。図面の矢印は、所定のデータフレームに関して行われる連続したタスクを示す。換言すると、タスクＡｎからタスクＢｎへ、タスクＢｎからタスクＣｎへ、タスクＣｎからタスクＤｎへの矢印が存在する。

図面の上部の動作並列スケジュール化構造では、入力フレーム１でタスクＡがプロセッサ１により実行されることが分かる。タスクＢがその後プロセッサ２により実行される。タスクＢが終了した後、タスクＣがプロセッサ３により実行される。最後にフレーム１のタスクＤがプロセッサ１により実行される。各入力フレームでは、同じタスクは同じプロセッサにより行われる。換言すると、タスクＡ、Ｂ、Ｃ、Ｄはプロセッサ１、２、３、１により夫々実行される。それ故、各プロセッサは１つの入力フレーム毎に同じタスクを行い、任意の１つの入力フレームで全てのタスクを行うプロセッサはない。

図３の下部のデータ並列スケジュール化構造では、入力フレーム１のタスクＡ−Ｄは、全てプロセッサ１により実行されることが分かる。各タスクは連続的なサイクルで実行され、（第１のフレームの）タスクＡは（異なるフレームの）タスクＤと同じサイクル中に実行される。従って、各データフレームは単一のプロセッサにより全て処理される。

これらの動作並列及びデータ並列スケジュール化構造は、両者とも厳密リアルタイム構造である。即ち、両構造は、入力データのリアルタイム処理を確実にする。しかし、動作並列またはデータ並列スケジュール化構造のいずれが使用されるかにかかわりなく、入力データフレームの処理で行われなければならないタスクは、利用可能な処理リソースの一部だけを使用することが認められる。先に指摘したように、最悪の場合には、タスクＡ−Ｄは、夫々０．４、０．７、０．９、０．３の処理サイクルを使用する。従って、３サイクルがタスクのスケジュールに必要とされ、２．３サイクルだけしか実際にタスクの実行に使用されることができない。これはプロセッサの利用可能な容量の約７７％のみの利用率である。より典型的な場合には、この利用率は更に低くなる。例えば、タスクＡ−Ｄが典型的な０．４、０．７、０．２、０．３サイクルだけを夫々使用するならば、プロセッサの利用率は約５３％に過ぎない（１．６／３．）。

典型的な場合のシナリオが図４に示される。この図面の上部は、（図３の上部の動作並列部分に対応する）厳密リアルタイムスケジュールを使用してスケジュールされたタスクを示す。タスクＣは０．９サイクルの代りに０．２サイクルしか必要としないので、プロセッサ３は十分に活用されていない。ここで、２サイクルで４つの全てのこれらのタスクを実行することが可能であることに注意すべきである。例えば、タスクＡとＤは１サイクルで行われ、他方でタスクＢとＣは別のサイクルで行われる。この最適化された２サイクル（２プロセッサ）スケジュールは、図４の下部に示される。

「２サイクル」と「３サイクル」は、データの単一の入力フレームを処理するための２及び３プロセッササイクルの使用を夫々指していることに注意すべきである。これらの２または３プロセッササイクルは、単一のプロセッサまたは多数のプロセッサにより実行されることができる。いずれの場合にも、同一量のデータが２サイクルスケジュールを実行する２つのプロセッサと、３サイクルスケジュールを実行する３つのプロセッサによって処理される。

最適化された２サイクルスケジュールは、明白にプロセッサをより良好に利用するが、通常の静的スケジュール化方法では、スケジュールが変更されることを可能にしない。３サイクルスケジュールまたは２サイクルスケジュールのいずれかが排他的に使用される。前述したように、３サイクルスケジュールは、厳密リアルタイムスケジュールであり、プロセッサを非常に効率的に使用しないが、このスケジュールは、入力データのリアルタイム処理を保証する。２サイクルスケジュールは、典型的な場合には（及び恐らくほとんどの場合）十分であるが、最悪の場合では（タスクＢとＣが共に０．７＋０．９＝１．６サイクルを必要とするので）破断されよう。２サイクルスケジュールは、それ故、疑似リアルタイムスケジュールと呼ばれる。

それ故、本発明の実施形態は、厳密リアルタイム及び疑似リアルタイムスケジュールの組み合せを使用する。これらのスケジュールは、交代的に使用され、それによって典型的な場合のシナリオに遭遇するときに疑似リアルタイムスケジュールの効率が得られるが、最悪の場合のシナリオに遭遇するときには、厳密リアルタイムスケジュールの保証されたリアルタイム処理が行われる。

厳密リアルタイムスケジュールが使用されるべきか、または疑似リアルタイムスケジュールが使用されるべきかについての決定は、入力データの処理中に行われる進行に基づく。１実施形態では、入力データの処理におけるシステムの進行は、出力バッファ中に記憶される処理されたデータの量によって決定される。出力バッファは、ユーザに与えられるためのデータがディスプレイ装置に転送されるまで、一時的に処理されたデータを記憶する。

データは、ディスプレイ装置が必要とする速度と正確に同じ速度で処理されない可能性があるので、出力バッファは、処理されたデータを記憶するために使用される。ディスプレイ装置が使用する速度よりも高い速度でデータが処理されるとき、データは出力バッファ中に累積される。ディスプレイ装置が使用する速度よりも低い速度でデータが処理されるとき、データは出力バッファから除去される。従って、短期間のデータスループットは、長期のスループットがディスプレイ装置に連続する処理されたデータ流を与えるのに十分高いスループットである限り、変化させることができる。

１実施形態では、出力バッファのデータの量が監視され、１以上のしきい値レベルと比較される。出力バッファのデータの量が第１のしきい値よりも高いならば、処理システムは、疑似リアルタイムスケジュールが使用されることを可能にするのに十分な進行を行っている。換言すると、出力バッファ中には十分なデータが存在するので、疑似リアルタイムスケジュールが破断しても（リアルタイムでデータを処理できなくても）、データはある程度の期間の時間だけ中断せずに出力バッファからディスプレイ装置へ供給され続けることができる。これによって処理システムは、疑似リアルタイムスケジュールを使用してより高い速度でデータを処理するか、または厳密リアルタイムスケジュールに切換えることによって回復することができる。これは、データが少なくともディスプレイ装置に与えられる速度程度の速度でデータを処理することを保証する。

図５を参照すると、例示的な実施形態の出力バッファを示す図が示される。図５は、複数のエントリ５２０−５２４を有する出力バッファ５１０を示す。この特定の実施形態では、ｎ個のエントリが存在する。バッファ５１０はＦＩＦＯ（先入れ先出し）バッファであり、データはバッファに記憶された順序と同じ順序でバッファから除去される。図面に示されるバッファエントリは、バッファ中の特定の記憶位置に対応しないで、代りにバッファ中で占有するエントリの数を示すことを意図することに注意すべきである。最下位置のバッファエントリ５２０は、それ故、バッファのヘッドのエントリに対応すると考えられ、一方で最上位置のバッファエントリは、バッファのテールのエントリに対応すると考えられる。

バッファ５１０は、それ故、この説明の目的に対しては、下部から上部まで満たされる（即ち、バッファエントリ５２０で開始し、必要な数だけ連続的なバッファエントリを使用する）。従って、出力データがバッファ５１０の３つのエントリを満たすならば、占有するエントリは、エントリ５２０−５２２である。ｎ−１個のエントリ中にデータが存在するならば、占有するエントリは、エントリ５２０−５２３である（エントリ５２２と５２３の間には、付加的なエントリが存在してもよい）。

図面で示されるように、第１のしきい値５３０と第２のしきい値５４０が存在する。２つのしきい値は、同一レベルに設定されることができるが、この実施形態では、２つのしきい値は、バッファ５１０中の異なるレベル（エントリ数）に対応する。第１のしきい値５３０は、図５では「緊急」しきい値として識別される。バッファ中の占有されたエントリ数が緊急しきい値５３０よりも小さいならば、システムは緊急状態にあると考えられる。これは、単にデータがデータ処理のためのリアルタイム要求を満たすのに十分な速度で処理されることを確実にするためのステップを、システムが取らなければならないことを意味する。換言すると、システムは、バッファからディスプレイ装置へ与えられる出力データ流に中断を生じさせるバッファのアンダーフローが存在しないこと（即ち、バッファ中にデータがないこと）を確実にしなければならない。

第２のしきい値５４０は、図面では、「グリーン」しきい値として識別される。バッファ中で占有するエントリ数がグリーンしきい値５４０よりも大きいならば、システムはグリーン状態にあると考えられる。これは、バッファ中に十分なデータが存在するので、システムは、幾つかの後続するサイクルでデータのリアルタイム処理を確実にする必要がないことを意味する。即ち、新しいエントリがリアルタイムでバッファに記憶されなくても、幾つかのサイクルにおいてリアルタイムで出力バッファからディスプレイ装置へデータを提供し続けるために十分なエントリが出力バッファに存在する。

それ故、しきい値５３０と５４０は、厳密リアルタイム及び疑似リアルタイム処理スケジュールが使用可能及び／または使用されなければならない状態を規定する。特に、システムが緊急状態である（バッファ５１０中のエントリ数が緊急しきい値５３０よりも小さい）ならば、これらのバッファエントリがリアルタイムで置換されない場合、連続的な出力データをディスプレイに提供するのに十分なエントリがバッファに存在しないので、厳密リアルタイムスケジュールを使用しなければならない。他方で、システムがグリーン状態である（バッファ５１０中のエントリ数がグリーンしきい値５４０よりも大きい）ならば、バッファエントリがリアルタイムで置換されなくても、十分なエントリが存在するので、データをバッファからディスプレイ装置へリアルタイムで提供することができる。

これは、勿論、無期限に継続できず、バッファ中のエントリ数が緊急しきい値より下に落ちたならば、システムは緊急状態にあり、バッファのアンダーランがないことを確実にするために厳密リアルタイムスケジュールを使用する必要がある。

別の実施形態において、しきい値は異なる必要はないことに注意すべきである。更に、システムの状態は、出力バッファ中の占有されたエントリの数が夫々のしきい値よりも大きいか小さいか、それに等しいときに変化することができる。

図６を参照すると、グリーン状態及び緊急状態と、これらの状態間の転移を示す状態図が示される。１実施形態では、データがまだ処理されておらず出力バッファ中に記憶されていないので、システムは緊急状態（６１０）で開始する。緊急状態では、システムは、厳密リアルタイムスケジュールに従ってデータを処理する。データが処理されるに従って、エントリがバッファ中に記憶される。データがバッファから除去されてディスプレイ装置に与えられるリアルタイム速度よりも大きい速度でデータが処理されるならば、データがバッファ中に累積され、占有されたエントリの数が増加する。バッファを占有するエントリの数がグリーンしきい値を超えるとき、システムはグリーン状態（６２０）に転移する。

システムがグリーン状態に入るとき、これは、データを処理するために疑似リアルタイムスケジュールを使用し始める。疑似リアルタイムスケジュールは、大部分のデータがリアルタイムで処理されることができるように構成される。実際にデータがリアルタイムで処理される程度まで、バッファ中を占有するエントリのレベルが維持されるか、増加される。しかしながら前述したように、疑似リアルタイムスケジュールは、ある場合には（例えば、最悪の場合）破断する。これが生じるとき、新しいバッファエントリは、古いエントリがバッファから除去されるようには、迅速に記憶されず、バッファを占有するエントリの数は減少する。占有するバッファエントリ数が緊急しきい値よりも下に落ちたならば、システムは緊急状態に戻り、ここで厳密リアルタイムスケジュールがデータを処理するために使用される。

図７を参照すると、１実施形態に従って、システムが厳密リアルタイムと疑似リアルタイム処理スケジュールとの間で切換えられる例示的なシナリオを示す図が示される。この例では、入力データは前述したのと同じ方法で処理される。即ち、タスクＡ−Ｄは、各入力データフレームについて実行され、結果的なデータは、ディスプレイ装置へ転送される前に出力バッファ中に記憶される。

図７から認められるように、入力データは最初にマルチプロセッサシステム中の３つのプロセッサにより処理される。この例では、プロセッサはデータ並列の厳密リアルタイムスケジュールを使用する。それ故、プロセッサ１は、同じサイクル（ｃ０）において入力データの第１のフレームのタスクＡを実行し、入力データの先のフレームのタスクＤを実行する。次のサイクルｃ１で、プロセッサ１は、データの第１のフレームのタスクＢを実行する。サイクルｃ２で、プロセッサ１は、データの第１のフレームのタスクＣを実行する。最後に、サイクルｃ３で、プロセッサ１は、データの第１のフレームのタスクＤ（ならびにデータの後のフレームのタスクＡ）を実行する。プロセッサ２及び３は、入力データの連続的なフレームの同一のタスクを行う。

サイクルｃ３中、出力バッファ中の占有されたエントリの数は、グリーンしきい値よりも大きいことが決定される。従って、システムは、サイクルｃ０−ｃ３中に使用される厳密リアルタイムスケジュールから疑似リアルタイムスケジュールへ切換える。この疑似リアルタイムスケジュールは、タスクＡ−Ｄを行うためにプロセッサのうちの２つだけを使用する。特に、各プロセッサは、単一のサイクルでタスクＡとＢを実行し、単一のサイクルでタスクＣとＤを実行する。タスクＡとＢを実行するのに必要な時間が単一のサイクルに組み合わせるのに十分なほど小さいので、この特定の疑似リアルタイムスケジュールがこの例で存在することに注意すべきである。同じことがタスクＣとＤにも当てはまる。これが当てはまらないならば、異なる疑似リアルタイムスケジュールが実行されよう。

サイクルｃ４で開始して実行される疑似リアルタイムスケジュールは、最初にリアルタイムで入力データを処理するが、個々のタスクを実行するのに必要な時間量は変化でき、それによってスケジュールは、もはやデータのリアルタイム処理を行わない。例えば図７のサイクルｃ７の開始で示されるように、タスクＣを実行するのに必要な処理時間量は増加され、それによってタスクＣとＤは、もはや単一のサイクルで実行されることができない。従って、タスクＣ６はサイクルｃ７でプロセッサ３により実行され、タスクＤ５はサイクルｃ８でプロセッサ３により実行される。これは、データの次のフレームにも当てはまる。疑似リアルタイムスケジュールは、もはやリアルタイムでデータを処理できないので、出力バッファ中の占有されたエントリの数は減少される。

サイクルｃ１０中、出力バッファ中の占有されたエントリの数は、緊急しきい値よりも下に落ち、システムが緊急状態にあることが決定される。結果として、システムは、疑似リアルタイムスケジュールから厳密リアルタイムスケジュールに戻るよう切換えられる。これは、（サイクルｃ０で）最初にシステムにより使用されたのと同じ厳密リアルタイムスケジュールである。従って、プロセッサ１はタスクＡとＤを実行し、一方、プロセッサ２はタスクＢを実行し、プロセッサ３はタスクＣを実行する。厳密リアルタイムスケジュールは、出力バッファが再度グリーンしきい値を超えた占有エントリ数を有するまで使用され続ける。

以上説明したスケジュールは、単なる例示であり、任意の適切な厳密リアルタイムスケジュール及び／または疑似リアルタイムスケジュールが使用されることができることに注意すべきである。図７の特定の例は、厳密リアルタイムスケジュールと疑似リアルタイムスケジュールとの切換えに遅延がないことを示すが、幾つかの実施形態は、スケジュールの切換えで遅延を受ける可能性があることにも注意すべきである。

前述の厳密リアルタイムスケジュールは、リアルタイムタスクの静的スケジュールを行うために通常使用される任意の方法で決定されることができる。１実施形態では、厳密リアルタイムスケジュールは、タスクが行われなければならない順序、処理のリアルタイム要求等、行われるタスクの制約を検査することによって決定される。幾つかの場合には、処理制約を識別するためにタスクグラフの使用が役に立つ。厳密リアルタイムスケジュールは、最悪の場合の処理シナリオに基づいて構成されることができる。

疑似リアルタイムスケジュールは、データのリアルタイム処理のような全ての処理制約が常に満たされることを保証する必要がないので、このスケジュールは、典型的な最悪でない場合のシナリオで利用可能な処理リソースを良好に使用することを選択することができる。特定の疑似リアルタイムスケジュールを選択するために多数の可能なベースと、実際にこのスケジュールを決定するための多数のアルゴリズムが存在する。１実施形態では、漸近的評価方法が疑似リアルタイムスケジュールを決定するために使用される。

この実施形態で使用される漸近的評価方法は、可能な疑似リアルタイムスケジュールの選択と、それらのリアルタイム処理性能に関するスケジュールの評価を含む。特定のスケジュールの性能が十分であると決定されたならば、そのスケジュールは、実際に厳密リアルタイムスケジュールに代わって疑似リアルタイムとして実行されることができる。

１実施形態では、候補の疑似リアルタイムスケジュールは、現在スケジュールされたプロセッサのうち２つのスケジュールを合併させ、結果的に得られたスケジュールを評価し、スケジュールのリアルタイム性能の改良が必要ならばスケジュールを負荷平衡化させることによって選択される。この方法は、図８の例示的なシナリオにおいて示される。

図８を参照すると、容認可能なリアルタイム性能を有する疑似リアルタイムスケジュールを実現するため、厳密リアルタイムスケジュールの変更を示す図が示される。この図面は、３つのスケジュールを示す。図面の上部は、例えば図３に関連して前述した厳密リアルタイムスケジュールである。図８の中間部のスケジュールは、この図の上部の厳密リアルタイムスケジュールに基づいた第１の変更されたスケジュールである。図８の下部のスケジュールは、図面の中間部の第１の変更されたスケジュールに基づいた第２の変更されたスケジュールである。

図８の上部の厳密リアルタイムスケジュールは、３つのプロセッサ（プロセッサ１、プロセッサ２、プロセッサ３）を使用する。典型的な場合のシナリオでは、厳密リアルタイムスケジュールは、（タスクＡとＤを実行する）プロセッサ１を約５０％だけ使用し、（タスクＢを実行する）プロセッサ２を約６０％使用し、（タスクＣを実行する）プロセッサ３を約７０％使用する。

疑似リアルタイムスケジュールの初期の候補は、２つのプロセッサのタスクを組み合わせることにより形成される。図８の例では、プロセッサ１と２のスケジュールされたタスクは、プロセッサ４で組み合わされて実行される。プロセッサ３でスケジュールされるタスクは、プロセッサ５によって実行される。図面で示されるように、各サイクルでスケジュールされたタスクは、サイクルｃ１、ｃ２、ｃ５でスケジュールされるように終了されるが、サイクルｃ３とｃ６ではスケジュールされるように終了されない。（これら及び付加的なサイクルに基づいて）候補スケジュールに対する故障率は３３％であると決定され、この実施形態では、これを容認することができない。

第１の候補スケジュールは、容認できる性能を与えないので、このスケジュールのタスクは、図面の下部に示されるように、新しい候補スケジュールを生成するために負荷平衡化される。この候補スケジュールでは、プロセッサ４は、タスクＡとＢを行い、一方、プロセッサ５は、タスクＣとＤを行う。示されるサイクル（ｃ１−ｃ６）及び付加的なサイクルに基づいて、このスケジュールは、１％のみの時間だけ故障する（スケジュールされたタスクを終了しない）と決定される。この実施形態では、この性能を容認できることが決定される。このスケジュールは、それ故、前述したようにシステムがグリーン状態であるときに実行されることができる。

図８の下部に示される候補スケジュールは、２つのみのステップ（即ち、プロセッサ１と２のスケジュールの合併と、プロセッサ４からプロセッサ５への負荷平衡化）から得られたが、これらのステップに対しては、複数回反復することができる。最適化された候補スケジュールの発生は、また進行中のプロセスであり、それによって主要なデータ及び／または処理状態に適合した疑似リアルタイムスケジュールは、連続的に再評価される。

図８を伴って前述した実施形態では、候補疑似リアルタイムスケジュールは、候補スケジュールを使用して、１対の利用可能なプロセッサで実際にデータを処理することによって評価されることに注意すべきである。データは、冗長（即ちプロセッサ１−３により処理される同じデータ）または非冗長データである。候補スケジュールのリアルタイム性能は、その代わりにタスクＡ−Ｄを行うためにプロセッサ１−３により必要とされる処理リソース量（サイクル数）を決定し、その後、そのタスクを実行するために候補スケジュールにより必要とされるサイクル数を計算することによって評価されることができる。

前述の漸近的スケジュール選択方法は、例示であることにも注意すべきである。多くの他の方法が対応するシステムがグリーン状態であるときに使用する適切な疑似リアルタイムスケジュールを選択するために別の実施形態で使用されることができる。同様に、システムがグリーンまたは緊急（或いは、等化状態）に入る時についてのインジケータとしてバッファしきい値を使用するための前述の方法は、システムにより実行されるデータ処理の進行の測定に使用されることのできる種々の方法の単なる例示である。システムの処理の進行を測定する他の方法が別の実施形態で使用されることができる。

図８と関連して前述した疑似リアルタイムスケジュールは、厳密リアルタイムスケジュールよりも少数のプロセッサを使用するが、これは、必ずしも別の実施形態の場合に必要でないことに更に注意すべきである。これらの実施形態では、厳密リアルタイムスケジュールにより使用されるのと同じ数のプロセッサで疑似リアルタイムスケジュールを実行するが、付加的なタスクをプロセッサで実行することが可能である。

前述の進行ベースのタスクスケジュール態様は、種々の多処理システムトポロジで実行されることができる。図９を参照すると、前述の方法が実行されることのできるマルチプロセッサシステムの例示的な実施形態を示す図が示される。この図面では、マルチプロセッサシステム９００は、他のマルチプロセッサシステムのように、複数の個々のプロセッサ９１１−９１４を含む。各プロセッサ９１２−９１４は、構造オブジェクト９２２−９２４の対応する１つを使用するために構成される。プロセッサ９１１もまた対応する構造オブジェクトを使用する可能性あるが、これは、必ずしもそのようでない。構造オブジェクトは、プロセッサが適切なタスク（例えば前述のタスクＡ−ｄ）を実行することを可能にするプログラミングを行う。

この実施形態では、プロセッサ９１１は、システム９００内で管理機能を行うために使用される主プロセッサである。例えば主プロセッサ９１１は、この実施形態では、スケジュール管理装置を動作させるように構成される。スケジュール管理装置９３０は、前述のスケジュール評価、変更（例えば合併及び負荷平衡化）、置換、ならびにデータ処理の進行の監視、状態制御を行う。スケジュール管理装置９３０は、出力バッファ９４０から受信された進行情報（例えばバッファレベル）と、プロセッサ９１１−９１４からのタスク実行情報（例えばタスクの実行に使用されたサイクル数）と、構造オブジェクト９２２−９２４とに基づいて動作する。

スケジュール管理装置９３０内で、スケジュール評価コンポーネント９３１は、プロセッサ９１１−９１４からのタスク実行情報と構造オブジェクト９２２−９２４とを受信する。スケジュール評価コンポーネント９３１は、スケジュールの性能を示すスケジュール評価情報（例えば、スケジュールが故障するサイクルの割合）をスケジュール選択コンポーネント９３２へ提供する。スケジュール選択コンポーネント９３２は、グリーン状態で使用するための疑似リアルタイムスケジュールを生成するためにスケジュール選択プログラミング９５２を実行する。このスケジュールは、スケジュール置換コンポーネント９３３に与えられ、これは、プロセッサ９１１−９１４と構造オブジェクト９２２−９２４により使用されるスケジュールの置換を実際に行う。スケジュールの置換は、進行ベースの制御手段９３４から受信された入力に基づいており、その進行ベースの制御手段９３４は、出力バッファ９４０中の占有されたエントリの数に基づく。

当業者は、ここで開示した実施形態に関して説明した種々の例示的な論理ブロック、モジュール、回路、アルゴリズムステップが、電子ハードウエア、コンピュータソフトウエア、またはその両者の組合せとして実施されてもよいことを認識するであろう。このハードウエアとソフトウエアとの交換能力を明白に示すため、種々の例示的な構成部品、ブロック、モジュール、回路、ステップをそれらの機能に関して一般的に前述した。このような機能がハードウエアまたはソフトウエアのいずれとして構成されるかは特定の応用と、システム全体に課された設計制約に従う。当業者は、各特定の応用に対して、説明した機能を種々の方法で実行できるが、このような実行の決定は本発明の技術的範囲からの逸脱として解釈されるべきではない。

ここで開示した実施形態に関して説明した種々の例示的な論理ブロック、モジュール、回路は、特定用途用集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、汎用目的のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）または他のロジック、ディスクリートなゲートまたはトランジスタロジック、ディスクリートなハードウエア構成部品、或いはここで説明した機能を実行するように設計された任意のその組合せによって構成または実行されることができる。汎用目的のプロセッサは任意の通常のプロセッサ、コントローラ、マイクロコントローラ、状態マシン等であってもよい。プロセッサはまたコンピュータデバイスの組合せ、例えばＤＳＰとマイクロプロセッサ、複数のマイクロプロセッサ、ＤＳＰコアと連結した１以上のマイクロプロセッサ、或いは任意の他のこのような構造として構成されることもできる。

ここで開示した実施形態に関連して説明した方法のステップは、直接的にハードウエア、プロセッサにより実行されるソフトウエア（プログラム命令）、またはその２つの組み合わせで実施されてもよい。ソフトウエアはＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、取出し可能なディスク、ＣＤ−ＲＯＭ、または技術的に知られるその他の形態の記憶媒体中に存在してもよい。例示的な記憶媒体はプロセッサに結合され、このようなプロセッサは情報を記憶媒体から読み出し、そこに情報を書込むことができる。その代りとして、記憶装置はプロセッサに一体化されることもできる。プロセッサ及び記憶媒体は例えばＡＳＩＣ中に存在してもよい。ＡＳＩＣはユーザ端末に存在してもよい。プロセッサ及び記憶媒体は代わりにユーザ端末またはその他のデバイスでディスクリートな構成部品として存在することもできる。

以上、本発明により与えられる効果及び利点が、特定の実施形態に関して説明された。これらの効果及び利点、ならびにこれらを生じさせる或いはより明白にさせるいかなる要件または限定も、特許請求の範囲に記載された任意または全ての特徴の、決定的、必須、或いは本質的な特徴として解釈されるべきではない。ここで使用されるように、用語「具備する」、「具備している」または任意の他のその変更例は排他的ではなく、これらの用語に付随する要件または限定を含むとして解釈されることを意図する。従って、１組の要件を含むシステム、方法、またはその他の実施形態は、これらの要件だけに限定されることを意図するものではなく、記載されていない或いは請求された実施形態に固有ではないその他の要件を含むことができる。

開示される実施形態の以上の説明は、当業者が本発明を実行または使用可能にするために提供される。これらの実施形態に対する種々の変形は当業者にとって容易に明白であり、ここで規定される一般原理は本発明の技術的範囲を逸脱せずに他の実施形態に適用されることができる。従って、本発明はここで示された実施形態に限定されず、ここで説明され且つ特許請求の範囲で列挙される原理及び新規な特徴と一貫して最も広い範囲に従うことを意図する。

例えば、本発明によれば、下記のような方法、システム、及びソフトウェアプログラムプロダクトを提供することができる。

（１）データのリアルタイム処理を行うための方法であって、
マルチプロセッサコンピュータ処理システムにおける複数のプロセッサで１組のタスクを行うために厳密リアルタイムスケジュールを実行するステップと、
前記複数のプロセッサの１以上のプロセッサで前記１組のタスクを行うために疑似リアルタイムスケジュールを実行するステップと、
動作条件の主要なセットを評価するステップと、
前記動作条件の前記主要なセットの評価に基づいて前記厳密リアルタイムスケジュールまたは前記疑似リアルタイムスケジュールを交代的に選択するステップと、
前記選択されたスケジュールに従って前記複数のプロセッサの１以上のプロセッサで前記１組のタスクを行うステップと、
を具備する。

（２）前記動作条件は、出力バッファを占有するエントリ数を具備する前記（１）に記載の方法。

（３）前記出力バッファ中の前記占有されたエントリの数が第１のしきい値よりも少ないとき、前記厳密リアルタイムスケジュールを選択するステップを更に具備する前記（２）に記載の方法。

（４）前記出力バッファ中の前記占有されたエントリの数が第２のしきい値よりも大きいとき、前記疑似リアルタイムスケジュールを選択するステップを更に具備する前記（２）に記載の方法。

（５）前記疑似リアルタイムスケジュールを動的に選択するステップを更に具備する前記（１）に記載の方法。

（６）前記疑似リアルタイムスケジュールは、漸近的評価アルゴリズムを使用して選択される前記（５）に記載の方法。

（７）前記疑似リアルタイムスケジュールの動的な選択は、前記厳密リアルタイムスケジュールの１以上の連続的な変更を行うステップと、各変更後、前記変更されたスケジュールが許容可能な疑似リアルタイム性能を有するか否かを決定するステップを具備する前記（５）に記載の方法。

（８）前記厳密リアルタイムスケジュールに対する１以上の連続的な変更を行うステップは、２以上のプロセッサにより行われるためタスクのスケジュールを合併させるステップを具備する前記（７）に記載の方法。

（９）厳密リアルタイムスケジュールに対する１以上の連続的な変更を行うステップは、２以上のプロセッサにより行われるタスクのスケジュールを負荷平衡化するステップを更に具備する前記（７）に記載の方法。

（１０）各変更の後における前記変更されたスケジュールが許容可能な疑似リアルタイム性能を有するか否かの決定は、冗長データの処理における前記変更されたスケジュールのリアルタイム性能を評価するステップを具備する前記（７）に記載の方法。

（１１）各変更の後における前記変更されたスケジュールが許容可能な疑似リアルタイム性能を有するか否かの決定は、非冗長データの処理における前記変更されたスケジュールのリアルタイム性能を評価するステップを具備する前記（７）に記載の方法。

（１２）複数のプロセッサと、
前記複数のプロセッサに結合するスケジュール管理装置と、
を具備するシステムであって、
前記スケジュール管理装置は、前記複数のプロセッサによって実行されたデータ処理のリアルタイムの進行を決定し、前記複数のプロセッサによって実行されたデータ処理の前記リアルタイムの進行に基づいて厳密リアルタイムスケジュールまたは疑似リアルタイムスケジュールのいずれかを選択するように構成され、
前記複数のプロセッサは、前記選択されたスケジュールに従って１組のデータ処理タスクを実行するように構成される。

（１３）前記複数のプロセッサにより処理されるデータを一時的に記憶し、前記処理されたデータをリアルタイムで出力装置に提供するように構成される出力バッファを更に具備する前記（１２）に記載のシステム。

（１４）前記スケジュール管理装置は、前記出力バッファ中の占有されたエントリの数を決定することによって前記複数のプロセッサにより行われるデータ処理の前記リアルタイムの進行を決定するように構成される前記（１３）に記載のシステム。

（１５）前記スケジュール管理装置は、前記出力バッファ中の占有されたエントリの数に基づいて、前記厳密リアルタイムスケジュール及び前記疑似リアルタイムスケジュールのいずれかを選択するように構成される前記（１４）に記載のシステム。

（１６）前記スケジュール管理装置は、前記出力バッファ中の占有されたエントリの数が第１のしきい値よりも少ないとき、前記厳密リアルタイムスケジュールを選択するように構成される前記（１５）に記載のシステム。

（１７）前記スケジュール管理装置は、前記出力バッファ中の占有されたエントリの数が第２のしきい値よりも大きいとき、前記疑似リアルタイムスケジュールを選択するように構成される前記（１５）に記載のシステム。

（１８）前記スケジュール管理装置は、静的な厳密リアルタイムスケジュールを使用し、前記疑似リアルタイムスケジュールを動的に決定するように構成される前記（１２）に記載のシステム。

（１９）前記スケジュール管理装置は、前記厳密なリアルタイムスケジュールに対して１以上の連続的な変更を行うことによって前記疑似リアルタイムスケジュールを動的に決定し、各変更後、前記変更されたスケジュールが、許容可能な疑似リアルタイム性能を有するか否かを決定するように構成される前記（１８）に記載のシステム。

（２０）前記厳密リアルタイムスケジュールの前記１以上の連続的な変更は、２以上のプロセッサによって行われるタスクのスケジュールの合併を含む前記（１９）に記載のシステム。

（２１）前記厳密リアルタイムスケジュールの前記１以上の連続的な変更は、２以上のプロセッサによって行われるべきタスクのスケジュールの負荷平衡化を含む前記（１９）に記載のシステム。

（２２）前記スケジュール管理装置は、前記変更されたスケジュールが、冗長データの処理によって許容可能な疑似リアルタイム性能を有するか否かを決定するように構成される前記（１９）に記載のシステム。

（２３）前記スケジュール管理装置は、前記変更されたスケジュールが、非冗長データの処理によって許容可能な疑似リアルタイム性能を有するか否かを決定するように構成される前記（１９）に記載のシステム。

（２４）コンピュータで読取り可能な記憶媒体を具備するソフトウェアプログラムプロダクトであって、
マルチプロセッサコンピュータ処理システムにおける複数のプロセッサで１組のタスクを行うために厳密リアルタイムスケジュールを実行するステップと、
１以上の前記複数のプロセッサで前記１組のタスクを行うために疑似リアルタイムスケジュールを実行するステップと、
動作条件の主要なセットを評価するステップと、
前記動作条件の主要なセットの評価に基づいて前記厳密リアルタイムスケジュールまたは前記疑似リアルタイムスケジュールを交代的に選択するステップと、
前記選択されたスケジュールに従って前記複数のプロセッサの１以上のプロセッサで前記１組のタスクを行うステップと、
を具備する方法をコンピュータに実行させるように構成される１以上の命令を含む。

デジタルテレビジョンデータの処理において実行されなければならない異なるタスクを示す例示的なタスクグラフ。 １実施形態におけるビデオデータの処理において実行される１組のタスクを示す説明図。 １実施形態に従う動作並列及びデータ並列静的スケジュール構造を示す説明図。 １実施形態における最悪の場合及び典型的な場合のシナリオに対する静的スケジュール構造を示す説明図。 １実施形態に従って、グリーン及び緊急状態を規定する出力バッファ及び対応するしきい値の構造を示す構成図。 １実施形態に従うグリーン状態及び緊急状態と、これらの状態間の転移を示す状態図。 １実施形態に従って、システムが厳密リアルタイムと疑似リアルタイム処理スケジュールとの間で切換える例示的なシナリオを示す説明図。 １実施形態に従って、容認可能なリアルタイム性能を有する疑似リアルタイムスケジュールを実現するため、漸近的アルゴリズムを使用する厳密リアルタイムスケジュールの変更を示す説明図。 １実施形態に従うマルチプロセッサシステムの構造を示す構成図。

Claims (5)

1. データのリアルタイム処理を行うための方法であって、
   マルチプロセッサコンピュータ処理システムにおける複数のプロセッサで１組のタスクを行うために厳密リアルタイムスケジュールを実行するステップと、
   前記複数のプロセッサの１以上のプロセッサで前記１組のタスクを行うために疑似リアルタイムスケジュールを実行するステップと、
   動作条件の主要なセットを評価するステップと、
   前記動作条件の前記主要なセットの評価に基づいて前記厳密リアルタイムスケジュールまたは前記疑似リアルタイムスケジュールを交代的に選択するステップと、
   前記選択されたスケジュールに従って前記複数のプロセッサの１以上のプロセッサで前記１組のタスクを行うステップと、
   を具備する。
2. 前記動作条件は、出力バッファを占有するエントリ数を具備し、前記出力バッファ中の前記占有されたエントリの数が第１のしきい値よりも少ないとき、前記厳密リアルタイムスケジュールを選択するステップを更に具備する請求項１に記載の方法。
3. 前記動作条件は、出力バッファを占有するエントリ数を具備し、前記出力バッファ中の前記占有されたエントリの数が第２のしきい値よりも大きいとき、前記疑似リアルタイムスケジュールを選択するステップを更に具備する請求項１または２に記載の方法。
4. 複数のプロセッサと、
   前記複数のプロセッサに結合するスケジュール管理装置と、
   を具備するシステムであって、
   前記スケジュール管理装置は、前記複数のプロセッサによって実行されたデータ処理のリアルタイムの進行を決定し、前記複数のプロセッサによって実行されたデータ処理の前記リアルタイムの進行に基づいて厳密リアルタイムスケジュールまたは疑似リアルタイムスケジュールのいずれかを選択するように構成され、
   前記複数のプロセッサは、前記選択されたスケジュールに従って１組のデータ処理タスクを実行するように構成される。
5. コンピュータで読取り可能な記憶媒体を具備するソフトウェアプログラムプロダクトであって、
   マルチプロセッサコンピュータ処理システムにおける複数のプロセッサで１組のタスクを行うために厳密リアルタイムスケジュールを実行するステップと、
   １以上の前記複数のプロセッサで前記１組のタスクを行うために疑似リアルタイムスケジュールを実行するステップと、
   動作条件の主要なセットを評価するステップと、
   前記動作条件の主要なセットの評価に基づいて前記厳密リアルタイムスケジュールまたは前記疑似リアルタイムスケジュールを交代的に選択するステップと、
   前記選択されたスケジュールに従って前記複数のプロセッサの１以上のプロセッサで前記１組のタスクを行うステップと、
   を具備する方法をコンピュータに実行させるように構成される１以上の命令を含む。

Images