オペレーティング システムに関する注意事項 - プロセス管理

2. プロセス管理

2.1 プロセスとスレッド

2.1.1 プロセスの紹介

コンピュータのオペレーティング システムでは、プロセスはリソース割り当ての基本単位であり、独立した操作の基本単位です。。

プリカーサーグラフ

先行グラフは有向非巡回グラフであり、各ノードはステートメント、プログラム セグメント、プロセスを表すことができ、ノード間の有向辺は 2 つのノード間の半順序または先行関係を表します。

→={(Pi _, P _j )|P _{i は}P _jが実行を開始する前に完了する必要があります}

プログラムの逐次実行

通常、プログラムは複数のプログラム セグメントで構成されます。これらは特定の順序で実行する必要があり、後続の操作は前の操作が実行された後にのみ実行できます。、この種の計算処理は、プログラムの逐次実行処理です。たとえば、ジョブを処理する場合、常に最初にユーザーのプログラムとデータが入力され、次に計算が実行され、最後に結果が印刷されます。

• 連続性。プロセッサの操作はプログラムで指定された順序で厳密に実行されます。つまり、各操作は次の操作が開始される前に終了する必要があります。
• 親近感。プログラムが実行を開始すると、その実行結果は外部要因の影響を受けません。プログラムは実行中にシステムのさまざまなリソースを独占するため、これらのリソースの状態 (初期状態を除く) はこのプログラムによってのみ変更できます。
• 再現性。プログラムを実行するときの初期条件と実行環境が同じであれば、プログラムを繰り返し実行しても同じ結果が得られます（つまり、プログラムの実行結果は時間に関係ありません）。

プログラムの同時実行

プログラムの同時実行とは、システム内で複数のプログラム (またはプログラム) が同時に実行されていることを意味します。これら (シーケンス) の実行は時間的に重複します。つまり、1 つのプログラム (またはプログラム セグメント) の実行は重なっていません。まだ終了していて、別のプログラム（またはプログラムセグメント）の実行がまだ終了していません。プログラムセクション）行が開始されました。

プログラムの同時実行により、システムの処理能力とリソース使用率が向上しますが、いくつかの新たな問題も生じ、順次実行とは異なるいくつかの特性も生じます。

• 間欠。プログラムが同時に実行される場合、プログラムはリソースを共有したり、同じタスクを完了するために互いに協力したりするため、相互に制限的な関係が形成されます。図 2-1 では、C ₁が完了しないと P ₁が実行できず、ジョブ 1 の印刷動作が中断されますが、これは同じタスクを完了するための相互協力による直接的な制約関係_です。 not completed, then I ₂、ジョブ 2 の入力操作が停止します。これは、共有リソースによる間接的な制限関係です。この相互制約関係により、並行プログラムは「実行、一時停止、実行、実行」という断続的な動作パターンを持つことになります。

• 閉鎖の喪失。プログラムを同時に実行すると、複数のプログラムがシステム内のさまざまなリソースを共有するため、これらのリソースのステータスが複数のプログラムによって変更され、プログラムが終了せずに実行されます。このようなプログラムを実行すると、プロセッサが占有されているプログラムが待機するなど、必ず他のプログラムの影響を受けることになります。

• 再現不可能性。プログラムを同時に実行すると、クロージャーが失われるため、実行結果の再現性も失われます。たとえば、変数 N を共有する 2 つのループ プログラム A と B があります。プログラム A が実行されるたびに N=N+1 操作が実行され、プログラム B が実行されるたびに print(N) 操作が実行され、その後 N=0 になります。プログラム A とプログラム B の実行は両方とも独立した速度で進行するため、プログラム A の N=N+1 操作は、print(N) 操作および B の N=0 操作の前に送信することも、プログラム A の N=0 操作の前に送信することもできます。 . 後または途中。ある瞬間の N の値を n とすると、B の 2 つの演算の前後で N=N+1 が現れる 2 つの状況 (図 2-2 を参照) について、サイクルの実行後に出力される N の値n+1とnです。

• プログラムの同時実行条件

  プログラムが同時に実行される場合、結果は再現不可能であり、ユーザーが望む結果ではありません。この目的を達成するために、プログラムは閉じたままにし、同時に実行するときに再現可能にする必要があります。同時実行におけるクロージャの損失は共有リソースの影響であるため、現在行うべき作業は、この影響を排除することです。

２つのプログラムｐ１、ｐ２は、以下の３つの条件を満たすことができれば_、同時に_実行することができ、その結果は再現可能である。

2.1.2 プロセスの定義と説明

マルチプログラミング環境では、プログラムの同時実行によりプログラムの閉鎖性と再現性が破壊され、プログラムと計算が 1 対 1 に対応しなくなり、プログラムの活動が閉鎖系ではなくなり、プログラムの動作に多くの新たな問題が発生します。プログラムの機能。この場合、プログラムの静的な概念はプログラム活動のこれらの特性を忠実に反映できなくなるため、新しい概念であるプロセスが導入されます。

プロセス定義

• プロセスとは、プロセッサ上でのプログラムの実行です。
• プロセスとは、他のプロセスと並行して実行できる計算です。
• プロセスは、データ収集上でプログラムを実行するプロセスであり、システム内のリソース割り当てとスケジューリングのための独立した単位です。
• プロセスは、データ構造とその上で動作できるプログラムとして定義できます。
• プロセスは、プログラムがプロセッサ上で一連のデータを実行するときに発生するアクティビティです。

プロセスの特徴

• 動的。プロセスはプロセッサ上でのプログラムの実行プロセスであるため、動的です。動的特性は、作成によって生成され、スケジューリングによって実行され、リソース不足によって中断され、最後にキャンセルによって終了するという点でも表れます。
• 同時実行性。同時実行性とは、複数のプロセスが同時にメモリ内に存在し、一定期間同時に実行できることを意味します。プロセスを導入する目的は、プログラムを他のプログラムと同時に実行できるようにして、リソースの使用率を向上させることです。
• 独立。プロセスは、独立して実行できる基本単位であり、システムによるリソースの割り当てとスケジューリングの独立した単位でもあります。
• 非同期性。非同期性とは、プロセスが独立した予測不可能な速度で前進することを意味します。
• 構造。プロセスの動きの変化を記述して記録し、正しく実行できるようにするために、プロセス制御ブロック (PCB) はプロセスごとに構成する必要があります。構造的な観点から見ると、各プロセスはプログラム セグメント、データ セグメント、およびプロセス制御ブロックで構成されます。。

プロセスとプログラムの関係

• プロセスは動的であり、プログラムは静的です。プロセスとは、プログラムの実行です。各プロセスには、プログラム セグメント、データ セグメント、およびプロセス制御ブロック (PCB) が含まれます。プログラムは、実行意味を持たない順序付けられたコードの集合です。
• プロセスは一時的なものですが、プログラムは永続的です。プロセスとは状態が変化する過程であり、プログラムは長期保存が可能です。
• プロセスとプログラムのコンポーネントは異なります。プロセスは、プログラム セグメント、データ セグメント、およびプロセス制御ブロックで構成されます。
• 複数の実行を通じて、1 つのプログラムが複数の異なるプロセスを生成でき、呼び出し関係を通じて 1 つのプロセスが複数のプログラムを実行できます。プロセスは他のプロセスを作成できますが、プログラムは新しいプログラムを作成できません。
• プロセスには並列特性 (独立性、非同期性) がありますが、プログラムにはありません。

プロセス イメージは、プログラム セグメント、関連データ セグメント、およびプロセス エンティティとも呼ばれる PCB の 3 つの部分で構成されます。プロセス イメージは静的、プロセスは動的、プロセスはプロセス エンティティの実行プロセスです。

プロセスとジョブの違い

ジョブは、特定のタスクを完了するためにユーザーがコンピュータに実行するように要求する作業の集合です。ジョブの完了は、ジョブの送信、ジョブの封じ込め、ジョブの実行、ジョブの完了の 4 つの段階を経ます。プロセスは、投入されたジョブの実行プロセスであり、リソース割り当ての基本単位です。

• ジョブは、ユーザーがコンピュータに送信するタスク エンティティです。ユーザーがジョブをコンピュータに送信すると、システムはそのジョブを外部メモリ内のジョブ待機キューに入れて実行を待ちます。プロセスはユーザーのタスクを完了する実行エンティティであり、システムに適用される割り当ての基本単位です。リソース。。どのようなプロセスでも、作成される限り、対応する部分がメモリ内に常に存在します。
• ジョブは複数のプロセスで構成でき、少なくとも 1 つのプロセスで構成する必要がありますが、プロセスは複数のジョブを構成することはできません。。
• ジョブの概念は主にバッチ処理システムで使用されます。UNIX のようなタイムシェアリング システムにはジョブの概念がありませんが、プロセスの概念はほぼすべてのマルチプログラミング システムで使用されます。

プロセス構成

• プロセス制御ブロック (PCB)。各プロセスには PCB があります。PCB は、プロセスの存在を識別し、実行の瞬間を特徴付けることができるデータ構造です。。プロセスが作成されると、システムはそれに対応する PCB を割り当てて構築します。
• プログラムセグメント。プログラムセグメントは、CPU 上で実行されるプログラムによってスケジュールできるプロセス内のプログラムコードのセグメントです。、対応する特定の機能を実現できます。
• データセグメント。プロセスのデータセグメントこれは、プロセスに対応するプログラムによって処理された元のデータである場合もあれば、プログラムの実行時に生成される中間データまたは結果データである場合もあります。。

PCB はプロセスの存在を示す唯一の兆候です。

PCB には次のものが含まれます。

• プロセス識別子 (PID)。各プロセスには、システム内の他のプロセスと区別するための一意のプロセス識別子があります。プロセスが作成されると、システムによって一意のプロセス識別番号が割り当てられます。
• プロセスの現在のステータス。プロセス スケジューラがプロセッサを割り当てるための基礎として、プロセスの現在の状態を記述します。
• プロセスキューポインタ。PCB キュー内の次の PCB のアドレスを記録するために使用されます。システム内の PCB は、レディ キュー、ブロッキング キューなどの複数のキューに編成される場合があります。
• プログラムアドレスとデータアドレス。プロセスのプログラムとデータが配置されているアドレスを示します。
• プロセスの優先順位。プロセスが CPU をどれだけ緊急に必要とするかを反映します。優先度の高いプロセスが最初にプロセッサを取得します。
• CPU サイト保護ゾーン。プロセスが何らかの理由でプロセッサを解放すると、CPU ローカル情報 (カウンタ ステータス レジスタ、汎用レジスタなど) が PCB のこの領域に保存され、プロセッサを取り戻した後もプロセスが実行を継続できるようになります。
• コミュニケーション情報。実行中にプロセスと他のプロセスの間で発生する情報交換を記録します。
• 家族のつながり。一部のシステムでは、プロセスが子プロセスを作成できるため、プロセス家系図が形成されます。PCB では、子プロセスと親プロセスの識別など、このプロセスとそのファミリーの間の関係を指定する必要があります。
• 保有リソースリスト。プロセスに必要なリソースと現在割り当てられているリソースのリスト。

システムには通常、多くのプロセスがあり、一部は準備完了状態、一部はブロック状態であり、ブロックされる理由は異なります。プロセスのスケジューリングと管理を容易にするために、各プロセスの PCB を適切な方法で編成する必要があります。現在一般的に使用されている整理方法には、リンクとインデックス作成が含まれます。。

PCB の役割は、プログラムの同時実行を保証することです。プロセスの作成は基本的にプロセスの PCB の作成であり、プロセスのキャンセルは基本的にプロセスの PCB のキャンセルです。

PCB がプロセスの存在を示す唯一の兆候であるのはなぜですか?

プロセスのライフサイクル全体を通じて、システムは常に PCB を通じてプロセスを制御します。つまり、システムはプロセスの PCB に基づいてプロセスの存在を認識します。したがって、PCB はプロセスの存在を示す唯一の兆候です。プロセス。

2.1.3 プロセスの状態と遷移

プロセスの 5 つの基本状態

• 準備完了状態。プロセスはプロセッサを除くすべてのリソースを取得しました。プロセッサを取得すると、すぐに実行できます。この時点で、プロセスは準備完了状態になります。
• 実行状態（実行状態）。プロセスが必要なリソースを取得し、CPU 上で実行している場合、プロセスは実行状態になります。
• ブロッキング状態（待機状態）。実行中のプロセスは、イベントの発生（I/Oの完了待ちなど）により一時的に実行できなくなり、ブロック状態となります。プロセスがブロックされると、プロセッサが割り当てられていても実行できなくなります。

質問をするときは、準備完了状態とブロック状態の区別に特に注意してください。この 2 つを区別するポイントは、プロセスにプロセッサを割り当てたときにすぐに実行できるかどうかです。すぐに実行できる場合は、それ以外の場合はブロックされます。

• ステータスを作成します。プロセスは作成中であり、まだ準備完了状態に移行していません。空の PCB を申請し、制御および管理プロセスに関する情報を PCB に入力します。その後、システムはプロセスの実行に必要なリソースを割り当て、最終的にプロセスは準備完了状態に移行します。
• 終了状態。プロセスはシステムから消えようとしています。正常に終了したか、他の理由で中断された可能性があります。

プロセス状態の相互変換

