JP2004533667A - 動的スレッドを有するスラック・スチールのための方法および装置 - Google Patents

動的スレッドを有するスラック・スチールのための方法および装置 Download PDF

Info

Publication number
JP2004533667A
JP2004533667A JP2002554867A JP2002554867A JP2004533667A JP 2004533667 A JP2004533667 A JP 2004533667A JP 2002554867 A JP2002554867 A JP 2002554867A JP 2002554867 A JP2002554867 A JP 2002554867A JP 2004533667 A JP2004533667 A JP 2004533667A
Authority
JP
Japan
Prior art keywords
slack
time
tasks
thread
task
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
JP2002554867A
Other languages
English (en)
Inventor
ビンズ，パメラ・エイ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honeywell International Inc
Original Assignee
Honeywell International Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/751,955 external-priority patent/US7140022B2/en
Application filed by Honeywell International Inc filed Critical Honeywell International Inc
Publication of JP2004533667A publication Critical patent/JP2004533667A/ja
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G06F9/4887—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues involving deadlines, e.g. rate based, periodic

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

様々な優先順位レベルを有するリアルタイムの調和的で動的なタスクを実行するマルチタスク・システムにおいて、時間線スラックと再利用されるスラックの両方からスラックがスチールされて、高優先順位の重要ではないタスクの実行がベスト・エフォートで可能になる。消費されたスラック、再利用されたスラック、および消費された周期的計算時間の量のカウントが、個別の優先順位レベルごとに保持され、ある時点で動的に更新される。アイドル時間が、優先順位レベルごとに計算される。利用可能なスラックが計算され、最高速度を最初に、また最低速度を最後にして、スラックが速度ごとに割り振られ、消費される。スラックは、複数の区分でタスクに供与される。すべてのスラックは、スラックの共通のシステム全体のプールに属する。また、時間区分化されたシステムにおいてスラック・スケジューリングを行うコンピュータ・システムおよび様々な方法も説明される。
【選択図】図１

Description

