1. デッドロックの概念
1. デッドロックの定義
各プロセスがお互いのリソースを待ち続けることで、各プロセスがブロックされて先に進めなくなる現象が発生します。
デッドロックと飢餓の区別に注意してください
2. デッドロックの必要条件
デッドロックは以下の 4 つの条件を同時に満たす必要があり、どれか 1 つでも当てはまらない限りデッドロックは発生しません。
(1) 相互排他条件。
デッドロックは、排他的に使用する必要があるリソース (賢者の箸、プリンター デバイスなど) の競合によってのみ発生します。
(2) リクエストアンドホールド条件。
プロセスは少なくとも 1 つのリソースを保持していますが、新しいリソース要求を送信し、そのリソースは他のプロセスによって占有されています。このとき、要求元のプロセスはブロックされますが、既存のリソースは手放されません。
(3) ループ待ち状態。
プロセス リソースには循環待機チェーンがあり、チェーン内の各プロセスによって取得されたリソースは次のプロセスによって同時に要求されます。
注: デッドロックが発生した場合は循環待機が発生する必要がありますが、循環待機が発生してもデッドロックが発生しない可能性があります。
(4) 条件の剥奪は行わない。
プロセスによって取得されたリソースは、使い果たされる前に他のプロセスによって強制的に奪われることはできませんが、積極的に解放することしかできません。
2. デッドロックの防止
デッドロックの処理はデッドロックを発生させないためのものであり、静的戦略（デッドロックを防ぐ）と動的戦略（デッドロックを回避する）に分けられます。
1. デッドロックを防ぐ
デッドロックが発生するために必要な 4 つの条件のうち 1 つまたは複数を破ります。
2. デッドロックを回避する
何らかの方法を使用してシステムが危険な状態に入るのを防ぎ、デッドロックを回避します (バンカーのアルゴリズム)
3. デッドロックの検出と解除
デッドロックは許可されますが、オペレーティング システムがデッドロックの発生を検出し、デッドロックを解決するために何らかの措置を講じます。
(1) 排他条件の破壊 相互
排他でしか使用できないリソースを共用できるように変換すれば、システムはデッドロック状態に陥りません。たとえば、SPOOLing テクノロジでは、オペレーティング システムは SPOOLing テクノロジを使用して、専用デバイスを共有デバイスに論理的に変換できます。
短所: すべてのリソースを共有リソースに変換できるわけではなく、システムのセキュリティ上、多くの場所で相互排他を保護する必要があるため、多くの場合、相互排他条件を破ることができません。
(2) 非剥奪条件の破棄
プロセスが新しいリソースを要求し、それが満たされない場合、プロセスは保持しているすべてのリソースを直ちに解放し、後で必要になったときに再適用する必要があります。つまり、一部のリソースは、たとえ使い果たされていない場合でも積極的に解放する必要があり、その結果、不可譲条件が破られます。
欠点:
a. 実装がより複雑になります。
b. 取得したリソースを解放すると、前の段階の作業が無効になる場合があります。したがって、この方法は通常、CPU など、状態の保存と復元が容易なリソースにのみ適しています。
c. リソースの適用と解放を繰り返すと、システムのオーバーヘッドが増加し、システムのスループットが低下します。
d. この種の破壊は、特定のリソースが一時的に利用できない限り、以前に取得したリソースを放棄し、後で再適用する必要があることを意味します。これが常に発生すると、プロセスの枯渇につながる可能性があります。
(3) リクエストを破棄して条件を維持する
静的割り当てを使用できます。つまり、プロセスは実行前に必要なすべてのリソースを適用しており、リソースが満たされなくなるまでプロセスは動作しません。一旦操作が開始されると、これらのリソースは常に彼によって所有され、プロセスは他のリソースを要求しません。
この戦略は実装が簡単ですが、明らかな欠点もあります。一部のリソースは短期間しか使用されないため、プロセスの実行期間全体にわたってすべてのリソースが保持されると、深刻なリソースの浪費とリソース使用率の低下が発生します。 。さらに、この戦略により一部のプロセスが停止する可能性があります。
(4) 循環待ち状態の解消
方法：システムの全リソースタイプを線形にソートする（逐次リソース割り当て方式）。まず、システム内のリソースに番号を付け、各プロセスは番号の昇順にリソースを要求することを規定し、同じ種類のリソース (つまり、同じ番号のリソース) を一度に申請できるようにします。
原則分析: プロセスは、小さな番号のリソースをすでに占有している場合にのみ、より大きな番号のリソースを申請できます。このルールによれば、すでに大きな番号のリソースを保持しているプロセスが、逆に小さな番号のリソースを申請することは不可能であるため、循環待ち現象は発生しない。
この戦略の欠点:
a. システム内のさまざまなリソースに指定されたシリアル番号は比較的安定している必要があり、新しいタイプの機器の増加が制限されます。
b. リソース タイプにシリアル番号を割り当てる際、ほとんどのジョブが実際にこれらのリソースを使用する順序が考慮されていますが、ジョブがさまざまなリソースを使用する順序がシステムによって指定された順序と異なることがよくあり、その結果、資源の無駄。
c. 利用者の利便性を考えると、システムは利用者がプログラミングを行う際にできる限り制約を課さないことが望ましいが、このように決められた順序でリソースを申請する方法では、必然的に利用者が単純かつ自主的にプログラミングすることは制限されてしまう。