• 準備完了状態 - 実行状態。プロセスはプロセス スケジューラによって選択されます。
• 実行状態はブロッキング状態です。リクエストしてイベントが発生するのを待ちます。
• 実行状態は準備完了状態です。タイム スライスがなくなるか、プリエンプティブ スケジューリングで優先度の高いプロセスが準備完了になります。
• ブロッキング状態 - 準備完了状態。プロセスは、特定の条件が発生するのを待っているため目覚めます。

以上のことから結論付けられるのは、

• すべてのプロセス状態遷移が元に戻せるわけではありません。プロセスは、ブロッキング状態から実行状態に変更することも、準備完了状態からブロッキング状態に変更することもできません。。
• プロセス間の状態遷移は、すべてがアクティブであるわけではありません。多くの場合、それらはパッシブです。実行状態からブロッキング状態への遷移のみがプログラムの自己動作であり (ブロッキング プリミティブはイベントによってアクティブに呼び出されます)、残りはプログラムの自己動作です。受動的です。
• プロセスステータスの一意性。特定のプロセスは、常に 1 つの状態にある必要があり、1 つの状態のみにすることができます。

2.1.4 プロセス制御

プロセス制御の責任は、システム内のすべてのプロセスを効果的に管理することであり、その機能には、プロセスの作成、プロセスのキャンセル、プロセスのブロックと覚醒などが含まれます。これらの機能は通常、オペレーティング システムのカーネルによって実装されます。

プロセスの作成

• プロセスプリカーサーグラフ

• プリミティブの作成

  • ユーザーログイン。タイムシェアリングシステムでは、ユーザーが端末にログイン情報を入力し、システムがプロセスを検出して通過すると、端末ユーザー用に新しいプロセスが作成され、レディキューに挿入されます。
  • ジョブのスケジュール設定。バッチ処理システムでは、ジョブ スケジューラが特定のアルゴリズムに従ってジョブをスケジュールすると、ジョブがメモリにロードされ、リソースが割り当てられ、プロセスが作成され、実行可能キューに挿入されます。
  • サービスをリクエストしてください。プロセスのニーズに基づいて、新しいプロセスが自動的に作成され、特定のタスクを完了します。

  プロセスの作成プリミティブが実装されており、その主な操作プロセスは次のとおりです。

  • まずシステムから無料の PCB を申請し、一意のプロセス識別子 (PID) を指定します。
  • 必要なリソースを新しいプロセスに割り当てます。
  • 新しいプロセスの PCB を初期化します。新しいプロセスの PCB のプロセス名、ファミリー情報、プログラム データ アドレス、優先順位などの情報を入力します。
  • 新しいプロセスの PCB を準備完了キューに挿入します。

ペアを元に戻す処理

プロセスが占有しているさまざまなリソースを速やかに解放するには、タスクの完了後にプロセスをキャンセルする必要があります。cancel プリミティブは 2 つの戦略を採用できます。1 つは指定された識別子を持つプロセスのみをキャンセルする方法、もう 1 つは指定されたプロセスとそのすべての子孫プロセスをキャンセルする方法です。。プロセスのキャンセルにつながるイベントには、プロセスの正常終了、プロセスの異常終了、外部介入などがあります。

cancel プリミティブの機能はプロセスをキャンセルすることであり、その主な操作プロセスは次のとおりです。

• まず、PCB コレクションで元に戻すプロセスの PCB を見つけます。
• 取り消されたプロセスが実行状態にある場合は、プロセスの実行を直ちに停止し、プロセスが取り消された後にプロセッサを他のプロセスに割り当てられるように再スケジュール フラグを設定する必要があります。
• 後者の取り消し戦略では、取り消されたプロセスに子孫プロセスがある場合、そのプロセスの子孫プロセスも取り消す必要があります。
• 取り消されたプロセスによって占有されていたリソースをリサイクルするか、親プロセスに戻すか、システムに戻します。最後に、PCB をリサイクルします。

プロセスのブロックと覚醒

ブロッキング プリミティブ (P プリミティブ) の機能はプロセスを実行状態からブロッキング状態に変更することであり、ウェイクアップ プリミティブ (V プリミティブ) の機能はプロセスをブロッキング状態から準備完了状態に変更することです。 。

ブロッキングプリミティブの主な操作プロセスは次のとおりです。

• まず、現在のプロセスの実行を停止します。プロセスが実行中であるため、プロセッサは中断される必要があります。
• プロセスの CPU コンテキストを保存して、後でプロセスを呼び出して、中断した時点から実行を再開できるようにします。
• プロセスを停止し、プロセスの状態を実行状態からブロック状態に変更してから、プロセスを対応するイベントの待機キューに挿入します。
• プロセス スケジューラに移動し、実行可能キューから新しいプロセスを選択して実行します。

ウェイクアップ プリミティブの主な動作プロセスは次のとおりです。

• 目覚めたプロセスを対応する待機キューから削除します。
• ステータスを準備完了に変更し、対応する準備完了キューに挿入します。

プロセス切り替え

プロセススイッチングは、プロセッサが、あるプロセスの実行から別のプロセスの実行に切り替えることを指します。このプロセス中に、プロセスの実行環境は大幅に変化します。。

プロセス切り替えのプロセスは次のとおりです。

• プログラム カウンターやその他のレジスターを含む、処理とコンテキストを保存します。
• PCB情報を更新します。
• プロセスの PCB を、特定のイベントの準備完了キュー、ブロックキューなどの対応するキューに移動します。
• 別のプロセスを選択して実行し、その PCB を更新します。
• メモリ管理データ構造を更新します。
• プロセッサーのコンテキストを復元します。

プロセスの切り替えにより、割り込みとプロセッサ モードの切り替え (つまり、ユーザー モードからカーネル モードに戻り、その後ユーザー モードに戻ります) が確実に生成されますが、プロセッサ モードの切り替えが必ずしもプロセスの切り替えを引き起こすわけではありません。たとえば、システム コールも切り替わります。ユーザー モードからカーネル モードに移行し、その後ユーザー モードに戻りますが、論理的には、同じプロセスが実行のためにプロセッサを占有したままになります。

2.1.5 プロセス通信

プロセスコミュニケーションは、プロセス間の情報交換を指します。。プロセスの相互排他と同期は、プロセス間の通信方法です。プロセス相互排除と同期の間で交換される情報量が少なく効率が低いため、これら 2 つのプロセス通信方式は、低レベル プロセス通信方式と呼ばれます。

同様に、P および V プリミティブは 2 つの低レベル プロセス通信プリミティブとも呼ばれます。

高度なプロセス通信方式は、共有メモリ システム、メッセージ パッシング システム、およびパイプライン通信システムの 3 つの主要なカテゴリに分類できます。

共有メモリシステム

大量のデータを転送するために、メモリ上に共有記憶領域が確保され、複数のプロセスが共有記憶領域に読み書きすることで通信することができます。通信の前に、システムに共有記憶領域を確立するプロセスが適用され、共有記憶領域のキーワードが指定されます。共有記憶領域が設定されている場合には、その共有記憶領域のディスクリプタが申請者に返却される。次に、申請者は、取得した共有記憶領域をプロセスに接続します。このようにして、プロセスは通常のメモリの読み書きと同じように共有メモリ領域の読み書きを行うことができます。

メッセージングシステム

メッセージング システムでは、プロセス間のデータのやり取りはメッセージ単位で行われ、利用者はシステムが提供する通信コマンド群（プリミティブ）を直接利用して通信を実現します。。オペレーティング システムは、通信の実装詳細を隠蔽し、通信手順を簡素化し、広く使用されています。

実装方法に応じて、メッセージング システムは次の 2 つのカテゴリに分類できます。

• 直接コミュニケーションをとる方法。送信プロセスはメッセージを受信プロセスに直接送信し、受信プロセスのメッセージ バッファ キューにハングし、受信プロセスはメッセージ バッファ キューからメッセージを取得します。
• 間接的なコミュニケーション方法。送信プロセスはメッセージを中間エンティティ (通常はメールボックスと呼ばれます) に送信し、受信プロセスはそこからメッセージを取得します。この通信方式はメールボックス通信とも呼ばれます。この通信方式はコンピュータネットワークで広く使われており、これに対応した通信システムは電子メールシステムと呼ばれています。

パイプ通信システム

パイプは、読み取りプロセスと書き込みプロセスを接続し、プロセス間の通信を可能にするために使用される共有ファイルです。。パイプに入力を与える送信プロセス（書き込みプロセス）は、大量のデータを文字ストリームの形式でパイプに送信し、パイプの出力を受け取るプロセス（読み取りプロセス）は、パイプからデータを受信できます。

2.1.6 スレッド

スレッドは、近年オペレーティング システムの分野で登場した非常に重要なテクノロジであり、その重要性はプロセスと同様に重要です。スレッドの導入によりプログラムの同時実行の度合いが向上し、システムのスループットがさらに向上します。

糸の概念

• スレッドの導入: オペレーティング システムにプロセスを導入する目的が、リソース使用率とシステム スループットを向上させるために複数のプログラムを同時に実行できるようにすることである場合、次のようになります。オペレーティング システムにスレッドを再導入する目的は、プログラムを同時に実行するときに発生する時間とスペースのオーバーヘッドを削減し、オペレーティング システムの同時実行性を向上させることです。。

• スレッドの定義

  • スレッドはプロセス内の実行単位であり、プロセスよりも小さいです。
  • スレッドは、プロセス内のスケジュール可能なエンティティです。
  • スレッドは、プログラム (またはプロセス) 内の比較的独立した制御フロー シーケンスです。
  • スレッド自体は単独で実行できず、プロセスに含めることができ、プロセス内でのみ実行できます。

  要約すると、スレッドを次のように定義するとよいでしょう。スレッドは、プロセス内で比較的独立したスケジュール可能な実行単位です。。スレッド自体は基本的にリソースを所有せず、実行時に不可欠な少数のリソース (プログラム カウンター、レジスタのセット、スタックなど) のみを所有しますが、プロセスが所有するすべてのリソースを他のスレッドと共有できます。同じプロセスに属します。

• スレッドの実装

  オペレーティング システムにスレッド サポートを実装するには、さまざまな方法があります。最も自然な方法は、オペレーティング システムのカーネルによってスレッド制御メカニズムを提供することです。プロセスという概念のみを持つオペレーティング システムでは、ユーザー プログラムは関数ライブラリを使用してスレッド制御メカニズムを提供できます。。もう 1 つのアプローチは、オペレーティング システムのカーネル レベルとユーザー プログラム レベルの両方でスレッド制御メカニズムを提供することです。

  • カーネルレベルのスレッド。カーネルに依存し、オペレーティング システム カーネルによって作成および破棄されるスレッドを指します。カーネル レベルのスレッドをサポートするオペレーティング システムでは、カーネルはプロセスとスレッドのコンテキスト情報を維持し、スレッドの切り替えを完了します。I/O 操作によりカーネル レベルのスレッドがブロックされても、他のスレッドの操作には影響しません。。現時点では、プロセッサ タイム スライスがスレッドに割り当てられるため、複数のスレッドを持つプロセスはより多くのプロセッサ時間を取得します。
  • ユーザーレベルのスレッドは、オペレーティング システムのコアに依存せず、スレッドの作成、同期、スケジュール、管理の機能を提供するスレッド ライブラリを使用してアプリケーション プロセスによって制御されるスレッドを指します。ユーザーレベルのスレッドのメンテナンスはアプリケーションプロセスによって完了するため、オペレーティングシステムのカーネルはユーザーレベルのスレッドの存在を認識する必要がなく、カーネルレベルのスレッドをサポートしていないマルチプロセスオペレーティングシステムでも使用できます。スレッド、さらにはシングルユーザーのオペレーティング システムでも可能です。ユーザーレベルのスレッド切り替えにはカーネル特権は必要なく、ユーザーレベルのスレッド スケジューリング アルゴリズムはアプリケーションに合わせて最適化できます。多くのアプリケーション ソフトウェアには独自のユーザーレベルのスレッドがあります。ユーザーレベルのスレッドのスケジューリングはアプリケーションプロセス内で実行されるため、通常は非プリエンプティブで単純なルールが使用され、ユーザー モードとカーネル モードを切り替える必要がないため、速度が特に高速になります。。もちろん、オペレーティング システムのカーネルはユーザー スレッドの存在を認識しないため、1 つのスレッドがブロックされると、プロセス全体が待機する必要があります。このとき、プロセッサタイムスライスがプロセスに割り当てられるため、プロセス内に複数のスレッドが存在する場合、各スレッドの実行時間が相対的に短縮されます。

• ネジロック

  スレッド ロックには、相互排他ロック、条件付きロック、スピン ロック、読み取り/書き込みロックが含まれます。一般に、ロックが強力になると、パフォーマンスが低下します。

  • ミューテックスロック。ミューテックスは、複数のスレッド間で共有されるリソースへの相互排他的アクセスを制御するために使用されるセマフォです。
  • 条件付きロック。条件付きロックは条件変数です。条件付きロックを使用すると、特定の条件が満たされたときにスレッドをブロックできます。条件が満たされると、その条件によってブロックされたスレッドが「セマフォ」の形式で目覚めます。
  • スピンロック。ミューテックスに似ていますが、異なります。スレッドは、ミューテックス ロックの適用に失敗すると他のタスクに切り替わり、スピン ロックの適用に失敗するとループと検出を継続します。。
  • 読み取り/書き込みロック。リーダライタ動作モデルのロックを実装しました。