【０００１】
関連発明
本発明は、本発明の譲受人と同一の者に譲渡された以下の発明に関連する。
すなわち、「タスク・スケジューリングおよびメッセージ渡し（Ｔａｓｋ Ｓｃｈｅｄｕｌｉｎｇ ａｎｄ Ｍｅｓｓａｇｅ Ｐａｓｓｉｎｇ）」という名称のシリアル番号０９／３１２５９２、および
「周期変換プロセスの改良応答時間に対するスラック・スケジューリング（Ｓｌａｃｋ Ｓｃｈｅｄｕｌｉｎｇ ｆｏｒ Ｉｍｐｒｏｖｅｄ Ｒｅｓｐｏｎｓｅ Ｔｉｍｅｓ ｏｆ Ｐｅｒｉｏｄ Ｔｒａｎｓｆｏｒｍｅｄ Ｐｒｏｃｅｓｓｅｓ）」という名称のシリアル番号０８／９１４９２４。
【０００２】
また、本発明は、本発明の譲受人と同一の者に譲渡され、本出願と同日に出願された以下の発明にも関する。
すなわち、「時間区分システムにおけるスラックを共有する方法および装置（Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｓｈａｒｉｎｇ Ｓｌａｃｋ ｉｎ ａ Ｔｉｍｅ−Ｐａｒｔｉｔｉｏｎｅｄ Ｓｙｓｔｅｍ）」という名称のシリアル番号に関する。
【０００３】
著作権の警告／許可
本特許出願の開示の一部分は、著作権保護の対象となる題材を含む。本著作権所有者は、米国特許商標庁のファイルまたは記録で見られる本特許開示の何人による複製にも異議を有さないが、それ以外、あらゆる無断転載を禁ず。以下の告知は、以下に、また添付の図面で記載するソフトウェアおよびデータに該当する。Ｃｏｐｙｒｉｇｈｔ（ｃ）１９９９、Ｈｏｎｅｙｗｅｌｌ，Ｉｎｃ．全権利は留保されている。
【０００４】
技術分野
本発明は、一般にマルチタスク・システム内のタスク・スケジューリングに関し、詳細には、利用可能なスラックを決定し、高優先順位のクリティカルでない動的なタスクまたはスレッドにスラックを割り振ることに関する。
【０００５】
背景
コンピュータ・プロセスは、しばしば、シリアル式かつ／またはパラレル式にタスクとして実行することが可能な様々な機能に細分される。このようなコンピュータ・プロセスを使用して情報を収集し、情報に従って動作し、その情報に応答して何らかの結果を生じさせることができる。このような機能タスクシステムには、様々な重要な環境において用途がある。例としては、発電−配電のシステムなどの産業プロセスの監視および制御、または航空機または宇宙船などの複雑な設備の監視および制御が含まれる可能性がある。
【０００６】
以上に述べたようなリアルタイム・システムでは、タスクの実行は、周期的タスクと非周期的タスクをともに含むことが可能である。周期的タスクを実行する１つの周知のやり方は、速度単調スケジューリング（ＲＭＳ）を使用することである。従来のＲＭＳ定式化は、厳密に周期的なタスク・セットのためのものである。周期的タスク・セットを指定するため、ｎ個のタスクのそれぞれ、たとえば、１≦ｉ≦ｎであるτｉが、周期Ｔｉおよび最悪ケースの計算時間Ｃｉに関連している。各タスクτｉは、速度１／Ｔｉでディスパッチされて実行され、また最悪ケースでは、各ディスパッチでＣｉに等しいプロセッサ時間を消費する。各タスクには、タスクの速度（または、等価であるが、タスクの周期の逆数）によって決定された優先順位が暗黙的に割り当てられ、優先順位は、速度のランキングに等しい。
【０００７】
ＲＭＳスケジューラが、ハードな期限を有する周期的タスクをスケジュール設定する。存立可能なリアルタイム・システムは、ハードな期限またはソフトな期限を有するのが可能な非周期的タスクも実行することができなければならない。タスク・スケジューリング・システムが、すべての周期的タスク期限が満たされ、非周期的タスクに関する応答時間が可能な限り短くなるような仕方で周期的タスクと非周期的タスクの入り混じったものをスケジュール設定することが望ましい。
【０００８】
Ｊｏｈｎ Ｐ．ＬｅｈｏｃｚｋｙおよびＳａｎｄｒａ Ｒａｍｏｓ−Ｔｈｕｅｌによる「固定割込み優先システムにおけるソフト非周期的タスクに対する最適アルゴリズム（Ａｎ Ｏｐｔｉｍａｌ Ａｌｇｏｒｉｔｈｍ ｆｏｒ Ｓｃｈｅｄｕｌｉｎｇ Ｓｏｆｔ−Ａｐｅｒｉｏｄｉｃ Ｔａｓｋｓ ｉｎ Ｆｉｘｅｄ−Ｐｒｉｏｒｉｔｙ Ｐｒｅｅｍｐｔｉｖｅ Ｓｙｓｔｅｍｓ）」、リアルタイム・システム・シンポジューム、ＩＥＥＥ会報、１９９２年１２月で、スラック・スチール・アルゴリズムが説明されている。このアルゴリズムは、サービスを促されたとき、周期的タスクから、タスクの期限を逸することを生じさせずに「スチール」することができるすべての処理時間を「スチール」することにより、非周期的タスクにサービスを提供するための時間を作ろうと試みる。これは、周期的タスクから「スラックをスチールする」ことと等価である。スラック・スチール・アルゴリズムは、非周期的タスクに関して応答時間の相当な改善を提供することが示されている。さらに、スラック・スチール・アルゴリズムは、周期的タスクが、最悪ケースの実行時間より少ない時間を必要としたとき、周期的タスクによって未使用のあらゆる処理時間を非周期的サービスに供与する再利用アルゴリズムと連携することにより、さらに改良されることが説明されている。
【０００９】
前述したスラック・スチール・アルゴリズムは、静的なセットの実行スレッドだけに、すなわち、新しい周期的タスクがまったくアクティブにされることのない、また周期的タスクがまったく非アクティブにされることのない固定されたセットの繰り返されるタスクだけに限定されている。しかし、実際のリアルタイム処理環境は、通常、ある周期的タスクがアクティブになり、他の周期的タスクが非アクティブになるので、動的セットのスレッドを含む。
【００１０】
したがって、周期的で動的なタスクを包含するリアルタイム環境においてスラック・スチールを提供することができるタスク・スケジューラの必要性が、当技術分野で存在する。
【００１１】
概要
本発明は、スレッドが動的である環境において、セットの周期的タスクおよび非周期的タスクに関するタスク・スケジューリングを扱う。
【００１２】
一実施形態では、本発明は、任意の時点で活動化または非活動化を要求することができるリアルタイムの調和的で動的なタスク（タスクの実際の活動化または非活動化は、タスクの次の周期境界で行われる）を実行するマルチタスク・システムを提供する。さらに、本発明は、タスクに優先順位レベルを割り当てること、およびアクティブになるタスクおよび非アクティブになるタスクを考慮に入れて、各優先順位レベルでタスクに関する利用可能なスラックを決定することを含むタスクをスケジュール設定する方法を提供する。この方法は、優先順位に従ってタスクにスラックを割り振ることをさらに含む。
【００１３】
別の実施形態では、本発明は、プロセッサ、およびそのプロセッサ上で実行される複数のタスクを含むマルチタスク・システムを提供する。この複数のタスクの各タスクは、周期的タスクおよび非周期的タスクからなるグループから選択されたタスク・タイプのものである。この複数のタスクの各タスクには、少なくとも１つの最悪ケースの実行時間が関連している。システムは、プロセッサと通信し、プロセッサ上のタスクのディスパッチを制御するエグゼクティブをさらに含む。エグゼクティブは、予測不可能な時点でアクティブになる周期的タスクおよび非アクティブになる周期的タスクを考慮に入れて利用可能なスラックを決定する第１のモジュールを含み、またエグゼクティブは、非周期的タスクに利用可能なスラックを割り振る第２のモジュールをさらに含む。一実施形態では、マルチタスク・システムは、航空管制システムである。
【００１４】
さらに別の実施形態では、本発明は、プロセッサに方法を実行させることができる命令を記憶しているマシン可読媒体を提供する。この方法は、タスクに優先順位レベルを割り当てること、アクティブになるタスクおよび非アクティブになるタスクを考慮に入れて、各優先順位レベルでタスクに関する利用可能なスラックを決定すること、および優先順位に従ってタスクにスラックを割り振ることを含む。
【００１５】
本発明は、特に頭記の特許請求の範囲において指摘する。ただし、添付の図面と併せて以下の詳細な説明を参照することにより、本発明の他の特徴がより明白となり、本発明がよく理解される。
【００１６】
実施形態の説明
本発明の実施形態の以下の詳細な説明では、この説明の一部を成し、例として、本発明を実施することができる特定の実施形態が示されている添付の図面を参照する。これらの実施形態は、当分野の技術者が本発明を実施できるようにするのに十分なだけの詳細で説明しており、本発明の趣旨および範囲を逸脱することなく、その他の実施形態を利用することができ、論理的変更、機械的変更、および電気的変更を行うのが可能であることを理解されたい。したがって、以下の詳細な説明は、限定する意味で受け取られるべきものではなく、本発明の範囲は、頭記の特許請求の範囲だけによって定義される。
【００１７】
「実施形態の説明」は、６つの主なセクションに分かれており、セクションの一部は、いくつかのサブセクションを含む。
セクション１で、本発明の実施形態を実施することができる例としての操作環境を説明する。
【００１８】
セクション２で、スラック・スケジューリングの背景を本発明を理解するための基礎として提供する。
セクション３で、デジタルエンジニアリング・オペレーティングシステム（ＤＥＯＳ）におけるタスク・スケジューリングを説明する。本発明は、どの特定の実施形態にも限定されないが、本発明を理解する際、一実施形態を相当に徹底的に説明することが役立つ。
【００１９】
セクション４で、動的スレッドを有するＤＥＯＳにおけるスラック・スケジューリングを説明する。
セクション５で、本発明の例としての実施形態の方法、およびマシン可読媒体を提供する。
最後に、セクション６で、詳細な説明の結論を提供する。
【００２０】
セクション１−例としての操作環境
図１は、本発明の実施形態に従って使用するための航空管制システム１を示す概略図である。航空管制コンピュータ３が、何らかの周期速度でタスクを実行する。航空管制コンピュータ３は、センサ２からセンサ・データ６を受け取り、センサ・データ６、ならびにオプションとして、前のディスパッチで計算された状態データ５を入力として計算を行い、アクチュエータ４に出力７を生成する。
【００２１】
航空管制システムのコンテキストで開示するが、本発明は、産業用制御システム、車両制御システム、通信プロセッサ、リアルタイム制御システム、汎用データ処理システムなどの多くのタイプのデータ処理システム、ならびに機能要件が本発明によって満たされるその他のタイプのデータ処理システムで使用することができる。
【００２２】
航空管制コンピュータ３が、マルチスレッド・オペレーティング・システムの上でアプリケーションを実行する。一実施形態では、オペレーティング・システムは、米国、ミネソタ州、ミネアポリスのＨｏｎｅｙｗｅｌｌ，Ｉｎｃ．によって開発されたデジタルエンジニアリング・オペレーティングシステム（ＤＥＯＳ）である。ただし、本発明は、その他のオペレーティング・システム・プラットフォーム上でも実施することができ、ＤＥＯＳには限定されない。当分野の技術者によって理解されるとおり、マルチスレッド・オペレーティング・システムは、複数のコンピュータ・プログラムが、互いに干渉することなく同時に実行されるのを可能にする「交通警官」として機能する。
【００２３】
本発明の一実施形態では、ＤＥＯＳは、周期的タスクおよび非周期的タスクの固定プリエンプティブ優先順位スケジューリングを提供する。周期的タスクの場合、優先順位は、周期または期限と逆に割り当てられ、より短い周期または期限を有するタスクが、より高いスケジューリング優先順位を有するようになる。また、非周期的タスクにも、スラック要求レベルを決定する速度または周期が割り当てられるが、非周期的タスクの優先順位は、非周期的タスクが実際に実行されているときには動的である。
【００２４】
本発明では、セットの調和的で動的なタスクまたはスレッドに関してスラック・スケジューリングが提供される。「調和的」タスク・セットとは、各タスクの周期Ｔｉが、ｉ＝１．．．ｎ−１であるＴｉ＋１を均等に分割するタスク・セットとして定義される。調和的タスク・セットは、周期が静的である複数のタスクまたはスレッドを含む。「静的」タスク・セットは、始動時にスケジュール設定されるタスクを含み、コンピュータがシャットダウンされるまでの時間にわたって存続するタスク・セットとして定義される。
【００２５】
「動的」タスクまたは「動的」スレッドは、予測不可能な形で開始または終了することが可能であり、始動時にスケジュール設定されないタスクとして定義される。実行されると、動的タスクは、周期的で予測可能であることが可能であり、また静的タスクと同様の仕方でスケジュール設定することができる。動的スレッドは、次の周期境界でアクティブまたは非アクティブにすることができる周期的タスクを含む。また、動的スレッドは、非周期的タスクも含む。また、動的スレッドは、スラックを動的に（すなわち、任意の時点で）要求するスラック・コンシューマも含むことが可能である。
【００２６】
一実施形態では、スラック・スチールが、様々な優先順位レベルを有するリアルタイムの調和的で動的なタスクを実行するマルチタスク・システムにおいて提供される。時間線スラックと再利用されるスラックの両方からスラックがスチールされて、高優先順位の重要でないタスクの実行が、ベスト・エフォートで可能になる。スチールに利用可能なスラックは、時間線スラックに再利用されるスラックを足して、アイドル時間を引いたものに等しい。消費されるスラック、再利用されるスラック、および消費される周期的計算時間の量のカウントが、個別の優先順位レベルごとに保持されて、ある時点で動的に更新される。アイドル時間が、優先順位レベルごとに計算される。利用可能なスラックが計算され、最高速度を最初に、また最低速度を最後にして、スラックが速度ごとに割り振られ、消費される。
【００２７】
図２は、本発明の実施形態によるマルチタスク・システム１０を示すブロック図である。マルチタスク・システム１０は、少なくとも１つのプロセッサ１１、および少なくとも１つのメモリ１２を含む。メモリ１２は、ランダム・アクセス・メモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、キャッシュ・メモリ、ハードディスク、ディスケット、フラッシュ・メモリ・カード、光コンパクト・ディスク（ＣＤ）などの取外し可能なメモリ等を含むことが可能な任意の１つまたは複数のメモリ・ユニットとして実装することができる。特定のアーキテクチャ上の実施形態は、限定されず、システムの要件に従って設計することができる。したがって、キャッシュ・メモリおよび／またはＲＡＭなどのメモリ１２のいくつかの部分は、プロセッサ１１内部に存在することが可能である。
【００２８】
メモリ１２は、タスク１４〜１６がスケジュール設定可能なアプリケーション・タスクである複数のタスク１４〜１７を含む。エグゼクティブ・タスク１７は、アプリケーション・タスク１４〜１７のスケジュール設定を含め、いくつかの監督タスクを行うことを担う。各アプリケーション・タスク１４〜１７は、周期的タスクに関する何らかの固定速度で、または、非周期的タスクに関する何らかのイベント、たとえば、ソフトウェアによって生成された割込み、またはその他のイベントに応答して繰り返しディスパッチされる。
【００２９】
セクション２−スラック・スケジューリングの背景
２．１ 従来の速度単調スケジューリング
先に述べたとおり、従来の速度単調スケジューリング（ＲＭＳ）は、厳密に周期的なタスクのセットのためのものである。周期的タスク・セットを指定するため、ｎ個のタスクのそれぞれ、たとえば、１≦ｉ≦ｎであるτｉに、周期Ｔｉおよび最悪ケースの計算時間Ｃｉが関連している。各タスクτｉは、速度１／Ｔｉでディスパッチされて実行され、また最悪ケースでは、各ディスパッチでＣｉに等しいプロセッサ時間を消費する。
【００３０】
タスクτｉの各ディスパッチと関連する期限の間で、タスクは、プロセッサからある量の計算時間を受け取って、ある量の作業を行わなければならない。ただし、プロセッサも、ディスパッチと完了の間でその他のタスクに対して作業を行って何らかの時間を費やす可能性があり、この間隔中、タスクが、その他のタスクによって先制されるという言い方をする。留意すべき重要なことは、タスク・ディスパッチ、すなわち、タスクが、優先順位付けされた作動可能待ち行列に入れられる時点、および期限、すなわち、タスクの完了に関するシステムによって定義された何らかの期限またはその他の制約は、周期的タスクに関する決定論的な時点で生じることである。ただし、タスク開始時、すなわち、タスクの計算が開始するとき、および完了時、すなわち、タスクの計算が完了するときは、スケジューリング要件および計算時間要件に依存して異なる可能性がある。
【００３１】
タスクは、４つの主なパラメータを使用して特徴付けられる。タスクのクラスは、周期的である、すなわち、ディスパッチのために定期的にスケジュール設定されるか、非周期的である、すなわち、何らかのスケジュール設定されていないイベントに応答してディスパッチされるかである。タスクの周期Ｔｉは、周期的タスクのディスパッチ間の間隔、または非周期的タスクに関するイベント出現間の最小間隔である。タスクの計算時間Ｃｉは、タスクのインスタンスが各ディスパッチ後に完了するのに必要とされるプロセッサ時間の量の上限である。実際には、実際の計算時間がこの値を超えないことの確実性の度合いは、タスクによって異なる。
【００３２】
一実施形態では、タスクのクリティカリティ（限界）は、プロセッサが過負荷になったとき、すなわち、タスクの一部のサブセットが、スケジュール設定不可能である場合にスケジューリングの挙動を制御するのに使用される整数値である。そのような数値ランキング・システムが、実施するのに好都合であるが、その他のランキング・システムも利用することができる。タスクのスケジュール設定の可能性は、自己のクリティカリティに等しいか、それを上回るクリティカリティを有する同一のプロセッサ上のタスクによってだけ影響される。より低いクリティカリティのタスクは、より高いクリティカリティのタスクが期限を逸することを生じさせずに、明言された計算時間を超えることが可能であるか、または、非周期的タスクの場合、明言された周期より高い速度でディスパッチされることが可能である。
【００３３】
図３は、従来技術における３つのタスクτ１、τ２、およびτ３の従来の速度単調スケジューリングを示すタスク実行時間線である。タスクτ１、τ２、およびτ３はそれぞれ、周期Ｔ１＝５ミリ秒、Ｔ２＝１０ミリ秒、およびＴ３＝３０ミリ秒を有する。また、タスクτ１、τ２、およびτ３はそれぞれ、対応する最悪ケースの実行時間Ｃ１＝１、Ｃ２＝２、およびＣ３＝８も有する。「ハイパー周期」、つまり周期Ｔ１、Ｔ２、およびＴ３の最小公倍数は、この例では、３０である。
【００３４】
各タスクには、タスクの速度（または、等価であるが、タスクの周期の逆数）によって決定された優先順位が暗黙的に割り当てられ、優先順位は、速度のランキングに等しい。周期Ｔ１＝５、Ｔ２＝１０、およびＴ３＝３０を有する３つのタスクの図３に示した例では、１の優先順位が、τ１に暗黙的に割り当てられ、優先順位２がτ２に、また優先順位３がτ３に割り当てられる。速度単調スケジューラは、単に作動可能待ち行列の中で最高優先順位を有するタスクにサービスを提供する固定優先順位プリエンプティブ・スケジューラである。
【００３５】
多くのスケジューリング・アルゴリズムとは異なり、ＲＭＳは、スケジュールが実施可能であるかどうかを検査するのに使用することができる付随する分析も有する。この分析は、極めて単純に、以下の式で与えられる厳密なスケジュール設定可能性基準として知られるものによって特徴付けられる。
【００３６】
【数１】
Figure 2004533667
【００３７】
ただし、Ｓｉ＝｛ｋ・Ｔｊ｜ｊ＝１、…、ｉ；ｋ＝１、…、「Ｔｉ／Ｔｊ」｝、ｉを上回らない優先順位を有するタスクに関するスケジューリング・ポイントのセット
数式１を解釈するため、その概念を説明する例を考慮する。数式１は、調和的でないタスク・セットにも、調和的なタスク・セットにも該当することに留意されたい。この例を説明するため、付録Ａの添付のテーブルで定義したいくらかの表記を使用する。テーブル（付録Ａ）を参照してから、この例に戻るのが有用である可能性がある。
【００３８】
時間線実行が図３で示されるタスク・セットが、テーブル１（付録Ａ）で定義されている。
Ｓ１は、スケジューリングの実施可能性を決定するのに、その先を考慮する必要がないτ１に関するすべてのスケジューリング・ポイントのセットである。ｉ＝１の場合、ｋの範囲は１であり、Ｓ１＝｛６｝である。というのは、τ１の周期は、６タイム・ユニットだからである。ｉ＝２の場合、τ１およびτ２に関して検査する必要があるスケジューリング・ポイントを考慮する。計算は、Ｓ２＝｛６，７｝およびＳ３＝｛６，７，１２，１４，１８，２１｝を与える。
【００３９】
レベルｉの作業が、ｉに等しいか、それを上回る優先順位を有するタスクによって要求された作業の量である場合、Ｗｉ（ｔ）を間隔［０，ｔ］においてディスパッチされたレベルｉの作業の量であるとすると、
【００４０】
【数２】
Figure 2004533667
【００４１】
時刻ｔ＝０で、３つすべてのタスクがディスパッチされ、したがって、Ｗ３（ｔ）＝Ｃ１＋Ｃ２＋Ｃ３＝４である。Ｗ３（ｔ）は、［０，Ｔ１）で定数である。というのは、その時点まで、システムにおいて新しい出現が存在しないからである。
以下の試験
【００４２】
【数３】
Figure 2004533667
【００４３】
が、τｉの各ディスパッチが、期限に間に合うかどうかを答える。言い換えれば、Ｓｉの中で、Ｗｉ（ｔ）≦ｔを満たすｔが存在する場合には、τｉのすべてのディスパッチが、期限までに完了する。したがって、Ｗ１（Ｔ１）≦Ｔ１である場合、τ１は、スケジュール設定可能であり、Ｗ１（Ｔ１）≦Ｔ１は、Ｗ１（６）＝１≦６であるため成立している。
【００４４】
τ２は、Ｗ２（Ｔ２）≦Ｔ２またはＷ２（７）＝２Ｃ１＋Ｃ２＝３≦７である場合、スケジュール設定可能である。したがって、τ２のすべてのディスパッチが、期限に間に合う。Ｓ３は、その中に６つの時刻を有している。任意のｔ∈Ｓ３が、Ｗ３（ｔ）≦ｔを満たす場合には、τ３も期限に間に合う。ｔ＝２１が、Ｗ３（２１）＝４Ｃ１＋３Ｃ２＋Ｃ３＝９≦２１を満たすのを検査するのは容易である。やはりＷ３（ｔ）≦ｔを満たすその他のポイントも、τ３の中に存在する可能性がある。
【００４５】
ｉ＝１．．．ｎに関して、ｈｉ＝ｍａｘｔ∈Ｓｉ Ｗｉ（ｔ）／ｔとする。すべてのタスク優先順位にわたってｈｉの最大値を取ることにより、数式１が与えられ、数式１は、タスク・セット全体が実施可能であるかどうかを決定する。例に戻ると、ｈ１＝１／６、ｈ２＝３／７、およびｈ３≦９／２１である。したがって、例における数式１は、ｍｉｎ（ｈ１，ｈ２，ｈ３）≦ｍｉｎ（１／６，３／７，９／２１）≦１であるかどうかを問い、これは、成立している。タスク・セットが調和的である場合、つまり、ｉ＝１．．．ｎ−１に関して、Ｔｉが、Ｔｉ＋１を均等に分割する場合、数式１は、目立って簡単になり、これにより迅速なオンライン承認試験が可能になる。
【００４６】
過去１０年間に現実のシステムにおいてＲＭＳを実際的にする多数の拡張が開発されてきた。これらの拡張の中には、タスク間通信、およびタスクのクリティカリティの指定（周期によって定義された暗黙の速度構造を無視することが可能な）を可能にするものがある。タスク間通信の最悪ケース限度が、厳密に周期的なタスクのセットのために開発されている。ただし、周期的タスクと非周期的タスクが入り混じったセットに関して通信およびエグゼクティブ実行時間を有効にモデル化することは、まだ一般的ケースにおける研究の領域にとどまっている。
【００４７】
参考のため、速度単調スケジューリングのために使用される周期的タスク・セットを記述するのに使用される表記をテーブル２で要約している（従来のＲＭＳにおける周期的スレッド仕様）（付録Ａ）。「タスク」という用語は、ＤＥＯＳにおけるある速度のすべてのスレッドのセットと考えることができ、このセットを集合スレッドと呼ぶ。集合スレッドの概念は、「動的スレッドを有するＤＥＯＳにおけるスラック・スケジューリング」と題したセクション４でより正確に定義する。
【００４８】
２．２ 古典スラック・スケジューリング
古典スラック・スケジューリングは、固定セットの周期的タスクを想定している。このセットのタスクを使用して、時間線に固有のスラックを記述するスラック・テーブルが統計的に計算され、ランタイムに使用するために記憶される。ランタイムで、セットの累算器が、周期的プロセスによって実際に消費された時間の量（また、周期的プロセスから再利用されたスラックの量も）、ならびに非周期的タスクによって消費された時間の量（アイドル・タスクを特別な非周期的タスクと考えることができる場合）を記録にとる。次に、これらの値を事前計算されたスラックの適切な量に加算／減算して、実際に何が起きたかを反映させる。以下のセクションは、以上の動作をより正確に定義する。
【００４９】
古典スラック・スケジューリングの開発のために使用される表記をテーブル３で要約しており（古典ＲＭＳのコンテキストにおけるスラック・スケジューリング仕様）（付録Ａ）、以下のセクションでそれを参照する。
【００５０】
２．２．１ 時間線スラックおよびオフライン計算
図４は、要求されない利用可能な／未使用のスラックを示すタスク実行時間線である。プロセスが、Ｃに等しい最悪ケースの実行時間を有する。ｔ＝０で、プロセスが実行を開始して、Ｃ（ｔ）の実行時間を消費する。ｔ１とｔ２の間で、プロセスが、実行を停止する。プロセスは、ｔ２で実行を再開し、ｔ＝Ｔで実行を停止して、Ｃ−Ｃ（ｔ）の実行時間を消費する。時間線スラックは、周期Ｔから最悪ケースの実行時間Ｃを引いたものに等しい。この例では、０の時間線スラックが再利用され、プロセスは、０時間、アイドルであった。
【００５１】
図５は、時間線スラック、再利用されるスラック、およびアイドル時間を示すタスク実行時間線である。プロセスは、Ｃに等しい最悪ケースの実行時間を有する。ｔ＝０で、プロセスが実行を開始して、ｔ１で実行を停止するまでにＣ（ｆ）の実行時間を消費する。プロセスは、この周期Ｔ中、再開されないものと想定する。ｔ１とｔ２の間の時間は、プロセッサのアイドル時間を表す。時間線スラックは、周期Ｔから最悪ケースの実行時間Ｃ（ｔ３における）を引いたものに等しい。再利用されるスラックは、プロセスが、最悪ケースの実行時間Ｃより前に実行を停止したことにより再利用することができるスラックの量である。この例では、再利用されるスラックは、Ｃ−Ｃ（ｆ）（すなわち、ｔ３−ｔ１）に等しい。
【００５２】
図６は、４つの異なるスラック・レベルで非周期的タスクによるスラック消費の連続的要求が存在する場合の周期的実行時間を示すタスク実行時間線である。図６は、４つの異なるスラック・レベルで利用可能なスラックを示しており、レベル１が一番上に、またレベル４が一番下にある。図６では、周期Ｔ１＝６、Ｔ２＝７、およびＴ３＝２１、ならびに最悪の計算時間周期Ｃ１＝１、Ｃ２＝１、およびＣ３＝２をそれぞれ有する３つの周期的タスクτ１、τ２、およびτ３が存在する。ハイパー周期は、４２である。周期的タスク・セットのプロパティは、前述したテーブル１（周期的タスク・セット）で要約している。レベルｉで割り振られるスラックは、τｉ、τｉ＋１．．．τｎのディスパッチの実行が可能な限り長く遅延されて、スラックを要求するタスクが実行されるのを可能にすることを意味する。レベルｎ＋１におけるスラックは、背景処理と等価である。
【００５３】
非常に簡単に述べると、時間線スラックの計算は、以下のとおりである。各間隔［０，Ｄｉ，ｊ］＝ｊ・Ｔｉに関して、レベルｉ−１のスラックの量、Ｌｉ，ｊが計算される。［０，Ｄｉ，ｊ］におけるレベルｉのスラックの量は、ＴｉｍｅＬｉｎｅＳｌａｃｋｉ，ｊで表されるＬｉ，ｊ−ｊＣｉである。ＴｉｍｅＬｉｎｅＳｌａｃｋｉ，ｊの値は、オフラインで計算され、ランタイム・エグゼクティブの一部分としてロードされるマトリックスの中に記憶される。テーブル１で記載するベースライン計算時間値を有する周期的タスク・セットに関して、時間線スラックの例に関する（ＴｉｍｅＬｉｎｅＳｌａｃｋｉ，ｊ）マトリックスをテーブル４（ＴｉｍｅＬｉｎｅＳｌａｃｋｉ，ｊ）（付録Ａ）で示している。（ＴｉｍｅＬｉｎｅＳｌａｃｋｉ，ｊ）マトリックスは、累積スラック・マトリックスとも呼ばれる。
【００５４】
ＤＥＯＳなどの、タスクの動的な活動化および非活動化をサポートするシステムの場合、スラック・テーブルは、静的ではなく、タスク活動化の時点、およびタスク非活動化の時点で効率的に再計算されなければならない。レベルｉにおけるタスクの活動化／非活動化の場合、ｋ＝ｉ．．．ｎに関して、Ｌｋの値、ｍｋが減少／増加され、現行のハイパー周期内でｍｋ＝γｋ＋１．．．Ｈ／Ｔｋであり、またすべての後続のハイパー周期に関してｍｋ＝１．．．Ｈ／Ｔｋである（タスク・セットが固定されたままであると想定すると）。スラック・テーブルを再計算している間に被る支出が存在し、このことは、スラック・スケジューリングをより詳細に説明している「動的スレッドを有するＤＥＯＳにおけるスラック・スケジューリング」と題したセクションで考察している。
【００５５】
時間線スラックは、「保証された」ハードな期限を有するタスクからスチールして、高優先順位の重要ではないタスクに供与することができる。時間線スラックをスチールする際、ハードな期限のタスクの実行は、タスクが期限を逸することを生じさせずに可能な限り長く遅延される。遅延されている可能性があっても、より高い優先順位のハードな期限のタスクは、より低い優先順位のハードな期限のタスクより前に実行される。
【００５６】
次に、時間線スラックの別の例を図７および８に関連して述べる。
図７は、第１のレベルにおけるスラック消費の連続的な要求が存在する場合の周期的実行時間を示すタスク実行時間線である。図７で示す例では、タスクτ１（レベル１）、タスクτ２（レベル２）、およびタスクτ３（レベル３）がそれぞれ、周期Ｔ１＝５ミリ秒、Ｔ２＝１０ミリ秒、およびＴ３＝３０ミリ秒を有する。また、タスクτ１、タスクτ２、およびタスクτ３はそれぞれ、対応する最悪ケースの実行時間Ｃ１＝１、Ｃ２＝２、およびＣ３＝８も有する。「ハイパー周期」、すなわち、周期Ｔ１、Ｔ２、およびＴ３の最小公倍数は、この例では、３０である。
【００５７】
図７で示したタスク実行時間線は、時間線スラックの要求が、ｔ＝０より前に行われており、またその要求が、最高優先順位にあることを想定している。
図７の周期的タスク・セットに関するスラック・テーブルの値は、テーブル５（付録Ａ）で示した静的ＴｉｍｅＬｉｎｅＳｌａｃｋｉ，ｊテーブルの中で提供している。
【００５８】
タスクτ１は、実行するのに１タイム・ユニットだけしか必要とせず（最悪ケース）、したがって、各ディスパッチ間で４タイム・ユニットの時間線スラックを提供する。τ１とτ２の両方が、τ２のディスパッチ周期（Ｔ＝１０）内で実行される（最悪ケース）場合、τ１が２タイム・ユニットを必要とし、またτ２が２タイム・ユニットを必要として（合計で４タイム・ユニット）、したがって、レベル２で６タイム・ユニットの時間線スラックが利用可能である。τ１〜τ３が、τ３のディスパッチ周期（Ｔ＝３０）内で実行される（最悪ケース）場合、τ１が６タイム・ユニットを必要とし、τ２が６タイム・ユニットを必要とし、またτ３が８タイム・ユニットを必要として（合計で２０タイム・ユニット）、したがって、１０タイム・ユニットのレベル３の時間線スラックが各ハイパー周期中に利用可能である。
【００５９】
図８は、間隔［１５，１６］において１０ユニットを超えるスラックを求める、レベル２におけるスラック消費の初期要求が存在する場合の周期的実行時間を示すタスク実行時間線である。図８に関する周期的タスク・セットは、図７のものと同一である。図８で示したタスク実行時間線は、時間線スラックの要求が、レベル２の優先順位を有する非周期的プロセスによってｔ＝２１で行われたものと想定している。ｔ＝２１で、利用可能なレベル２のスラックが、表記ＡＳ（２，２１）で表され、６タイム・ユニットに等しい。また、ｔ＝２１で、レベル１でアイドル時間が、表記Ｉ（１，２１）で表され、２１−５＝１６に等しく、レベル２でアイドル時間は、Ｉ（２，２１）＝２１−５−４＝１２であり、またレベル３でアイドル時間は、Ｉ（３，２１）＝２１−８−５−４＝４である。
【００６０】
図９は、一群の周期的タスク時間線を示している。図９に関する周期的タスク・セットは、図３のものと同一である。図９の一番上の線５０は、図３のものと同一である。レベル１は、優先順位１のタスクに関する周期的タスク時間線を表す。レベル２は、優先順位１および２のタスクに関する周期的タスク時間線を表す。レベル３は、優先順位１〜３のタスクに関する周期的タスク時間線を表す。
【００６１】
タスクτ１ないしτｎに関して、図９に示した各時間線は、交替するレベルｉのビジー（Ｂ）間隔とアイドル（Ｉ）間隔を含む。すべてのレベルｉビジー周期Ｂ（ｉ）は、レベル（ｉ＋１）ビジー周期Ｂ（ｉ＋１）に含まれる。すべてのレベル（ｉ＋１）アイドル周期Ｉ（ｉ＋１）は、レベルｉアイドル周期Ｉ（ｉ）に含まれる。時間線は、ハイパー周期ごとに繰り返され、したがって、アイドル累算器およびスラック累算器が、リセットされることが可能である。
【００６２】
２．２．２ 再利用されるスラック
スラック・スケジューリングを使用する際、最悪ケースの実行時間より少ない時間で完了するタスクからのスラックを再利用することができる。再利用されるスラックは、「保証された」ハードな期限を有するタスクからスチールして、高優先順位の重要ではないタスクに供与することができる。再利用されるスラックは、ハードな期限のタスクが実行された後に初めてスチールすることができる。
【００６３】
図１０は、最悪ケースの時間線を示すタスク実行時間線である。図１０では、周期Ｔ１＝１０およびＴ２＝１５、ならびに最悪ケースの計算時間Ｃ１＝４およびＣ２＝７をそれぞれ有する２つの周期的タスクτ１およびτ２が存在する。ハイパー周期は、３０である。図１０は、両方のタスクが最悪ケースの実行時間を消費するケースを示している。４タイム・ユニットだけが使用されていない。
【００６４】
図１１は、未使用の計算時間からのスラック再利用を示すタスク実行時間線である。図１０に関して前述したのと同一の周期的タスク・セットを使用して、図１１は、タスクτ１が最悪ケースの実行時間より少ない時間を使用し、したがって、τ２の第１のディスパッチが、図１０における時刻１５ではなく、時刻８に実行を完了するケースを示している。
【００６５】
従来のＲＭＳは、未使用の実行時間を自動的に再利用するが、どれだけ多くのスラックが再利用されたかを記録にとることはなく、したがって、どれだけを他のタスクに割り振ることができるかを保証することができない。
【００６６】
２．２．３ スラック・スケジューリング・ランタイム計算
このセクションは、ランタイムに行われるスラック・スケジューリング計算を定義する。２つの基本動作、すなわち、スラック変数を更新すること、および利用可能なスラックを計算することが存在する。
【００６７】
スラック変数を更新するための擬似コードが、付録Ｂのアルゴリズム（１）によって提供されている。アルゴリズム（１）は、スラックの可用性を計算する際に使用されるアイドル・スラック変数を更新する。Ｕｐｄａｔｅ＿ｔｉｍｅは、定数（場合により、ｉに基づく）である、このルーチンを実行する最悪ケースの時間に等しい。アルゴリズム（１）は、周期的タスク（実行時間割当てをオーバーランしていない）が完了したとき、呼び出される。理論上、タスクは、自らの実行時間割当てをオーバーランすることができ、それでも、スラック・アルゴリズムは、正しく動作し、場合により、負のスラック値をもたらす。実際には、タイマが満了したとき（実行時間割当てを超えたことに対応する）、そのポイントを超えたタイマの値が、時刻を見失っており、しばしば、タイマ割込みからのリターンは、内部レジスタを予測可能な状態にはしておかない。したがって、タイマが満了したとき、戻される値は、実際の時間使用を反映せず、またそのポイント以降のスラック計算は、信頼できるものではない。
【００６８】
非周期的スラック変数を更新するための擬似コードが、アルゴリズム（２）（付録Ｂ）によって提供される。アルゴリズム（２）は、スラックの可用性を計算する際に使用される非周期的スラック変数を更新する。アルゴリズム（２）は、周期的タスク増分に関する余剰計算時間を含む可能性がある非周期的タスクが完了した時点ではいつでも、あるいはアイドル・タスクが完了した時点、あるいは新たに到着するスラックの要求が生じた時点で呼び出される。Ｕｐｄａｔｅ＿ｔｉｍｅは、定数（場合により、ｉに依存する）である、このルーチンを実行する最悪ケースの時間に等しい。非周期的タスクｔは、いくつかの時間増分にわたって実行されることが可能であり、すなわち、スケジュール設定することができ、すべてのスラックを消費し、自らをサスペンドし、より多くのスラックが利用可能になった時点で再びスケジュール設定されることが可能である。
【００６９】
現行では、非周期的タスクは、次の３つのタイプのタスクのどれかである。すなわち、割込みサービス・ルーチン（ＩＳＲ）スレッド、アイドル・プロセス、または元の時間割当て中に完了せず、完了するためにスラックを要求した何らかの周期的タスク。最後のタイプの非周期的タスクでは、未完了の周期的タスクの残りの部分が、タスク増分と呼ばれる。
【００７０】
利用可能なスラックを計算するための擬似コードが、アルゴリズム（３）（付録Ｂ）によって提供される。アルゴリズム（３）は、新しいスレッドがまったく作成されず、既存のスレッドがまったく破壊されないと想定して、呼出しの時点に開始し、Ｔｉによって定義される周期の終りに終了する利用可能なスラックを計算する。このアルゴリズムは、タスクがスラックを消費するのを望む場合だけに呼び出される。要求側タスクは、関数ＡｖａｉｌａｂｌｅＳｌａｃｋを呼び出すのに先立ち、スラック変数を更新することが必要な場合、ｕｐｄａｔｅＡｐｅｒｉｏｄｉｃＳｌａｃｋＶａｒｉａｂｌｅｓを呼び出したものと想定される。実際には、利用可能なスラックが、何らかの値δより小さい場合、関数ＡｖａｉｌａｂｌｅＳｌａｃｋは、値ゼロを戻すことに留意されたい。δは、スラックを割り振るに値しない場合のシステムによって定義された量である。明らかに、δは、コンテキスト・スワップをする時間より小さい。たとえば、δ＝３または４のコンテキスト・スワップを選択すること、あるいは場合により、スラック消費スレッドの予期される実行時間に依存してより小さいものを選択することが望ましい可能性がある。
【００７１】
ＤＥＯＳに関して留意すべき２つのことは、（１）スラック変数の更新が、タスクごとの完了時にではなく、「集合」タスク・セットあたり１回だけ行われる必要があること、および（２）より高い優先順位のタスクが作成または破壊されたときはいつでも、スラックを再計算する必要があることである。これらの変更の詳細は、「動的スレッドを有するＤＥＯＳにおけるスラック・スケジューリング」と題したセクション４で提供している。
【００７２】
その他の必要な手続きは、すべてのスラック累算器をゼロにするハイパー周期リセット、およびスラック累算器をゼロにし（ハイパー周期初期設定が直後に呼び出されない場合）、スラック待ち行列を割り振り、タスク（または周期）識別子をゼロにする初期設定ルーチンである。これらのアルゴリズムを「動的スレッドを有するＤＥＯＳにおけるスラック・スケジューリング」と題したセクション４で再び提供している。
【００７３】
２．３ ブロッキング時間およびオーバーヘッドを計算すること
ＤＥＯＳにおいて２進セマフォー（ミューテックス）にアクセスするスレッドが、最高ロッカ・プロトコル（Ｈｉｇｈｅｓｔ Ｌｏｃｋｅｒ Ｐｒｏｔｏｃｏｌ）（ＨＬＰ）として周知のプロトコルを使用し、このプロトコルは、任意のスレッドがモニタをロックすることができる最高の優先順位を、モニタをロックする任意のスレッドに割り当てる。この割当ては、ロックが認可された時点で行われ、スレッドがロックを開放するまで保持される。
【００７４】
ＤＥＯＳスラック・スケジューリングの一実施形態では、スラックは、「ベスト・エフォート」でだけ認可される。スレッドに既に認可されたスラックに関する保証は、まったく行われない。スラックは、スレッドがクリティカルなセクションを実行していない、またはリソース待ち行列の先頭にないときはいつでも、（高優先順位スラック消費スレッドにより）取り去ることができる。
【００７５】
スラック消費スレッドに関するオーバーヘッド・アカウンティングは、以下の状況で行われる。
・スラック消費スレッドが、リソース（ミューテックス、セマフォー、またはイベントのどれか）を待つ待ち行列に入れられたとき、スラック累算器から十分な量のスラックを事前に減分して、スレッドがリソース待ち行列リストの先頭に到着したとき／場合にリソース要求の処理を可能にしなければならない。
【００７６】
・スラック消費スレッドが、スラックで実行されないスレッドを先制するとき、アイドル累算器を事前に増分して、コンテキスト・スワップおよび行われる可能性の高いキャッシュ・リフレッシュなどのオーバーヘッドに起因する可能な実行時間の損失を反映させるようにしなければならない。この増分は、先制されるスレッドに加算される。アカウンティング機構は、ＩＳＲスレッドによって生じさせられる先制のためにＤＥＯＳにおいて使用するものであることが可能である。（１）これは、スラックを消費しない周期的スレッドとＩＳＲスレッドの両方の先制に当てはまること、および（２）スラック消費スレッドが、別のスラック消費スレッド（周期的スレッドまたはＩＲＳスレッド）を先制するとき、増分はまったく計算されないことに留意されたい。（２）は、スラックの消費がベスト・エフォートであるので、そういうことになる。
【００７７】
・また、ミューテックスを実行する直前に、スラック累算器が、ミューテックスの最悪ケースの実行時間によって減分されなければならない。
以上すべてのケースで、十分なスラックが利用できない場合には、スレッドの要求は認可されず、スレッドは、再びスラック要求待ち行列に入れられる。以下のセクションで、以上のアルゴリズム規則をより明確にする。
【００７８】
最後に留意すべきこととして、スラックの割振りが保証される場合には、以上のケースのすべては、単一の保証機構に含まれる。スラックの事前割振りのためのアルゴリズムは、刊行物で見ることができる。
【００７９】
セクション３−ＤＥＯＳにおけるタスク・スケジューリング
このセクションは、ＤＥＯＳにおける様々なタスク・スケジューリング構成を定義する。少なくとも５つの基本タイプの構成を明確に定義して画定し、スラック・スケジューリングの実施可能性を評価できるようにしなければならない。５つの基本タイプの構成は、以下のとおりである。
【００８０】
・ＤＥＯＳによってアプリケーションに提供される基本スレッド・スケジューリング・サービス、
・スレッドの作成／開始および強制終了／停止のためのＤＥＯＳ承認試験アルゴリズム、
・サービスをスケジュール設定するためのＤＥＯＳ時間請求ポリシー、
・時間区分スレッドに関するスラック累算器の範囲、および
・システムの障害および／または電源投入／遮断に応答するスラック変数の回復。
以上５つのトピックを以下で扱う。
まず、ＤＥＯＳアーキテクチャの簡単な概説を提供する。
【００８１】
３．１ ＤＥＯＳアーキテクチャ
ＤＥＯＳアーキテクチャ内部における本発明の様々な実施形態の実施は、限定するものと解釈されるべきではない。というのは、本発明は、本明細書で例示するもの以外の多くの代替の実施形態で実施することができるからである。
【００８２】
ＤＥＯＳ実施の設計が、スケジューリング・アルゴリズムおよび実施可能性分析の設計にどのような影響を与えるかを理解するために、いくつかの概念が極めて重要である。この設計において明示的に示す情報は、時間の経過とともに観察可能であるが、すべての時点で観察可能ではないという意味で、実際の実施では、暗黙的に現れる可能性があることに留意されたい。それでも、事物を明確に述べることは、実施形態の挙動を理解するための概念上の助けとして役立つ。スラック・スケジューリングのアプリケーションに関連する４つの概念が、スレッド状態、スレッド・タイプ、スレッド待ち状態（スレッド状態の特別ケースである）、および時間区分化である。
【００８３】
３．１．１ スレッド状態
各スレッドは、次の状態、すなわち、ＮｏｔＣｒｅａｔｅｄ、Ｄｏｒｍａｎｔ、ＣｏｍｐｌｅｔｅＦｏｒＰｅｒｉｏｄ、Ｒｅａｄｙ、ＷａｉｔｉｎｇＦｏｒＰｒｅｄｅｃｅｓｓｏｒ、Ｒｕｎｎｉｎｇ、ＡｃｔｉｖｅｌｙＷａｉｔｉｎｇＦｏｒＲｅｓｏｕｒｃｅ、またはＰａｓｓｉｖｅｌｙＷａｉｔｉｎｇＦｏｒＲｅｓｏｒｃｅの１つまたは複数のシーケンスとして表されるライフ・サイクルを有するものと見なすことができる。最後の２つの状態では、リソースが、イベント、セマフォー、またはミューテックスである。これらは、セクション３．１．３でより詳細に定義している。スレッドは、通常、ＤＥＯＳサービスのどれかを実行することに応答して状態を変化させる。また、スレッドは、認可されていた何らかのリソース限度（時間割振りなどの）を超えた場合にも状態を変化させる。
【００８４】
説明を容易にするため、スレッドは、Ｒｅａｄｙ、Ｒｕｎｎｉｎｇ、ＷａｉｔｉｎｇＦｏｒＰｒｅｄｅｃｅｓｓｏｒ、またはＡｃｔｉｖｅｌｙＷａｉｔｉｎｇＦｏｒＲｅｓｏｕｒｃｅの状態にある場合、アクティブであると定義する。待ち状態に関するアクティブ・ステータスは、待ち状態の最終的定義に依存する。詳細には、ＣｏｍｐｌｅｔｅＦｏｒＰｅｒｉｏｄであるか、またはＰａｓｓｉｖｅｌｙＷａｉｔｉｎｇＦｏｒＲｅｓｏｕｒｃｅであるスレッドは、アクティブではなく、そのスレッドの未使用の計算時間をスラックとして再利用することができる。
【００８５】
各スレッドは、スレッドが、イネーブルにされているとき、スラックの要求を行うか否かを示すブール値、Ｓｌａｃｋを有する。さらに、スラック・コンシューマとして指定されたスレッドに関して、ＥｘｅｃｕｔｉｎｇＯｎＳｌａｃｋとｎｏｔ ｅｘｅｃｕｔｉｎｇ ｏｎ ｓｌａｃｋの区別が、オーバーヘッドのより効率的な予算アカウンティングのために行われる。
【００８６】
３．１．２ スレッド・タイプ
ＤＥＯＳにおいて２つのタイプのスレッド、周期的スレッドおよび割込みサービス・ルーチン（ＩＳＲ）スレッドが存在する。周期的スレッドは、静的または動的であることが可能であり、静的な周期的スレッドは、命名され、ｓｃｈｅｄｕｌｅ＿ｂｅｆｏｒｅ関係に参加することが許される。ＩＳＲスレッドは、割込みによって「ディスパッチ」されるものと考えることができる。また、ＩＳＲスレッドは、ときとして、非周期的スレッドとも呼ばれ、常に動的である。ＩＳＲスレッドも周期的スレッドもともに、予算が、固定された予算に加えてスラックを消費するものと指定されており（すなわち、Ｓｌａｃｋが真であり）、スラック機能が「オン」と指定されているという条件で、自らの固定された予算に加えてスラックを要求することができる。
【００８７】
一般に、スラックの認可に関しても、またスラックが認可された後のスラックの消費に関しても、保証は、まったく存在しない。このポリシーに関して「ベスト・エフォート」という用語が使用される。他の実施形態では、スラック・スケジューラが、スラックの割振りに関するオンライン承認試験をサポートして、公正さを、特により低い優先順位のスラックの要求側に対する公正さを促進することが可能である。
【００８８】
周期的スレッドにも、ＩＳＲスレッドにもともに、速度が関連している。スレッドの速度の逆数が、スレッドの周期である。スレッドを選択することができる速度のセットは、コールド・スタートで固定される。静的な周期的スレッドは、活動化間で変更することができない速度を有する。動的スレッドには、作成時に、利用可能な速度の任意のものを割り当てることができる。ＩＳＲスレッドには、常に最高速度が割り当てられ、ＩＳＲスレッドの優先順位は、一意的であり、プロセスの中の他のすべてのユーザ定義のスレッドより高い。周期的スレッドとＩＳＲスレッドの両方に予算を与えることができ、予算は、スレッドが周期中に消費することができる最大量の時間（またはその正規化）である。さらに、周期的スレッドも非周期的スレッドもともに、スラック要求側である（Ｓｌａｃｋ＝真）、またはスラック要求側ではない（Ｓｌａｃｋ＝偽）と宣言することができる。
【００８９】
等しい速度を有するすべての周期的スレッドは、等しい優先順位を有する。同じ速度のすべての周期的スレッドの集合を「集合スレッド」と呼ぶ。同じ速度のスレッドがサービスを受ける順序は、ｓｃｈｅｄｕｌｅ＿ｂｅｆｏｒｅ関係によって別の仕方で定義されていない場合、不定である。集合ＩＳＲスレッドの概念は、どう見ても不完全なものである。これは、すべてのＩＳＲスレッドが、同時にディスパッチされるわけではなく、したがって、同じ最高速度の周期において２つのＩＳＲスレッドのうちより低い優先順位のスレッドが実行されるのを許すシーケンスが、極めて普通である可能性があるので、そういうことになる。ＥｘｅｃｕｔｉｎｇＯｎＳｌａｃｋであるスレッドが存在しない限り、アイドル累算器の更新は、速度Ｒで実行されるスレッドからより低い速度で実行されるスレッドに遷移するときに、行われるだけでよい。すべてのスラック要求を評価する前に、アイドル累算器の更新が必要である。
【００９０】
周期的スレッドもＩＳＲスレッドもともに、ミューテックスにアクセスすることができる。ミューテックスも、予算を有し、ミューテックスに対する各アクセスが計時される。周期的スレッドは、周期あたり１回だけ実行され、したがって、周期あたりのミューテックス・アクセスの回数は、周期的スレッドに関して既知である。周期的プロセスの計算時間は、ミューテックスの実行時間を含む。ミューテックス実行時間は、やはり実施可能性の分析に含まれなければならないブロッキング期間に加えて含まれることに留意されたい。
【００９１】
ＩＳＲスレッドも予算を有するが、周期あたり１回、実行されることに制限されない。一実施形態では、すべてのＩＳＲスレッドが、最高速度（すなわち、最短周期）でスケジュール設定される。周期あたりＩＳＲスレッドが実行されることが可能な回数に対するハードな制限は存在しないので（実際には、割込みに応答する時間はゼロではないので、ハードウェアは、常にハードな制限を課す）、先制を行うＩＳＲスレッドから先制されるスレッドに幾分の予算を効果的に移動するアカウンティング機構が考案されている。わずかな変更を加えて、この予算移動機構を、ＩＳＲスレッドと同様にランダムに到来し、周期あたりの要求の数が事前に知られていないスラック要求側に適用することができる。ＤＥＯＳ時間請求ポリシー、およびこのポリシーのスラック要求に対する関係をセクション３．４で説明する。
【００９２】
３．１．３ スレッド待ち状態
スレッドは、リソースが、セマフォーまたはイベントである場合、リソースを待つことができる。ミューテックスは、待機ポリシーに関して２進セマフォーの特別ケースであると見なされるものと想定する。したがって、ミューテックス待機ポリシーは、特別ケースとして扱われない。ミューテックスの最大カウントが１である場合、ロック動作は、待ち動作と解釈されるものとし、ロック解除動作は、信号動作と解釈されるものとする。
【００９３】
セマフォーを実行するのを待っているとき、スレッドは、実際には、セマフォーが、最大カウントより少なくカウントされるのを待っている。ＤＥＯＳにおいてランダムな時刻にスレッドのスケジュール設定をもたらすイベントは、割込み（ＩＳＲスレッドをトリガする）、およびイベントが生じるのを待っているスレッドである。３つのタイプの待機、ＩｎｄｅｆｉｎｉｔｅＴｉｍｅｏｕｔ（不確定タイムアウト）、ＬｏｎｇＤｕｒａｔｉｏｎＴｉｍｅｏｕｔ（長期間タイムアウト）、およびＳｈｏｒｔＤｕｒａｔｉｏｎＴｉｍｅｏｕｔ（短期間タイムアウト）が、ＤＥＯＳにおいてサポートされている。
【００９４】
リソース長期間要求応答または不定期間要求応答に応答してスレッドが自らをサスペンドしたときはいつでも、そのスレッドの予算の残りから、何らかのオーバーヘッド処理のための時間を引いたものが、スラックに与えられるものと想定する。スレッドが、後継のスレッドを有する場合、スレッドは、サスペンドの時点でＣｏｍｐｌｅｔｅＦｏｒＰｅｒｉｏｄである。そうではなく、スレッドの予算が、スラック構成要素を有するものと指定されている場合、スレッドは、リソース待機待ち行列に加えて、スラック要求待ち行列にも入れられる。
【００９５】
アルゴリズム４〜６で使用する表記は、示唆することだけを意図し、必ずしもＤＥＯＳ実施形態において使用される表記を反映するものではない。すべてのタイプのタイムアウトが、ミューテックス、セマフォー、およびイベントに適用可能である。以下のアルゴリズムでは、ｃを呼出し側スレッドとし、ｅ（またはｒ）を、呼出し側スレッドが待っているイベント（リソース）とする。
【００９６】
不定のタイムアウトを扱うための擬似コードが、アルゴリズム４（付録Ｂ）によって提供されている。アルゴリズム４では、ｑｕｅｕｅ＿ｔｉｍｅ（ｃ）およびｒｅｓｏｕｒｃｅ＿ｔｉｍｅ（ｒ）が、定義を必要とする。まず、ｑｕｅｕｅ＿ｔｉｍｅは、スレッド・タイプ（ＩＳＲ、周期的）、および／またはスレッド状態属性ＥｘｅｃｕｔｉｎｇＯｎＳｌａｃｋに依存する。スレッドが、スラックで実行されているＩＳＲスレッドまたは周期的スレッドである場合には、ｑｕｅｕｅ＿ｔｉｍｅ（ｃ）は、２＊（ｃｓｗａｐ＋ｄｅｌｔａ）にキャッシュボーナスを足したものに設定される。スレッド・タイプが、スラックで実行されない周期的スレッドである場合には、ｑｕｅｕｅ＿ｔｉｍｅ（ｃ）はｃｓｗａｐにｄｅｌｔａを足したものである。
【００９７】
ｒｅｓｏｕｒｃｅ＿ｔｉｍｅ（ｒ）の値は、リソースｒに依存し、またｒに対するアクセスを受け取るスレッドｃにも依存する。ｒが、ミューテックスまたはセマフォーである場合には、ｒｅｓｏｕｒｃｅ＿ｔｉｍｅ（ｒ）は、ｒの実行時間にコンテキスト・スワップに関して受けたオーバーヘッドを足したものである。ｒがイベントの場合には、ｒは単にコンテキスト・スワップのオーバーヘッドである。（イベントをパルス化する時間は、パルス化する側のスレッドに課せられ、待機側のスレッドには課せられない。）コンテキスト・スワップ・オーバーヘッドは、ｑｕｅｕｅ＿ｔｉｍｅ（ｃ）で定義される。
【００９８】
長期間タイムアウトを扱うための擬似コードが、アルゴリズム５（付録Ｂ）によって提供される。アルゴリズム５とアルゴリズム４の間の違いは、反復の回数を記録にとることだけである。オーバーヘッド・アカウンティングは同一である。
【００９９】
短期間タイムアウトを扱うための擬似コードが、アルゴリズム６（付録Ｂ）によって提供される。スレッドが、自らの予算をスラックに引き渡す際、次の周期に先立って予算の残りを再利用することができるという保証は、まったく行われないことに留意されたい。ＩＳＲスレッドも周期的スレッドもともに、自らの予算の部分をスラックに引き渡すことができる。スレッドは、周期に関して完了しない限り、再開された場合にスラックで実行するのが可能になるように常に十分な予算を保持する。
【０１００】
セマフォーに関して保証はまったく行われないので（モニタを除き）、セマフォーに関連するコードの実行に関してスラックの事前の減分はまったく行われない。セマフォーは、クリティカルなセクションではないので（また、優先順位が変化しないので）、先制が許される。
【０１０１】
その他の実施形態では、ＩＳＲスレッドを最高速度以外の速度でサポートすることができる。この場合、スラック・スチールにより、ＩＳＲスレッドの応答時間を向上させるための機構が提供されることが可能である。
【０１０２】
３．１．４ 時間区分化
一実施形態では、時間区分化に関して以下の想定が行われる。ＤＥＯＳアプリケーションが、プロセスの集合を含む。プロセスは、スレッドの集合である。各プロセスには、全ＵＰＵ帯域幅の一部分が割り振られ、したがって、プロセッサを使用してある形態の時間区分化が生成される。各プロセスは、区分と考えることができる。各スレッドは、単一の区分に属する。
【０１０３】
各区分には、ある量の時間、つまり予算が「保証」される。システム始動時に、各プロセスに、スレッドが開始および／または作成される際のスケジュール設定可能性試験に関する計算におけるファクタである「プロセス利用率限度」が与えられる。プロセスの予算は、プロセス利用率限度にハイパー周期を掛けたものに等しく、ハイパー周期は、システムにおけるすべての周期の最小公倍数である。どのタスクも、自らの実行時間予算を超えることは許されない。
【０１０４】
また、ブロッキング時間が、プロセス・レベルではなく、システム・レベルで計算されることも認められよう。この計算の概要は、セクション３．３．２で見ることができる。
【０１０５】
すべてのプロセスは、アクティブまたは非アクティブであるＰｒｉｍａｒｙ＿Ｔｈｒｅａｄを有する。非アクティブであるとき、Ｐｒｉｍａｒｙ＿Ｔｈｒｅａｄの予算は、時間線スラックの一部である。Ｐｒｉｍａｒｙ＿Ｔｈｒｅａｄは、システム・レベルの機能を行い、アプリケーション開発者によって定義されていない。１次スレッドの予算は、プロセスの予算、およびそのプロセスの中のすべてのアクティブなスレッドによって暗黙的に定義される。１次スレッドの予算は、どのような他のスレッドがプロセスの中でアクティブであるかに依存して、ゼロ予算からプロセスの最大予算までの範囲内で変化する。
【０１０６】
プロセスが最初に開始されたとき、１次スレッドの予算は、プロセスの予算に等しい。実際には、プロセス開始時に、そのプロセスの１次スレッドだけがアクティブであり、またさらに、１次スレッドは、初期設定等のために多くの実行時間を消費し、これにより、少なくとも最初は、ＣＰＵ時間の多くの割当てを必要とする可能性がある。初期設定後、新しいスレッドが開始され、１次スレッドの予算割当てが低減されることが可能である。
【０１０７】
説明を簡単にするため、１次スレッドの予算は、プロセスの中のスレッドが開始／作成されたとき低減させられ、スレッドが停止／削除されたときに増加される明示的な量であるものと想定する。
【０１０８】
概略を述べると、スケジュール設定可能性の分析が、各プロセスに適用され、すべてのプロセスが実行可能である場合にだけ、システム全体がスケジュール設定可能であると言われる。システム実施可能性は、各プロセスのスケジュールが実施可能であることを暗に示すのではないことに留意されたい。区分を超えてミューテックスを共用することが許容可能であり、その場合、ミューテックス予算は、ミューテックスにアクセスするスレッドを有するプロセスのそれぞれの予算からではなく、システム予算から取られる。これは、プロセスの実施可能性の試験からブロッキング時間を取り出してシステム・レベルの試験にそれを移動する最適化である。この詳細をセクション３．３のオンライン承認試験でより正確に提示している。
【０１０９】
その他の想定は、システムにおける速度のセットが調和的であり、固定であることである。スレッドおよび区分は、動的である。活動化および非活動化は、スレッドの次の周期境界で行われる。スレッドおよび区分の許可のためにオンライン承認試験が使用される。
【０１１０】
３．２ ＤＥＯＳによって提供されるスケジューリング・サービス
テーブル６（スレッド・サービス）（付録Ａ）が、スラック・スケジューリングに関連するＤＥＯＳスレッド・サービスを明らかにしている。これらのスレッド・サービスについて次に述べる。
【０１１１】
３．２．１ スレッド作成
ＣｒｅａｔｅＴｈｒｅａｄに対する関係のある入力は、周期およびｃｐｕ＿ｔｉｍｅである。
【０１１２】
動的スレッドの場合、スレッドは、作成されるだけでなく、開始される。使用されるオンライン承認試験、およびスレッドが開始されるときの条件に関しては、ＳｔａｒｔＴｈｒｅａｄを参照されたい。
【０１１３】
静的スレッドの場合、この動作は、スラック・スケジューラの視点からは、ノーオペレーションのようなものである。静的スレッドの場合、実際のスケジュール設定可能性の試験は、スレッドが活動化される前にＳｔａｒｔＴｒｅａｄ手続きで行われる。この試験をＣｒｅａｔｅＴｈｒｅａｄで行うことは、悲観的である。というのは、すべての静的スレッドが同時にアクティブである必要はないからである。
【０１１４】
この手続きが呼び出されたとき、すべての静的スレッドおよびあらゆるｓｃｈｅｄｕｌｅ ｂｅｆｏｒｅ関係が行われる。許容可能なスタック・サイズ、名前および速度の正当性、および、場合により、セマフォー・アクセスの正当性のようなことに関する静的検査が、このルーチンで行われる。
【０１１５】
３．２．２ スレッドを開始する
この動作は、静的スレッドだけに該当する。ただし、動的スレッドの作成に適用されるスラック更新も、ここで提供される。このスレッドが追加されても、実施可能なスケジュールがもたらされる場合、活動スラック中のスレッドは、現在の周期の残りの間、ＣｏｍｐｌｅｔｅＦｏｒＰｅｒｉｏｄ状態に置かれ、次の周期の開始時にディスパッチされる（すなわち、作動可能にされる）。スケジューリングの点からは、呼出しの時点でスレッドが活動スラック状態にない場合、またはそのスレッドを含め、結果のスケジュールが実施不可能である場合、このサービスは、ノーオペレーションである。
【０１１６】
セクション３．３が、スレッドの許可により、実施不可能なプロセス・スケジュールがもたらされるかどうかを決定するのに使用することができるオンライン承認試験を説明している。スレッドの追加により、実施可能なスケジュールがもたらされる場合、そのスレッドは、開始され、実施可能なスケジュールがもたらされない場合には、誤り条件が戻される。
【０１１７】
プロセスのＰｒｉｍａｒｙＴｈｒｅａｄがアクティブである場合には、新しいスレッドを開始／作成するための予算は、その１次スレッドの予算から来る。この場合、２回のスラック更新が必要とされる。第１に、１次スレッドに割り振られた確保された時間が、低減され、１次スレッドのスラック・レベルにおける時間線スラックが増加することがもたらされ、また第２に、割振りが行われる新しいスレッドに関して、時間線スラックの低減が行われなければならない。プロセスのＰｒｉｍａｒｙＴｈｒｅａｄが停止された場合には、あるスレッドを開始するのに先立ち、時間線スラックの低減が行われなければならない。したがって、ＰｒｉｍａｒｙＴｈｒｅａｄがアクティブではない場合、スラック変数を更新するのに伴う作業がより少ない。スレッドの作成／開始を反映させるのに必要とされるスラック変数更新を以下に提供する。
【０１１８】
スラック変数が更新される際、スラックの割振り変更に関する何らかの面倒な問題が生じる可能性がある。特に、現在、スラックを消費しているレベルｋのスレッドに何が生じるだろうか。ＴｉｍｅＬｉｎｅＳｌａｃｋｉｊが更新される場合には、スラック消費スレッドは、作動可能待ち行列の先頭に戻ると、スラックの可用性を再計算する必要がある。スラックの可用性の計算が行われる回数を最小限に抑えることが望ましい。特に、スラックの可用性が変化していない場合（場合により、再利用されるスラックの追加を例外として）には、単一回のスラック計算だけが行われるべきである。この目的での最適化が、「動的スレッドを有するＤＥＯＳにおけるスラック・スケジューリング」と題したセクション４でより詳細に与えられる。
【０１１９】
プロセス間のスラック共用のため、理論上、プロセスの利用率限度に違反するどのスレッドにも割振りは行われず、したがって、利用率限度を超えて消費を行うプロセスのタスク・セットをもたらすスラック消費スレッドは、ベスト・エフォート・スレッドに限定されなければならない。また、クリティカルなスレッドまたは重要なスレッド（すなわち、ハードな期限を有するスレッド）が、いつスラックを使用することができるかに関する条件についても、「動的スレッドを有するＤＥＯＳにおけるスラック・スケジューリング」と題したセクション４で述べている。ここでの主な関心事は、スラック更新回数を制限して（これは、スラックが、既に保証された帯域幅に関する応答時間を短縮するためだけに使用される場合、可能であるように思われる）、過度の回数、スラックの可用性を計算して計算予算が消費されないようにすることである。ベスト・エフォート・スレッドは、常にスラックを使用しようと試みることができるが、スラックの可用性に関する保証はまったく行われない。
【０１２０】
以下に、プロセスのＰｒｉｍａｒｙＴｈｒｅａｄが停止された際、スレッドの活動化のために必要とされるスラック変数更新のいくつかを示している。１次スレッドが停止されていない場合、１次スレッドによる利用率を低減するさらなる更新が必要とされる。より詳細なアルゴリズムが、「動的スレッドを有するＤＥＯＳにおけるスラック・スケジューリング」と題したセクション４で与えられる。以上のスラック変数更新のすべては、ＣｒｅａｔｅＴｈｅａｄ／ＳｔａｒｔＴｈｒｅａｄの実行時間の一部として、呼出しを行うスレッドに課せられる。
【０１２１】
ＳｔａｒｔＴｈｒｅａｄ（または、動的スレッドの場合、ＣｒｅａｔｅＴｈｒｅａｄ）が、第γｉ番（現在のハイパー周期の開始以来）の周期で速度ｉのスレッドのために呼び出された場合、スレッドを追加しても、実施可能なスケジュールがもたらされると想定して、ｋ＝ｉ．．．ｎに関して値、ＴｉｍｅｌｉｎｅＳｌａｃｋｋ，γｋ＋１を更新する必要がある。
【０１２２】
時刻γｋ・Ｔｋに、ＴｉｍｅｌｉｎｅＳｌａｃｋｋ，γｋ＋１がＴｉｍｅｌｉｎｅＳｌａｃｋｋ，γｋ＋（Ｔｋ−Ｃｋ，γｋ）に初期設定される。次に、スレッドを開始／作成するそれぞれの呼出し時に、以下の更新が必要である。
【０１２３】
【数４】
Figure 2004533667
【０１２４】
ｃｐｕ＿ｔｉｍｅは、作成されるスレッドの最悪ケースの実行時間である。ＴｉｍｅｌｉｎｅＳｌａｃｋｋ，γｋ＋１の計算は、ＴｉｍｅｌｉｎｅＳｌａｃｋｋ，γｋに関する計算が使用のために用意されているときに開始されることに留意されたい。理論上、ｋ∈｛ｉ，ｉ＋１．．．ｎ｝およびｊ∈｛γｋ＋１，γｋ＋２．．．Ｈ／Ｔｋに関してＴｉｍｅｌｉｎｅＳｌａｃｋｋ，ｊを計算することが望まれるが、速度ｉの次の周期で新しいスレッドを開始することができるだけでなく、調和的タスクでは、（ＴｉｍｅｌｉｎｅＳｌａｃｋｋｊ）マトリックスの２つの次元を縮約して、速度の数に等しい長さを有するベクトルにすることができる。この縮約および計算の導出が、「動的スレッドを有するＤＥＯＳにおけるスラック・スケジューリング」と題したセクション４で提供される。以上の更新がいつ行われるか、またどのレベルで行われるか（更新は、各レベルに同時に適用されない）も、セクション４で提示する。
【０１２５】
３．２．３ スレッドを開始する
指定されたすべての活動スラック中のスレッドが開始される。リストの中のアクティブなスレッドに関して、スケジューリングの点で動作はまったく行われない。それぞれ活動スラック中のスレッドに関して、ｋ＝ｉ，ｉ＋１．．．ｎについて、ＴｉｍｅｌｉｎｅＳｌａｃｋｋ，γｋ＋１の適切な値を更新する必要があり、またｐｒｏｃｅｓｓ＿ｃｐｕ時間変数を適切に減分する必要がある。概念上、入力リストの中のそれぞれ活動スラック中のスレッドに関してＳｔａｒｔＴｈｒｅａｄ手続きが呼び出される。実際には、ＳｔａｒｔＴｈｒｅａｄを多数回、呼び出すよりもこのルーチンを一回、呼び出すほうが、オーバーヘッドが小さい。
【０１２６】
３．２．４ スレッドを再スタートする
アクティブなスレッドが再スタートされる。スレッドがアクティブでない場合、このサービスの結果は、スラック・スケジューリングの点からはノーオペレーションである。
【０１２７】
スケジューリングの点からは、アクティブなスレッドの状態が、ＣｏｍｐｌｅｔｅＦｏｒＰｅｒｉｏｄに変更され、その周期の終りまで、そのスレッドがサスペンドされて、周期の終りの時点で再びスケジュール設定される。
【０１２８】
スラックは、このルーチン中、再利用することができる。具体的には、スレッドの状態がＣｏｍｐｌｅｔｅＦｏｒＰｅｒｉｏｄに変更されたとき、これは、スレッドの完了と見なされ、したがって、スレッドの完了時に行われるのと同じ更新が行われる。より具体的には、再利用されるスラックの量は、スレッドが、再スタートされるスレッドである場合、ｗｏｒｓｔ＿ｃａｓｅ＿ｅｘｅｃ＿ｔｉｍｅ（スレッド）−ａｃｔｕａｌ＿ｅｘｅｃ＿ｔｉｍｅ（スレッド）である。
【０１２９】
スレッドが、（スラック）レベルｉで実行されるようにスケジュール設定されている場合には、スラック累算器は、（最終的には、更新が、集合スレッドの完了まで延期されるかどうかに依存して）アルゴリズム１３（付録Ｂ）で示すとおり更新される。更新が、集合スレッドが完了したとき、または非周期的スレッドをスケジュール設定するときにだけ実行される場合、括弧に入れた「最終的には」という節が発動されて、再利用されるスラックは、集合的更新が行われるまでローカルで記憶される。これに関するより詳細な説明は、「動的スレッドを有するＤＥＯＳにおけるスラック・スケジューリング」と題したセクション４で見ることができる。
【０１３０】
スレッドがミューテックスを実行していた場合、ミューテックスは、再スタート・ルーチンによってロック解除される。これを反映させるように実行時間カウンタを調整する必要がある。ミューテックスのステータスは、ミューテックスが、スレッド再スタートの結果としてロック解除されたことを示す。ミューテックスがロックされたスレッドに関する実行時間を更新することは、スラック変数の更新に対してまったく異常な影響は与えないようである。
【０１３１】
スレッドが、自らを再スタートしている場合には、前述した再利用されるスラックは、このルーチンを実行するのにかかる時間だけ、さらに減分しなければならず、スレッドが、自らを再スタートしていない場合には、この時間は、実行を呼び出したスレッドに課せられることに留意されたい。
【０１３２】
３．２．５ スレッドを強制終了／停止する
ＤＥＯＳの一実施形態では、静的スレッドだけが停止される。次に、停止された静的スレッドを強制終了させることができる。動的スレッドが強制終了され、これは、動的スレッドを停止してから強制終了させる効果を有する。スレッドの状態は、ＮｏｔＣｒｅａｔｅｄになる。アクティブなスレッドまたは活動スラック中のスレッドだけを強制終了させることができる。
【０１３３】
動的スレッドが強制終了されたとき、または静的スレッドが停止されたときにスラック変数の更新を行うことができる。停止された静的スレッドが強制終了されたときには、更新はまったく行われない。プロセスのＰｒｉｍａｒｙＴｈｒｅａｄがアクティブである（すなわち、停止されていない）場合には、強制終了／停止されるスレッドの予算は、１次スレッドの予算に戻る。プロセスのＰｒｉｍａｒｙＴｈｒｅａｄが停止された場合、強制終了／停止されるスレッドの予算は、スラック・プールに行く。
【０１３４】
予算がスラックに行くとき（すなわち、１次スレッドが停止されたとき）、周期ｊで実行される停止／強制終了サービスを伴う速度ｉを有するスレッドに関して、ＴｉｍｅｌｉｎｅＳｌａｃｋｉ，ｊ＋１の値は、速度ｉの次の周期の開始時にスラックに利用可能になるスレッドに割り振られたｃｐｕ＿ｔｉｍｅだけ増分される。スレッド開始／作成におけるのと同様に、このスラックの更新は、スラックでだけ現在、実行されているスレッドに関する新しいスラックの可用性の計算を必要とする。スレッドのプロセスのＰｒｉｍａｒｙＴｈｒｅａｄがアクティブである場合、強制終了／停止されたスレッドの予算は、１次スレッドの予算に戻され、また、これにより、時間線スラック変数を更新することが必要とされる。
【０１３５】
Ｔｋの第γｋ＋１番の周期の開始時に、レベルｋの停止／強制終了されたスレッドの予算をスラック・プールに戻すための時間線スラック変数の更新を以下に提示する。
【０１３６】
時刻γｋ・Ｔｋに、ＴｉｍｅｌｉｎｅＳｌａｃｋｋ，γｋ＋１がＴｉｍｅｌｉｎｅＳｌａｃｋｋ，γｋ＋（Ｔｋ−Ｃｋ，γｋ）に初期設定される。ｋｉｌｌＴｈｒｅａｄ（またはｓｔｏｐＴｈｒｅａｄ）動作ごとに、
【０１３７】
【数５】
Figure 2004533667
【０１３８】
強制終了されるスレッドの予算は、ｃｐｕ＿ｔｉｍｅであり、ｃｐｕ＿ｔｉｍｅは、Ｔｋタイム・ユニットごとに利用することができる。この割振り解除ポリシーは、すべてのハードな期限の（周期的およびＩＳＲ）スレッドに適用される。
【０１３９】
１次スレッドがアクティブであるとき、予算は、１次スレッドに割振り変更される。また、これを反映させるためにスラックの更新も必要とされる。「ベスト・エフォート」スレッドを強制終了するため、「ベスト・エフォート」スレッドが、保証された帯域幅をまったく有さず、利用可能なスラックでだけ実行されるという条件で、ＴｉｍｅｌｉｎｅＳｌａｃｋｉ，ｊには、まったく調整が行われない。
【０１４０】
また、スレッドの未使用の予算の残りも、所望される場合、この周期で使用するために再利用することができる。これは、ハードな期限のスレッドとベスト・エフォート・スレッドの両方に当てはまる。ハードな期限のスレッドに関して、再利用可能なスラックは、ｗｏｒｓｔ＿ｃａｓｅ＿ｅｘｅｃ＿ｔｉｍｅ（スレッド）−ａｃｔｕａｌ＿ｅｘｅｃ＿ｔｉｍｅ（スレッド）である。ベスト・エフォート・スレッドに関して、再利用可能なスラックは、ｒｅｍａｉｎｉｎｇ＿ｓｔａｃｋ（スレッド）であり、これは、要求の時点で認可されたスラックから、スラック要求時以来、使用されたスラック（または、等価であるが、実行時間）を引いたものに等しい。
【０１４１】
強制終了されたスレッドの予算は、Ｔｋで定義される次の周期の開始時にその他のスレッドによって使用されるために利用可能になることに留意されたい。これは、スレッド開始動作と同様である。
【０１４２】
強制終了／停止されるスレッドが、ミューテックス・ロックを保持している場合、ミューテックス・ロックは、このサービス呼出しによってロック解除される。この時点で、ミューテックスのステータスは、ミューテックスが、スレッド強制終了／停止呼出しの結果としてロック解除されたことを示す。
【０１４３】
強制終了／停止されるスレッドが、イベントを待っている場合、そのスレッドは、そのイベントに関するリンク・リストから除去される。スレッドが、後継のスレッドをまったく有さず、能動的にイベントを待ち続けている場合、この周期に関するスレッドの予算の未使用の部分を再利用することができる。
【０１４４】
３．２．６ 次の周期まで待つ
呼出し側スレッドは、次の周期の開始までサスペンドされる。この手続きは、自らをサスペンドするスレッドにより、または予算が間もなく切れるときにカーネルによって呼び出されることが可能である。スレッドが自らをサスペンドする場合には、この呼出しは、１次スレッドに課せられる。ただし、１次スレッドは、ゼロ予算を有する可能性がある（１次スレッドが停止されていた場合）。あるいは、予算が切れた場合、カーネルが検出を行って呼出しを開始し、したがって、請求を受ける。というのは、カーネルが、サスペンドを開始したからである。
【０１４５】
この周期における未使用の計算時間をスラックとして再利用することができる。多くの他のカーネル動作におけるのとまったく同様に、再利用されるスラックは、スレッドの最悪ケースの実行時間が（ほとんどのケースで）、そのスレッドの予算である場合、ｗｏｒｓｔ＿ｃａｓｅ＿ｅｘｅｃ＿ｔｉｍｅ（スレッド）−ａｃｔｕａｌ＿ｅｘｅｃ＿ｔｉｍｅ（スレッド）である。
【０１４６】
ＩＳＲスレッドは、周期あたり多数回、実行されることが可能であるという意味で、異なる可能性がある。スラックが、ＩＳＲスレッドのために再利用される場合には、最悪ケースの実行時間の正式の規定が必要とされ（スレッド予算とは異なる場合）、また再利用されるスラックは、前述した計算を使用して獲得される。スラック累算器がいつ更新されるかに依存して、集合スレッド更新までこの情報をローカルで保持すること、またはアルゴリズム１３（付録Ｂ）に対する呼出しを即時に行うことが可能である。
【０１４７】
３．２．７ プロセスを再スタートする
プロセスの中のすべてのスレッド、ミューテックス、およびイベントが強制終了される。１次スレッドだけが再スタートされる。１次スレッドには、呼出しの時点でどうであったかに関わらず、完全な予算が与えられる。
【０１４８】
すべての強制終了されたスレッドに関してスラック累算器を更新する必要があり、また、プロセスの１次スレッドに関してもスラック累算器を更新する必要がある。プロセスをいつ再スタートすることができるかに関する制限は、まったく存在しない。論理上、ｋｉｌｌＴｈｒｅａｄサービスに関するセクションで述べたとおり、スレッド強制終了のたびに毎回、ＴｉｍｅｌｉｎｅＳｌａｃｋｉｊが調整される。同様に、ＴｉｍｅｌｉｎｅＳｌａｃｋｉｊは、１次スレッドのｃｐｕ＿ｔｉｍｅを割り振る際に更新される。時間線スラック変数更新動作のこのシーケンスは、繰返しの更新を行うのではなく、単に新しいセットの時間線変数が計算される場合、相当に縮減することができる。
【０１４９】
ｋ≧ｉに関して、ＴｉｍｅｌｉｎｅＳｌａｃｋｋ，γｋの後続の計算は、ＴｉｍｅｌｉｎｅＳｌａｃｋｋ，γｋ＋１＝ＴｉｍｅｌｉｎｅＳｌａｃｋｋ，γｋ＋（Ｔｋ−ｎｋ｜ｉ・ｃｐｕ＿ｔｉｍｅ）であり、ただし、ｃｐｕ＿ｔｉｍｅは、プロセスの１次スレッドが、唯一のアクティブなスレッドである場合、実際のプロセスの１次スレッドのものである。
【０１５０】
システム・レベルで保持されるスラックに関して、プロセスの１次スレッドは、プロセス利用率予算とプロセスの１次スレッドのｃｐｕ＿ｔｉｍｅが区別されるように、制約ベクトルを必要とする。プロセスの１次スレッドのｃｐｕ＿ｔｉｍｅは、プロセスの１次スレッドが取る最悪ケースの量の実行であり、これは、時間の経過とともに変化することが可能である。最初、ｃｐｕ＿ｔｉｍｅは、ｐｒｉｍａｒｙ＿ｔｈｒｅａｄがプロセス初期設定を行っている際の利用率予算に等しいことが可能である。後に、ｃｐｕ＿ｔｉｍｅは、ゼロにまで低減されること、または中間の値に低減されることが可能である。
【０１５１】
３．２．８ ミューテックスを作成する
スケジューリングの点からは、以上のことは、時間線スラック変数には影響を与えることはなく、ミューテックスを実行するスレッドによって生じさせられる最悪ケースのブロッキング時間を決定するのに使用される。したがって、ミューテックスが、スケジュール設定可能性試験の結果に影響を与える可能性がある。ミューテックス・ブロッキング時間は、プロセスごとにではなく、システム・レベル・パラメータとして計算される。
【０１５２】
ミューテックス・アクセスのために使用されるプロトコルは、最高ロッカ・プロトコルとして知られ、このプロトコルは、周知の優先順位上限プロトコルの変更されたバージョンである。最高ロッカ・プロトコルは、以下のとおり動作する。スレッドｔが、ミューテックスＭにアクセスすることを望む場合には、Ｍに対するアクセスが認可されたとき、ｔが、Ｍに対するアクセス特権を有する任意のスレッドの最高（数値として最低の）優先順位を（一時的に）継承する。
【０１５３】
ミューテックスにアクセスすることができるスレッドのどれかによって実行あたりミューテックスがロックされることが可能な最大時間に、ｍａｘ＿ｌｏｃｋ＿ｔｉｍｅが入力され、その最大時間を定義する。また、ミューテックスにアクセスすることができる最高（数値として最低の）優先順位を有するスレッドの周期を特定するｐｒｉｏｒｉｔｙ＿ｃｅｉｌｉｎｇ＿ｐｅｒｉｏｄも入力される。スレッドが、セットのミューテックスに、たとえば、Ｍｊがνｊ回、アクセスを受ける、Ｍ１、Ｍ２．．．Ｍｋにアクセスする場合には、そのスレッドの最悪ケースの実行時間が、加算されている。
【０１５４】
【数６】
Figure 2004533667
【０１５５】
実施可能性の分析を計算する際、ｐｒｉｏｒｉｔｙ＿ｃｅｉｌｉｎｇ（ミューテックス）レベルでブロッキング時間として導入される可能性がある利用率の構成要素は、ｍａｘ＿ｌｏｃｋ＿ｔｉｍｅ（Ｍ）／ｐｒｉｏｒｉｔｙ＿ｃｅｉｌｉｎｇ＿ｐｅｒｉｏｄ（Ｍ）である。システム・レベルにおけるブロッキング時間を含む実施可能性の分析をセクション３．３で提示している。
【０１５６】
３．２．９ ミューテックスをロックする
ミューテックスがロックされる場合、呼出し側スレッドには、ミューテックスがロック解除されるまで待つ機会が与えられる（すなわち、呼出し側は、ｗａｉｔ＿ｏｋａｙパラメータを真に設定することができる）。呼出し側スレッドが待つ場合、より低い優先順位のプロセスがミューテックスを実行するのを待つ間に待ち行列に入れられる時間が、待機するスレッドに関するブロッキング時間としてカウントされる。（技術上、実施の点からは、ミューテックスを実行するより低い優先順位のスレッドが、少なくとも待機するスレッドと同じだけ高いミューテックスの優先順位上限を継承しているので、これは先制である。）より高い優先順位のスレッドが実行されるのを待つことは、先制である。先制時間とブロッキング時間はどちらも、スレッドの累積された実行時間としてカウントされない。ただし、両方とも、実施可能性の分析において考慮される。
【０１５７】
ユーザ定義の特権を有するすべてのスレッド（ＩＳＲスレッドを含め）は、ミューテックスをロックすることができる。保証されたハードな期限を有するスレッドに関しては、ミューテックスをロックするのに先立ち、スラックの可用性を検査することは、まったく必要ない。「ベスト・エフォート」スレッドに関しては、アクセスを認可するのに先立ち、ミューテックスの実行を完了するのに十分なだけのスラックが割り振られていなければならない。これは、要求を行うスレッドがサスペンドされるまでの実行に関する残余のタイム・スライスを見ることによって容易に試験することができる。残余のタイム・スライスが、ミューテックスに関する最悪ケースの実行時間より小さい場合、ロックは認可されず、スレッドは、（スレッドが、ミューテックスに対するアクセスを必要としない代替のパスは進まないと想定すると）自らをサスペンドすることが賢明である。ただし、このポリシーは、スラックの使用を必要とするより高い優先順位のスレッドによって呼び出される別のサービスが、ミューテックスの実行が完了する前に開始することが許されない場合にだけ、うまくいく。
【０１５８】
ＤＥＯＳにおいて、スレッドの残余のタイム・スライスは、まず、最悪ケースのミューテックス実行時間だけ減分される。次に、ミューテックスが実行され、ミューテックスの実行が、最悪ケースの実行時間より短かったとき、そのスレッドの実行時間が低減される。ここで、スラック変数の更新はまったく必要ない。
【０１５９】
３．２．１０ ミューテックスをリセットする
ミューテックスのステータスは、ミューテックスがリセットされたことを示すように設定される。ミューテックスがロックされていた場合、このロックが開放され、ロッカの実行時間が、ミューテックスを実行するのに費やされた時間を反映するように調整される。ロッカがミューテックスをリセットした場合、このサービスの実行時間が、ロッカの実行時間に加算される。この動作中、スラック変数は、まったく更新されない。
【０１６０】
３．２．１１ イベントを待つ
３つの異なるタイプの指定可能なイベント待機が存在する。すなわち、不定のタイムアウト、計時されたタイムアウト、および即時のタイムアウトであり、これらをそれぞれ、アルゴリズム４〜６（付録Ｂ）で説明している。
【０１６１】
スレッドが、後継のスレッドを有する場合には、不定のタイムアウト待機または長いタイムアウト待機は、スレッドが、パルス化されていないイベントの最初のクエリの後、自らをサスペンドし、次に不定の（不定のタイムアウトの場合）回数、またはせいぜい、事前に指定された（長期間タイムアウトの場合）回数、周期的にイベントをポーリングするという意味で、受動的である。第１回以降のすべてのポーリングは、周期の開始時に行われる。サスペンドされる際、スレッドの予算から時間はまったく請求されず、実際、未使用の計算時間をその周期に関するスラックとして再利用することができる。
【０１６２】
スレッドが、後継のスレッドをまったく有さない場合には、待機は、不定のタイムアウト待機または計時されたタイムアウト待機として能動的である。能動的に待機するのに費やされた時間は、スレッドのＣＰＵ予算から請求される。アクティブなスレッドは、イベントのリンク・リストに追加される。
【０１６３】
イベントは、スレッドの周期に関して残っている予算に先立ってパルス化される場合、作動可能待ち行列に入れられる。スレッドの予算が尽きる前にイベントがパルス化されない場合、スレッドは、周期に関して完了し、次の周期の開始までサスペンドされる。この場合、ローカルのスラックの更新が、（スレッドが集合の一部である場合）必要である。スレッドは、最悪ケースの実行時間を消費しており、したがって、スラックは、まったく再利用することができない。
【０１６４】
能動的な待機が、不定の（不定のタイムアウトの場合）回数の周期、またはせいぜい、指定された（計時されたタイムアウトの場合）回数の周期の開始時に再開される。能動的に待つ間、イベントがパルス化される場合、スレッドは、そのイベントのリンク・リストから除去されて（待っているすべてのスレッドも除去されて）、作動可能待ち行列に入れられる。この時点でスラックの更新は、まったく必要とされないが、スレッドの実行時間は、能動的に待つのに費やされた時間を反映しなければならない。
【０１６５】
スレッドが自らをサスペンドする間にイベントがパルス化された場合（受動的待機のため、または周期中の能動的待機が尽きたため）、スレッドは、次のディスパッチの時点で作動可能待ち行列に直接に入れられる。サスペンドの時点で行われたスレッドの実行時間の更新およびスラック変数の更新は、ディスパッチの時点では必要ない。
【０１６６】
即時のタイムアウトは、先制によって説明されるもの以外の待ちをまったく有さない。したがって、即時のタイムアウトを有するスレッドは、作動可能待ち行列の先頭に達したとき、イベントがパルス化されていない場合、自らをサスペンドし、状態をＣｏｍｐｌｅｔｅＦｏｒＰｅｒｉｏｄに変化させる。この時点でスラックを再利用することができる。
【０１６７】
３．２．１２ イベントをパルス化する
このサービスの実行により、イベントのリンク・リストからすべてのスレッドが除去されて作動可能待ち行列に移動される（そのリンク・リストがサスペンドされたままであるべき理由が他に存在しない場合）。この時点で、そのイベントを能動的に待っていたスレッドのそれぞれに関して、経過した実行時間が更新される。
【０１６８】
３．３ ＤＥＯＳにおけるスケジュール設定可能性の承認試験アルゴリズム
スケジューリング分析の点で、ＤＥＯＳは、２つのレベル、プロセス・レベルおよびシステム・レベルのどちらかに関して量を定義する。プロセスは、セットのスレッドであり、そのプロセスの中のすべてのスレッドに関する時間区分を定義する。各プロセスは、利用率限度を有し、ブロッキング時間を無視すると、プロセスの中のすべてのアクティブなスレッドが実施可能でなければならない。周期的プロセス（または、等価であるが、非ＩＳＲスレッド）に関して、スレッドの最悪ケースの計算時間は、２回のコンテキスト・スワップ（１回は、開始時に、また１回は、終了時に）を行うのにかかる時間、およびスレッドによってアクセスされる（１回または複数回）すべてのミューテックスを実行するのにかかる時間を含む。
【０１６９】
ブロッキング時間は、システム・レベルで保持される。システム・レベルまでブロッキング時間を引き上げることにより、何らかの全体的最適化を行うことができる。このタイミング最適化により、ハードウェア障害に関するフォールト・トレランスが潜在的に低くなることがもたらされる可能性がある。特に、複数のプロセスによって共用されるモニタを実行している最中に回復可能なタイミング障害またはメモリ障害に遭遇したとき、その誤りが単一のプロセスの中に限定されていると主張することは困難である。すべての障害が、完全に回復不可能である可能性がある。
【０１７０】
このセクションの残りの部分では、まず、ブロッキング時間を無視するプロセスごとのスケジューリング実施可能性試験を説明し、次に、ブロッキング時間を考慮に入れたシステム・レベルの実施可能性試験を説明する。
【０１７１】
３．３．１ プロセス・レベルの実施可能性試験
各プロセスは、セットの制約ベクトルを有し、各ベクトル・セットは、速度ごとに１つのベクトルを含む。記号では、Ｃｐ＝｛（Ｔｐ，ｉ，Ｃｐ，ｉ）｜ｉ＝１．．．ｎ｝であり、ただし、ｎは、ＤＥＯＳによってサポートされる速度の数である。Ｔｐ，ｉ＝Ｔｉは、ＤＥＯＳによってサポートされる第ｉ番の速度の周期であり、またＣｐ，ｉは、プロセスｐの中の集合スレッド予算を指す。より具体的には、プロセスｐが、最悪ケースの計算時間ｃｐ，ｉ，１、ｃｐ，ｉ，２．．．ｃｐ，ｉ，ｎｐ，ｉを有する速度ｉ、ｔｐ，ｉ，１、ｔｐ，ｉ，２．．．ｔｐ，ｉ，ｎｐ，ｉでそれぞれ実行されるスレッドとして有する場合には、
【０１７２】
【数７】
Figure 2004533667
【０１７３】
各プロセスは、最高速度周期であるＳｙｓｔｅｍＴｉｃｋＰｅｒｉｏｄ＝Ｔ１を与えられたＰｒｉｍａｒｙＴｈｒｅａｄを有し、またはＰｒｉｍａｒｙＴｈｒｅａｄは、プロセスの中のどのスレッドも下回らない速度で実行される。１次スレッドは、明示的には宣言されない。１次スレッドが停止されない限り、１次スレッドの計算時間、または等価であるが、１次スレッドの予算は、プロセスの中の他のすべてのアクティブなスレッドによって決定される。また、各プロセスｐは、利用率限度Ｕｐも含む。
【０１７４】
次に、非ＩＳＲスレッドだけに関して実行可能性の分析を考慮する（ブロッキング時間を無視して）。非ＩＳＲスレッドは、定期的にディスパッチされ、周期ごとに正確に１回、実行される周期的スレッドである。ｃｐ，ｉ，ｊをスレッドｔｐ，ｉ，ｊの予算とし、ただし、予算は、２つのｃｓｗａｐ時間、および任意の実行中にｃｐ，ｉ，ｊがアクセスする可能性があるすべてのミューテックスの実行時間を考慮に入れるべきものである。これにより、悲観的な結果がもたらされるが、最悪ケースのコンテキスト・スワップ・オーバーヘッドが考慮に入れられる。
【０１７５】
次に、ｉ＝１．．．ｎに関して、
【０１７６】
【数８】
Figure 2004533667
【０１７７】
ブロッキング時間を無視すると、プロセスｐは、
【０１７８】
【数９】
Figure 2004533667
【０１７９】
である場合、実行可能であると言われる。
【０１８０】
３．３．２ システム・レベル・ブロッキング試験
実施可能性の分析に対する最悪ケースのブロッキング時間の影響を評価するため、なんらかの追加の表記が必要とされる。ｍ個の２進セマフォー、たとえば、最悪ケースの計算時間ｃ１、ｃ２．．．ｃｍをそれぞれ有するＭ１、Ｍ２．．．Ｍｍが存在するものと想定しよう。さらに、セマフォーは、ＤＥＯＳにおいて入れ子にされたセマフォーは許されているものの、入れ子にされていないものと想定する。入れ子にされたセマフォーは、簡単な拡張である。
【０１８１】
τｉをレベルｉのプロセス全体における集合スレッドであるものとする。したがって、τｐ，ｉ，ｊは、各プロセスｐおよび各速度ｉの指標ｊに関するτｉの実行の一部分である。Ｓｉ＝｛Ｍｊ｜τｉが、実行の一部分としてＭｊにアクセスする｝であるものとする。βｉをτｉの実行をブロックすることができるすべてのセマフォーの合併であるものとする。記号では、βｉ＝（∪ｊ＞ｉＳｊ）∩Ｓｉである。βｎ＝Φ（空集合）であることに留意されたい。次に、Ｂｉで表すτｉに関する最悪ケースのブロッキング時間を計算することができる。Ｂｉは、τｉ＋１．．．τｎの任意のものによって実行されることが可能な、またτｉによっても実行されることが可能なすべてのセマフォーの最悪ケースの実行時間である。記号では、Ｂｉ＝ｍａｘ｛ｃｋ｜Ｍｋ∈βｉである。βｎ＝Φ⇒Ｂｎ＝０であることに留意されたい。これは、τｎをブロックするより低い優先順位のジョブが存在しないため、予測されるものである。
【０１８２】
次に、ｉ∈｛１．．．ｎ｝に関して、ＵＢｉ＝Ｂｉ／Ｔｉであるものとする。これは、最悪ケースのレベルｉのブロッキング利用率である。ＵＢ＝ｍａｘ（ＵＢ１．．．ＵＢｎ）であるものとする。次に、Ｃｉをτｉの最悪ケースの実行時間であるものとし、したがって、
【０１８３】
【数１０】
Figure 2004533667
【０１８４】
最後に、システムは、
【０１８５】
【数１１】
Figure 2004533667
【０１８６】
である場合、またはより弱い条件で、
【０１８７】
【数１２】
Figure 2004533667
【０１８８】
である場合、実施可能である。
ゼロではない整相および／または調和的でないタスク・セットが存在する場合、ＲＭＳ実施可能性の試験は、より複雑なものである可能性がある。
【０１８９】
３．３．３ ＩＳＲスレッドに関する実施可能性の分析
ＤＥＯＳにおけるＩＳＲスレッドに関する実施可能性の試験は、さらなる困難な問題を生じさせる。というのは、ＩＳＲスレッドは、厳密に周期的なものとして扱われないからである。すべてのＩＳＲスレッドは、周期および（周期あたりの）予算を有する。ただし、ＩＳＲスレッドは、任意の周期中に無制限に頻繁に出現する可能性があり、また自らの予算を超えていない限り、サービスを受ける。理論上、ＩＳＲスレッドに関して出現間の時間に対する制限は、存在しない（ただし、割込みをラッチする最小限の時間により、最小限の出現間の時間と等価なものが課せられる）。唯一の要件は、ＣＰＵ予算を超えるものが、ある周期中のすべての出現の合計に与えられないことである。たとえば、ＩＳＲスレッドが、４０ミリ秒の周期あたり１０ミリ秒の予算を有し、また各実行が、せいぜい３００μ秒しかかからない場合には、３３≒１０／０．３のＩＳＲスレッドが４０ミリ秒周期中に実行されることが可能である。
【０１９０】
その他の実施形態では、ＩＳＲスレッドは、周期によって暗黙的に定義された優先順位で実行される必要はなく、最高優先順位でも実行されることが可能である。この結果、ＩＳＲスレッドの実行は、より高い優先順位レベルに関するブロッキング時間として、またより低い優先順位レベルにおける先制としてモデル化される。ＩＳＲスレッドが、優先順位Ｐｅで実行され、優先順位Ｐｒにスケジュール設定される（速度を介して）場合には、そのＩＳＲスレッドの実行時間は、Ｐｅ≦Ｐ＜Ｐｒであるように、優先順位Ｐを有するすべてのスレッドに関するブロッキング時間として含まれる。さらに、ＩＳＲスレッドは、通常の実施可能性の分析を使用してスケジュール設定され、より低い優先順位のスレッドに関する先制時間が、正確に取り込まれるようになる。
【０１９１】
αｐ，ｊが、予算ｃｐ，ｊおよび周期Ｔｊを有するＩＳＲスレッドであるとして、αｐ，ｊが、優先順位ｉで実行され、ただし、１≦ｉ≦ｊであるものと想定する。ｃｊは、周期中のすべての実行に関する通常の計算時間に加え、すべてのコンテキスト・スワップ時間およびすべてのクリティカルなセクションの計算時間を含む予算である。たとえば、αｐｊのディスパッチあたりの実行時間が、ミューテックス実行時間を含むが、コンテキスト・スワップ時間は含まないｃｐｕ＿ｔｉｍｅであり、またαｐｊが、継続時間Ｔｊの任意の時間間隔中に最高でｋ回、実行される場合には、ｋ回の実行がＴｊの周期中にサポートされる場合、ｋ（２ｃｓｗａｐ＿ｔｉｍｅ＋ｃｐｕ＿ｔｉｍｅ）≦ｃｊである。
【０１９２】
ＩＳＲスレッドを追加するための実行可能性の承認試験は、周期的スレッドの実行可能性の承認試験とはわずかに異なる。まず、次のとおり、優先順位１．．．ｊ−１に関するブロッキング時間を変更する。Ｂｉ＝ｍａｘ（Ｂｉ，ｃｊ）。優先順位ｊ．．．ｎに関するブロッキング時間は、変更されないままである。言い換えれば、ｉ∈｛ｊ．．．ｎ｝に関してＢｉ＝Ｂ’ｉである。Ｕ’Ｂｉ＝Ｂ’ｉ／ＴｉかつＵ’Ｂ＝ｍａｘ（Ｕ’Ｂ１．．．Ｕ’Ｂｎ）であるものとする。
【０１９３】
次に、ＩＳＲスレッドを含むようにタスクτ１、τ２．．．τｎの定義を拡張すると、スケジュールは、ｉ∈｛１．．．ｎ｝に関して、
【０１９４】
【数１３】
Figure 2004533667
【０１９５】
である場合、実施可能である。
以上は、同じ優先順位の複数のＩＳＲスレッドにも拡張することができ、また同じ優先順位で周期的スレッドとして指定されたＩＳＲスレッドに関しても拡張することができる。
【０１９６】
スラック・スチールを使用して、ＩＳＲスレッドに、ＩＳＲスレッドが望むサービスの優先順位を提供することができる。直感的な理由は、速度によって示されるよりも高い優先順位で実行されるＩＳＲスレッドは、より高速でのブロッキング時間として含まれていることによる。ブロッキング時間の分析は、その速度において十分なスラックが利用可能であり、それらが、さらなるオーバーヘッドをまったく生じさせないはずであることを暗黙的に示す。
【０１９７】
非周期的スレッドは、自らの優先順位が最高になるのを待つ（非周期的スレッドに最高速度が割り当てられていると想定して）のではなく、スラックを消費するのを試みることができる。スラックを使用することの理由は、より迅速な応答時間を得ようと試みることである。十分なスラックが利用可能であり、ＩＳＲスレッド全体が、自らをサスペンドする必要なしに完了まで実行されることが可能であるような場合には、そのＩＳＲスレッドを実行することができる。実行が完了すると、スレッドは、最悪ケースの実行時間（この例では、３００μ秒）をスラックに返して、その他のスレッドが、その時間を消費できるようにするのを望むことが可能である。あるいは、スレッドは、自らの予算の残りの全体を保持して、場合によっては、別の実行をひそかに入れるのを選択することが可能である。スラックは、どちらの目的でも使用することができる。
【０１９８】
３．４ ＤＥＯＳサービスに関する時間請求サービス
このセクションでは、どのようにＤＥＯＳが、被ったオーバーヘッドをタスクに請求するかを説明する。一般に、ＤＥＯＳは、可能な限り多くのオーバーヘッド時間をタスクに割り当てる。この目標の１つの理由は、ＤＥＯＳによって蓄積される請求の可変性を低くすることである。たとえば、スレッドの作成および破壊は、動的プロセスであり、したがって、出現の回数が可変であり、したがって、スレッドの作成および破壊は、ＤＥＯＳにではなく、活動化するスレッドおよび非活動化するスレッドに請求される。原則として、オーバーヘッドを招くスレッドに、時間が請求される。
【０１９９】
オーバーヘッドの１次的で継続的な源は、コンテキスト・スワップ時間である。各タスク実行（各タスク予算ではなく）に、２つのコンテキスト・スワップ時間が請求され、１つは、タスクが開始されたときに生じるものであり、１つは、タスクが完了したときに生じるものである。タスクが先制を受ける場合、どちらの端でもコンテキスト・スワップの請求を受けるのは、先制を行う側のタスクである。ＩＳＲスレッドは、周期あたり多数回、実行されることが可能であり、各実行が請求されることに留意されたい。おそらく、アプリケーション開発者には、計算時間を推定する際、または等価であるが、予算を指定する際、ｃｓｗａｐを実行する時間が提供される。
【０２００】
また、ミューテックスをロックすること、実行すること、およびロック解除することも、オーバーヘッドを導入し、このオーバーヘッドの一部は、ミューテックスの実行時間に請求され、また一部は、要求側の開放するスレッドに請求される。ロック実行時間およびロック解除実行時間は、ミューテックスをロックまたはロック解除しようと試みるスレッドに請求される。ミューテックス実行時間には、開始時および完了時の２つのｃｓｗａｐ時間が請求される。これらの時間は、ミューテックスの最悪ケースの実行時間の一部分として含まれる（予算と実行時間は、ＩＳＲスレッドの場合、同一ではないことに留意されたい）。
【０２０１】
各プロセスに関して、予算を有するＰｒｉｍａｒｙＴｈｒｅａｄが存在する。プロセスは、もはや独自の予算を有さない。ＰｒｉｍａｒｙＴｈｒｅａｄがアクティブである場合、その予算は、プロセスの中のその他のスレッドに割り振られていないすべての利用可能な時間として定義される。ＰｒｉｍａｒｙＴｈｒｅａｄが停止された場合、残りのプロセス予算は、スラックに割り当てられ、ＰｒｉｍａｒｙＴｈｒｅａｄの予算は、ゼロである。あるいは、ＰｒｉｍａｒｙＴｈｒｅａｄの予算は、何らかの中間のものになり、不特定の期間にわたってプロセスの利用率限度Ｕｐが、実質上、下げられることが可能である。
【０２０２】
ＤＥＯＳは、実行時間を監視してタイムアウトを実施する。この監視は、単にタイマを最悪ケースの実行時間に設定することによって行うことができ、タイマが満了した場合には、タイミング障害が生じており、ＤＥＯＳ（違反をするスレッドまたはモニタではなく）が、障害ハンドラを実行する。さらなるオーバーランをもたらす割込みに応答する時間が存在し、時間障害ハンドラの実行は、それをプロセスのＰｒｉｍａｒｙＴｈｒｅａｄに請求することを介して、ＤＥＯＳに請求される。プロセスのＰｒｉｍａｒｙＴｈｒｅａｄがゼロの予算を有する場合、これにより、問題が生じるが、その予算の中で障害処理機能を確保しておくことが可能である。
【０２０３】
すべてのミューテックスは、モニタ・プロセスを有する。モニタ・プロセスは、関連する何らかの時間割振りを有する。ミューテックスがロックされたとき、ロッキング時間が、モニタ・プロセス時間から引かれる。
【０２０４】
３．５ スラック・スチール範囲
利用可能なスラックを保持することができる２つの論理レベルが存在する。すなわち、システム・レベル、およびプロセス・レベルのそれぞれにおいてである。一部のスラックをシステム・レベルで保持し、また一部をプロセス・レベルで保持する可能性は、考慮しない。システム・レベル対プロセス・レベルのスラック・スケジューリングに関連するいくつかのトレードオフが存在する。一実施形態によれば、システム・レベルのスラック・スケジューリングがサポートされ、したがって、システム・レベルのスラックの可用性の利点から始める。次に、いくつかの潜在的な欠点をリストする。システム・レベルのスラックの利点をプロセス・レベルのスラックの欠点に変形することは、困難でなく、また同様に、システム・レベルのスラックの欠点をプロセス・レベルのスラックの利点に変形することも困難でない。
【０２０５】
システム・レベルのスラックのいつくかの利点を以下に提示する。
・スラックの共用が、プロセス間で行われることが可能であり、単一のプロセスに限定されない。再利用されるスラックと時間線スラックがともに、プロセス間で共用されることが可能であり、帯域幅を強く必要としているスレッドが、ＤＥＯＳシステムにおけるすべての利用可能なスラックを使用することが可能になる。
【０２０６】
・実装コードが縮減される可能性が高い。指定すべき単一のセットのスラック変数だけが存在する。具体的には、単一の時間線スラック・ベクトル、ならびに単一のセットのアイドル時間累算器および活動時間累算器が存在する。これにより、いくらかの量の空間が節約されるが、スラック変数がパラメータとして渡されない限り（これは、ランタイム・オーバーヘッドを招く）、スラック更新動作に関する複製コードも節約される。
【０２０７】
システム・レベルのスラックのいくつかの欠点を以下に提示する。欠点のほとんどは、潜在的と分類することができ、欠点の潜在性、または潜在性の欠如は、詳細なアルゴリズムが生成される際により明確になる。ＤＥＯＳが特に回避するいくつかの欠点は、他の実施形態において関心の対象となる可能性がある。
【０２０８】
・潜在的に、システム・レベル・スラックの更新を必要とする動作を実行する方が、プロセス・レベル・スラックの更新を必要とする動作を実行するより長い時間がかかる。これは、システム・レベルの集合スレッドが、プロセス・レベルの集合スレッドよりはるかに多くの構成要素スレッドを含む傾向にあることから、そうなる。スレッド完了更新が、増分式に行われる場合（集合の完了時に単一回の更新を伴う）には、このことは、関係がない可能性がある。
【０２０９】
・プロセス間の確認がより困難である可能性がある。これは、大体においてＤＥＯＳの観察能力に依存し、問題ではない可能性がある。
・潜在的に、障害が区分内にそれほど限定されない可能性がある。障害条件の下で、システム・レベルのスラック変数により、誤りの伝播がもたらされる可能性がある。すべての可能なハードウェア障害、ならびに可能な誤り検出および誤り回復のための機構およびその効果のセットの分析が、システム・レベルのスラック変数が、回復可能な、またそれ以外の形で限定可能なプロセスの誤りをもたらすのが可能であるかどうかを決定するのに必要とされる。ブロッキング時間に関してセクション３．３．２も参照されたい。
【０２１０】
３．６ スラック・スケジューリングに関するその他の考慮
このセクションは、スラック・スケジューリングをサポートするその他の考慮すべき事項をリストする。特に、スラック変数の値に影響を与える可能性が高いいくつかのＤＥＯＳサービス（前述していない）をリストする。
【０２１１】
（１）システム始動／再スタートを任意の時点で行うことができる。
システム始動に関して、何らかの同期および初期設定が、ＤＥＯＳにおいて行われる。時間線スラック変数は、プロセスのＰｒｉｍａｒｙＴｈｒｅａｄに割り当てられるプロセスの利用率の予算に基づいて初期設定される。スラック活動およびスラック・アイドル累算器が、ゼロに初期設定される。システム始動時におけるスラック初期設定に関するアルゴリズムが、「動的スレッドを有するＤＥＯＳにおけるスラック・スケジューリング」と題したセクション４で定義されている。
【０２１２】
一時的電源の遮断に応答するシステム再スタートに関して、「クロック」が、最新で記録された最高速度周期の開始時に再開されることが可能である。たとえば、最高速度周期がＴ１である場合には、ｋＴ１と（ｋ＋１）Ｔ１の間の何らかの時点で、電力障害が検出された場合、再スタートの時刻は、ｋＴ１であると「宣言」される。
【０２１３】
考慮しなければならない、各スラック・レベルに関して１つの、３つのスラック変数が存在する。
次に、集合スレッドが完了したときにはいつでも更新されるレベルｉの活動（ＡｐｅｒｉｏｄｉｃＴｉｍｅｉ）変数およびレベルｉの非活動（Ｉｄｌｅｉ）変数が存在する。
【０２１４】
（２）プロセス再スタートを任意の時点で行うことができる。技術上、これは、スレッド開始およびスレッド停止の下でカバーされるが、プロセス再スタートは、しばしば、異常な状況に対する応答として考えられているので、ここで繰り返す価値がある。プロセス再スタートが実行され、ＰｒｉｍａｒｙＴｈｒｅａｄがアクティブである場合には、プロセスの中の他のすべてのスレッドが停止／強制終了され、それらのスレッドの予算が、ＰｒｉｍａｒｙＴｈｒｅａｄに戻る。ＰｒｉｍａｒｙＴｈｒｅａｄが停止されたとき、それが開始される。両方の場合で、時間線スラック変数が、強制終了／停止されたスレッドに関して低減され、ＰｒｉｍａｒｙＴｈｒｅａｄに関して増加される。
【０２１５】
（３）プロセスの作成および破壊を任意の時点で行うことができる。スラック計算に関して、最初、あたかも新しいプロセスのＰｒｉｍａｒｙＴｈｒｅａｄが、唯一のアクティブなスレッドであるかのように思われ、したがって、これは、スラック変数を調整することに関して、開始スレッド呼び出しであるように見える。ただし、ある種のシステム実施可能性の試験も呼び出される必要がある。というのは、新たに作成されたプロセスは、システムが実施不可能であることをもたらす利用率限度を有することができないからである。
【０２１６】
セクション４−動的スレッドを有するＤＥＯＳにおけるスラック・スケジューリング
本発明は、たとえば、航空機または宇宙船などの飛行システムを制御するのに用途を有する実行の動的スレッドを使用するリアルタイム・オペレーティング・システム（ＲＴＯＳ）におけるスラック・スケジューリング実施形態に関する。一実施形態では、本発明は、ミネソタ州、ミネアポリスのＨｏｎｅｙｗｅｌｌ，Ｉｎｃ．によって開発された飛行制御システムで使用される、デジタルエンジニアリング・オペレーション・システム（ＤＥＯＳ）として知られるリアルタイム・オペレーティング・システムの一環を成す。ただし、本発明は、ＤＥＯＳにおける、またはＲＴＯＳにおける実施に限定されず、任意のタイプのデータ処理システムにおいて利用することができる。ただし、本発明は、産業用、住宅用、商用、軍用、またはその他のタイプの制御システムなどのリアルタイム制御システムにおいて特に実用性を有する。
【０２１７】
リアルタイム制御システムは、固定セットのタスクに対立するものとして、動的スレッドを含む場合、堅固なスラック・スチール能力を実装するのにより一般的で、より複雑なセットのアルゴリズムを必要とする。この説明は、動的スレッドを有するＲＴＯＳにおいてスラック・スケジューリングを実施するための相当に詳細な擬似コード・アルゴリズムを提供する。これらのアルゴリズムを最適化しようとする試みは、まったく行っていない。というのは、最適化がかなりシステムに依存しているからである。
【０２１８】
セクション４は、以下のとおり編成されている。
セクション４．１が、ＤＥＯＳにおける「アクティブなタスク・セット」と従来のＲＭＳシステムにおける「アクティブなタスク・セット」の間の想定の違いからもたらされるスラック計算に対する影響を説明する。動的な性質のため、「将来の」アイドル時間の可用性に関する想定が、実質的に消え去り、スラックの可用性の更新が、すべてのスラック・レベルにおいて（具体的には、システムの任意の１次スレッドの最高速度において）はるかに頻繁になる。
【０２１９】
セクション４．２が、動的スレッド、ならびにプロセスの活動化および非活動化のコンテキストで「時間線スラック」を説明し、またどのように「時間線スラック」を計算するかを説明する。スレッドを保持し、記録にとり、更新し、また動的スレッドを有するリアルタイム・オペレーティング・システムにおける時間区分化のために使用される予算を処理し、また（非）活動化を処理するアルゴリズムが、利用可能な（動的）時間線スラックに関する正確な値を計算する際に使用するクリティカルな量を定義する。
【０２２０】
セクション４．３が、スラック累算器を使用して、再利用されるスラックの可用性、およびすべてのスラック消費を記録にとるためのアルゴリズムを提供する。先に述べたとおり、再利用されるスラックは、周期に関して早期に完了することによって最悪ケースの予算から任意の時点で「引き渡される」。
【０２２１】
セクション４．４が、スラックの割振りに関する２つの異なる手法を説明する。違いは、より高い速度のスラック・コンシューマが後に存在するようになったとき、低い速度のスラック・コンシューマのためのスラックの可用性の計算を延期することにある。
【０２２２】
便宜のため、テーブル８で表記の大きいテーブルが見られる。テーブル８の表記の多くは、コンテキストの中で前に定義した。
セクション４．１ ＤＥＯＳスケジューリングの想定
以下のＤＥＯＳの４つのプロパティにより、周知のスラック・スチールが変更されることが必要とされる。
【０２２３】
１．動的スレッドの活動化および非活動化からもたらされる動的「周期時間線」スラック（すなわち、「時間線スラック」が、スラック・スチールをサポートする周知のシステムにおけるのとは異なり、動的に変化し、またＤＥＯＳの「時間線」スラックの源が、非アクティブな１次スレッドの予算、割り振られていないシステム・レベルのスラック、および、場合により、ほとんど即時にＣｏｍｐｌｅｔｅＦｏｒＰｅｒｉｏｄになるアプリケーション・スレッドから再利用されるスラックだけである）。
【０２２４】
２．集合スレッド、または等価であるが、明示的に禁止された互いの優先順位の順序付けを有する同じ速度で実行される多数のスレッド（これは、未使用の最悪ケースの実行時間からスラックを再利用するための時刻の選択をもたらす）。
【０２２５】
３．プロセス間におけるスラックの共用、およびプロセスの中のスレッド間における予算の共用（待ち状態のユーザ・スレッドの活動化および非活動化がエグジットを要求したときの１次スレッドの活動化および非活動化が、スラック再利用率値を変更する必要があることを意味する）、ならびに、最後に、
４．プロセッサ／プロセス／スレッド再スタートからの回復、一時的障害、およびスラック・スチールをサポートしている間の時間同期に関するフォールト・トレランス。
【０２２６】
このセクション４で使用するシステム・レベルの表記の一部は、テーブル７（周期的スレッド表記）（付録Ａ）で見られる。テーブル８（スラック・スケジューリング表記）（付録Ａ）は、より頻繁に使用される表記のリストを含む。
【０２２７】
スレッドが静的であるか、または動的であるかを絶え間なく特定しなくても済むように、動的スレッドを作成すること、および静的スレッドを開始することに関して「スレッド活動化」と呼ぶ。同様に、「スレッド非活動化」を使用して、動的スレッドを強制終了すること、または静的スレッドを停止することを意味する。作成／開始および強制終了／停止の使用は、スレッド・タイプ（動的／静的）のコンテキストから明白なはずである。この同一の用語法をプロセスならびにスレッドに適用する。
【０２２８】
スラック・スケジューリングに関連する基本的に４つのクラスのアルゴリズムが存在する。
１．スラック変数の初期設定ルーチンおよびハイパー周期のリセット・ルーチンが、スラック変数を初期設定し、周期的にリセットする。これらのルーチンは、セクション４．２．２および４．２．３で説明している。スレッドの動的な割振りを許す場合、周期リセットは、静的スレッドだけが存在する場合よりも複雑である。
【０２２９】
２．ユーザ・スレッド（非）活動化またはユーザ・プロセス（非）活動化の要求が行われたとき、１次スレッドの予算の中で請求された量を記録して、その量を適切な周期リセット時に周期時間線の再計算に含めることができるようにする（１次スレッドが非アクティブであるとき）必要がある。この計算は、セクション４．２．４〜４．４．６で説明する。
【０２３０】
３．スラック変数累算器の更新ルーチンが、セクション４．３でリストするいくつかのイベントのどれかに応答して実行される。このカテゴリの中のスラック変数は、再利用されるスラック、消費されるアイドル時間、および消費されるスラック時間を記録にとる。
【０２３１】
４．スラックの可用性の計算を、スレッドが（暗黙的に）スラックを要求したときにはいつでも行わなければならない。このアルゴリズムは、セクション４．４で提示している。スラックの可用性を計算するためのアルゴリズムは、選択されたポリシーに応じて、相異なるセットのスラック累算器の値に基づく可能性がある。
【０２３２】
セクション４．２ 動的な時間線スラック
さしあたり、ブロッキング時間のために確保された瞬間システム利用率を無視すると、すべての静的な時間線スラックは、ＤＥＯＳにおいてゼロであると想定される。というのは、スレッドおよび／またはプロセスが活動化されて、場合により、１００％のシステム利用率がもたらされることが可能だからである。したがって、将来の時間線スラックの可用性に関してまったく想定を行わず、１次スレッドの速度で小さな増分で、動的な（周期）時間線スラックをスラックが利用可能になるにつれて分配する。
【０２３３】
プロセッサが、１００％からそれほど離れていない（また、ときとして、１００％を超える）最悪ケースの利用率を有することも珍しくなく、したがって、実際には、再利用されるスラックだけの想定が適用可能である。現在、ＤＥＯＳの推定される最悪ケースの利用率は、およそ８８％である。また、ＤＥＯＳは、スレッドおよびプロセスに関する次の周期で有効なランダムに出現する活動化要求および非活動化要求をサポートするスラック・モデルも認める。ＤＥＯＳは、実質上、タスクを計時する設計をサポートせず、増分式タスクをサポートすることにあまり効果的でない（ただし、必ずしも無効ではない）。というのは、より高い速度のスレッドによってもたらされる利用可能なスラックが、先見的には、より低い速度のスレッドに利用可能ではない（少なくとも先見的な１つの短い周期では、利用可能でない）からである。
【０２３４】
周期時間線スラックの少なくとも２つの源は、（ｉ）プロセスに割り振られていないシステム時間、および（ｉｉ）非アクティブであると宣言されたときの１次スレッドの予算（すなわち、Ｚにおけるζｋの合計）である。一実施形態では、これら２つの源は、レベル１で生じ、時刻ｊＴ１、ｊ∈｛０，１，２．．．｝で供与される。以上の定義は、Ｔ１より遅い速度の１次スレッドを有するプロセスに容易に拡張される。この詳細の多くは、本明細書で提示するアルゴリズムに含まれる。
【０２３５】
可能な第３の源は、ほぼ即時に、たとえば、リソースをポーリングするが獲得しないときＣｏｍｐｌｅｔｅＦｏｒＰｅｒｉｏｄになるＩＳＲスレッドおよび周期的スレッドであることが可能である。どれだけすぐにスレッドが周期に関して完了するかを知る手立ては存在しないので、各周期の開始時にユーザ・スレッド・スラックを再利用しようとする特別な試行が行われない場合、実施がより簡単になる可能性が高い。ハイパー周期時間線スラックが、元のモデルにおけるハイパー周期を介してだけ存続するのとまったく同様に、周期時間線スラックは、そのスラックが次の周期だけに割り振れたレベルにおいて存続することが保証される。ただし、ある条件下では、周期時間線スラックを繰り越すのが可能であることが分かる。
【０２３６】
周期時間線スラックの概念は、大体において概念モデルであり、スラック再利用機構を介して実施することができることに留意されたい。周期中、早期にそれを明示的に再利用することにより、スラック再利用機構は、特にＴＣＰ／ＩＰ要求などの高速非周期的割込みスラック要求に関して、スラック・スチーラが迅速にアプリケーションに応答できるようにするのを助ける。また、スラック再利用機構は、異なるアプリケーション間の「公平性」設計に関する試験と分析の両方を容易にすることができる、周期時間線スラックの可用性をより容易に測定するための明示的なハンドルも提供する。
【０２３７】
いくつかのデータ構造を使用して、現在の利用率と将来の利用率（認可された活動化／非活動化要求を待っている）を記録にとる。テーブル９（プロセス・レコード属性−予算更新ベクトル）（付録Ａ）が、各プロセスに関して保持される予算更新ベクトルを説明している。予算更新ベクトルは、各プロセスの将来の（予測される）ＵｓｅｒＢｕｄｇｅｔを記録にとる。時間線遅延の更新の実際の値は、スレッドの（非）活動化が有効になる時刻まで延期される（ΔＴｉｍｅｌｉｎｅＳｌａｃｋを使用することにより）。
【０２３８】
元に提案したのと同様な表記を採用すると、ＴｉｍｅｌｉｎｅＳｌａｃｋｉ＝ＴｉｍｅｌｉｎｅＳｌａｃｋｉ（ｔ）を使用して、Ｔｉで定義される最後の周期の開始以来、レベルｉのスラック要求側（だけ）に利用可能であった周期時間線スラックの量を表す。ＴｉｍｅｌｉｎｅＳｌａｃｋｉの値は、ハイパー周期の開始以来、累積的ではなく、速度ｉでもたらされたスラックだけに当てはまり、このどちらも、元の定義から離れていることに留意するのが重要である。以上の定義をテーブル８で要約している。
【０２３９】
さらに、システムは、利用率変化ベクトル、ΔＵｓｙｓ、およびシステム利用率値、Ｕｓｙｓを保持する。これらの量をテーブル９（プロセス・レコード属性−予算更新ベクトル）の一番下で示している。プロセスのＵｓｅｒＢｕｄｇｅｔと同様に、Ｕｓｙｓの値は、さらなるプロセスがまったく（非）活動化されず、すべての現在、待ち状態にある要求が行われることが許される場合、システム利用率である。プロセスに割り振られた現在のシステム利用率は、ΔＵｓｙｓ（ｉ）の中に記憶されたレベルｉにおける利用率の起ころうとしている変化から構成することができる。この構成は、以下で述べる実施可能性の試験のために重要である。
【０２４０】
一実施形態では、ｉ∈｛２．．．ｎ｝に関して、ＴｉｍｅｌｉｎｅＳｌａｃｋｉ＝０であることになる。というのは、すべての１次スレッドが、速度１を有するからである。同様にΔＵｓｙｓは単一の値である。というのは、すべての１次スレッドが同じ値を有するからである。その他の実施形態では、異なる速度で宣言された１次スレッドを有する、異なるプロセスに関して備えが必要とされる可能性がある。本明細書で提示するアルゴリズムは、これをサポートする。また、一部の実施形態も、アプリケーション間でスラックを分割するためのサポートを必要とする可能性がある（場合により、より優れた公平性の保証のため）。これにより、スラック・データ構造の多くにプロセス指標を導入することが必要となる。
【０２４１】
ＴｉｍｅｌｉｎｅＳｌａｃｋｉの値の更新をもたらすことが可能なアルゴリズムは、ユーザ・スレッド（非）活動化の要求（アルゴリズム１０）、１次スレッド（非）活動化の要求（アルゴリズム９）、およびプロセス（非）活動化の要求（アルゴリズム１１）である。以上のアルゴリズムのそれぞれの説明を以降のセクションで行う。
【０２４２】
すべてのタスクが調和的である場合、周期時間線スラック・テーブルおよび集合計算時間情報を保持するのに必要とされる実際的なストーレッジは、Ｏ（ｎ２）である。具体的には、（ｎｉ｜ｊ）マトリックス、ならびにｊ≧ｉで、周期ＴｊとＴｉの開始が次に一致するとき、レベルｉで時間線スラックに生じる変化を記録するマトリックス（ΔＴｉｍｅｌｉｎｅＳｌａｃｋｉ，ｊ）を記憶するのに、Ｏ（ｎ２）のストーレッジが必要とされる。いくつかの追加のｎベクトルが使用される。各プロセスは、プロセスごとのＯ（ｎ）データ構造である各予算速度の起ころうとしている変化を記録にとらなければならない。これをテーブル９で示している。一実施形態では、ΔＴｉｍｅｌｉｎｅＳｌａｃｋは、ｎベクトルとして表すことができる。というのは、すべてのプロセスの１次スレッドが、周期Ｔ１を有するからである。
【０２４３】
適切な周期境界まで時間線スラックの更新を延期して、現在、実行されているスレッドが完了するのに予算が利用可能であること（非活動化の場合）、およびあまりにも早期から過剰な予算が供与されないこと（将来の活動化の場合）を確実にして、既存のスレッド（「同時に」非活動化されて、その他のスレッドを活動化できるようにすることが可能な）を危険にさらさないようにすることが必要である。
【０２４４】
図１２は、動的スレッド活動化に関する概念モデルを示すタスク実行時間線である。図１２は、時間区分化を使用するシステムにおける理論化された時間スケジューリング・モデルを表している。図１２で、非周期的タスクからのスラック要求は存在しない。
【０２４５】
初期構成では、５ミリ秒の予算および非アクティブな１次スレッドをそれぞれが有する２つの区分Ｐ１およびＰ２が存在する。区分Ｐ１は、図１２で低いブロックによって描かれ、また区分Ｐ２は、中くらいのブロックで描かれている。各区分は、２つの速度Ｒ１およびＲ２を有する。速度Ｒ１は、斜影線で表し、速度Ｒ２は、点描で表している。速度Ｒ１は、周期＝１０ミリ秒を有し、速度Ｒ２は、周期＝２０ミリ秒を有する。１次スレッドは、最高速度で実行され、このことは、ＤＥＯＳ実施形態では常に真である。
【０２４６】
図１２で、各スレッドが、「Ｐ」が区分ｉｄであり、「Ｒ」が速度ｉｄであり、また「Ｔ」がスレッドｉｄであるｔ（Ｐ，Ｒ，Ｔ）の形式のデータ構造で特定される。
【０２４７】
区分Ｐ１のスレッド１に関する最悪ケースの実行時間は、Ｃ（Ｐ１，Ｒ１，Ｔ１）＝１ミリ秒である。区分Ｐ１のスレッド２に関する最悪ケースの実行時間は、Ｃ（Ｐ１，Ｒ２，Ｔ２）＝２ミリ秒である。
【０２４８】
区分Ｐ２のスレッド１に関する最悪ケースの実行時間は、Ｃ（Ｐ２，Ｒ１，Ｔ１）＝１ミリ秒である。区分Ｐ２のスレッド２に関する最悪ケースの実行時間は、Ｃ（Ｐ２，Ｒ２，Ｔ２）＝２ミリ秒である。
【０２４９】
時刻ｔ＝２で、Ｒ１スレッドが、区分Ｐ１の中で活動化される（スレッド３）。区分Ｐ１のスレッド３は、ｔ＝１０ミリ秒で、すなわち、次の周期で有効であり、非活動化される（図示せず）までアクティブなままである。区分Ｐ１のスレッド３に関する最悪ケースの実行時間は、Ｃ（Ｐ１，Ｒ１，Ｔ３）＝１ミリ秒である。したがって、区分Ｐ１のスレッド３には、スケジューラによって毎１０ミリ秒に１ミリ秒が割り振られる。図１２の単一の下向き矢印は、Ｐ１のスレッド３が実行される時刻を示す。
【０２５０】
時刻ｔ＝６で、Ｒ２のスレッドが、区分Ｐ２の中で活動化される（スレッド３）。区分Ｐ２のスレッド３は、ｔ＝２０ミリ秒で、すなわち、次の周期で有効であり、非活動化される（図示せず）までアクティブなままである。区分Ｐ１のスレッド３に関する最悪ケースの実行時間は、Ｃ（Ｐ２，Ｒ２，Ｔ３）＝２ミリ秒である。したがって、区分Ｐ２のスレッド３には、スケジューラによって毎２０ミリ秒に２ミリ秒が割り振られる。図１２の２重の下向き矢印は、区分Ｐ２のスレッド３が実行される時刻を示す。
【０２５１】
時間線スラック（Ａ）が図１２で、時刻４と１０の間のＡ＝６、時刻１５と２０の間のＡ＝５、時刻２６と３０の間のＡ＝４、および時刻３６と４０の間のＡ＝４で示されるとおり利用可能である。
【０２５２】
ただし、図１２では、再利用されるスラックは利用可能ではない。というのは、各スレッドに最悪ケースの実行時間がかかっているからである。
図１３は、スラック要求を有さない観察されたスレッド活動化を示すタスク実行時間線である。図１３は、非周期的タスクからのスラック要求を有さない実際の時間線を表している。スレッドは、区分の時間予算が切れていない限り、速度による優先順位で実行される。図１２では、タスクが、ハイパー周期全体で一様に構成に分散されているが、図１３では、作動可能である最高優先順位のタスクが最初に実行されることで、図１３の実際の時間線は、図１２の概念モデルとは異なることが観察されよう。図１２の時間線スラックの概念モデルは、将来に関する想定を行うことができず、したがって、タスクが、ハイパー周期全体に一様に分散されていると想定しなければならない。しかし、タスクは、作動可能であるとき実行され、したがって、図１３の観察される時間線は、図１２の時間線スラックの概念モデルとは異なる。
【０２５３】
図１２とまったく同様に、区分Ｐ１のスレッド３が、時刻ｔ＝２で活動化され、時刻ｔ＝１０で有効になる。同様に、区分Ｐ２のスレッド３が、時刻ｔ＝６で活動化され、時刻ｔ＝２０で有効になる。
【０２５４】
図１３の単一の下向き矢印は、区分Ｐ１のスレッド３が実行される時刻を示す。スレッド（１，２，２）が、図１３では２つの連続するタイム・ユニット（すなわち、時刻２と４の間、および時刻２３と２５の間）で実行されるが、図１２では、このスレッドが、４つの別個の１ユニット間隔で実行されることが観察されよう。
【０２５５】
図１３の２重の下向き矢印は、区分Ｐ２のスレッド３が実行される時刻を示す。スレッド（２，２，２）が、図１３では２つの連続するタイム・ユニット（すなわち、時刻４と６の間、および時刻２５と２７の間）で実行されるが、図１２では、このスレッドが、２つの別個の２ユニット間隔で実行されることが観察されよう。
【０２５６】
また、スレッド（２，２，３）が、図１３では２つの連続するタイム・ユニット（すなわち、時刻２７と２９の間）で実行されるが、図１２では、このスレッドが、２つの別個の１ユニット間隔で実行される。
【０２５７】
利用可能なスラックＡの量および未使用のスラックＵの量は、時間線の上に示している。
図１４は、本発明の実施形態によるスラック要求を有するスレッド活動化を示すタスク実行時間線である。非周期的スラック要求が、図１４でボックス６１〜６５によって描かれている。
【０２５８】
図１２および１３とまったく同様に、区分Ｐ１のスレッド３が、時刻ｔ＝２で活動化され、時刻ｔ＝１０で有効になる。同様に、区分Ｐ２のスレッド３が、時刻ｔ＝６で活動化され、時刻ｔ＝２０で有効になる。
【０２５９】
さらに、図１４では、非周期的タスクの以下のスラック要求にサービスが提供される。
・表現ＳＡ（５，１）で表される、時刻ｔ＝５における優先順位１の２ミリ秒の時間のスラック要求６１
・表現ＳＡ（１２，１）で表される、時刻ｔ＝１２における優先順位１の６ミリ秒の時間のスラック要求６２
・表現ＳＡ（２１，２）で表される、時刻ｔ＝２１における優先順位２の（ｔ＝２３で開始する）４ミリ秒の時間のスラック要求６３
・表現ＳＡ（３２，１）で表される、時刻ｔ＝３２における優先順位１の３ミリ秒の時間のスラック要求６４
・表現ＳＡ（３７．５，２）で表される、時刻ｔ＝３７．５における優先順位２の２．５ミリ秒の時間のスラック要求６５
また、非周期的ボックスの中には、利用可能なスラック、未使用のスラック、再利用されるスラック、および要求されたスラックに関する情報も含まれる。
【０２６０】
４．２．１ ＤＥＯＳにおける時間区分化の保存
時間区分化は、時間障害管理を提供する際に重要である。１つの区分Ｐ１の中のどのスレッドも、別の区分Ｐ２の中で時間障害を生じさせることができない。むしろ、時間障害は、Ｐ１の中に限定される。
【０２６１】
また、時間区分化は、認定の時間とコストを削減することも提供する。区分は、「クリティカリティ」によって分類される。極めてクリティカルな区分は、認定するのにより高いコストがかかる。時間区分化を使用すると、より低いクリティカリティの区分の中のタスクへの変化が、より高いクリティカリティの区分の再認定を必要としない。
【０２６２】
ＤＥＯＳにおいて、行われることが可能な２つのタイプの「予算」共用が存在する。スラックを介する予算共用は、どのような形でも時間区分化に違反しないことを理解することが重要である。
【０２６３】
第１に、１次スレッドがアクティブである（レベルｈで）とき、新たに活動化されるスレッド（たとえば、レベルｉ≧ｈで）に関する予算が、１次スレッドの予算から来なければならず、また最近、非活動化されたスレッドに関する予算が、１次スレッドの予算に戻されるという意味で、予算がプロセスの中で共用される。プロセスＰの１次スレッドがアクティブであるとき、Ｐに関するシステム・スラックは、自らの最悪ケースの実行時間より少ない時間を消費して周期に関して完了するユーザ・スレッドからだけ来る。したがって、スラックは、スレッド活動化のためには決して使用されない。というのは、スラックの存続時間は、スラックが再利用された周期に限られているからである。
【０２６４】
第２に、１次スレッドが非アクティブであるとき、そのプロセスに関してユーザ・スレッドに割り振られていないどの余剰予算も、基本的に、共通のシステム・レベル・スラック・プールに割り振られる（一実施形態において）。余剰予算は、毎周期Ｔｈ、割り振られ、ここで、Ｔｈは、プロセスの中で宣言された最高速度のスレッドの周期である（一実施形態の場合、すべてのプロセスに関してＴｈ＝Ｔ１である）。また、１次スレッドも、速度Ｔｈを有する。これは、ユーザ・スレッドから入手可能なスラックに加えてのスラックである。１次スレッドが非アクティブのときでさえ、プロセスは、適時に（ユーザまたは１次）スレッドを活動化または非活動化するために再利用することができる利用率（システム・レベル・スラックの中で保持される）の残りにアクセスを有することが分かる。
【０２６５】
第３に、システム・レベルで再利用されるスラックのプールが、最初、時間区分化が保存されるかどうかに関する疑問を生じさせる可能性がある。（ｉ）プロセスの利用率が、そのプロセスに属するスレッド活動化の実施可能性を決定するのに、やはり使用されるとき、および（ｉｉ）スラックがスレッド活動化によって消費される可能性がある次の周期を超えて、スラックが事前に割り振られないとき、時間区分化が保存されるのを理解するのは、難しくない。
【０２６６】
ハードウェア・タイミング障害が存在しない場合、すべてのアクティブなプロセス間の時間区分化が保存されるのを理解するのは、難しくない。具体的には、スレッドｔを活動化してプロセスＰに入れる許可の決定は、Ｐの１次予算の可用性だけに基づく。Ｐの１次予算がアクティブであるか、または非アクティブであるかに関わらず、同一の実施可能性の試験が、ユーザ・スレッドに関して使用される。プロセスの１次スレッドを活動化／非活動化する要求は、１次スレッドに（から）割り振られる（割振り解除される）予算の量がＰの中のアクティブなスレッドに既に割り振られていない残りのすべての予算であることを除き、この場合も、同一の実施可能性の試験に基づく。
【０２６７】
したがって、プロセスＰの中のスレッドｔは、１次スレッドがアクティブであるか、または非アクティブであるかに関わらず、Ｐの１次スレッドの中に十分な予算が存在するのでない限り、活動化することができない。明らかに、Ｐの１次スレッドがアクティブであるとき、Ｐの「活動化予算」はまったくシステム・スラック・プールに割り振られず、したがって、ｔの活動化は、実施可能性の条件だけに制約され、時間区分化に違反しない。
【０２６８】
次に、Ｐの１次スレッドが非アクティブであり、またｔが、時刻ｓにレベルｊの活動化を要求するものと想定する。また、ｔの活動化の要求も、実施可能であると見なされているものと想定する。Ｐの１次スレッドの速度は、ｈであり、ｈ≦ｊである。時刻（γｊ（ｓ）＋１）Ｔｊで、ＴｉｍｅｌｉｎｅＳｌａｃｋｈが、δｊ／ｎｊ｜ｈだけ低減され、また時刻ｓで開始して供与されるその量のスラックが、すべてのレベルｋ∈｛ｈ．．．ｎ｝のスラック・コンシューマに対して低減されることを示さなければならない。これは、δｊ／ｎｊ｜ｈの量だけのΔＴｉｍｅｌｉｎｅＳｌａｃｋｈ，ｊの減分からそうなり、したがって、時刻ｓで始まってＴｉｍｅｌｉｎｅＳｌａｃｋｈは、ΔＴｉｍｅｌｉｎｅＳｌａｃｋｈ，ｊだ低減される。
【０２６９】
簡単な計算により、Ｔｋ、ｋ∈｛ｈ．．．ｊ｝で定義される任意の周期中の周期再利用スラックの量が、（γｊ（ｓ）＋１）Ｔｊ以降に開始して、（ｎｋ｜ｈ＼δｊ）／ｎｊ｜ｈだけ低減されることが示される。スラックの可用性の低減は、Ｔｈの周期の開始時にδｊ／ｎｊ｜ｈの量だけ行われることに留意されたい。この低減は、各周期レベルに関して一斉に行われるのではない。したがって、スラック・スケジューリングを使用する際、ＤＥＯＳにおいて時間区分化が保存される。
【０２７０】
次に、ＤＥＯＳ「システム」を予算を有するプロセスと見なし、また各プロセスをスレッドと見なすことができる。新しいプロセスに関する実施可能性が、システム・レベルにおける割り振られていない帯域幅の量に基づき、またプロセスの予算を新しいスレッドに移動するのに使用したのと同じ予算移動機構が、新しいプロセスにシステム予算を移動するのに使用される。まったく同様の議論を使用して、プロセスの作成／削除が存在する場合にも時間区分化が保存されるのを示すことができる。
【０２７１】
タスク区分とは独立にすべてのタスクに関する共通の「スラック・プール」を提供することにより、本発明は、スラック・スチールと時間区分化の両方の相当な利点を実現する。
【０２７２】
たとえば、本発明により、デバッグ、監視、ネットワーキング等のそうでなければ実施不可能なクリティカルでない機能の実行が可能になり、かつ／または表示速度を高めることなどの重要なタスクの強化が可能になる。
【０２７３】
さらに、本発明は、より堅固な時間障害管理をサポートする。１つの区分内の時間障害は、スラックが別の時間区分から再利用されている場合、回復可能である可能性がある。
【０２７４】
図１５は、スラック・スチールを伴わないタスク実行を示すタスク実行時間線である。区分Ｐ１およびＰ２が、クリティカルなものとして定義される。区分Ｐ３は、重要ではない。Ｐ１は、１０ミリ秒の時間を使用し、Ｐ２は、１０ミリ秒の時間を使用し、またＰ３は、最小で５ミリ秒を使用し、最大で２０ミリ秒を使用する。ハイパー周期は、３０ミリ秒である。５ミリ秒の時間が、割り振られていない時間線スラックであり、タスク区分とは独立に、すべてのタスクによって使用されるための共通のスラック・プールの使用がない場合、何らかの背景タスクによってだけ使用されることが可能である。図１５は、プールされたスラックのスチールなしでは、背景タスクだけが利用されていないスラックを共用することができることを示している。
【０２７５】
図１６は、再利用されるスラックと時間線スラックをともに使用するタスク実行を示すタスク実行時間線である。図１６では、タスク区分とは独立に、すべてのタスクによって使用されるために共通のスラック・プールが提供されるものと想定している。区分Ｐ１ないしＰ３は、図１５に関して前述したとおりである。
【０２７６】
ただし、図１６では、Ｐ１が、４ミリ秒早く完了する。Ｐ２が、Ｐ１によって開放されたスラック・プールからの再利用されるスラックを使用して、４ミリ秒早く開始し、時刻２１でオーバーランする。Ｐ３が、スラック・プールからの割り振られていない時間線スラックを使用する。
【０２７７】
図１６は、タスク区分とは独立に、すべてのタスクにとって利用可能である共通プールからのスラック・スチールの使用を介する障害回復の例を示している。 図１７は、再利用されるスラックを使用するタスク実行を示すタスク実行時間線である。図１７では、タスク区分とは独立に、すべてのタスクによって使用されるために共通のスラック・プールが提供されるものと想定している。区分Ｐ１ないしＰ３は、図１５に関して前述したとおりである。
【０２７８】
図１７では、Ｐ１が、４ミリ秒早く完了する。時刻ｔ＝１１から開始して、Ｐ３が、スラック・プールからの再利用されるスラック（Ｐ１によって開放された）を使用し、ｔ＝１５まで実行される。次に、ｔ＝１５で、Ｐ３が、時間線スラックを使用してｔ＝２０まで実行される。Ｐ２が、ｔ＝２０で開始して実行されるが、ｔ＝２６で早く終了し、この時点で、Ｐ３が、Ｐ２からの再利用されるスラックを使用してｔ＝３０まで再び実行される。
【０２７９】
図１７は、Ｐ３のような高優先順位ではあるが、重要ではない区分が、時間線スラックと、スラックの共通プールからの再利用されるスラックの両方をどのように使用することができるかを示している。
【０２８０】
本発明は、時間区分とは独立であるスラック・プールを保持するのではなく、各時間区分に関してスラック・プールを保持することによって実施することも可能である。
【０２８１】
４．２．２ 初期設定
システム・ブート後、あるスラック変数を初期設定しなければならない。そのスラック変数をアルゴリズム７（付録Ｂ）で示しており、初期設定は、「第１の」ハイパー周期が実行される前に行われなければならない。データ構造は、すべてテーブル６および７で定義されている（付録Ａ）。１次スレッドが、Ｔ１以外の周期を有することが可能である場合、このアルゴリズムの拡張が必要である。
【０２８２】
スラック変数のシステム初期設定を扱うための擬似コードが、アルゴリズム７（付録Ｂ）によって提供されている。アルゴリズム７は、最初のハイパー周期の開始前に一回、呼び出される。この時点でスラック変数が初期設定されないと、後に偽の値がもたらされる。このアルゴリズムは、１次スレッドの周期がＴ１以外であることが可能な場合、変更を必要とする。
【０２８３】
４．２．３ スラック変数の周期リセット
周期リセット時に、スラック累算器の値の多くをリセットしなければならず、また時間線スラックの値を更新するのが必要である可能性がある。スレッドが、（非）活動化されていないときでも、周期指標（すなわち、γｉ）を増分し、集合完了指示子をリセットするため、周期リセットがやはり必要である。レベルｋの周期リセットが、時刻ｊ・Ｔｋで行われ、ただし、ｊは、任意の自然数である。
【０２８４】
以上の機能を提供するための擬似コードが、アルゴリズム８（付録Ｂ）によって与えられている。アルゴリズム８は、最初（システム初期設定コードを実行した後）、値ｊ＝ｎで呼び出して、ハイパー周期の開始時に累算器の値を初期設定しなければならない。このアルゴリズムは、毎周期の開始時に、つまり、時刻０、Ｔｊ、２Ｔｊ．．．等で呼び出される。このアルゴリズムは、最大周期で一回、呼び出される。つまり、ｋ≦ｊであるとき、Ｔｊの周期の開始は、Ｔｋの周期の開始でもある。「ｒ」は、１次周期がサポートされる速度を指し示す。一実施形態では、常にｒ＝１であり、したがって、これは、Ｏ（ｎ）ルーチンである。スレッドの（非）活動化が行われたとき、動的な周期時間線スラックの変更を更新する。指標を有するプロセス・セットを１次スレッドに関して導入しなければならない可能性がある。
【０２８５】
ΔＴｉｍｅｌｉｎｅＳｔａｃｋｉを設定する内部ループは、そのルーチンの実行に先立って１≦ｋ≦ｊである期間Ｔｋの最後の周期中にレベルｋで、活動化または非活動化がまったく行われなかった場合、ノーオペレーションである。最適化は、ブール・ベクトル、たとえば、αｋが、レベルｋにおいて非／活動化が行われた場合だけにＴＲＵＥであるα＝（α１．．．αｎ）を保持することであるのが可能である。
【０２８６】
Ｔｋは、ｋ＜ｉに関してＴｉを均等に分割するので、周期的更新は、最も遅い速度によって一回だけ呼び出されればよく、その時点で、より高い速度のスレッドに関するすべての更新が行われる。これは、おそらく、ｉ回の別々の呼出しを行うよりも効率的である。
【０２８７】
４．２．４ １次スレッドの活動化および非活動化
１次スレッドの活動化および非活動化のための擬似コードが、アルゴリズム９（付録Ｂ）で提供されている。Ｉｆ Ｐ．ａｃｔｉｖｅ，ｔｈｅｎ Ｐの１次スレッドを非活動化する；ｅｌｓｅ Ｐの１次スレッドを活動化する．（非）活動化要求「処理」時刻は、ｓにおいてであり、ただし、ｒ＝Ｐ．ｒａｔｅで、γｒＴｒ≦ｓ≦（γｒ＋１）Ｔｒである。
【０２８８】
時間線スラックの可用性を調整することに関し、ユーザ・スレッドを有さないプロセスの非活動化は、プロセスを強制終了することと等価である。同様に、ユーザ・スレッドを有さない１次スレッド予算の活動化は、時間線スラックの変化に関して、プロセスを作成することと等価である。真のプロセス作成／削除は、プロセスのレジストリおよびステータスを更新すること、および実施可能性の分析を行うことを必要とするが、１次スレッドに関する（非）活動化要求は、実施可能性に基づいて常に認可される。
【０２８９】
アルゴリズム９の呼出しは、活動化ステータスを切り替えるものと暗黙的に想定する。実際には、明示的な要求が行われる可能性が高く、したがって、最初に、ノーオペレーションに関する検査が存在することになる。
【０２９０】
ＰｒｉｍａｒｙＴｈｒｅａｄ（Ｄｅ）ａｃｔｉｖａｔｉｏｎアルゴリズムに関するいつくかの所見は、述べておくに値する。プロセス・レコード属性は、テーブル９に含まれている。ＣｕｒＩＤ（ｊ）およびＰ．ＲｅｑＩＤ（ｊ）が、Ｔｊで定義される周期を一意的に特定するものと想定する。γｊを使用するのは十分ではない。というのは、Ｐ．ＲｅｑＩＤおよびＰ．ΔＢｕｄｇｅｔがゼロ設定される時点は、（ユーザまたは１次）スレッドが、（非）活動化されるときだけだからである。特に、Ｐ．ＲｅｑＩＤおよびＰ．ΔＢｕｄｇｅｔは、周期的にゼロ設定されない。Ｐ．ＲｅｑＩＤおよびＰ．ΔＢｕｄｇｅｔを周期的に（ハイパー周期においてなど）ゼロ設定しない理由は、ｐがアクティブなプロセスの数であるＯ（ｐ）オペレーションを導入するのを望まないからである。というのは、アクティブなプロセスの数が、ＤＥＯＳにおいては、非決定性だからである。
【０２９１】
試験ＣｕｒＩＤ（ｊ）＞Ｐ．ＲｅｑＩＤ（ｊ）は、現実には、ＣｕｒＩＤ（ｊ）＞Ｐ．ＲｅｑＩＤ（ｊ）、またはｃが任意の定数≧ｎｎ｜１であるＰ．ＲｅｑＩＤ（ｊ）−ＣｕｒＩＤ（ｊ）＞〜ｃと読替えられなければならない。この試験の第２の部分は、カウンタ・ロールオーバを考慮に入れる。この試験なしに、ＣｕｒＩＤ（ｊ）とＰ．ＲｅｑＩＤ（ｊ）が誤って一致する２３２分の１の確率が存在する。この一致は、永久の誤りをもたらす。というのは、活動化の誤った要求が、システムを「永久に」不十分に利用される状態におき（認可された場合）、また非活動化の誤った要求が、システムが実際よりも低い利用率を有すると信じるため、過剰予約をもたらす可能性があるからである。
【０２９２】
一実施形態では、スレッドを非活動化する時刻は、限定されないが、他の実施形態では、限定される。前述した実施形態では、スレッド非活動化の要求は、スレッドが実行された次の周期で有効になるものと想定している。
【０２９３】
４．２．５ ユーザ・スレッドの活動化および非活動化
ユーザ・スレッドの活動化および非活動化の要求に応答してプロセス・レコードおよびシステム時間線変化を更新する擬似コードが、アルゴリズム１０（付録Ｂ）によって提供されている。アルゴリズム１０は、活動化／非活動化が処理される／認可される時点で実行され、次のＴｊ周期境界において実行されるのではない。再利用される時間線スラックが更新されるのが、次のＴｊ周期境界においてである。
【０２９４】
実施可能性の試験は、活動化要求および／または非活動化要求が行われる順序によって定義されたタスクのセットに基づくことに留意するのが重要である。この順序は、活動化および非活動化が有効になる順序とは異なる可能性がある。通常の状況下では、活動化要求および非活動化要求が認可された（ただし、行われていない）スレッドのセットは、活動化および非活動化が実際に行われるスレッドのセットとは異なる可能性がある。たとえば、速度ｊで活動化する要求の直後にｔを非活動化する要求が続くと、両方の要求が、Ｔｊで定義された同じ周期中に行われるという条件付きで、アクティブなスレッドのセットにまったく変更がもたらされない。
【０２９５】
スレッド活動化の実施可能性に関するオンライン許可試験（セクション３．３を参照）が、前に呼び出されている可能性があり、そうである場合、第２の承認試験は、不必要である。Ｐの１次スレッドがアクティブである場合には、Ｐの１次スレッドのステータスが、後にアクティブから非アクティブに変更されない限り、利用可能な時間線スラックにおける予算の更新は、まったく行われない。Ｐの１次スレッドのステータスが、後にアクティブから非アクティブに変更された場合、１次スレッド（非）活動化の要求時にＰによって保持されるユーザ予算の量は、Ｐ．ＲｅｑＩＤおよびＰ．ΔＢｕｄｇｅｔＲｅｑを使用して構成することができる。この再構成をＵｓｅｒＴｒｅａｄ（Ｄｅ）ａｃｔｉｖａｔｉｏｎアルゴリズム（アルゴリズム１０）で示している。
【０２９６】
活動化も非活動化もともに、周期Ｔｊの次の開始時に有効になり、ただし、ｊは、（非）活動化されるスレッドの速度を定義するものと想定する。スレッドの非活動化は、実施可能性に基づく条件付ではない。不適切な状態にあるスレッドは、非活動化することができないが、これは、スケジューリングの問題ではなく、したがって、本明細書では、考察しない。スレッドの状態は、ＵｓｅｒＴｈｒｅａｄ（Ｄｅ）Ａｃｔｉｖａｔｉｏｎコードが呼び出されるまでには、非活動化に適切であるものと想定する。
【０２９７】
すべてのプロセスの間で、ｎ０≦ｎの速度だけが、プロセスの１次スレッドによって使用される場合には、ＴｉｍｅｌｉｎｅＳｌａｃｋの次元は、１×ｎ０であり、またΔＴｉｍｅｌｉｎｅＳｌａｃｋの次元は、ｎ０×ｎである。一実施形態では、ｎ０＝１であり、したがって、ＴｉｍｅｌｉｎｅＳｌａｃｋは、スカラー値であり、またΔＴｉｍｅｌｉｎｅＳｌａｃｋは、長さｎの行ベクトルである。他の実施形態では、１次スレッドは、１以外の速度を有することが可能である。
【０２９８】
４．２．６ プロセスの活動化および非活動化
プロセス活動化とは、プロセス作成を指し、１次スレッド活動化を指すのではない。新たに作成されたプロセスは、アクティブなユーザ・スレッドをまったく有さず、また１次スレッドは、アクティブであるものと想定する。（非アクティブな１次スレッドは、実際には、より簡単なケースである。）
同様に、プロセス非活動化とは、プロセス削除を指し、１次スレッド非活動化を指すのではない。プロセスは、プロセスのユーザ・スレッドのどれかがアクティブである場合、削除することができない。１次スレッドは、アクティブである場合、まず、ＰｒｉｍａｒｙＴｈｒｅａｄ（Ｄｅ）ａｃｔｉｖａｔｉｏｎを呼び出すことによって非活動化される。
【０２９９】
プロセスは、ＤＥＯＳにおいて真に動的であることが可能であり、また宣言されている（ｎｏｔ ＰｒｏｃＡｃｔｉｖｅステータスを使用して）必要はないことに留意されたい。アルゴリズムは、現在、すべてのプロセスが存在し、プロセスの一部はアクティブであり（Ｐ．ＰｒｏｃＡｃｔｉｖｅ）、またプロセスの一部はアクティブではないものと想定している。まず、プロセスが存在するかどうかを検査し、存在しない場合、プロセスを作成するための拡張は、簡単である。
【０３００】
スラックの点から、プロセスが作成されたとき、プロセスの予算のすべては１次スレッドに属し、１次スレッドはアクティブであるものと想定する。プロセスが削除され、プロセスの１次スレッドが非アクティブであるとき、行われる唯一のアカウンティングは、アクティブなプロセスの更新である（スラックの可用性の変化は存在しない）。１次スレッドがアクティブであるときのプロセス削除の場合、確保されたプロセス利用率は、時間線スラックに変換される。
【０３０１】
以上の動作のための擬似コードが、アルゴリズム１１（付録Ｂ）として表されている。アルゴリズム１１は、アルゴリズム９を呼び出して、予算の必要な移動があれば、それを行う。プロセス作成／削除は、（γｒ（ｔ）＋１）Ｔｒで定義される次の周期境界で行われ、ただし、ｔは、要求の時刻であり、またｒは、プロセスの速度、Ｐ．Ｒａｔｅであるものと想定した。ｔは、ＤＥＯＳが、待ち状態の要求に関して変数の更新を行うのを決めた時刻であると想定する。
【０３０２】
４．３ スラック累算器の更新
ＤＥＯＳにおいて、アプリケーションを実行することができる比較的少数（たとえば、４または５）の速度が存在する。各プロセスは、同じ速度で実行される多数の（場合により、数十の）スレッドを有する可能性が高い。速度ｉで実行されるすべてのスレッドの集合を集合スレッドと呼び、集合スレッドは、τｉで示してきた。集合スレッドは、プロセスとは独立に定義されることに留意されたい。所望される場合、集合スレッドを分解してプロセス群の中の集合スレッドにすることが可能であるが、すべてのスラックがシステム・レベルでプールされる場合、これは必要ない。スラック・スチールの元の定義は、各スレッドに別個の優先順位を割り当てる（等しい速度を有するスレッドが、そのスレッド間において明示的で静的な優先順位の順序付けを有する場合）。
【０３０３】
このセクションでは、スラック更新回数に注目する。前に定義していないとしても、テーブル８で定義しているスラックを記録にとるいくつかの異なる累算器が存在する。
【０３０４】
一般に、あるセットのスラック累算器の更新が、最高で６つの異なる状況で必要とされる。
１．周期境界においていつでも（これは、残念ながら、頻度が高く、必要な更新である。）、
２．再利用されるべきスラックを有する固定予算で実行される際、周期に関して完了するときはいつでも、
３．アイドル・プロセッサからビジー・プロセッサに遷移するときはいつでも、
４．あらゆる新しいスラック消費出現に関してスラックの可用性を計算する直前に；（ＤＥＯＳでは、これは、スラックでさらに実行されることを望む周期に関して完了したスレッド、または尽きた固定予算を有する新たに出現したＩＳＲスレッドに関する）、
５．スラックで実行される際、周期に関して完了したときはいつでも；またはより高い優先順位のスラック・コンシューマ（ただし、より高い優先順位の固定予算のコンシューマではなく）によって先制されたとき、ならびに
６．スラック消費スレッドによるミューテックス実行前に（スラック累算器を事前に減分して導入されるシステム・オーバーヘッドを考慮に入れるため）。
【０３０５】
このセクション４では、「スラック・スケジューリングの背景」と題したセクション２で説明した定義と比べたとき、累算器の定義に意味の変化が存在することに留意されたい。この変化の影響の一部は、固定された予算で実行されている際、スレッドの完了に関する更新回数が、相当に少なくなるが、スラックの可用性を計算する頻度が、顕著に増加することである。基本的な違いは、スラック・アカウンティングが、各レベルで行われ（すべてのレベルにおいて累積的であるのと対比して）、これにより、周期におけるリセットが可能になり、スラックが満了時刻を越えて存続しないのが確実にされることである。
【０３０６】
また、ユーザ・スレッドが、レベルｊにおける非アクティブな１次予算で非活動化されたとき、スラックは、必ずしも１でないレベルｊに戻ることに留意されたい。
【０３０７】
４．３．１ 周期境界の更新
セクション４．２は、周期境界遷移に関連するスラックの更新を説明することに充てられている。どの変数が更新されるかを説明する詳細なアルゴリズムは、前にアルゴリズム８として提示した。
【０３０８】
このセクションは、改良されたスラック・スチール・スケジューリング・アルゴリズムと、周期更新を必要としなかった（ハイパー周期リセットを超えて）周知のスラック・スチール・アルゴリズムの違いを強調する。この違いの根元は、動的なスレッド／プロセスの作成では、将来の知識を想定することができず、したがって、レベルｉで利用可能な時間線スラックは、周期に関してだけ、その周期τｉの開始時に計算できることに由来する。
【０３０９】
この変更された公式化から、３つの含意が帰結する。
１．周期境界の前に、以下のアルゴリズム１４で示す消費される非周期的スラックの量が、ＴｉｍｅｌｉｎｅＳｌａｃｋｉが現行のものではない場合、計算されなければならない。１≦ｉ≦ｊであるＴｉｍｅｌｉｎｅＳｌａｃｋｉの値は、毎周期τｊの完了に先立って更新されなければならない。というのは、この値が、周期境界更新コードにおいて使用されるからである。１≦ｊ≦ｎであるＴｉｍｅｌｉｎｅＳｌａｃｋｊを更新してもよい。
【０３１０】
２．周期境界の前に、累積されたアイドル時間の量（すなわち、Ｉｄｌｅｊ）、および再利用に関する損失時間の量（すなわち、Ｌｊ）が、毎周期境界τｊの前に更新される必要がある。これは、アルゴリズム１３と同等のコードを呼び出すことに相当する。１≦ｊ≦ｎであるＩｄｌｅｊおよびＬｊを更新してもよい。
【０３１１】
３．アルゴリズム８で示した擬似コードと同等のコードが、周期境界で実行されなければならない。これは、アイドル累算器および非周期的累算器が更新された後に実行される。
【０３１２】
４．最後に、すべての利用可能なスラックが消費された場合、スラック・コンシューマが再開する準備ができるたびに毎回、実際の利用可能なスラックが、再計算されなければならない（というのは、スレッド再利用から、または周期時間線スラックから、より多くのスラックが利用可能になっている可能性があるからである）。下方への速度変化までスラックの更新を延期するのが保守的（すなわち、安全）である。
【０３１３】
ｉ＞１に関して毎周期τｉ、レベルｉで利用可能なスラックを再計算するのが必要であることは、いくつかの異なるスラック評価オプションを示唆し、このオプションは、セクション４．４まで先に延ばす。アルゴリズムは、前述した最大回数の更新を想定している。
【０３１４】
４．３．２ 固定予算スレッド完了の更新
周知のスラック・スチール・アルゴリズムでは、スラックの要求が存在しない場合、スラック累算器の変数は、各周期的スレッドが完了したとき（またはアイドル周期からビジー周期に遷移したとき）、更新を必要とする。ＤＥＯＳでは、これは、集合スレッドの完了後のスラック変数の更新に対応する。実際、必要な唯一の更新は、固定予算のレベルｉのスレッドが、周期に関して早期に完了した場合に再利用されるスラックの値を増加させるときだけである。
【０３１５】
スラック累算器の変数を更新するための擬似コードが、アルゴリズム１２（付録Ｂ）によって与えられている。アルゴリズム１２は、スラックの可用性を計算する際に使用される、再利用されるスラックの変数を更新する。アルゴリズム１２は、固定予算で実行されるタスクが、周期に関して完了したときはいつでも呼び出される。増分式更新を行うか、または集合更新を行うかに関わらず、同一のアルゴリズムが適用される。
【０３１６】
周期に関して完了するとき、スラック・スチールに関連するオーバーヘッドはあまりにも少ないので、オーバーヘッドを低減することは、集合スレッドを使用するための重要な動機にはならない。より少ない回数の更新（集合スレッドのように）の方を好む１つの可能な動機は、スラックの可用性の計算が行われる回数が削減される可能性である。
【０３１７】
このセクションにおけるアルゴリズムの多くは、集合更新を想定しているが、実際的な目的では、増分式の更新が、簡単であるために、最初、最もよいやり方であるように思われる。集合更新から増分式の更新にするのに必要とされる変更は、大したものではない。集合スレッドの完了後に更新を行うことを集合更新と呼ぶ。同様に、各スレッドの完了後にスラック変数を更新することを増分式の更新と呼ぶ。
【０３１８】
ある速度の中では、スレッドの明示的な優先順位付けは、ＤＥＯＳにおいて禁止されている。というのは、スレッドが、待つことを選択する（先行スレッドを有さないとき）か、または待つことを強制される（先行スレッドを有するとき）ことが可能であるからである。これは、等しい速度を有するスレッドに、固定の優先順位が恣意的に割り当てられることで、ＲＭＳとは異なっている。優先順位の逆転または遅延が存在しない場合、所与の速度のすべてのスレッドは、順次に実行され、また集合更新が、更新に関する自然な考え方である。
【０３１９】
一実施形態では、少なくとも２つの理由で、増分式の更新が提供される。第１に、更新あたりのオーバーヘッドが最小であり、増分式の更新は、より均一な解決策を提供する。第２に、集合更新は、速度ｉのすべてのスレッドが、速度ｉのどれかが、スラックの消費を開始する前に、周期に関して完了しなければならないことを暗示している。速度ｉのスレッドは、リソースを待つことができ、一方、その他のスレッドが周期に関して完了しているため、集合更新は、レベルｉでスラックが消費されるのを妨げる可能性がある（より遅い速度のスレッドに、または、さらに悪い場合、アイドル・スレッドに優先順位を与えることにより）。
【０３２０】
テーブル１０（スレッド状態時間変数）（付録Ａ）は、必要な実行時間の情報を提供するセットのスレッド属性を示唆している。ＴｉｍｅＳｌｉｃｅ属性を使用して、中間タイムアウトが満了する前にスレッドに割り振られた時間の量が示される。もちろん、代替のセットも可能である。
【０３２１】
ＥｘｅｃＴｉｍｅ属性は、再利用されるスラックを決定するための機構を提供する。具体的には、周期的スレッドの完了時（周期中の）、そのスレッドから再利用されるスラックの量は、ＣｏｍｐｕｔｅＴｉｍｅ−ＥｘｅｃＴｉｍｅである。
【０３２２】
固定予算が切れた後、スラック消費に計算を適用することができることに留意されたい。スレッドがスラックで実行される際、ＣｏｍｐｕｔｅＴｉｍｅの値が、要求の時点で利用可能なスラックに設定される。ただし、スラック消費に関するこのモデルは、スラックが割り振られた時刻と、スラックで実行されるスレッドが完了する時刻の間に、認可されたスラックを消費するその他のスレッドがまったく存在しない場合にだけ成立する。（認可されたスラックの概念は、セクション４．４で定義する。今のところ、認可されたスラックは、任意の割り振られたスラックと理解することができる。）
【０３２３】
１つのスラック消費スレッドが、別のスラック消費スレッドを先制したとき、先制されたスレッドからは、まったくスラックが再利用されず（先制の時点で）、先制されたスレッドに関してＥｘｅｃＴｉｍｅとＣｏｍｐｕｔｅＴｉｍｅがともに、スラック累算器Ａ非周期を更新した後、先制されたスレッドをゼロに設定しなければならない。これはすべて、先制を行おうと試みているスレッドに関してスラックの可用性の計算を行うのに先立って行われなければならない。
【０３２４】
テーブル１０の中の属性のセットが、集合スレッドに対応する場合には、スラックが、スレッドが完了するにつれて増分式に再利用されるとすれば、スレッドごとに等価の情報が保持されなければならない。この能力が所望される場合、より簡単なコードの点から、増分式の更新の場合、確認の労力がわずかに減少する可能性がある。しかし、これは、実際には、試験を複雑にする。というのは、その場合、はるかに多くの「イベント・ケース／シーケンス」が生じることが可能だからである。
【０３２５】
レベルｉの再利用されるスラックは、レベルｊ＜ｉに一斉に適用することができ、また現在のτｉ周期の残りに何らかの形で分散されなければならない。現在のτｉ周期は、［γｉ（ｔ）Ｔｉ，（γｉ（ｔ）＋１）Ｔｉ］で定義され、ただし、ｔは、τｉが周期に関して完了する時刻である。現在、レベルｉで再利用されるスラックは、速度ｊ∈｛１，．．．ｉ−１｝で利用可能でない。
【０３２６】
Ｒｉが、レベルｉで再利用されるスラックの量であり、またＢｊ ｒが、現行の周期Ｔｉ中の期間Ｔｊの残りの完全な周期の数である場合、残りの完全な周期のそれぞれは、スラック要求に割り振られたＲｉ／（Ｂｊ ｒ＋１）のタイム・ユニットを有することが可能であることに留意されたい。
【０３２７】
Ｒｉが、τｉから再利用されるべき未使用の最悪ケースの固定予算の量である場合には、Ｔｊで定義される現在の周期中にレベルｊの要求側（ｊ＜ｉ）に与えることができるスラックの量は、Ｒｉと、周期Ｔｊの次の開始と現在の時刻に残りの未使用のＩＳＲ予算を足したものとの差の小さい方、すなわち、ｍｉｎ（Ｒｉ，（γｉ（ｔ）＋１）Ｔｊ−（ｔＢｊ ｒ（ｔ））である。
【０３２８】
４．３．３ アイドル−ビジー遷移の更新
アイドル累算器のスラック変数（Ｉｄｌｅｉ，１≦ｉ≦ｎ）は、アイドル・プロセッサからビジー・プロセッサに遷移する際に更新される。この更新は、プロセッサがどれだけ長くアイドル状態で過ごしたかの知識を必要とする。
【０３２９】
アイドルからビジーに遷移する際にアイドル・スラック変数を更新する擬似コードが、アルゴリズム１３（付録Ｂ）によって提供される。アルゴリズム１３は、アイドル・タスクが完了したとき（優先順位（ｎ＋１）で）はいつでも呼び出される。このアイドル・プロセスは、τｎ＋１で示される。Ｕｐｄａｔｅ＿ｔｉｍｅ＝このルーチンを実行する最悪ケースの時間である。
【０３３０】
ＤＥＯＳにおいて、「背景」モードで実行されるアイドル・プロセスが存在する。アルゴリズム１３におけるアイドル累算器の更新に関して、アイドル・プロセスは、優先順位ｎ＋１で実行されるτｎ＋１として考えることができる。ただし、アイドル・スレッドは、固定の計算時間予算をまったく有さない（１≦ｊ≦ｎであるτｊとは異なり）。
【０３３１】
アイドル・スレッドは、ゼロではない予算を必要とする可能性がある。というのは、アイドル・スレッドは、スレッド／プロセス削除のようなことを行い、そのいくつかの部分は、実行されるクリティカルなセクションだからである（したがって、何らかの最低限の固定予算が存在することが可能である）。
【０３３２】
一実施形態では、アイドル・プロセスの実行時間は、クロックの刻みで更新され、したがって、アイドル時間は、決してＴ１より大きくない。この想定を緩和することは、完全に簡単なことではなく、さらなる、また場合により、トリビアルでない記帳を導入する。自らの予算を保持しながら、リソースを待つことができるスレッドに関して、消費されるｉｄｌｅ＿ｔｉｍｅが必要である範囲のケース・ステートメント。困難は、あるスレッドがリソースを待ち、自らの予算を開放せず、確保された予算に割り込むのに十分なアイドル時間が経過し、次に、そのスレッドが、自らの予算全体をスラックに与えるのを決めた（予算の一部が、アイドルによって消費された後）とき、生じる。
【０３３３】
ＤＥＯＳでは、ＩＳＲスレッドだけが、待っている間、自らの予算をスラックに与えることなくリソースを待ち、また、ＩＳＲスレッドは、速度１でだけスケジュール設定される。したがって、ｊ＝２．．．ｎに関してＣｊ＝０であり、これにより、いくつかの実施の最適化が可能になる。また、Ｃｊは、スレッドの活動化／非活動化の時に更新される必要があることに留意されたい。Ｃｊという表記は、Ｃｊの値＝τｊの計算時間が、確かに保守的であるために選択された。ただし、このアルゴリズムにおけるＣｊは、はるかに小さいことが可能であり、したがって、変数名は、多重定義になる。
【０３３４】
アイドル変数は、周期境界が更新される前に更新されなければならないことに留意されたい。多くの場合、これは、新しいスレッドが周期境界でスケジュール設定されるため、自動的に行われるが、更新は、アイドル・プロセスが実行され続けるときにやはり必要である。
【０３３５】
一実施形態では、ゼロの固定予算のスラック消費スレッドは、サポートされない。そのようなクラスのスレッドは、リソースにアクセスすることが許されないか、または、別の形で、ブロッキングに関連するオーバーヘッドを導入する。したがって、すべてのスラック消費スレッドが、何からの速度で実行されなければならず、またゼロではない固定予算を有する。これが暗示することは、優先順位ｎ＋１で実行されることが可能なスラック消費スレッドが存在しないこと、または等価であるが、背景モードで実行されることが可能なスラック消費スレッドが存在しないことである。他の実施形態では、優先順位が、特定の速度のスラック消費スレッド間に導入されることが可能である。
【０３３６】
スラックが時間区分化されている場合、いくつかの「アイドル」スレッドが存在しなければならないことになり、時間区分内で過ぎたアイドル時間だけが適用可能であることが認められよう。プロセスにアイドル間隔が一意的に関連していることは、困難な問題を生じさせる可能性がある。ただし、プールされたシステム・レベルのスラックを使用すると、単一のアイドル「プロセス」だけが存在する。
【０３３７】
４．３．４ スラック消費の前およびスラック消費の後
スラック消費の前およびスラック消費の後、時刻を検出する際にまったく困難は生じない。スラック変数を更新することは、スラックの可用性を計算するのとは異なる活動であることに留意されたい。ただし、各周期Ｔ１における動的な時間線スラックの再評価を使用すると、消費されたスラック（すなわち、ＡｐｅｒｉｏｄｉｃＴｉｍｅｉ）を更新し、周期時間線スラックを更新し、次にスラックの可用性を再計算するのが最も好都合である可能性がある。周期境界の後に再開するスラックで実行されるスレッドは、タイムスライスがリセットされなければならないことに留意されたい。ただし、この最大限の更新の手法は、相当なオーバーヘッドを招く可能性がある。
【０３３８】
スラック変数の更新は、利用可能なスラックに関する計算された値が楽観的でないことを確実にするため、スラックの可用性を計算するのに先立って常に必要である。スラックを消費した後のスラック変数の更新は、スレッドの完了後のスラック変数の更新と同様であり、この更新は、スラックの新しい要求が出現するまで、または下方への速度遷移が生じるまで（すなわち、より高速のスレッドを実行することからより低速のスレッドを実行することへのＤＥＯＳ遷移）、延期できる可能性がある。
【０３３９】
スラックの可用性を計算する際に使用される非周期的スラック変数を更新する擬似コードが、アルゴリズム１４（付録Ｂ）によって提供されている。アルゴリズム１４は、非周期的タスクが完了したときはいつでも呼び出され、これは、周期的タスク増分に関する余剰の計算時間、または完了するアイドル・タスクを含むことが可能である。ｕｐｄａｔｅ＿ｔｉｍｅ＝定数（場合により、ｉに依存する）である、このルーチンを実行する最悪ケースの時間である。
【０３４０】
非周期的タスクｔは、いくつかの時間増分にわたって実行されることが可能であり、すなわち、スケジュール設定され、すべてのスラックを消費し、自らをサスペンドし、さらなるスラックが利用可能になったときに再びスケジュール設定されること等が可能である。
【０３４１】
アルゴリズム１４は、非周期的累算器を更新するのに適切な擬似コードを含み、この擬似コードは、Ｏ（ｎ）である。アルゴリズム１４は、テーブル１１（スラック・レコード属性）（付録Ａ）で示したスラック・データ構造を参照する。スラック・レコードは、各レベルでどれだけのスラックが再利用されたか（Ｒｉ）を記録にとり、またどれだけのレベルｉ専用の未使用のスラックを繰り越すことができるか（Ｕｉ）を記録にとる。いくつかの追加の変数を候補のアルゴリズムで使用して、必要とされる更新の回数を削減する。
【０３４２】
アルゴリズム１４で、時間線スラックを分解して、１≦ｊ≦ｋである速度ｊの要求側が、速度ｋですべての利用可能なスラックを消費することができる、それぞれの特定の速度で利用可能な量にしなければならない。一般に、レベルｉのスラックは、レベルｉ＋１のスラックの前に消費される。というのは、レベルｉのスラックが先に切れるからである。したがって、このアルゴリズムは、単にレベル１で開始し、スラックの消費に先立って消費されるスラックとレベル１で利用可能なスラックの小さい方でＡｐｅｒｉｏｄｉｃＴｉｍｅ１を減分し、消費されたスラックの量を減分し、すべてのスラックが、ＡｐｅｒｉｏｄｉｃＴｉｍｅｊに含まれるまで、より低い速度のスラック・レベルに進み続ける。すべての帰属可能なスラックが消費されることに留意されたい。
【０３４３】
周期境界が更新される前に、非周期的変数が更新されていなければならないことに留意されたい。多くの場合、これは、先制を行うスレッドが周期境界でスケジュール設定されるため、自動的に行われるが、スラック消費スレッドが実行され、周期境界で先制を受けないとき、やはり更新が必要である。
【０３４４】
また、タスクにスラックが認可されている場合、そのタスクが、利用可能であると言われたすべてのスラックを受け取る保証は存在しないことに留意されたい。特に、より高い優先順位のスラック消費スレッドの活動化または出現により、スラックの損失がもたらされる。この意味で、スラックは、ベスト・エフォートでだけ提供される。少量のスラックが、累算器から事前に減分され、これにより、コンテキスト・スワップがカバーされるのが保証されるが、一般に、保証は、待ち状態の要求のスラック待ち行列の使用を介して提供される。
【０３４５】
次のセクションでは、固定予算で実行されるＩＳＲスレッドに関して使用されるものと同様の不変式を導入して、スラック・コンシューマが被るオーバーヘッドを考慮に入れる。この不変式は、リソース使用の前だけでなく、スラックをスケジュール設定するときはいつでも成立する。
【０３４６】
４．３．５ モニタおよびリソース使用の前および後
システム・オーバーヘッドを考慮に入れることに関して、スラック消費スレッドは、ＩＳＲスレッドと同じ問題の多くを生じさせる。幸い、ＩＳＲスレッドに関するのと同様のアカウンティング解決策が、スラックで実行されるスレッドに適用される。
【０３４７】
特に、固定予算で実行されるＩＳＲスレッドと同様の不変式が、スラックで実行されるスレッド（周期的またはＩＳＲ）に適用される。すなわち、「スケジューラは、少なくとも２＊ｃｏｎｔｅｘｔＳｗｉｔｃｈＰｌｕｓＤｅｌｔａ＋ＣａｃｈｅＢｏｎｕｓ＋ＳｌａｃｋＶａｒＵｐｄａｔｅＴｉｍｅレベルｉスラックが利用可能でなければ、決してレベルｉのスレッドＥｘｅｃｕｔｉｎｇＯｎＳｔａｃｋが、実行を開始／再開すること、またはリソースを待つことを許容してはならない。」
最低限の量の利用可能なスラックを必要とすることに加えて、スラック累算器は、要求側スレッドが、別のスラック・コンシューマによって先制された場合、事前に減分されなければならない。これは、呼出し側スレッドのｅｘｅｃｕｔｉｏｎ＿ｔｉｍｅ＿ｓｉｎｃｅ＿ｌａｓｔ＿ｓｃｈｅｄｕｌｉｎｇを２＊ｃｏｎｔｅｘｔＳｗｉｔｃｈＰｌｕｓＤｅｌｔａ＋ＣａｃｈｅＢｏｎｕｓに設定して、アルゴリズム１４においてＵｐｄａｔｅＡｐｅｒｉｏｄｉｃＳｌａｃｋＶａｒｉａｂｌｅｓを呼び出すことによって達せられる。
【０３４８】
この不変式は、スラック消費スレッドによるリソース要求の待機に先立ってだけでなく、スラック消費スレッドをスケジュール設定するときはいつでも成立することに留意されたい。特に、最初のスケジューリング、ならびにリソースを待つあらゆる要求に加え、スラックで実行されるスレッドの通常の再開に先立ち、実施可能性（不変式によって決定される）が、検査される。
【０３４９】
この理論的根拠は、ｃｏｎｔｅｘｔＳｗｉｔｃｈＰｌｕｓＤｅｌｔａが、要求側スレッドの実行を開始するのに必須の必要とされるコンテキスト交換のオーバーヘッド・コストをカバーすることである。別のｃｏｎｔｅｘｔＳｗｉｔｃｈＰｌｕｓＤｅｌｔａが、先制されたスレッドを再開するのに必要な予測不可能なコンテキスト交換のコストをカバーする。ＣａｃｈｅＢｏｎｕｓにより、先制されたスレッドを再開する際、キャッシュの最悪ケースの再書込みが可能になる。（実際、ＣａｃｈｅＢｏｎｕｓおよびｃｏｎｔｅｘｔＳｗｉｔｃｈＰｌｕｓＤｅｌｔａは、先制されるスレッドの残りの予算に追加される。）加えて、スラック累算器を事前に減分する際に消費される追加のＳｌａｃｋＶａｒＵｐｄａｔｅＴｉｍｅが、必要とされる。
【０３５０】
ＣａｃｈｅＢｏｎｕｓ＋ｃｏｎｔｅｘｔＳｗｉｔｃｈＰｌｕｓＤｅｌｔａは、先制されるスレッドの予算に移動される（固定予算で実行されるＩＳＲスレッドが、あるスレッドを先制するときとまったく同様に）ことに留意されたい。
【０３５１】
リソースまたはタイムアウトを保持することが完了した後、下方への速度変化が存在する場合（たとえば、ミューテックス・ロックを開放して、または時間制限が満了して）、スラック累算器は、ミューテックスの優先順位で更新しなければならないことに留意されたい。下方への速度変化が存在しない場合、スラック累算器の更新は、延期することができる。
【０３５２】
スラックで実行されることが可能であり、またミューテックスをロックし、かつ／またはリソースを待つことができるスレッドは、リソース・ロック時間に等しい最低限の固定予算を有さなければならない。ミューテックスの場合、最低限の固定予算は、その（入れ子にされた）ミューテックスに関する最悪ケースの実行時間である。その他のリソースの場合、最低限の固定予算は、単にコンテキスト・スワップのコストをカバーするのに必要とされるオーバーヘッドである（すなわち、２＊ｃｏｎｔｅｘｔＳｗｉｔｃｈＰｌｕｓＤｅｌｔａ＋ＣａｃｈｅＢｏｎｕｓ）。最低限の固定予算を必須にする理由は、ＴＢＥ（超過した時間予算）例外が、ミューテックスを保持するスレッドの優先順位を下げることなく、またそのスレッドが、次の周期でアクティブになったとき、事前に減分されたスラックが切れていることになるからである。
【０３５３】
４．４ スラックの割振り
繰り返すと、スレッド／プロセスが動的に更新されるとき、すべての利用可能なスラックが要求側の速度で消費されるには、より低い速度のスレッドに関する利用可能なスラックの計算が、より頻繁に行われる必要がある。また、一実施形態では、ｊ＜ｉである場合、レベルｉで再利用されるスラックは、レベルｊにおける消費に利用できない可能性があることに留意されたい。ただし、他の実施形態では、利用できる可能性がある。
【０３５４】
利用可能なスラックを決定する擬似コードが、アルゴリズム１５（付録Ｂ）によって提供されている。アルゴリズム１５は、ｎベクトルのスラック時間＝（Ｓ（１），Ｓ（２）．．．Ｓ（ｎ））を戻す。このアルゴリズムは、呼出しの時点で、たとえば、ｓで開始して、（（γ１（ｓ）＋１）Ｔ１，（γ２（ｓ）＋１）Ｔ２．．．（γｎ（ｓ）＋１）Ｔｎ）で定義される周期の終りで終了する利用可能なスラックを計算する。より多くの周期時間線スラックが、その要求の後のその間隔中に利用できるようになる可能性があることに留意されたい。これは、前から知られているスラック・スチール・アルゴリズムとは相当に異なる。
【０３５５】
実際には、いかなるレベルで利用可能なスラックが、コンテキスト・スワップにその他のオーバーヘッドを加えたもののコストをカバーするには、余りにも小さい場合、そのスラックを使用することにより、負の効果が生じる。δおよびｃａｃｈｅＢｏｎｕｓが、ｃｓｗａｐを超えるシステム・オーバーヘッドに基づいて選択される。必要なとき、このルーチンの実行に先立ち、ＵｐｄａｔｅＡｐｅｒｉｏｄｉｃＳｌａｃｋＶａｒｉａｂｌｅｓが、呼び出されなければならない。このルーチンの実行に先立ち、ＵｐｄａｔｅＩｄｌｅＳｌａｃｋＶａｒｉａｂｌｅｓが、自動的に呼び出されている。
【０３５６】
スラック可用性の計算の詳細を見る前に、パフォーマンスおよび／または公平性に影響を与える可能性がある（ＤＥＯＳにおいて、またはその他の実施形態において）スラック割振りポリシーの問題をより広く考察する。以下に２つの可能な最適化をリストし、次に、このセクションの終りでその最適化を説明する。
【０３５７】
１．レベルｉで周期に関して完了するスレッドからの再利用されるスラックは、レベル１．．．ｉ−１に割り振られてはならない。実施の点からは、これは、明らかに実施するのが最も容易であり、また、速度の間である形の公平性を提供する利点も提供する。レベルｉから再利用されるスラックは、レベルｉ．．．ｎにおけるスレッドにだけ利用可能である。
【０３５８】
特に、常に高速のスラック・コンシューマが存在する場合には、高速のスラック・コンシューマは、より低い速度のスラック・コンシューマに供与されたすべてのスラックをそのより低い速度のスラック・コンシューマから奪うことができる。
【０３５９】
この否定的な側面は、レベルｉまたはより低い優先順位のスラック・コンシューマが存在しない場合、レベルｉの再利用されるスラックが、より高い優先順位のスラック・コンシューマに供与されないことである。これを克服するため、このセクションで後に説明するスラック・レベル下降、または等価であるが、スラック優先順位下降の着想を導入する。
【０３６０】
２．スラックの可用性の更新は、ときとして、遅延させることができる。より具体的には、ｊ＜ｉに関してレベルｊでスラックが利用可能になるたびに毎回、レベルｉでスラックを再計算する必要はない。このことの利点は、より高い優先順位のスラック・コンシューマが、より低い速度のスラック・コンシューマに既に割り振られていないスラックで実行され、レベルｉで前に割り振られたスラックの量が、そのままにされるのが可能なことである。また、ｊ≦ｉであるレベルｉでスラック・コンシューマを実行している場合、レベルｊでより多くの再利用されるスラックが利用可能になったとき、更新を延期することもできる。
【０３６１】
アルゴリズム１５が呼び出されて、利用可能なスラックが計算される。各レベルにおける利用可能なスラックを含む長さｎの行ベクトルが戻される。スラックの可用性を計算する直前に、すべてのアイドル累算器および非周期的累算器が、更新されていなければならない。アイドル累算器は、アイドルからビジーに遷移する際に（これは、スラックの可用性の計算を行うのに先立って生じていることになる）、自動的に更新される。しかし、非周期的累算器は、更新されなくてもよい（たとえば、スラック・コンシューマが、別のスラック・コンシューマを先制している）。したがって、アルゴリズム１４が、アルゴリズム１５においてＡｖａｉｌａｂｌｅＳｌａｃｋを呼び出すのに先立って実行されていなければならない。
【０３６２】
以下は、オーバーヘッドに関するいくらかのコメントを提供する。スラックで実行される、またはスラックでリソースを待っているスレッドを開始／再開するのに先立ち、オーバーヘッドを考慮にいれるため、またどれだけのスラックが利用可能であるかを決定するためにいくつかのステップが行われなければならない。
【０３６３】
１．どれだけのスラックが現在、利用可能であるかの推定を得るため、アイドル累算器および／または非周期的累算器が、更新される必要がある。これは、アルゴリズム１４および／または１５におけるコードを呼び出すことに相当する。
【０３６４】
２．次に、利用可能なスラックが計算されなければならない。これは、アルゴリズム１５におけるコードを呼び出すことに相当する。
３．最後に、要求された優先順位で十分なスラックが利用可能である場合、スラック累算器が、コンテキスト・スワップおよびキャッシュ効果を可能にするのに十分な量だけ事前に減分される。これには、アルゴリズム１４におけるコードに対する再度の呼出しが必然的に伴う。
【０３６５】
ここでの要点は、各ルーチンが、Ｏ（ｎ）の複雑度であっても、最適化は、最適化を行うことができるときにはいつでも行われなければならないことである。
【０３６６】
４．４．１ スラック優先順位下降
４．４．２ 延期されたスラック累算器の更新
ｋ＞ｊであり、レベルｊの要求に関して利用可能なスラックが不十分であるが、レベルｋの要求に関して利用可能なスラックが十分、存在するということが可能である。この状況は、第１に、レベルｊにおけるスラックの量が、２（ｃｓｗａｐ＋δ）＋キャッシュボーナス）より少ない場合に生じ、また第２に、スラックが、レベルｋ（レベルｊには見えない）で再利用されている場合に生じる。
【０３６７】
ｋ＞ｊであり、レベルｊの要求に関して利用可能なスラックが不十分であるが、レベルｋの要求をスケジュール設定可能にするのに十分である利用可能なスラックが存在する場合には、レベルｋのスラック・コンシューマを実行させることができる。
【０３６８】
より多くのレベルｊのスラックが、Ｔｋ次の周期の前にあるＴｊの次の周期で利用可能になることに留意されたい。その時点で、レベルｋのスラック・コンシューマは、レベルｊのスラック・コンシューマを優先させるように先制を受ける（速度によって定義されるスラック優先順位が守られる場合）。このような状況が繰り返されると、多くのスラック累算器の更新がもたらされる可能性があり、多くのオーバーヘッドがもたらされる可能性がある。保証されたスラックを提供することにより、更新の一部が節約される。というのは、その場合、より高い優先順位のスラック・コンシューマが、先制と見なされるが、後のスラックの要求が、先制されたスラック・コンシューマによって行われる必要がないからである。
【０３６９】
４．５ 障害条件下の整合性のあるスラック値
以下は、障害条件のリストである。
１．クロック・ドリフトに起因する時間同期。時間においては、先にだけ進み、ジャンプを行う前の古い時刻が分かっているものと想定される。時間同期ポイントは、常に周期境界にある。
２．プロセス／スレッドが、再スタートする
３．プロセッサが、再スタートする
４．その他の一時的誤り
【０３７０】
セクション５−発明の例としての実施形態の方法、およびマシン可読媒体
図１８Ａおよび１８Ｂはともに、本発明の実施形態による、調和的タスクおよび動的タスクを実行するシステムにおいてスラック・スチールを使用するタスク・スケジューリングの様々な方法を包含するプロセス流れ図である。図１８Ａ〜Ｂは、アクション・ボックス１０１、１０３、１０５、１０７、１０９、１１１、１１３、１１５、および１１７を有するプロセス流れ図である。
【０３７１】
方法は、ボックス１０１で開始する。ボックス１０３で、マルチタスク・システムが、速度単調アルゴリズムに従ってタスクをスケジュール設定する。スケジューリングの一環として、様々なタスクに優先順位レベルが割り当てられる。
【０３７２】
ボックス１０５で、予測不可能な時刻にアクティブになり、かつ／または非アクティブになるタスクを考慮に入れて、各優先順位レベルにおけるタスクに関して利用可能なスラックが決定される。ボックス１０７ないし１１１は、利用可能なスラックを決定する様々な実施を提供する。ボックス１０７で、時間線スラックに関して静的テーブルが保持される。このスラック・テーブルは、タスク活動化時、およびタスク非活動化時に再計算される。
【０３７３】
ボックス１０９で、累算器が、消費されたスラック、再利用されるスラック、およびアイドル時間を含むスラック関係のパラメータを記録にとるように保持される。累算器の内容に基づき、消費されたスラック、再利用されるスラック、およびアイドル時間をすべて計算することができる。
【０３７４】
ボックス１１１で、累算器が、以下のグループからのイベントが出現すると、更新される。
・周期境界を越えるとき、
・タスクが、再利用されるべきスラックを有する固定予算で実行される際、周期に関して完了したとき、
・タスクを実行するプロセッサが、アイドルからビジーに遷移したとき、
・タスクが、スラックで実行されている際、周期に関して完了したとき、
・新しいスラック消費タスクに関する利用可能なスラックを計算する前に、また
・スラック消費スレッドによるミューテックス実行の前に。
【０３７５】
ボックス１１３で、コンテキスト・スワップ、キャッシュ・リフレッシュなどのスラックを割り振ることに関連するオーバーヘッドを見越して累算器が事前に減分される。
【０３７６】
ボックス１１５で、スラックがタスクに、タスクの優先順位に応じて割り振られ、最高優先順位のタスクに、最初にスラックが割り振られる。この結果、非周期的な高優先順位のタスクは、周期的な低優先順位のタスクからスラックをスチールすることを、その周期的タスクのハードな実行期限に影響を与えることなく行うことができる。
【０３７７】
ボックス１１７で、方法が終了する。
図１８Ａ〜Ｂに示した方法に関連して前述した動作は、本明細書で説明したのとは異なる順序で行うことができる。また、ＢｅｇｉｎボックスおよびＥｎｄボックスを示しているが、方法は、通常、連続的に行われることも理解されよう。
【０３７８】
図１９は、マシン可読媒体１３２に結合されたプロセッサ１３０を描いたブロック図である。プロセッサ１３０は、その他のプロセッサおよび／またはデータ処理システムのその他の構成要素と通信するため、バス１３４にさらに結合されていることが可能である。マシン可読媒体１３２には、内部記憶媒体またはプログラマブル・メモリ・デバイスなどの、プロセッサ１３０に結合された固定デバイスが含まれることが可能である。マシン可読媒体１３２には、取外し可能な記憶媒体またはプログラミンググ・カートリッジなどの、プロセッサ１３０に結合された取外し可能なデバイスがさらに含まれることが可能である。マシン可読媒体１３２は、プロセッサ１３０が、本明細書で説明した方法を実行するようにさせることができる記憶された命令をマシン可読形式で含む。
【０３７９】
セクション６−詳細な説明の結論
本発明は、周期的で動的なタスクを包含するリアルタイム環境においてスラック・スチールを提供することができるタスク・スケジューラのための装置と方法をともに提供する。本明細書で説明したとおり動作することができるコンピュータ・システムが、航空宇宙の航空管制システムおよび産業プロセス制御システムを含むが、それらには限定されない多くのタイプのリアルタイム制御システムにおいて商業上、望ましい。
【０３８０】
本発明の様々な実施形態を使用して、マルチタスク・システムのタスク・スケジューリング活動を行う電子システムを定義することができる。説明した電子システムは、マシン可読形式の命令を利用して本明細書で説明した方法を実行する１つまたは複数のプロセッサを有する様々な電子機器を使用する。
【０３８１】
本明細書では、特定の実施形態を例示して説明してきたが、同一の目的を達するように計算された任意の構成で、提示した特定の実施形態を置き換えるのが可能であることが、当分野の技術者には理解されよう。本発明の多くの適合形態が、当分野の技術者には明白であろう。したがって、本出願は、本発明のあらゆる適合形態および変形形態を範囲に含むものとする。本発明は、明示的に、頭記の特許請求の範囲およびそれと等価のものだけによって限定されるものとする。
【図面の簡単な説明】
【図１】
本発明の実施形態に従って使用するための航空管制システムを示す概略図である。
【図２】
本発明の実施形態によるマルチタスク・システムを示すブロック図である。
【図３】
従来技術の３つのタスクの従来の速度単調スケジューリングを示すタスク実行時間線である。
【図４】
利用されていない利用可能な／未使用のスラックを示すタスク実行時間線である。
【図５】
時間線スラック、再利用されるスラック、およびアイドル時間を示すタスク実行時間線である。
【図６】
４つの異なるスラック・レベルで非周期的タスクによるスラック消費の連続的要求が存在するときの周期実行時間を示すタスク実行時間線である。
【図７】
第１のレベルでスラック消費の連続的要求が存在するときの周期実行時間を示すタスク実行時間線である。
【図８】
間隔［１５，１６］で１０ユニット以上のスラックを求める第２のレベルにおけるスラック消費の初期要求が存在するときの周期実行時間を示すタスク実行時間線である。
【図９】
一群の周期的タスク時間線を示す図である。
【図１０】
最悪ケースの時間線を示すタスク実行時間線である。
【図１１】
未使用の計算時間からのスラック再利用を示すタスク実行時間線である。
【図１２】
動的スレッド活動化に関する概念モデルを示すタスク実行時間線である。
【図１３】
スラック要求を伴わない観察されたスレッド活動化を示すタスク実行時間線である。
【図１４】
本発明の実施形態によるスラック要求を伴うスレッド活動化を示すタスク実行時間線である。
【図１５】
スラック・スチールを伴わないタスク実行を示すタスク実行時間線である。
【図１６】
再利用されるスラックと時間線スラックをともに使用するタスク実行を示すタスク実行時間線である。
【図１７】
再利用されるスラックを使用するタスク実行を示すタスク実行時間線である。
【図１８】
図１８Ａは、本発明の実施形態による、調和的で動的なタスクを実行するシステムにおいてスラック・スチールを使用するタスク・スケジューリングの様々な方法を包含するプロセス流れ図である。
図１８Ｂは、本発明の実施形態による、調和的で動的なタスクを実行するシステムにおいてスラック・スチールを使用するタスク・スケジューリングの様々な方法を包含するプロセス流れ図である。
【図１９】
マシン可読媒体に結合されたプロセッサを描いたブロック図である。

