デッドロックの防止:デッドロックの 4 つの条件のうち 1 つを破壊するだけです。
0. 相互排他条件を破棄する: 相互排他条件は非共有デバイスに必要であるため、変更できないだけでなく、保証する必要があります。したがって、残りの 3 つの条件を主に考慮します。
1. 「リクエストアンドホールド」条件の解除
リクエスト アンド ホールドとは、システムがリソースを要求し、現在そのリソースを占有しているが、解放せずに新しいリソースにも適用されることを意味します。
解決：
1) すべてのプロセスが開始される前にすべてのリソースを適用します。これにより、実行全体を通じてリソースが再度適用されなくなります。この解決策は簡単ですが、一度に大量のリソースを割り当てる必要があるため、大量のリソースが無駄になり、一部のプロセスが対応するリソースを取得できないために一部のプロセスが枯渇してしまいます。
2) プロセスが最初に必要なリソースを取得することによってのみ実行を開始できるようにし、その後、プロセス自体に割り当てられ、プロセスの実行中に使用されたリソースを徐々に解放します。これは最初の解決策よりも合理的です。
2. 「非プリエンプション」条件を破棄します。
新しいリソースに対するプロセスの要求を満たすことができない場合、プロセスは保持しているすべてのリソースを直ちに解放し、後で必要になったときに再度適用する必要があります。つまり、プロセスがすでに占有しているリソースは一時的に解放されますが、一部のリソースが使い尽くされていない場合でも、積極的に解放する必要があり、非プリエンプション条件が破棄されます。
このソリューションの欠点:
1. 実装がより複雑になります。
2. 獲得したリソースを解放すると、前段階の作業が失敗する可能性があります。したがって、この方法は通常、CPU など、状態の保存と復元が容易なリソースにのみ適しています。
3. リソースの申請と解放を繰り返すと、システムのオーバーヘッドが増加し、システムのスループットが低下します。
4. 特定のリソースが一時的に利用できない限り、以前に取得したすべてのリソースを放棄し、将来的に再適用する必要があります。これが常に発生すると、プロセスの枯渇につながります。
3.ループ待ち状態を解消するには、順次リソース割り当て方法を
使用できます。まず、システム内のリソースに番号を付け、各プロセスが番号の昇順でリソースを要求する必要があることを規定します。また、同じ種類のすべてのリソース (つまり、同じ番号を持つリソース) を一度に要求できるようにします。
プロセスは、より小さい番号のリソースをすでに占有している場合にのみ、より大きい番号のリソースを申請できます。このルールによれば、すでに大きな番号のリソースを保持しているプロセスが、逆に小さな番号のリソースを申請するために戻ってくることはできないため、ループ待ち現象は発生しません。
この戦略の欠点:
- すべての番号を再割り当てする必要があるため、新しい機器を追加するのは不便です。
- プロセスが実際にリソースを使用する順序は、数値の昇順と一致しない可能性があり、リソースの無駄につながります。
- リソースは指定された順序で適用する必要があるため、ユーザーのプログラミングが面倒になります。
デッドロックを回避します。
デッドロックの回避も予防戦略ですが、これはデッドロックに必要な条件を破壊するために事前に何らかの制限措置を講じることを意味するのではなく、デッドロックを回避するためにリソースを動的に割り当てるときにシステムが危険な状態にならないようにすることを意味します。
1. 安全シーケンス: いわゆる安全シーケンスとは、システムがこのシーケンスに従ってリソースを割り当てれば、各プロセスが正常に完了できることを意味します。安全なシーケンスが見つかる限り、システムは安全な状態にあります。もちろん、複数のセキュリティ シーケンスが存在する可能性があります。
リソースを割り当てた後、システム内で安全なシーケンスが見つからない場合、システムは安全でない状態に入ります。これは、その後のすべてのプロセスがスムーズに実行されない可能性があることを意味します。もちろん、プロセスが事前にリソースを返せば、システムは安全な状態に戻る可能性がありますが、リソースを割り当てる前に常に最悪のシナリオを考慮する必要があります。
システムが安全な状態であればデッドロックは絶対に発生しませんが、システムが安全でなくなった場合にはデッドロックが発生する可能性があります（安全でない状態だからといってデッドロックが発生しているとは限りませんが、デッドロックが発生する場合はデッドロックが発生している必要があります）したがって、
リソースを割り当てる前に、この割り当てによってシステムが安全でない状態になるかどうかを事前に判断し、リソース割り当て要求を許可するかどうかを決定できます。これは「バンカーズアルゴリズム」の中核となる考え方でもあります。
バンカーズ アルゴリズムを使用してデッドロックを回避する方法の詳細については、オペレーティング システム - デッドロックを回避するバンカーズ アルゴリズム_デッドロックを回避するバンカーズ アルゴリズムの使用_プログラミングで詩を書くためのブログ-CSDN ブログを参照してください。
銀行家のアルゴリズムの例:
システム内に 5 つのプロセス {P0、P1、P2、P3、P4} と 3 種類のリソース {A、B、C} があり、各種リソースの数がそれぞれ 10、5、7 であるとします。図に示すように、時刻 T0 では次のようになります。
| マックス | 割り当て | 必要 | 利用可能 | |
| A B C | A B C | A B C | A B C | |
| P0 | 7 5 3 | 0 1 0 | 7 4 3 | 3 3 2（2，3，0） |
| P1 | 3 2 2 | 2 0 0（3，0，2） | 1 2 2（0，2，0） | |
| P2 | 9 0 2 | 3 0 2 | 6 0 0 | |
| P3 | 2 2 2 | 2 1 1 | 0 1 1 | |
| P4 | 4 3 3 | 0 0 2 | 4 3 1 |
時間 T0 でのセキュリティ: セキュリティ アルゴリズムを使用して時間 T0 でのリソース割り当てを分析すると、時間 T0 でセキュリティ シーケンス {P1、P3、P4、P2、P0} が存在するため、システムは安全であることがわかります。
| 仕事 | 必要 | 割り当て | 仕事+割り当て | 仕上げる | |
| A B C | A B C | A B C | A B C | ||
| P1 | 3 3 2 | 1 2 2 | 2 0 0 | 5 3 2 | 真実 |
| P3 | 5 3 2 | 0 1 1 | 2 1 1 | 7 4 3 | 真実 |
| P4 | 7 4 3 | 4 3 1 | 0 0 2 | 7 4 5 | 真実 |
| P2 | 7 4 5 | 6 0 0 | 3 0 2 | 10 4 7 | 真実 |
| P0 | 10 4 7 | 7 4 3 | 0 1 0 | 10 5 7 | 真実 |
次の 3 つの状況は、バンカー アルゴリズムの 3 つの状況を示すために使用されます。ここでの 3 つの状況は、1 つの連続実行シナリオです。したがって、次の状況のデータは、上記の状況から引き継がれます。ここで疑問に思うかもしれませんが、ヒントを教えてください。
最初のケース: P1 がリソースを要求します: P1 は要求ベクトル Request(1,0,2) を送信し、システムは銀行家のアルゴリズムに従ってチェックします。
リクエスト(1,0,2)<=必要(1,2,2) リクエスト(1,0,2)<=利用可能(3,3,2)
システムはリソースを P1 に割り当てます。Available、Allocation、Need の最初の表の括弧内の内容は、割り当て後の結果です。
セキュリティアルゴリズムを検証に使用すると、セキュリティシーケンス{P1、P3、P4、P0、P2}も取得できるため、それが割り当てられます
| 仕事 | 必要 | 割り当て | 仕事+割り当て | 仕上げる | |
| A B C | A B C | A B C | A B C | ||
| P1 | 2 3 0 | 0 2 0 | 3 0 2 | 5 3 2 | 真実 |
| P3 | 5 3 2 | 0 1 1 | 2 1 1 | 7 4 3 | 真実 |
| P4 | 7 4 3 | 4 3 1 | 0 0 2 | 7 4 5 | 真実 |
| P0 | 7 4 5 | 7 4 3 | 0 1 0 | 7 5 5 | 真実 |
| P2 | 7 5 5 | 6 0 0 | 3 0 2 | 10 5 7 | 真実 |
2 番目のケース: P4 がリソースを要求します: P4 は要求ベクトル Request(3,3,0) を発行し、システムは銀行家のアルゴリズムに従ってチェックします。
リクエスト(3,3,0)<=必要(4,3,1)
Request(3,3,0)>Available(2,3,0) は P4 を待機させます
3 番目のケース: P0 がリソースを要求します: P0 は要求ベクトル Request(0,2,0) を発行し、システムは銀行家のアルゴリズムに従ってチェックします。
リクエスト(0,2,0)<=必要(7,4,3)
リクエスト(0,2,0)<=利用可能(2,3,0)
システムは最初にリソースが P0 に割り当てられていると想定し、その後変更を加えます。
| マックス | 割り当て | 必要 | 利用可能 | |
| A B C | A B C | A B C | A B C | |
| P0 | 7 5 3 | 0 3 0 | 7 2 3 | 2 1 0 |
| P1 | 3 2 2 | 3 0 2 | 0 2 0 | |
| P2 | 9 0 2 | 3 0 2 | 6 0 0 | |
| P3 | 2 2 2 | 2 1 1 | 0 1 1 | |
| P4 | 4 3 3 | 0 0 2 | 4 3 1 |
セキュリティチェックが実行された結果、利用可能なリソースがどのプロセスのニーズも満たせないことが判明したため、システムは安全でない状態となり、リソースは割り当てられません。