スレッドのステータスと遷移

• スレッドの 6 つの状態
  • 初期 (NEW): 新しいスレッド オブジェクトが作成されますが、start() メソッドはまだ呼び出されていません。
  • 準備完了状態 (READY): スレッド オブジェクトが作成された後、プロセスの start() メソッドが呼び出され、プロセスは「実行可能なスレッド プール」に入り、実行可能になります。プロセスは、スレッド オブジェクトを使用する権利を取得するまで待つ必要があるだけです。実行前のCPU。今すぐ準備完了状態のスレッドは、CPU に加えて、動作に必要な他のすべてのリソースを取得しています。。新しく作成されたスレッドは準備完了状態に入る前に実行状態にあってはいけないため、start() メソッド自体を呼び出すことはできませんが、実行状態の他のスレッドによって呼び出されます。
  • 実行状態 (RUNNING): 準備完了状態のスレッドが CPU を取得した後、スレッドのコードの実行を開始します。
  • BLOCKED: スレッドは何らかの理由で CPU の使用権を放棄し、一時的に実行を停止します。
  • 待機中 (WAITING): スレッドが wait() メソッドを使用すると、待機状態になります (待機キューに入る)。この状態に入ると、ブロックとは異なり、占有されていたリソースが解放されます。この状態は自動的に起動することができないため、起動するには他のスレッドに依存して notification() メソッドを呼び出す必要があります。。
  • タイムアウト待機 (TIMED_WAITING): この状態は待機状態とは異なりますが似ています。唯一の違いは、時間制限があるかどうかです。つまり、この状態のスレッドは一定時間待機した後にウェイクアップされます。もちろん、この時間より前に起動することもできます。以前は、notify() メソッドによって起動されていました。
  • TERMINATED: スレッドが実行を完了したことを示します。

スレッドとプロセスの比較

• スケジューリング。従来のオペレーティング システムでは、リソースと独立したスケジューリングを備えた基本単位はプロセスです。スレッドを導入するオペレーティング システムでは、スレッドは独立したスケジューリングの基本単位であり、プロセスはリソース所有権の基本単位です。。同じプロセス内では、スレッドの切り替えによってプロセスの切り替えが発生することはありません。あるプロセスのスレッドから別のプロセスのスレッドに切り替えるなど、異なる
  プロセスでスレッドを切り替えると、プロセス切り替えが発生します。
• リソースを持っています。従来のオペレーティング システムであっても、スレッドを備えたオペレーティング システムであっても、プロセスはリソースを所有する基本単位であり、スレッドはシステム リソースを所有しません (すべてのリソースではなく、いくつかの重要なリソースがあります)。ただし、スレッドはそのリソースにアクセスできます。従属プロセスのシステムリソース。
• 同時実行性。スレッドを導入したオペレーティング システムでは、プロセスが同時に実行できるだけでなく、同じプロセス内の複数のスレッドも同時に実行できます。これにより、オペレーティング システムの同時実行性が向上し、システムのスループットが大幅に向上します。
• システムのオーバーヘッド。プロセスが作成またはキャンセルされると、システムはメモリ空間や I/O デバイスなどのリソースをそのプロセスに割り当てたり再利用したりする必要があるためです。オペレーティング システムが支払うオーバーヘッドは、スレッドの作成または破棄時のオーバーヘッドよりもはるかに大きくなります。。同様に、プロセスを切り替えるときは、現在のプロセス全体の CPU 環境を保存し、新しくスケジュールされたプロセスの CPU 環境を設定する必要があります。スレッドを切り替えるときは、少量のレジスタの内容を保存して設定するだけでよいため、オーバーヘッドは非常に少ない。さらに、同じプロセス内の複数のスレッドがプロセスのアドレス空間を共有するため、オペレーティング システムの介入がなくても、複数のスレッド間の同期と通信を非常に簡単に実現できます。

マルチスレッドモデル

一部のシステムはユーザー レベルのスレッドとカーネル レベルのスレッドの両方をサポートしているため、ユーザー レベルのスレッドとカーネル レベルのスレッドの接続方法に基づいて 3 つの異なるマルチスレッド モデルがあります。

• 多対一モデル。多対 1 モデルは、複数のユーザーレベルのスレッドを 1 つのカーネルレベルのスレッドにマップします。このモデルを使用するシステムでは、スレッドはユーザー空間で管理され、比較的効率的です。ただし、複数のユーザーレベルのスレッドが 1 つのカーネルレベルのスレッドにマップされるため、1 つのユーザーレベルのスレッドがブロックされる限り、プロセス全体がブロックされます。また、システムは 1 つのスレッド (カーネル レベルのスレッド) しか認識できないため、複数のプロセッサがある場合でも、プロセスの複数のユーザー レベルのスレッドは同時に 1 つしか実行できず、並列実行できません。。
• 1対1モデル。1 対 1 モデルは、カーネル レベルのスレッドをユーザー レベルのスレッドに 1 対 1 でマッピングします。これを行う利点は、スレッドがブロックされても、他のスレッドの実行には影響しないため、1 対 1 モデルの同時実行性は多対 1 モデルよりも優れています。。そうすることで、複数のプロセッサ上でマルチスレッドの並列処理を実現できます。このモデルの欠点は、ユーザーレベルのスレッドを作成するには、対応するカーネルレベルのスレッドを作成する必要があることです。
• 多対多モデル。多対多モデルは、複数のユーザー レベルのスレッドを複数のカーネル レベルのスレッドにマップします (カーネル レベルのスレッドの数はユーザー レベルのスレッドの数を超えず、カーネル レベルのスレッドの数は次の基準に基づいて決定されます)特定の状況による）。このようなモデルを採用すると、ユーザーレベル スレッドに関する最初の 2 つのモデルの制限を打ち破ることができ、複数のユーザーレベル スレッドを本当の意味で並列実行できるようになるだけでなく、ユーザーレベル スレッドの数も制限されなくなります。。ユーザーは、必要なユーザーレベルのスレッドを自由に作成できます。複数のカーネルレベルのスレッドは、必要に応じてユーザーレベルのスレッドを呼び出します。ユーザーレベルのスレッドがブロックされると、他のスレッドの実行をスケジュールできます。

2.2 プロセッサのスケジューリング

2.2.1 プロセッサの 3 レベルのスケジューリング

スケジュールはオペレーティング システムの基本機能であり、ほとんどすべてのリソースは使用前にスケジュールする必要があります。CPU はコンピュータの主要なリソースであるため、スケジューリング設計は CPU を効率的に利用する方法を中心に展開します。

マルチプログラミング環境では、通常、ジョブは送信から実行まで、高レベル スケジューリング、中間スケジューリング、低レベル スケジューリングなどのマルチレベル スケジューリングを受けます。システムの動作パフォーマンスはスケジューリングに大きく依存するため、マルチプログラミングではスケジューリングが鍵となります。

アドバンストスケジューリング（ジョブスケジューリング）

高度なスケジューリングは、マクロ スケジューリング、ジョブ スケジューリング、または長期スケジューリングとも呼ばれます。主なタスクは、特定の原則に従って外部メモリ上のバックアップ状態にある 1 つ以上のジョブを選択し、それらにメモリ入出力デバイスなどの必要なリソースを割り当て、ジョブが競合するジョブを取得できるように対応するプロセスを確立することです。権利 (ジョブとは、ユーザーがコンピューティング プロセスまたはトランザクションでコンピュータに要求する作業の合計です)。ジョブのスケジュールはそれほど頻繁ではなく、通常は数分ごとに実行されます。

スケジューラは、オペレーティング システムが許可できるジョブの数を決定する必要がありますか?

ジョブ スケジューリングによって毎回メモリに入れられるジョブの数は、マルチプログラムの並行性の程度、つまり、メモリ内で同時に実行できるジョブの数によって決まります。メモリ内で同時に実行できるジョブが多すぎると、所要時間が長すぎるなど、システムのサービス品質に影響を与える可能性があります。メモリ内で同時に実行されるジョブが少なすぎると、システム リソースの使用率とスループットが低下します。したがって、マルチプログラミングの並行性の程度は、システムのサイズと実行速度に基づいて決定する必要があります。

スケジューラはどのジョブを許可するかを決定する必要がありますか?

どのジョブを外部ストレージからメモリに転送するかは、採用されているスケジューリング アルゴリズムによって異なります。最も単純なスケジューリング アルゴリズムは、外部メモリにある最も早いジョブを最初にメモリに転送する先着順スケジューリング アルゴリズムです。より一般的に使用されるスケジューリング アルゴリズムは、ジョブを次の条件で転送するショート ジョブ ファースト スケジューリング アルゴリズムです。外部ストレージからメモリへの実行時間が最も短いジョブが最初にメモリにロードされますが、他のスケジューリング アルゴリズムもあります。

中間スケジューリング

中間スケジューリングは、ミッドレンジ スケジューリングまたはスイッチング スケジューリングとも呼ばれます。中間スケジューリングは、メモリ使用率とシステム スループットを向上させるために導入されており、その主なタスクは、外部メモリ スワップ領域にある実行状態のプロセスを、指定された原則と戦略に従ってメモリに転送し、ステータスを準備完了状態に変更して待機することです。レディキューに移行したり、一時的に動作しなくなったメモリ上のプロセスを外部のメモリスワップ領域に移したりする処理を行いますが、このときのプロセスの状態をサスペンド状態と呼びます。。中間スケジューリングには、主にメモリ管理と拡張が含まれます (実際、中間スケジューリングは、ページング中に外部と内部の間でページをスケジュールすることとして理解できます)。

ローレベルスケジューリング（プロセススケジューリング）

低レベル スケジューリングは、マイクロ スケジューリング、プロセス スケジューリング、またはショートレンジ スケジューリングとも呼ばれます。その主なタスクは、特定の戦略と方法に従ってレディキューからプロセスを選択し、それにプロセッサを割り当てることです。プロセス スケジューリングの実行頻度は非常に高く、通常は数十ミリ秒ごとです。。

高レベルのスケジューリングと低レベルのスケジューリングの違いは次のとおりです。

• ジョブのスケジューリングはプロセスを呼び出す準備をし、プロセスのスケジューリングはプロセスを呼び出せるようにします。言い換えると、ジョブのスケジューリングの結果、ジョブのプロセスが作成され、プロセスのスケジューリングの結果、プロセスが実行されます。。
• ジョブのスケジューリングの数は少なく、プロセスのスケジューリングの頻度は高くなります。
• 一部のシステムではジョブのスケジューリングを設定する必要はありませんが、プロセスのスケジューリングは必要です。

2.2.2 スケジューリングの基本原則

スケジューリング アルゴリズムが異なれば、スケジューリング戦略も異なります。これにより、スケジューリング アルゴリズムがジョブの種類に応じて異なる影響を与えることも決まります。スケジューリング アルゴリズムを選択するときは、さまざまなアルゴリズムの特性を考慮する必要があります。スケジューリングアルゴリズムのパフォーマンスを測定するために、いくつかの評価基準が提案されています。

CPU使用率

CPU はシステムの最も重要かつ高価なリソースであり、その使用率はスケジューリング アルゴリズムを評価するための重要な指標です。バッチ処理やリアルタイム システムでは、一般に CPU 使用率が比較的高いレベルに達する必要がありますが、PC や使用率を重視しない一部のシステムでは、CPU 使用率は最も重要ではありません。

システムのスループット

システム スループットは、単位時間あたりに CPU によって完了されたジョブの数を表します。長いジョブの場合は、CPU 処理に長時間かかるため、システムのスループットが低下しますが、短いジョブの場合はその逆です。

反応時間

システムのスループットと CPU 使用率に関連して、応答時間は主にユーザー指向です。対話型システム、特にマルチユーザーシステムでは、複数のユーザーが同時にシステムを操作するため、一定時間以内に全員が応答する必要があり、一部のユーザーのプロセスを長時間呼び出すことができません。したがって、ユーザーの観点から見ると、スケジュール戦略では、応答時間がユーザーの許容範囲内になるように、可能な限り短い応答時間を保証する必要があります。

ターンアラウンドタイム

各ジョブの観点から見ると、ジョブを完了するまでにかかる時間は重要であり、通常はターンアラウンド タイムまたは加重ターンアラウンド タイムによって測定されます。

• 所要時間: 待機時間と実行時間を含む、ジョブの送信から完了までの時間間隔を指します。ターンアラウンドタイム Ti _;として表されるジョブ_iの所要時間 T i = ジョブ i の完了時間 – ジョブ i の送信時間

• 平均所要時間: 平均所要時間は、複数のジョブ (n 個のジョブなど) の平均所要時間を指します。平均所要時間 T は次のように表されます。T=(T ₁ +T2 ₂ +…+T _n ) /n。

• 加重ターンアラウンド タイム: 加重ターンアラウンド タイムは、実行時間に対するジョブのターンアラウンド タイムの比率です。ジョブ i の加重所要時間 Wi は次の式で表されます_。W _i = ジョブ i の所要時間 / ジョブ i の実行時間。

• 平均加重所要時間: 平均加重所要時間と同様、平均加重所要時間は、複数のジョブの加重所要時間の平均です。

2.2.3 プロセスのスケジューリング