Claims (28)

  1. 異なる時間区分の中でタスクを実行するデータ処理システムにおいて、
    利用可能なスラックを決定するステップと、および
    異なる時間区分の中のタスクにスラックを割り振るステップと、
    を含むタスクをスケジュール設定する方法。
  2. スラックを割り振られる前記タスクは、非周期的な重要ではないタスクである、請求項１に記載の方法。
  3. 前記タスクは、重要なタスクおよび重要ではないタスクを含み、スラックを割り振られる前記タスクは、新しい重要ではないタスク、および重要なタスクに対する拡張からなるグループからのタスクである、請求項２に記載の方法。
  4. 決定する際、時間線スラックと再利用されるスラックがともに決定される、請求項１に記載の方法。
  5. 異なる時間区分の中で実行するようにタスクをスケジュール設定するステップと、
    利用可能なスラックを決定するステップと、および
    異なる時間区分の中のタスクにスラックを割り振るステップとを含む、プロセッサに方法を実行させることができる命令を記憶しているマシン可読媒体。
  6. 第１の時間区分の中でスケジュール設定されていない実行時間を探すステップと、および
    前記第１の区分の中でスケジュール設定されていない実行時間が見つかった場合、前記スケジュール設定されていない実行時間を第２の区分の中のタスクに割り振るステップと、
    を含むタスクをスケジュール設定する方法。
  7. 前記第２の区分の中の前記タスクは、非周期的な重要ではないタスクである、請求項６に記載の方法。
  8. 前記タスクは、重要なタスクおよび重要ではないタスクを含み、また前記第２の区分の中の前記タスクが、新しい重要ではないタスク、および重要なタスクに対する拡張からなるグループからのタスクである、請求項７に記載の方法。
  9. スケジュール設定されていない実行時間を探す際、時間線スラックと再利用されるスラックがともに考慮される、請求項６に記載の方法。
  10. 異なる時間区分の中で実行されるようにタスクをスケジュール設定するステップと、
    第１の時間区分の中でスケジュール設定されていない実行時間を探すステップと、および
    前記第１の区分の中でスケジュール設定されていない実行時間が見つかった場合、前記スケジュール設定されていない実行時間を第２の区分の中のタスクに割り振るステップとを含む、
    プロセッサに方法を実行させることができる命令を記憶しているマシン可読媒体。
  11. 重要なタスクおよび重要ではないタスクを実行する時間区分化されたシステムにおいて、
    時間線スラックおよび再利用されるスラックからなるグループからの利用可能なスラックを決定するステップと、
    利用可能なスラックを共通スラック・プールの中にプールするステップと、および
    前記共通スラック・プールからのスラックをタスクに割り振るステップと、
    を含むタスクをスケジュール設定する方法。
  12. 割振りを行う際、スラックは、重要ではないタスクに割り振られる、請求項１１に記載の方法。
  13. 割振りを行う際、スラックは、新しい重要ではないタスク、および重要なタスクに対する拡張からなるグループからのタスクに割り振られる、請求項１１に記載の方法。
  14. 異なる時間区分の中で実行されるようにタスクをスケジュール設定するステップと、
    時間線スラックおよび再利用されるスラックからなるグループからの利用可能なスラックを決定するステップと、
    利用可能なスラックを共通スラック・プールの中にプールするステップと、および
    前記共通スラック・プールからのスラックをタスクに割り振るステップと、
    を含むプロセッサに方法を実行させることができる命令を記憶しているマシン可読媒体。
  15. 重要なタスクおよび重要ではないタスクを実行する時間区分化されたシステムにおいて、
    利用可能な時間線スラックを決定するステップと、
    利用可能な再利用されるスラックを決定するステップと、
    利用可能な時間線スラックおよび利用可能な再利用されるスラックをプールするステップと、および
    スラックを任意の時間区分の中のタスクに割り振るステップと、
    を含むタスクをスケジュール設定する方法。
  16. 割振りを行う際、スラックは、重要ではないタスクに割り振られる、請求項１５に記載の方法。
  17. 割振りを行う際、スラックは、新しい重要ではないタスク、および重要なタスクに対する拡張からなるグループからのタスクに割り振られる、請求項１５に記載の方法。
  18. プロセッサに方法を実行させることができる命令を記憶しているマシン可読媒体であって、
    前記方法が、
    異なる時間区分の中で実行されるようにタスクをスケジュール設定するステップと、
    利用可能な時間線スラックを決定するステップと、
    利用可能な再利用されるスラックを決定するステップと、
    利用可能な時間線スラックおよび利用可能な再利用されるスラックをプールするステップと、および
    スラックを任意の時間区分の中のタスクに割り振るステップと、
    を含む媒体。
  19. プロセッサと、
    それぞれが、重要なもの、および重要でないものからなるグループから選択されたタスク・タイプであり、またそれぞれに、少なくとも１つの最悪ケースの実行時間が関連している、前記プロセッサ上で実行される複数のタスクと、
    前記プロセッサと通信し、前記プロセッサ上でタスクをディスパッチすることを制御するエグゼクティブであって、
    利用可能なスラックを決定する第１のモジュールと、
    利用可能なスラックを異なる時間区分の中のタスクに割り振る第２のモジュールとを含むエグゼクティブとを含む時間区分化されたシステム。
  20. 前記第１のモジュールは、時間線スラック、再利用されるスラック、およびアイドル時間からなるグループからのスラックを決定することによって利用可能なスラックを決定する、請求項１９に記載の時間区分化されたシステム。
  21. 前記第１のモジュールは、利用可能なスラックのプールを保持する、請求項２０に記載の時間区分化されたシステム。
  22. 前記第１のモジュールは、任意の時間区分の中のタスクによって使用されることが可能な利用可能なスラックの共通プールを保持する、請求項２０に記載の時間区分化されたシステム。
  23. 前記第２のモジュールは、利用可能なスラックを重要ではないタスクに割り振る、請求項１９に記載の時間区分化されたシステム。
  24. 前記タスクは、新しい重要ではないタスク、および重要なタスクに対する拡張からなるグループからのタスクである、請求項２３に記載の時間区分化されたシステム。
  25. 前記エグゼクティブは、異なる優先順位レベルをタスクに割り当てる第３のモジュールをさらに含む、請求項２３に記載の時間区分化されたシステム。
  26. 前記第１のモジュールは、各優先順位レベルにおけるタスクに関する利用可能なスラックを決定する、請求項２３に記載の時間区分化されたシステム。
  27. 前記第２のモジュールは、利用可能なスラックを優先順位の順序でタスクに割り振る、請求項２３に記載の時間区分化されたシステム。
  28. 前記システムは、航空管制システムである、請求項１９に記載の時間区分化されたシステム。
JP2002554867A 2000-12-29 2001-06-01 動的スレッドを有するスラック・スチールのための方法および装置 Withdrawn JP2004533667A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/751,955 US7140022B2 (en) 2000-06-02 2000-12-29 Method and apparatus for slack stealing with dynamic threads
PCT/US2001/017738 WO2002054237A2 (en) 2000-12-29 2001-06-01 Methods and apparatus for slack stealing with dynamic trheads

Publications (1)

Publication Number Publication Date
JP2004533667A true JP2004533667A (ja) 2004-11-04

Family

ID=25024230

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002554867A Withdrawn JP2004533667A (ja) 2000-12-29 2001-06-01 動的スレッドを有するスラック・スチールのための方法および装置

Country Status (3)

Country Link
EP (1) EP1433054A2 (ja)
JP (1) JP2004533667A (ja)
WO (1) WO2002054237A2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10768984B2 (en) 2015-06-11 2020-09-08 Honeywell International Inc. Systems and methods for scheduling tasks using sliding time windows

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2219112A3 (en) * 2009-01-23 2012-08-15 Imec Method and system for operating in hard real time
JP5689239B2 (ja) 2010-02-03 2015-03-25 昭和シェル石油株式会社 ガソリンエンジンおよびディーゼルエンジン油
US9465664B1 (en) * 2015-09-09 2016-10-11 Honeywell International Inc. Systems and methods for allocation of environmentally regulated slack

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10768984B2 (en) 2015-06-11 2020-09-08 Honeywell International Inc. Systems and methods for scheduling tasks using sliding time windows
US11507420B2 (en) 2015-06-11 2022-11-22 Honeywell International Inc. Systems and methods for scheduling tasks using sliding time windows