マルチプログラミング システムでは、ユーザー プロセスの数がプロセッサの数よりも多くなることが多く、ユーザー プロセスがプロセッサをめぐって競合します。さらに、システム プロセスでもプロセッサを使用する必要があります。したがって、システムは、実行可能キュー内のプロセスを実行するために、特定の戦略に従ってプロセッサを動的に割り当てる必要があります。プロセッサによって割り当てられたタスクは、プロセス スケジューラによって完了されます。

プロセススケジューリング機能

• システム内のすべてのプロセスの関連情報とステータス特性を記録します。
• プロセッサを取得するプロセスを選択します。
• プロセッサの割り当て。

プロセスのスケジューリングの原因

• 現在実行中のプロセスが終了します。タスクが完了したため正常終了、またはエラーが発生したため異常終了します。
• 現在実行中のプロセスは、I/リクエスト、P 操作、ブロッキング プリミティブなどの何らかの理由により、実行状態からブロッキング状態に入ります。
• システムコールなどのシステムプログラムの実行後、ユーザプロセスに戻ると、システムプロセスが実行されたとみなし、新たなユーザプロセスをスケジュールすることができます。
• プリエンプティブ スケジューリングを使用するシステムでは、優先度の高いプロセスがプロセッサの使用を要求すると、現在実行中のプロセスがレディ キューに入ります (これはスケジューリング方法に関連します)。
• タイムシェアリング システムでは、プロセスに割り当てられたタイム スライスが使い果たされています (これはシステム タイプによって異なります)。

プロセススケジューリングができない場合

• 割り込み処理中。割り込み処理プロセスは複雑であり、実装上のプロセスの切り替えが困難であり、また、割り込み処理はシステム作業の一部であり、論理的に特定のプロセスに属するものではないため、プロセッサのリソースを奪われるべきではありません。
• オペレーティング システムのカーネル プログラムのクリティカル セクション。プロセスがクリティカル セクションに入った後は、共有データに排他的にアクセスする必要があり、理論的には、他の並列プログラムが進入できないようにロックする必要があります。共有データのリリースを高速化するために、ロックを解除する前に他のプロセスに切り替えるべきではありません。
• 割り込みの完全なマスクを必要とするその他のアトミック操作中。ロック、ロック解除、オンサイト保護の中断、リカバリなどのアトミック操作。アトミック操作は細分化できず、一度完了する必要があり、プロセスの切り替えはできません。

プロセスのスケジュール方法

プロセスのスケジューリング方法は、プロセッサ上でプロセスが実行されているとき、処理する必要があるより重要または緊急のプロセスがある場合 (つまり、優先度の高いプロセスがレディ キューに入る場合)、この時点でプロセッサをどのように割り当てるべきかを指します。 ?。

• プリエンプティブ: 剥奪可能な方法とも呼ばれます。このスケジューリング方法は、プロセッサ上でプロセスが実行されているときに、より優先度の高いプロセスがレディ キューに入ると、実行中のプロセスが直ちに中断され、プロセッサが新しいプロセスに割り当てられることを意味します。
• 非プリエンプティブ方式。譲渡不可能な方法とも呼ばれます。この方法は、プロセッサ上でプロセスが実行されているときに、優先度の高いプロセスがレディ キューに入った場合でも、プロセスが完了するか何らかのイベントが発生するまで、実行中のプロセスは実行を継続することを意味します。新しいプロセスは、完了またはブロック状態になった場合にのみ実行されます。

2.2.4 一般的なスケジューリング アルゴリズム

先着順スケジューリング アルゴリズム (ジョブ スケジューリング、プロセス スケジューリング)

先着順スケジューリング アルゴリズム (FCFS) は最も単純なスケジューリング アルゴリズムであり、ジョブ スケジューリングとプロセス スケジューリングに使用できます。基本的な考え方は、プロセスがレディ キューに入った順序でプロセッサを割り当てることです。先着順スケジューリング アルゴリズムは、非プリエンプティブ スケジューリング方法を採用しています。つまり、プロセス (またはジョブ) がプロセッサーを占有すると、そのプロセス (またはジョブ) が作業を完了するか、続行できなくなるまで実行され続けます。イベントを待機しているため、プロセッサは実行時にのみ解放されます。

表面的には、先着順のスケジューリング アルゴリズムはすべてのプロセス (またはジョブ) に対して公平です。到着順にご提供します。しかし、長いプロセス (10t) と短いプロセス (t) の数が等しいとすると、数が等しいため、どちらが先に到着する確率も等しいことになります。長い工程が先の場合、短い工程の待ち時間は10tですが、短い工程が先の場合、長い工程の待ち時間はわずかtです。それで先着順のスケジューリング アルゴリズムは、長いプロセス (ジョブ) には適していますが、短いプロセス (ジョブ) には適していません。。

現在、先着順スケジューリング アルゴリズムが主要なスケジューリング戦略として使用されることはほとんどありません。特に、タイムシェアリング システムやリアルタイム システムの主要なスケジューリング戦略として使用することはできません。多くの場合、他のスケジュール戦略と組み合わせて使用​​されます。たとえば、スケジューリング ポリシーとして優先度を使用するシステムでは、同じ優先度を持つ複数のプロセスまたはジョブが先着順で処理されることがよくあります。。

ショートジョブ優先スケジューリングアルゴリズム（ジョブスケジューリング、プロセススケジューリング）

ショート ジョブ ファースト (SJF) スケジューリング アルゴリズムは、プロセス スケジューリングに使用される場合、ショート プロセス ファースト スケジューリング アルゴリズムと呼ばれます。ジョブのスケジューリングとプロセスのスケジューリングの両方に使用できます。。

短いジョブ (またはプロセス) の優先スケジューリング アルゴリズムの基本的な考え方は、最も速く完了したジョブ (またはプロセス) にプロセッサを割り当てることです。ジョブのスケジューリングでは、短いジョブ優先スケジューリング アルゴリズムにより、毎回バックアップ ジョブ キューから推定実行時間が最も短い 1 つまたは複数のジョブが選択され、それらがメモリに転送され、リソースが割り当てられ、プロセスが作成され、レディ キューに入れられます。プロセス スケジューリングでは、ショート プロセス優先スケジューリング アルゴリズムにより、毎回実行可能キューから推定実行時間が最も短いプロセスが選択され、そのプロセスにプロセッサが割り当てられ、プロセスの実行が許可され、プロセスが完了するかブロックされるまでプロセッサは解放されません。理由。

すべてのジョブが同時に到着する場合、SJF スケジューリング アルゴリズムは、平均所要時間が最も短い最適なアルゴリズムです (短いプロセスが最初に実行されると、長いプロセスの待機時間が長くなります。最初に実行される長いプロセスの方がはるかに短いため、平均待機時間は長くなります)プロセスの実行中に時間が最も短くなります (時間は決定され、変更されません)。しかし、アルゴリズムは明らかです多くの短いジョブが常に準備完了キューに入っている場合、長いジョブは長時間スケジュールできないため、「飢えて」しまいます。(「飢餓」現象とは、プロセスの実行をスケジュールできないか、一定期間必要なリソースを取得できないことを意味します)。

優先スケジューリングアルゴリズム（ジョブスケジューリング、プロセススケジューリング）

優先順位スケジューリング アルゴリズムは、一般的に使用されるプロセス スケジューリング アルゴリズムであり、ジョブ スケジューリングとプロセス スケジューリングの両方に使用できます。基本的な考え方は、最高の優先順位を持つプロセスにプロセッサを割り当てることです。アルゴリズムの中心的な問題はプロセスに優先順位を付ける方法です。プロセスの優先度は、プロセスの重要性、つまり実行の優先度を表すために使用されます。

プロセスの優先度は、通常、静的優先度と動的優先度の 2 種類に分けられます。

• 静的な優先度はプロセスの作成時に決定され、プロセス全体を通じて変更されません。静的優先度を決定する基準は次のとおりです。
  • プロセスクラスによって決定されます。システムプロセス優先度 > ユーザープロセス優先度
  • ジョブのリソース要件に基づいて決定されます。より多くのリソースを適用するプロセス > より少ないリソースを適用するプロセス
  • ユーザーのタイプと要件によって決定されます。ユーザの課金基準が高いほど、ユーザのジョブに対応する処理の優先度が高くなる。
• 動的優先度とは、プロセスの作成時に、プロセスの特性や関連する状況に基づいて優先度が決定され、プロセスの実行中に状況の変化に応じて優先度が調整されることを意味します。動的優先度を決定する基準は次のとおりです。
  • プロセスが CPU を占有する時間の長さに基づいて決定されます。プロセスが CPU を占有する時間が長くなるほど、その優先度は低くなります。、プロセスが CPU を占有する時間が短いほど、優先度が高く、再度
    スケジュールされる可能性が高くなります。
  • これは、プロセスが CPU 間で待機する時間によって異なります。プロセスがキュー内で待機する時間が長くなるほど、その優先度は高くなります。、スケジュールされる可能性は高くなります。逆に、準備完了プロセスが準備完了キューで待機する時間が短いほど、優先度は低くなり、スケジュールされる可能性は低くなります。

優先度ベースのスケジューリング アルゴリズムは、さまざまなスケジューリング方法に従って、非プリエンプティブ優先スケジューリング アルゴリズムとプリエンプティブ優先スケジューリング アルゴリズムに分けることもできます。