Also Published As

Publication number Publication date
WO2002054237A2 (en) 2002-07-11
EP1433054A2 (en) 2004-06-30
WO2002054237A3 (en) 2004-04-01

Similar Documents

Publication Publication Date Title
US7302685B2 (en) Methods and apparatus for sharing slack in a time-partitioned system
US7140022B2 (en) Method and apparatus for slack stealing with dynamic threads
US7207042B2 (en) System and method for robust time partitioning of tasks in a real-time computing environment
Baker et al. The cyclic executive model and Ada
Sha et al. Real-time scheduling theory and Ada
Fidge Real-time schedulability tests for preemptive multitasking
Jones et al. {CPU} Reservations and Time Constraints: Implementation Experience on Windows {NT}
Schwan et al. Multiprocessor real-time threads
van den Heuvel et al. Transparent synchronization protocols for compositional real-time systems
WO2002054238A2 (en) Methods and apparatus for sharing slack in a time-partitioned system
Burns et al. Restricted tasking models
JP2004533667A (ja) 動的スレッドを有するスラック・スチールのための方法および装置
Wellings et al. Cost enforcement and deadline monitoring in the real-time specification for Java
Elrad Comprehensive race control: A versatile scheduling mechanism for real-time applications
Burns et al. Guide for the use of the Ada Ravenscar Profile in high-integrity systems
WO2004019205A2 (en) System and method for robust time partitioning of tasks in a real-time computing environment
van den Heuvel et al. Dependable resource sharing for compositional real-time systems
Corbett Constructing abstract models of concurrent real-time software
Dos Santos et al. On the design and implementation of real-time resource access protocols
Nicolau Specification and analysis of weakly hard real-time systems
Baxter Requirements for Safety-Critical Java Virtual Machines
Naedele Petri net models for single processor real-time scheduling
Xu A Semi-partitioned Model for Scheduling Mixed Criticality Multi-core Systems
Tessler et al. Bringing Inter-Thread Cache Benefits to Federated Scheduling--Extended Results & Technical Report
Destelle et al. Deterministic scheduling reconciles cache with preemption for WCET estimation

Legal Events

Date Code Title Description
A300 Application deemed to be withdrawn because no request for examination was validly filed

Free format text: JAPANESE INTERMEDIATE CODE: A300

Effective date: 20080805