• 非プリエンプティブ優先スケジューリング アルゴリズムの実装の考え方は、システムがレディ キュー内で最も優先度の高いプロセスにプロセッサを割り当てると、プロセスは独自の理由で自発的に放棄するまで実行を継続するというものです (タスクの完了や機器の適用など）プロセッサは、現在の優先順位が最も高い別のプロセスに割り当てられます。
• プリエンプティブ優先スケジューリング アルゴリズムの実装の考え方は、最も優先度の高いプロセスに処理を割り当てて実行させることです。プロセスの実行中に、より高い優先度を持つ別のプロセスが現れると (たとえば、待機イベントの発生により、より高い優先度のプロセスが準備完了になる)、プロセス スケジューラは現在のプロセスを停止し、新しいプロセスに割り当てられたプロセッサを使用します。優先度の高いプロセス。

タイムスライスラウンドロビンスケジューリングアルゴリズム（プロセススケジューリング）

プロセス スケジューリングでは、通常、タイム スライス ラウンド ロビン スケジューリング アルゴリズムが使用されます。タイム スライス ラウンドロビン スケジューリング アルゴリズムでは、システムはすべての準備完了プロセスを到着時間順にキューに配置します。プロセス スケジューラは常にキュー内の最初のプロセスを選択して実行し、一定の実行時間を規定します。タイムスライス (例: 100ms)。プロセスがこのタイム スライスを使い切ると (プロセスが終了していない場合でも)、システムはタイム スライスをレディ キューの最後に送信し、プロセッサを次のレディ プロセスに割り当てます。このようにして、レディキュー内のプロセスは順番に処理時間のタイムスライスを取得し、キューの最後に戻って実行を待機することができ、このサイクルは完了するまで続きます。。

タイム スライスの設定が大きすぎて、すべてのプロセスを 1 つのタイム スライス内で実行できる場合、タイム スライス ローテーション スケジューリング アルゴリズムは先着順のスケジューリング アルゴリズムに変質します。タイム スライスの設定が小さすぎる場合は、頻繁に切り替えることで、プロセッサが実際にユーザー プロセスの実行に費やす時間が短縮されます。したがって、タイムスライスサイズは適切に設定する必要があります。

タイム スライスのサイズは、次の要因によって決まります。

• システムの応答時間。タイムシェアリング システムは、システムの応答時間要件を満たす必要があります。システムの応答時間とタイム スライスの関係は、次のように表すことができます。

  T=Nxq
  で、T はシステムの応答時間、タイム スライスのサイズ、N は準備完了キュー内のプロセスの数です。。この関係によれば、システム内のプロセス数が一定の場合、タイム スライスのサイズはシステムの応答時間に比例することがわかります。

• 準備完了キュー内のプロセスの数。応答時間が固定されている場合、準備完了キュー内のプロセスの数はタイム スライスのサイズに反比例します。

• システム処理能力。通常はユーザーが入力する必要がある頻繁に使用されるコマンドは、タイム スライス内で処理できます。したがって、コンピュータが高速であればあるほど、単位時間あたりに処理できるコマンドが多くなり、タイム スライスを小さくすることができます。

高応答率優先スケジューリングアルゴリズム（ジョブスケジューリング）

高応答率優先スケジューリング アルゴリズムは、先着順と短いジョブ優先スケジューリング アルゴリズムの特性を組み合わせたものです。つまり、ジョブの待機時間とジョブの実行時間の 2 つの要素が考慮され、以前の優先スケジューリング アルゴリズムでは、ジョブの待機時間と実行時間の 2 つの要素が考慮されます。 2 つのスケジューリング アルゴリズムでは、そのうちの 1 つだけが考慮されるため、要素が不十分です。

高応答率優先スケジューリング アルゴリズムは、主にジョブのスケジューリングに使用されます。基本的な考え方は、ジョブがスケジュールされるたびに、まず準備完了キュー内の各ジョブの応答率が計算され、最も高い応答率を持つジョブが選択されて実行されるということです。

応答率 = ジョブの応答時間/推定実行時間

今すぐ応答率 = (ジョブ待機時間 + 推定実行時間) / 推定実行時間

このアルゴリズムは、短いジョブ (ジョブの待機時間が同じ場合、推定実行時間が短いほど応答率が高くなります) を優先し、一方、長いジョブ (ジョブの待機時間が十分に長い限り、応答率は高くなります) を考慮します。最高。このアルゴリズムでは、短いジョブと長いジョブの両方が考慮されますが、各バックアップ ジョブの応答率を計算する必要があるため、システムのオーバーヘッドが増加します。。

マルチレベルキュースケジューリングアルゴリズム（プロセススケジューリング）

マルチレベルキュースケジューリングアルゴリズム基本的な考え方は、プロセスの性質やタイプに応じてレディキューをいくつかの独立したキューに分割し、各プロセスは固定のキューに属するというものです。各キューはスケジューリング アルゴリズムを使用し、異なるキューは異なるスケジューリング アルゴリズムを使用できます。たとえば、タイム スライス ラウンドロビン スケジューリング アルゴリズムを使用する対話型タスク用のレディ キューをセットアップする例や、先着順スケジューリング アルゴリズムを使用するバッチ タスク用に別のレディ キューをセットアップする例があります。

マルチレベルフィードバックキュースケジューリングアルゴリズム（プロセススケジューリング）

マルチレベル フィードバック キュー スケジューリング アルゴリズムは、タイム スライス ローテーション スケジューリング アルゴリズムと優先度スケジューリング アルゴリズムを合成および発展させたものです。プロセスの優先順位とタイム スライス サイズを動的に調整することにより、マルチレベル フィードバック キュー スケジューリング アルゴリズムは複数のシステム目標を考慮に入れることができます。

まず、複数のレディキューを設定し、各キューに異なる優先順位を与える必要があります。最初のキューの優先順位が最も高く、2 番目のキューの優先順位が 2 番目に高く、残りのキューの優先順位は順番に低くなります。。

次に、各キュー内のプロセスの実行タイム スライスのサイズも異なり、プロセスが配置されているキューの優先度が高いほど、対応するタイム スライスは短くなります。通常、i+1 キューのタイム スライスは、i キューのタイム スライスの 2 倍です。。

新しいプロセスがシステムに入るときは、最初のキューの最後に配置され、先着順でスケジューリングのためにキューに入れられる必要があります。プロセスが実行する番になったとき、このタイム スライス内にプロセスが完了できれば、システムは退避する準備ができます。プロセスがタイム スライスの終わりまでに完了していない場合、スケジューラはプロセスを次に、先着順の原則に従ってスケジューリングの実行を待ちます: プロセスが 2 番目のキューでタイム スライスを実行した後に完了しない場合、プロセスは 3 番目のキューに転送されます。同じ方法。このように続けて、タイム スライス ラウンド ロビン スケジューリング アルゴリズムが最後のキューで使用されます。

最後に、スケジューラは、最初のキューがアイドル状態の場合にのみ 2 番目のキューのプロセスが実行されるようにスケジュールし、-1 番目のキューのプロセスは、最初から -1 番目のキューが空の場合にのみ実行されるようにスケジュールします。プロセッサが i 番目のキュー内のプロセスにサービスを提供しているときに、新しいプロセスがより高い優先順位でキューに入ると、新しいプロセスは実行中のプロセスのプロセッサを占有します。つまり、スケジューラは実行中のプロセスを元に戻します。キューの最後でプロセッサが新しいプロセスに再割り当てされます。

2.3 同期と相互排他

2.3.1 プロセス同期の基本概念

2 つの形式の制約

• 間接的な相互制限関係 (相互排他): あるプロセスが特定のリソースの使用を必要とし、そのリソースが別のプロセスによって使用されており、そのリソースを 2 つのプロセスが同時に使用することは許可されていない場合、そのプロセスはリソースを占有しているプロセスを待つ必要があります。リソースを再度使用する前にリソースを解放してください。この制限関係の基本的な形式は、「プロセス-リソース-プロセス」です。

  この制約関係は、同じ種類の複数のプロセスが特定のシステム リソース (プリンターなど) を相互に共有する必要があることから生じます。相互排他は、リソースへの相互排他的アクセスを実現するために、同じタイプのプロセス間で設定されます (たとえば、プロデューサーとコンシューマーの問題では、プロデューサーはバッファー プールへの相互排他的アクセスを必要とします)。。

• 直接制約関係（同期）

  プロセスは、別のプロセスから提供される必要な情報を受信しないと実行を続行できません。この状況は、2 つのプロセスが特定の時点で情報を交換し、動作ステータスについて相互に通信する必要があることを示しています。この制限関係の基本形式は「プロセス-プロセス」です。

  この制限は主にプロセス間の連携に起因します。同期は、複数のプロセス間の同期を実現するために、異なるプロセス間で設定されます (たとえば、生産者-消費者問題では、生産者は製品を生産してバッファー プールに入れることができ、消費者は消費のためにバッファー プールから製品を取得します。生産者 生産者が製品を生産しなければ、消費者はそれを消費することはできません）。

同じ種類のプロセスが排他関係にある限り、コンシューマとコンシューマは排他関係、コンシューマとプロデューサは同期関係など、異なる種類のプロセスは同期関係にあります。

重要なリソースと重要なセクション

プロセスは実行中、通常、他のプロセスとリソースを共有し、一部のリソースは排他的に使用されます。一度に 1 つのプロセスのみが使用できるリソースはクリティカル リソースと呼ばれます。プリンターやプロッターなど、多くの物理デバイスは重要なリソースです。

重要なリソースへのアクセスは、次の 4 つの部分に分割できます。

• エリアに入ります。クリティカルセクションに入ってクリティカルリソースを使用するには、クリティカルセクションが入力エリアに入力可能かどうかを確認する必要があります。クリティカル セクションに入ることができる場合、通常は、他のプロセスが同時にクリティカル セクションに入ることを防ぐために、対応する「クリティカル セクションにアクセス中」フラグが設定されます。。
• クリティカルセクション。プロセス内の重要なリソースにアクセスするために使用されるコード (クリティカル セクションとも呼ばれます)。
• 出口ゾーン。「クリティカル セクションへのアクセス」ログをクリアするために使用されるクリティカル セクションの後の部分。
• 残りのエリア。上記 3 つの部分以外のプロセス。

簡単に言えば、クリティカル リソースは、異なるプロセスによる相互排他的アクセスを必要とするシステム リソースであり、クリティカル セクションは、クリティカル リソースにアクセスし、対応するプロセスに属する各プロセス内のコードの一部です。、検査および回収のためのクリティカルセクションの前後に入口エリアと出口エリアを設定する必要があります。クリティカルセクションとクリティカルリソースは異なります。クリティカルリソースは、相互にアクセスする必要があるリソースです。このリソースは同時に 1 つのプロセスのみ使用できますが、このリソースを必要とするプロセスは複数あります。そのため、クリティカルセクションを使用するプロセスは、リソースを処理する必要があります。管理する、クリティカルセクションの概念も生まれました。

各プロセスのクリティカル セクション コードは異なる場合があります。プロセスが重要なリソースに対してどのような操作を実行するかは、重要なリソースや相互排他同期管理とは関係がありません。

相互に排他的な概念と要件

相互排除の定義によれば、プロセスがクリティカル リソースを使用するためにクリティカル セクションに入った場合、他のプロセスは、新しいプロセスがクリティカル リソースにアクセスできるようになる前に、クリティカル リソースを占有しているプロセスがクリティカル セクションを出るまで待機する必要があります。

2 つのプロセスが同時にクリティカル セクションに入ることを防ぐために、ソフトウェア アルゴリズムまたは同期メカニズムは次のガイドラインに従う必要があります。

• 空いているときに入れてください。クリティカル セクションにプロセスが存在しない場合、クリティカル セクションへの入場を要求したプロセスは、即座に自身のクリティカル セクションへの入場を許可されます。
• 忙しい場合はお待ちください。プロセスがクリティカル セクションに入ると、クリティカル セクションに入ろうとしている他のプロセスは待機する必要があります。
• 待機時間が限られています。クリティカルなリソースへのアクセスを必要とするプロセスは、限られた時間内にクリティカル セクションに入ることができることが保証される必要があります。
• 電源を待ってください。何らかの理由でプロセスがクリティカル セクションに入ることができない場合、プロセッサを他のプロセスに解放する必要があります。

同期の概念と実装メカニズム

一般に、あるプロセスが別のプロセスと比較して実行される速度は定義されていません。つまり、プロセスは非同期環境で実行されます。しかし、相互に協力するプロセスには、特定の重要なポイントでの取り組みを調整する必要があります。いわゆるプロセスの同期とは、連携する複数のプロセスが要所要所で相互に待機したり、情報を交換したりする必要があることを意味し、この相互制約関係をプロセス同期と呼びます。。同期はセマフォを使用して実現できます。

2.3.2 相互排除の実現方法

相互排他は、ソフトウェアまたはハードウェアのいずれかの方法を使用して実装できます。

ソフトウェアアプローチ

アルゴリズム 1: クリティカル セクションに入ることが許可されるプロセス ID を表すパブリック整数変数を設定します。ターンが 0 の場合、プロセス P ₀はクリティカル セクションに入ることが許可されます。それ以外の場合は、ターンがプロセスの ID になるまで変数がループでチェックされます。出口領域では、入ることが許可されたプロセス P 0 の ID は次のとおりです。 1に修正されました。プロセス P1_のアルゴリズムはこれと同様です。2 つのプロセスのプログラム構造は次のとおりです。

この方法では、重要なリソースへの相互排他的アクセスが保証されますが、問題は、2 つのプロセスがクリティカル セクションに交互に入るように強制すると、リソースの使用率が不十分になりやすいことです。。

たとえば、プロセス P ₀がクリティカル セクションを出るとき、turn は 1 に設定され、プロセス P ₁がクリティカル セクションに入ることができますが、プロセス P ₁が一時的にクリティカル リソースにアクセスする必要がなく、P ₀がアクセスしたい場合は、クリティカルリソースを再度実行すると、クリティカルセクションに入ることができなくなります。このアルゴリズムでは、「アイドル ギブイン」基準の実装を保証できないことがわかります。

アルゴリズム２：クリティカルセクションで処理を実行するかどうかを示すフラグ配列flagを設定し、初期値は全てfalseとする。各プロセスがクリティカル リソースにアクセスする前に、まず別のプロセスがクリティカル セクションにあるかどうかを確認します。そうでない場合は、このプロセスのクリティカル セクション フラグを true に変更して、クリティカル セクションに入ります。出口エリアです。2 つのプロセスのプログラム構造は次のとおりです。

このアルゴリズムは「フリーエントリー」の問題を解決し、しかし、どちらのプロセスもクリティカル セクションに進入しない場合、それぞれのアクセス フラグが false になるという新たな問題が発生します。は false (2 つのプロセスが交互にチェック ステートメントを実行すると、どちらも flag[]=false 条件を満たす)、そのため 2 つのプロセスはそれぞれのクリティカル セクションに同時に入ります。これは、クリティカル セクションのアクセス ルール「wait when」に違反します。忙しい"。

アルゴリズム 3: このアルゴリズムは依然としてフラグ配列 flag を設定しますが、フラグはプロセスがクリティカル セクションに入りたいかどうかを示すために使用されます。各プロセスがクリティカル リソースにアクセスする前に、最初に独自のフラグを true に設定し、希望していることを示します。クリティカルセクションに入り、他のプロセスをチェックするプロセスフラグ。別のプロセスのフラグが true の場合、プロセスは待機し、そうでない場合はクリティカル セクションに入ります。2 つのプロセスのプログラム構造は次のとおりです。

このアルゴリズムは、2 つのプロセスが同時にクリティカル セクションに入ることを効果的に防止できます。しかし、2つのプロセスが同時にクリティカルセクションに進入したい場合、それぞれのプロセスが自身のフラグをtrueに設定し、その時点で相手の状態を確認するため、どちらのプロセスもクリティカルセクションに進入できないという問題があります。同時に、相手もクリティカルエリアに入ろうとしていることが分かり、お互いブロックしてしまい、お互いクリティカルエリアに入れないという「デッドウェイト」現象が発生し、「限定ルール」に違反します。 「待て」原則。

アルゴリズム 4:このアルゴリズムのアイデアは、アルゴリズム 3 とアルゴリズム 1 を組み合わせたものです。フラグ配列 flag[] は、プロセスがクリティカル セクションに入るか、クリティカル セクションで実行するかを示します。さらに、クリティカル セクションに入ることが許可されるプロセス ID を表すターン変数が設定されます。2 つのプロセスのプログラム構造は次のとおりです。

この時点では、アルゴリズム 4 は完全に正常に動作します。flag[] を使用して重要なリソースへの相互排他的アクセスを解決し、tumn を使用して「飢餓」現象を解決します。。

ハードウェア方式

ソフトウェア方式を完全に使用してプロセスの相互排他を実現するには大きな制限があり、現在ではソフトウェア方式のみが使用されることはほとんどありません。ハードウェア方式の主な考え方は、1 つの命令を使用してフラグのチェックと変更の 2 つの操作を完了することで、チェックと変更の操作が中断されないようにするか、チェックと変更が確実に実行されるようにすることです。全体スルー割り込みマスク。

ハードウェアには主に 2 つの方法があり、1 つは割り込みマスキング、もう 1 つはハードウェア命令です。。

ハードウェアアプローチの利点:

• 幅広い用途。ハードウェア アプローチは任意の数のプロセスで機能し、ユニプロセッサ環境でもマルチプロセッサ環境でも同じです。
• 単純。ハードウェア メソッドのフラグは設定が簡単で、意味が明確で、その正しさを簡単に検証できます。
• 複数のクリティカルセクションをサポートします。プロセス内に複数のクリティカル セクションがある場合、各クリティカル セクションにブール変数を設定するだけで済みます。

ハードウェアによるアプローチには多くの利点がありますが、それだけでは克服できない欠点もいくつかあります。これらの欠点としては、主に、クリティカル セクションに入るまでのプロセスがプロセッサ時間を消費すること、「電力待ち」が実現できないこと（判定にソフトウェアが協力する必要があること）、クリティカル セクションに入るプロセスの選択アルゴリズムにいくつかの欠陥があることが挙げられます。ハードウェア実装により、一部のプロセスが選択されず、「飢餓」が発生する可能性があります。。

2.3.3 信号量

前に説明したソフトウェアおよびハードウェアの方法は相互排他問題を解決できますが、いずれにも欠点があります。ソフトウェア方式のアルゴリズムは複雑すぎて非効率で直感的ではなく、「ビジーウェイト」現象（ゾーンに入るときにフラグ変数が検出され続ける）が発生します。ハードウェア方式に関して言えば、割り込みマスク方式はユーザープロセスにとって適切な相互排他機構ではなく、ハードウェア命令方式では「右待ち」を実現できないなどの欠点があります。

セマフォと同期プリミティブ

セマフォは確定タプル (s, q) です。s は非負の初期値を持つ整変数、q は初期状態が空のキューです。整数変数 s は、システム内の特定の種類のリソースの数を表します。その値が 0 より大きい場合、システム内で現在利用可能なリソースの数を表します。その値が 0 より小さい場合、その絶対値は、このタイプのリソースに対する要求により、システムはブロックされています。プロセス数。セマフォの初期値に加えて、セマフォの値は、P 操作 (待機操作とも呼ばれます) と V 操作 (シグナル操作とも呼ばれます) によってのみ変更できます。。オペレーティング システムは、その状態を使用してプロセスとリソースを管理します。

セマフォの確立について説明する必要があります。つまり、s の意味と初期値を正確に説明する必要があります (注: この初期値は負の値ではありません)。各セマフォには対応するキューがあり、セマフォが確立された時点ではキューは空です。。

セマフォにしましょう。

P(s) が実行されると、主に次のアクションが完了します:最初に s=s-1 を実行します。s>=0 の場合、プロセスは実行を継続します。s<0 の場合、プロセスはブロックされ、待機状態に挿入されます。セマフォがキューにあります。

V(s) が実行されると、主に次のアクションが完了します:最初に s-s+1 を実行; s > 0 の場合、プロセスは実行を継続します: s <= 0 の場合、最初のプロセスをセマフォ待機キューから削除します。これにより、プロセスは準備完了状態になって準備完了キューに挿入され、元のプロセスに戻って実行を継続します。

P 操作と V 操作はどちらも分割できないアトミック操作であり、セマフォの操作プロセスが中断またはブロックされないことが保証されます。。P 操作はリソースの申請に相当し、V 操作はリソースの解放に相当します。P 操作と V 操作はシステム内でペアで使用する必要がありますが、必ずしも 1 つのプロセス内にある必要はなく、別のプロセスに分散することもできます。。

セマフォの分類

• 整数セマフォ: 整数セマフォは整数 s です。初期化を除き、標準のアトミック操作 P および V を通じてのみアクセスできます。。整数セマフォでは P および V 演算が導入されますが、P 演算を実行する場合、使用可能なリソースがない場合、プロセスはセマフォのテストを継続し、「ビジー待機」現象が発生し、「正しいのを待つ」原則に従わなくなります。。

• レコード セマフォ (リソース セマフォ): 整数セマフォの「ビジー待機」問題を解決するために、リソースを待っているすべてのプロセスをリンクするリンク リスト構造が追加されます。レコード セマフォは、まさにレコード タイプを使用しているためです。データ構造。

  プロセスがセマフォに対して P 操作を実行するとき、その時点で利用可能なリソースが残っていない場合、プロセスは自身をブロックし、プロセッサを放棄し、待機リストに挿入します。この仕組みは「力を与えて待つ」の原則に従っていることがわかります。プロセスがセマフォに対して V 操作を実行するときに、リンク リスト内のリソースを待機しているプロセスがまだある場合は、リンク リスト内の最初の待機プロセスが起動されます。

  セマフォの初期値が 1 の場合、そのリソースは 1 つのプロセスのみが同時にアクセスできる重要なリソースであることを意味します。。

セマフォの応用

• プロセスの同期を実現する

  _{同時プロセス P 1}と P ₂があるとします。P ₁にはステートメント S ₁があり、 P ₂にはステートメント S _{2 があります。S 1 は}S ₂より前に実行する必要があります。この同期の問題は、セマフォを使用すると簡単に解決できます。

• プロセスの相互排他を実装する

  _{プロセス P 1}と P ₂があり、どちらも独自のクリティカル セクションを持っているとします。ただし、システムでは、同時に 1 つのプロセスのみが自身のクリティカル セクションに入ることができる必要があります。ここでセマフォを使用すると、クリティカル セクションの相互排他的なエントリを簡単に解決できます。セマフォ N を初期値 1 (つまり、使用可能なリソースの数が 1) に設定します。P(N) と V(N) の間にクリティカル セクションを配置するだけで、2 つのプロセスの排他的エントリが実現されます。 。

リソースへの相互排他的アクセスが必要なプロセスが 2 つ以上ある場合は、初期値 1 でセマフォを設定し、これらのプロセスがリソースにアクセスするコードの前後でセマフォに対して P 操作と V 操作を実行できます。プロセスがリソースに相互に排他的にアクセスできるようにするため。

2.3.4 従来の同期の問題

生産者と消費者の問題

プロデューサーとコンシューマーの問題は、よく知られたプロセス同期の問題です。これは、消費者のグループに製品を提供する生産者のグループを表しており、生産者が製品を置き、消費者が製品を持ち帰る境界のある緩衝地帯を共有します。。この問題は、多くの相互に協力するプロセスを抽象化したものです。たとえば、入力中は、入力プロセスがプロデューサーであり、コンピューティング プロセスがコンシューマです。出力中は、コンピューティング プロセスがプロデューサで、印刷プロセスがコンシューマです。

この問題を解決するには、2 つの同期セマフォを設定する必要があります: 1 つは空として表現される空のバッファーの数を示し、初期値は制限されたバッファー サイズ n です。もう 1 つは満杯のバッファーの数 (つまり、 products)、full と表現すると、初期値が 0 であることを意味します。さらに、複数のプロデューサまたはコンシューマがバッファ プールに相互にアクセスできるようにするために、ミューテックス セマフォを初期値 1 に設定する必要があります。

P(full)/P(empty) と P(mutex) の順序を逆にすることはできません。最初にリソース セマフォに対して P 操作を実行し、次にミューテックス セマフォに対して P 操作を実行する必要があります。そうしないと、デッドロックが発生します。

複数のセマフォが同時に存在する場合、通常、P 操作を元に戻すことはできません。最初にリソース セマフォに対して P 操作を実行し、次に相互排他的セマフォに対して P 操作を実行する必要があります。これにより、セマフォのアクセス権を占有しているときにリソースを確実に使用できます。そうでないと、使用権は占有されているがリソースが利用できないという「デッドウェイト」現象が発生します。

同じ種類のプロセスが複数ある場合は常に、相互に排他的なセマフォが必要です。

リーダーライター問題

リーダー/ライター問題では、多くのプロセスによって共有されるデータ領域があります。このデータ領域はファイルまたはメイン メモリ内の領域です。このデータ領域の読み取りのみを行うプロセス (リーダー) と、読み取りのみを行うプロセスが存在します。データ領域 データを書き込むプロセス (ライター)。さらに、次の条件を満たす必要があります。

• 任意の数のリーダーが同時にこのファイルを読み取ることができます。
• ファイルに一度に書き込むことができるライターは 1 人だけです (ライターは相互に排他的である必要があります)。
• ライターが動作している場合、リーダー プロセスはファイルの読み取りを禁止され、他のライター プロセスはファイルへの書き込みを禁止されます。

• リーダーファーストアルゴリズム

  リーダーが読み取り操作を実行しようとしたときに、その時点で別のリーダーが読み取り操作を実行している場合は、待たずに直接読み取り操作を開始できます。読み取り操作を実行するリーダーが存在する限り、ライターは書き込みを実行できませんが、後続のリーダーは直接読み取り操作を実行できるため、リーダーが次々に到着する限り、リーダーは到着次第読み取り操作を開始でき、ライターの処理は完了します。すべてのリーダーが読み取りを完了するまで待機することしかできません。書き込み操作は終了後にのみ実行できます。これはリーダーの優先順位です。

  この問題を解決するには、次のセマフォを設定する必要があります。リーダーの数を記録する整数変数 readcount を設定します。初期値は 0 です。その値が 0 より大きい場合、リーダーが存在し、ライターは書き込み操作を実行できないことを示します: ミューテックス セマフォの初期値を設定します。複数の読み取りプロセスの readcount への相互排他アクセスを確保するには、1 に設定します。初期値 1 で相互排他セマフォ ミューテックスを設定し、データ領域への書き込みプロセスの相互排他アクセスを制御します。。アルゴリズムは次のとおりです。

• フェアケースアルゴリズム

  プロセスの実行順序は到着順です。つまり、リーダーが読み取り操作を実行しようとしたときに、ライターが書き込み操作を待機しているか、書き込み操作を実行している場合、後続のリーダーは、読み取り操作を開始する前に、最初に到着したライターが書き込み操作を完了するまで待つ必要があります。

  この問題を解決するには、リーダーファーストアルゴリズムと比較して、セマフォwmutexを追加する必要があります。初期値は1で、書き込み中の書き込み者がいるか待機しているかを示すために使用されます。書き込み者がいる場合、新しいリーダーの入力は禁止されます。 。。アルゴリズムは次のとおりです。

• ライターファーストアルゴリズム

  フェア シチュエーション アルゴリズムをライターファーストと呼ぶ書籍もありますが、これは本当の意味でのライターファーストではなく、到着順に読み書き操作を実行するだけです。真のライターを最初に達成する（すなわち、ライターとリーダーが同時に待機している場合、後続のライターは、待機中のリーダーが到着したときに、待機しているリーダーよりも先にキューに入ることができます。待機キューにライターがいる限り、いつ到着しても、ライターは開始される前にウェイクアップされます。読者の皆様。)、制御のために追加のセマフォを追加する必要があります。

  この目的を達成するために、ライターが到着したときに、リーダーがリーダーより先にクリティカル セクションに入ることができるように制御するには、追加のセマフォ読み取り可能を追加する必要があります。ライターが到着したら、クリティカル セクションに直接入る前に、前のライターが書き込みを完了するのを待つだけで済みます。読者、それが書き手の前に届くか後に届くか。さらに、ライターの数をカウントするには、整数の writeount を追加する必要があります。以前のアルゴリズムと比較して、wmutex の役割は変更され、書き込み者の書き込みカウントへの相互排他的アクセスを制御するために使用されるようになりました。。アルゴリズムは次のとおりです。

このメソッドは、読み取り可能なセマフォを追加して、ライターがラインにジャンプできるようにします。最初の書き込み者が到着すると、読み取り可能なセマフォの占有を申請します。占有が成功した後も、引き続き占有します。後続の読み取りプロセスは、読み取り可能なセマフォを申請できないためブロックされます。後続の書き込み者が到着すると、書き込みは行われません。したがって、セマフォはライターの後ろでキューに入れられ、キューにジャンプするという目的が達成されます。すべてのライターが書き込みを終了し、最後のライターが読み取り可能なセマフォを解放するまで、リーダーは読み取りを続けることができません。新しいライターが到着すると、読み取り可能なセマフォを占有し続け、後続のリーダーが読み取り操作を実行できないようにし、このプロセスを繰り返します。。このアルゴリズムはライターの優先順位を真に実装しており、最初に到着したリーダーが動作する前に、新しいライターがデータ領域を占有することもできます。

哲学者の食事問題

5 人の哲学者が円卓の周りに座っています。テーブル上には 5 つのペグがあり、2 人の哲学者の間に 1 つずつあります。哲学者の行動には、考えることと食べることが含まれます。食事をするとき、彼は左右の 2 本のペグを同時に持ち上げる必要があります。 . 2本の箸を持ち、考え事をしたら2本の箸を同時に元の場所に戻します。食事の哲学者問題は、並行処理が実行される場合の重要なリソースを扱う典型的な問題とみなすことができます。

箸は重要なリソースであり、2 人の哲学者が同時に使用することはできないため、箸を表すためにセマフォ配列が使用されます。

この解決策には問題があり、デッドロックにつながります (5 人の哲学者が同時にお腹が空いていて、それぞれが左側の箸を取ると、5 つの箸すべてが占有されてしまいます。右側の箸を取ろうとすると、5 人の哲学者が同時に空腹になります。 、箸がないので全員ブロックされます。「無限に待ちます」）。

このデッドロックの問題に対しては、次の解決策を使用できます。

• 同時に食事をできるのは最大 4 人の哲学者だけです。
• 哲学者は、左右の箸が同時に使える場合にのみ箸を持つことができます。
• 哲学者に番号を付け、奇数番号の哲学者に左の箸を最初に取り、偶数番号の哲学者に右の箸を最初に取るように依頼します。

最後の方法の解決策は次のとおりです。奇数番目の哲学者は最初に左の箸を取り、次に右の箸を取ると規定されており、偶数番目の哲学者はその逆を行います。アルゴリズムは次のとおりです。

床屋の問題

理髪店には、理髪師、理容椅子、そして顧客が待つための椅子がいくつかあります (ここに椅子が n 個あると仮定します)。客がいないときは理容師は理容椅子で寝ていて、客が来たらまず理容師を起こさなければなりません。理容師が顧客に散髪をしている場合、空のスツールがあれば顧客は待ちますが、空のスツールがなければ顧客は立ち去ります。各理容師と顧客の活動を説明するプログラムを設計します。

この質問については 2 つの考え方があります。1 つは、理容椅子と待機スツールを 2 つの異なるリソースとして考える方法であり、もう 1 つは、理容椅子とスツールを統合された椅子リソースとして考える方法です。。最初のアイデアで使用されているコードは、書くのが少し複雑ですが、考えるのは簡単です。2 番目の方法はコードが少ないですが、理解するのは簡単ではありません。

• 

  

• 

セマフォ機構の問題解決手順の分析

• 関係分析: まず、問題にどのような同期関係が存在するかを判断する必要があります。同期関係のペアが存在する限り、多くの場合、リソース セマフォが必要になります。リソース セマフォの初期値は、質問内の対応するリソースの数に設定する必要があります。タイトルの各文は通常、同期関係またはリソースの種類を暗示します。、同期関係は 2 つのロール (プロデューサーとコンシューマーなど) の間だけでなく、同じロール (プロデューサーとプロデューサーなど) の間にも存在する場合があります。これは考えられる例にすぎません。実際には、プロデューサー間に同期関係はありません)。

• クリティカル リソースの決定: クリティカル リソースにアクセスするコードはクリティカル セクションと呼ばれます。クリティカル リソースには一度に 1 つのプロセスしかアクセスできないため、クリティカル リソースにアクセスする場合はミューテックス セマフォを使用する必要があります。ミューテックスの初期値semaphore は 1 で、ミューテックス セマフォの名前として mutex が一般的に使用されます。クリティカル セクションを記述する一般的な方法は次のとおりです。

  

  なお、クリティカルリソースにアクセスする際の同期や相互排他関係にその他の制限（ロック）がある場合、この制限に関係するリソースセマフォのPおよびV動作は、通常、上記の一般的なクリティカルセクションのコードの外に記述されます。 。リソース セマフォを N とすると、クリティカル セクションの変更後の書き込み方法は次のようになります。

  

• アイデアを整理する: 問題内のさまざまな役割プロセスの具体的なコードと使用されるセマフォを決定し、セマフォ メカニズムの問題に対する答えを完成させます。応答する場合、P 操作 (待機操作) はそのリソースの数を 1 減算するもの、V 操作 (シグナル操作) はそのリソースの数を 1 増やすものとみなすことができます。。

同期の相互排他問題を解決する場合、同時実行性を表現するためにループ ステートメントを追加する必要がありますか?

ループ文を追加するかどうかは、実際の処理の種類によって異なります。。たとえば、生産者と消費者の問題では、生産者と消費者は常に生産と消費を行うため、生産コードと消費コードをループで実行する必要があります。この場合、ループ ステートメント (通常は while ステートメントを使用します) を使用して、コードが確実に実行されるようにします。実行を続けます。質問で特定の条件下で実行を停止する必要がある場合は、ループ内の適切な位置に Break ステートメントを追加するだけです。一部の問題のプロセスは、ループで実行する必要はありません (理髪店の問題の顧客プロセスなど)。顧客は通常、散髪が終了すると退席します。つまり、顧客プロセスは 1 回実行するだけで終了します。同様の処理のコードは一度実行するだけなので、ループ文を追加する必要はありません（顧客が常にヘアカットを望むとは限らず、これは常識ではありません）。

2.3.5 パイプライン

セマフォの仕組みはプロセス間の同期や相互排他を実現するために利用できますが、セマフォの制御がプログラム全体に分散されるため正当性の解析が難しく、使い方を誤るとプロセスのデッドロックを引き起こす可能性もあります。セマフォ メカニズムにおけるこれらの問題に対応して、Diikstra は 1971 年に、各共有リソースに「秘書」を設定して、そのリソースへのアクセスを管理することを提案しました。すべての訪問者は「秘書」を経由する必要があり、「秘書」は一度に 1 人の訪問者 (プロセス) にのみ共有リソースへのアクセスを許可します。これにより、共有リソースのシステム管理が容易になるだけでなく、プロセス間の相互排他的アクセスと同期も確保されます。。1973年、ハンソンとホアは「秘書コンセプト」を経営コンセプトに発展させました。

モニターは、データ構造と、同時プロセスで実行できる一連の操作を定義します。この一連の操作により、プロセスを同期し、モニター内のデータを変更できます。モニターの定義から、モニターは、モニターにローカルな共有データ構造の記述、これらのデータ構造を操作するための一連のプロシージャー、およびモニターにローカルなデータ構造の初期値を設定するステートメントで構成されていることがわかります。モニター。このモニターは、さまざまなプロセスに散在する重要なセクションを収集し、パブリック変数への相互排他的アクセスを提供してそれらを保護します。。

チューブプロセスの基本的な特徴:

• モニターに対してローカルなデータには、モニターに対してローカルなプロシージャによってのみアクセスできます。
• プロセスは、モニター内のプロシージャを呼び出すことによってのみモニターに入り、共有データにアクセスできます。
• モニター内の内部プロセスを実行できるのは、一度に 1 つのプロセスだけです。つまり、プロセスは内部プロシージャを呼び出すことによって相互に排他的にモニターに入ります。モニターに入ろうとする他のプロセスは待機する必要があり、待機キュー内でブロックされます。

同期をサポートする次の機能がプロセス定義に含まれています。

• モニターにローカライズされ、モニター内からのみアクセスできる多数の条件変数。さまざまな待機理由を区別するために使用されます。
• 条件変数を操作する 2 つの関数プロシージャは wait および signal します。wait は、条件変数に関連付けられたキュー内でこの関数を呼び出すプロセスをブロックし、チューブを使用可能にします。つまり、他のプロセスがチューブに入ることができるようになります。シグナルは、条件変数でブロックされているプロセスをウェイクアップします。そのようなプロセスが複数ある場合は、そのうちの 1 つを選択してウェイクアップします。条件変数でブロックされているプロセスがない場合は、何も行いません。モニターのシグナル・プロシージャーは、wait プロシージャーが呼び出された後に呼び出す必要があります。。

2.4 デッドロック

2.4.1 デッドロックの概念

マルチプログラミング システムでは、複数のプロセスを同時に実行することでシステム リソースの使用率が向上し、システムの処理能力が向上しますが、複数のプロセスの同時実行によりデッドロックという新たな問題も発生します。

システム リソースの競合や相互通信により複数のプロセスが永続的にブロックされると、これらのプロセスは外部の力がなければ前進できなくなります。これらの各プロセスは、グループ内の別のプロセスが所有し、決して取得できないリソースを無限に待ちます。この現象はデッドロックと呼ばれます。。

• 少なくとも 2 つのプロセスがデッドロックに関係しています。
• デッドロックに関与している各プロセスはリソースを待っています。
• デッドロックに関係するプロセスのうち少なくとも 2 つがリソースを占有しています。
• デッドロックされたプロセスは、システム内の現在のプロセス セットのサブセットです。

2.4.2 デッドロックの原因と必要条件

リソースの分類

オペレーティング システムは、さまざまな種類のリソースをプロセスに割り当てる役割を担うリソース管理プログラムです。最新のオペレーティング システムで管理されるリソースの種類は非常に豊富で、さまざまな観点から分類できます。たとえば、リソースは剥奪可能なリソースと剥奪不可能なリソースに分類できます。

• 剥奪可能なリソースは、リソース所有者プロセスはリソースを使用する必要がありますが、別のプロセスが所有者プロセスからリソースを強制的に奪い、独自に使用することができます。。
• 譲渡不可能な資源は、リソースを使用する必要がなくなり、積極的にリソースを解放する占有プロセスを除いて、他のプロセスは、占有プロセスがリソースを使用している間、そのリソースを強制的に奪うことはできません。。

リソースが剥奪可能なリソースであるかどうかは、リソース自体の性質に完全に依存します。

デッドロックの原因

リソース競合によりデッドロックが発生する。システム内で実行中のプロセスが 1 つだけで、すべてのリソースがこのプロセス専用である場合、デッドロックは発生しません。システム内で複数のプロセスが同時に実行されている場合、システム内のリソースがすべてのプロセスのニーズを同時に満たすのに十分でない場合、プロセスがリソースを求めて競合し、デッドロックが発生する可能性があります。

リソースの競合によりデッドロックが発生する場合がありますが、リソースの競合＝デッドロックではなく、プロセス実行時にリソースの要求と解放の順序が不適切な場合（つまり、プロセスが不適切な順序で進められた場合）にのみデッドロックが発生します。。

デッドロックは、システムリソースの不足やプロセスの進行順序が不適切なために発生します。

システム リソースの不足がデッドロックの根本原因です、オペレーティング システムを設計する目的は、同時プロセスがシステム リソースを共有できるようにすることです。そして不適切なプロセス進行シーケンスがデッドロックの重要な原因となるシステム リソースがプロセスに対して十分なだけである場合、プロセスの不適切な進行順序により、プロセスが互いに必要なリソースを占有しやすくなり、デッドロックが発生する可能性があります。

デッドロックが発生するための必要条件

• 相互に排他的な条件。プロセスは、割り当てられたリソースの排他制御を必要とします。つまり、特定のリソースは、一定期間内に 1 つのプロセスによってのみ占有されます。
• 条件の剥奪はありません。プロセスが取得したリソースは、使い果たされる前に他のプロセスに強制的に奪うことはできません。つまり、リソースを取得したプロセスだけが解放できます。
• 条件をリクエストして保留します。プロセスは毎回そのリソースの一部を申請し、新しいリソースが割り当てられるのを待機している間、プロセスは割り当てられたリソースを占有し続けます。要求および保留条件は、部分割り当て条件とも呼ばれます。
• ループ待ち状態。プロセス リソースには循環的な待機チェーンがあり、チェーン内の各プロセスが取得したリソースは、チェーン内の次のプロセスによって同時に要求されます。

デッドロックが発生するためには、これら 4 つの条件が必須であるため、これらの条件の 1 つまたは複数を破壊することでデッドロックを回避できます。。

2.4.3 デッドロックに対処する基本的な方法

• ダチョウのアルゴリズム: ダチョウのようにデッドロックには目をつぶります。つまり、デッドロックを無視します。
• デッドロックを防ぎます。デッドロックに必要な 4 つの条件のうち 1 つ以上を破るために一定の制限を設定することで、デッドロックの発生を防ぎます。
• デッドロックを回避します。リソースを動的に割り当てる過程では、システムが危険な状態にならないように何らかの方法が使用され、デッドロックの発生が回避されます。
• デッドロックを検出して除去します。デッドロックの発生は、システムの検出メカニズムによって適時に検出され、デッドロックを緩和するために何らかの対策が講じられます。

デッドロックの防止とは、スケジュール方法においてデッドロックが発生する必要条件を破壊し、システムがデッドロックを発生させないようにすることである。, 剥奪プロセスのスケジューリング方式を採用すると、優先度の高いプロセスが常にリソースを獲得して操作を完了できるため、システムがデッドロックすることはありません。

デッドロックの回避とは、動的割り当てプロセス中にシステムが危険な状態に陥るかどうかを予測することであり、リソース割り当てによってデッドロックが発生する可能性がある場合には、そのような割り当ては実行されません。, 後述するバンカーズアルゴリズムはデッドロックを回避する手法です。

デッドロックの検出と解放は比較的受動的な方法であり、デッドロックの発生を検出した後に処理されます。デッドロック プロセスからリソースを剥奪したり、プロセスにリソースを強制的に解放したり、デッドロック プロセスを終了してデッドロック状態を緩和したりするその他の方法が含まれます。

2.4.4 デッドロックの防止

デッドロックの発生を防ぐには、デッドロックに必要な 4 つの条件のうち 1 つを破棄するだけで済みます。

相互に排他的な条件

相互排他条件を解除するには、複数のプロセスがリソースに同時にアクセスできるようにする必要があります。ただし、これはリソース自体の固有の特性によって制限されます。一部のリソースは同時にアクセスできず、相互にのみアクセスできます。たとえば、プリンタでは、動作中に複数のプロセスがデータを交互に印刷することができず、相互排他的にのみ使用できます。この観点から見ると、相互排他条件を破壊することでデッドロックの発生を防ぐことはできません。。

剥奪条件なし

非剥奪状態を破るために、次のような戦略を立てることができます。特定のリソースを取得したプロセスの場合、新しいリソース要求をすぐに満たせない場合は、取得したすべてのリソースを解放し、リソースが必要になったときに再適用する必要があります。将来的には。これは、プロセスによって取得されたリソースが動作中にリソースを奪われ、非剥奪状態が破壊される可能性があることを意味します。この戦略は実装が複雑です。取得したリソースを解放すると、以前の作業が無効になる可能性があります。リソースの適用と解放を繰り返すと、システムのオーバーヘッドが増加し、システムのスループットが低下します。このメソッドは通常、リソースの剥奪にコストがかかる状況では使用されません。たとえば、プリンタの割り当てには使用されません。プロセスが印刷している場合、デッドロックを緩和するために剥奪メソッドは使用されません。。

リクエストと保留の条件

リクエストとホールドの条件を解除するには、事前静的割り当て方法を使用できます。事前静的割り当て方法では、プロセスが実行前に必要なすべてのリソースを一度に適用する必要があり、リソースが満たされなくなるまでプロセスは動作しません。一度動作を開始すると、これらのリソースは常にそのリソースによって所有され、他のリソース要求は行われないため、システムがデッドロックすることはありません。。この方法はシンプルで安全ですが、リソース使用率が低下します。これは、この方法を使用するには、一部のリソースが実行の後半でしか使用できない場合でも、ジョブ (またはプロセス) に必要なすべてのリソースを事前に把握しておく必要があるためです。通常運用時には全く使用されず、事前に申請する必要があるため、システムリソースを最大限に活用できません。

プリンターを例にとると、ジョブは最終的に完了したときに計算結果を印刷するだけで済みますが、ジョブを実行する前にプリンターを割り当てる必要があります。その後、ジョブの実行中、プリンターは基本的にidle、while other プリンターを待機しているプロセスの実行開始が遅れ、他のプロセスが「スターブ」状態になります。

ループ待ち条件

ループ待ち状態を解消するには、順序付けされたリソース割り当て方法を使用できます。順序付けされたリソース割り当て方法では、システム内のすべてのリソースに種類に応じて番号が割り当てられ (たとえば、プリンターは 1、テープ ドライブは 2)、各プロセスは番号の昇順に厳密にリソースを要求する必要があります。リソースを一度に申請できます。。つまり、プロセスがリソース R _{iを要求している限り、後続のリクエストでは R i} (i はリソース番号)の後にランク付けされたリソースのみをリクエストでき、 R _i

この方法は、さまざまなリソースに番号を付けた後の変更には適しておらず、新しい機器の追加が制限されます。異なるジョブで使用されるリソースの順序は完全に同じではありません。システムがリソースに番号を付けるときにほとんどの状況を考慮しても、システムとの差異は常に存在します。一貫性のない数値を持つジョブ、つまりリソースの無駄が発生します。リソースを連続して使用すると、プログラミングの複雑さも増加します。。

2.4.5 デッドロックの回避

デッドロック防止方法で使用されるいくつかの戦略は一般に強力な制限を課しており、実装は比較的簡単ですが、システムのパフォーマンスに重大なダメージを与えます。デッドロックを回避する方法では、課される制約が弱くなり、より良いシステム パフォーマンスを得ることが可能になります。この方法では、システムの状態を安全な状態と危険な状態に分け、システムが常に安全な状態であればデッドロックを回避することができる。。

安全な状態と危険な状態

デッドロックを回避する方法では、プロセスは動的にリソースを申請することができ、システムはまずリソース割り当ての安全性を計算してからリソースを割り当てます。この割り当てによってシステムが安全でない状態にならない場合、リソースはプロセスに割り当てられます。割り当てられない場合、プロセスは待機する必要があります。

ある時点で、システムが最大需要に達するまで各プロセスに必要なリソースを特定の順序で割り当てて、各プロセスを正常に完了できる場合、この時点のシステム状態は安全な状態と呼ばれます。シーケンスはセキュリティシーケンスのために呼び出されます。ある瞬間にこのような安全なシーケンスがシステム内に存在しない場合、そのときのシステムの状態をアンセーフ状態と呼びます。セキュリティ シーケンスは特定の時点では一意ではない可能性がある、つまり、複数のセキュリティ シーケンスが同時に存在する可能性があることに注意してください。

それでもすべての安全でない状態がデッドロック状態であるわけではありませんが、システムが安全でない状態に入ると、デッドロック状態に入る可能性があり、逆に、システムが安全な状態にある限り、デッドロック状態に入るのを回避できます。。

注意すべき点は 2 つあります。

• 安全でない状態は、システムでデッドロックが発生したことを意味するものではありません。安全でない状態とは、システム内でデッドロックが発生する可能性がある状態を指しており、システム内でデッドロックが発生していることを意味するものではありません。
• システムが安全でない状態であっても、必ずしもデッドロックが発生するとは限りません。デッドロックは、危険な状態の適切なサブセットです。

銀行家のアルゴリズム

代表的なデッドロック回避アルゴリズムは、ダイクストラによるバンカーズアルゴリズムです。バンカーのアルゴリズムを実装するには、システム内にいくつかのデータ構造を設定する必要があります。

システム内にn 個のプロセス (P ₁、P ₂、...P _n ) と m 種類のリソース (R ₁、R ₂、...R _m ) があると仮定します。バンカーのアルゴリズムで使用されるデータ構造は次のとおりです。次のように：

• 利用可能なリソースのベクトルが利用可能です。これは m 個の要素を持つ配列です。Available[i] の値は、タイプ i のリソースの既存のアイドル数を表します。その初期値は、システムに構成されているこのタイプのリソースの数です。その値は、このタイプのリソースの割り当てとリサイクルに応じて動的に変化します。。
• 最大需要マトリックス これは n×m 行列で、システム内の各プロセスに必要な m タイプのリソースの最大数を定義します。Max[i][j] の値は、j​​ 番目のタイプのリソースに対する i 番目のプロセスの最大需要を表します。。
• 割り当てマトリックス 割り当て。これは n × m 行列でもあり、システム内のリソースの種類ごとに、各プロセスに現在割り当てられているリソースの数を定義します。Allocation[i][j] の値は、i 番目のプロセスが現在所有しているタイプ j のリソースの数を表します。。
• マトリックスが必要です。これは、システム内の各プロセスが依然として必要とするさまざまなリソースの数を定義する n×m 行列でもあります (注: これは「全体の必要性」ではなく「まだ必要」であり、この行列も変化していることを意味します)）。Need[i][j] の値は、i 番目のプロセスにも必要な j 番目のタイプのリソースの数を示します。。Vector Need _i ; は行列 Need の i 番目の行であり、プロセス i の需要リソース ベクトルです。

必要性[i] [j]=最大[i] [j]-割り当て[i] [j]

---

バンカーアルゴリズムの説明:

セキュリティ アルゴリズムは次のように説明されます。

2.4.6 デッドロックの検出と解除

デッドロック検出

• リソース割り当てマップ

  システム リソース割り当てグラフは、タプル SRAG=(V,E) として定義できます。ここで、V は頂点セット、E は有向エッジ セットです。頂点セットは 2 つの部分に分けることができます。P = (P ₁ , P ₂ …, P _n ) はシステム内のすべてのプロセスで構成されるセットであり、各 P はプロセスを表します。R=(r ₁ , r ₂ ,...,rm ₎は
  システム内のすべてのリソースの集合であり、各 r はリソースのタイプを表します。

  有向枝集合 E の各枝は、要求されたリソースまたは割り当てられたリソースを表す順序ペアであり、<Pi _, r _i > は要求されたリソース、<ri _, Pi _>は割り当てられたリソースです。

  SRAGでは、円を使用してプロセスを表し、ボックスを使用して各種類のリソースを表します。。各タイプの複数のリソース n が存在する可能性があり、各リソースはボックス内の円で表すことができます。アプリケーション エッジはプロセスからリソースへの有向エッジです。これは、プロセスがリソースを申請しましたが、プロセスはまだリソースを取得していないことを意味します。割り当てエッジは、リソースからプロセスへの有向エッジであり、リソースがプロセスに割り当てられていることを示します。アプリケーション エッジはリソース クラス r を表すボックスのみを指し、適用時に特定のリソースが指定されていないことを示します。プロセス Pi がリソース クラス r _{iのリソースを申請する}と、リクエスト エッジがリソース割り当てグラフに追加されます。リクエストが満たされると、リクエスト エッジはすぐに割り当てエッジに変換されます。その後プロセスがリソースを解放すると、その後、割り当てエッジが削除されます。

  

  

• デッドロック理論

  リソース割り当てグラフを簡略化する方法は、システム状態Sがデッドロック状態であるかどうかを検出するために使用することができる。

  • リソース割り当てグラフで、ブロックも分離もされていないプロセス ノード Pi を見つけます₍つまり、プロセス セットから接続されたエッジを見つけ、リソース要求の数がシステム内のアイドル リソースの数より少ないです)。プロセス Pi は必要なすべてのリソースを取得しているため、完了するまで実行を継続し、その後、占有しているすべてのリソースを解放します (これは、 Pi のすべてのアプリケーション エッジと割り当てエッジを削除し、孤立ノードにすることと同じ_です)。
  • プロセス Pi がリソースを_解放した後、これらのリソースを待機している間にブロックされているプロセスをウェイクアップできます。元々ブロックされていたプロセスは非ブロッキング プロセスになる可能性があり、割り当てエッジとアプリケーション エッジは最初のステップの簡略化された方法に従って削除されます。 。
  • 最初の 2 つのステップの単純化プロセスを繰り返した後、グラフ内のすべてのエッジを削除でき、すべてのプロセスが孤立ノードになれば、グラフは完全に単純化可能であると言われます。グラフがどのプロセスによっても完全に単純化できない場合、グラフはグラフは完全に簡略化可能であると言われていますが、グラフは完全に簡略化できるわけではありません。

  単純化次数が異なっても、同じ既約グラフが得られることがわかります。システム状態 S がデッドロック状態である条件は、状態 S のリソース割り当てグラフを完全に単純化できない場合に限り、この定理はデッドロック定理と呼ばれます。

デッドロックと検出アルゴリズム

デッドロック検出アルゴリズムの基本的な考え方は次のとおりです。特定の時刻 t におけるシステム内のさまざまな種類の利用可能なリソースの番号ベクトル available(t) を取得し、プロセスのグループ {P 1 、_P 2 _、 ...システム_内で、さまざまなタイプのリソースに対する要求の数が、システム内で使用可能なさまざまなタイプのリソースの数よりも少ないプロセスを見つけます。このようなプロセスは、必要なすべてのリソースを取得して実行を終了できます。実行が終了すると、占有しているすべてのリソースが解放され、それによって利用可能なリソースの数が増加します。このようなプロセスを、実行および終了できるプロセスのシーケンスに追加します。 . 次に、残りのプロセスについて上記の検査を行います。グループ内の複数のプロセスがこのシーケンスに属さない場合、デッドロックが発生する可能性があります。

デッドロックの解除

システム内でデッドロックが検出されると、デッドロックされたプロセスをデッドロック状態から解放する、つまりデッドロックを解除する必要があります。

デッドロックを解消するために一般的に使用される 3 つの方法があります。

• 資源を奪う。デッドロック状態を緩和するために、他のプロセスからデッドロックされたプロセスに十分なリソースを確保します。
• プロセスを元に戻します。デッドロックを解消するのに十分なリソースが他のプロセスに割り当てられるまで、一部のプロセスを元に戻します。
• プロセスはロールバックされます。デッドロックを回避するために、1 つ以上のプロセスを十分にロールバックさせます。プロセスがロールバックすると、リソースが剥奪されるのではなく、自発的に解放されます。システムはプロセスの履歴情報を保持し、復元ポイントを設定する必要があります。

2.4.7 デッドロックと飢餓

システムがデッドロックに陥っていない場合でも、プロセスによっては長時間待機する場合があります。待ち時間がプロセスの進行や応答に大きな影響を与える場合、この時点でプロセス飢餓が発生するといい、飢餓状態が一定のレベルに達し、プロセスによって割り当てられたタスクがたとえタスクを割り当てられていても実質的な意味を持たなくなった場合、プロセス飢餓が発生します。が完了すると、そのプロセスは餓死すると言われています。。

デッドロックと飢餓の違い:

• プロセスの状態を考慮すると、デッドロック プロセスはすべて待機状態にあり、混雑時に待機しているプロセス (実行中または準備完了状態) は待機状態ではありませんが、飢餓状態になる可能性があります。
• デッドロックされたプロセスは、決して解放されないリソースを待機しています。一方、スターブド プロセスは、解放されるが自分自身に割り当てられないリソースを待機しています。これは、待機時間に上限がないという事実で明らかです (列に並んで待っているか、混雑している時間帯に待っています）。
• 循環待機によりデッドロックが発生するはずですが、飢餓は発生しません。これは、リソース割り当てグラフがデッドロックが存在するかどうかを検出できるが、プロセスが飢餓状態に陥っているかどうかを検出できないことも示しています。
• デッドロックには複数のプロセスが関与する必要がありますが、スターブまたはスターブ状態のプロセスが 1 つだけ存在する場合もあります。

スタベーションとスタベーションはリソース割り当て戦略に関連しているため、マルチレベルのフィードバック キュー スケジューリング アルゴリズムなど、すべてのプロセスが無視されないように公平性の観点からスタベーションとスタベーションを防ぐことができます。