オペレーティングシステム〜デッドロックの概念、防止、検出、および解放

デッドロックとは何ですか

各プロセスは互いの手にあるリソースを待機しているため、各プロセスがブロックされ、先に進むことができません。

デッドロック、飢餓、および無限ループの違い

デッドロック:少なくとも2つのプロセスが一緒にデッドロックされ、デッドロックされたプロセスはブロック状態になります。
飢餓:1つのプロセスのみが空腹になる可能性があります。飢餓プロセスはブロックまたは準備ができている可能性があります。
無限ループ:1つのプロセスのみが無限ループを持つ可能性があります。無限ループプロセスをオンにすることができます。プロセッサ

デッドロックと枯渇はオペレーティングシステムが解決しなければならない問題であり、デッドループはアプリケーションプログラマーが解決しなければならない問題です。

デッドロックの4つの必要条件


リソースの使用に関する相互に排他的な条件は、競争を相互に排除する必要があり、プロセスを維持するためにリソースを
奪うことなく、リソースと非プリエンプティブリソース消費するなど、デッドロックにつながる
可能性があります。
要求条件を維持し
、これらのリソースが解放されていないものの維持するために、他のリソースの要求
条件を待って巡回します。
プロセス資源の循環待機チェーンがあります。
巡回待ちは必ずしもデッドロックされていない、とデッドロックは、環状待機を持っている必要があります

デッドロックはいつ発生しますか

不可侵のリソースの不当な割り当てはデッドロックにつながる可能性があります

デッドロック処理戦略

デッドロックの防止デッドロック回避するためにデッドロック
必要な4つの条件を
破棄する
システムが危険な状態にならないようにする(バンカーのアルゴリズム)
デッドロックの検出と削除
デッドロックの発生を許可するシステムは、デッドロックを検出して削除する責任があります。

デッドロックを防ぐ

相互に排他的な条件を破る

相互に排他的な条件相互に排他的でなければならないリソースの競合のみがデッドロックを引き起こします。

相互に排他的にのみ使用できるリソースが共有使用を許可するように変換された場合、システムはデッドロック状態になりません。例:スプーリングテクノロジー。オペレーティングシステムは、SPOQLingテクノロジを使用して、排他的デバイスを共有デバイスに論理的に変換できます。たとえば、SPooLingテクノロジを使用してプリンタを共有デバイスに変換する...
ここに画像の説明を挿入します
この戦略の欠点:すべてのリソースを共有リソースに変換できるわけではありません。また、システムセキュリティのために、この相互排除は多くの場所で保護する必要があります。したがって、多くの場合、相互排除条件を破ることはできません。

非剥奪条件を弱体化させる

非剥奪条件:プロセスによって取得されたリソースは、使い果たされる前に他のプロセスによって強制的に奪われることはできず、アクティブにのみ解放されます。

破棄と非剥奪の条件
オプション1:プロセスが満たされていない新しいリソースを要求した場合、プロセスは保持しているすべてのリソースをすぐに解放し、将来必要になったときに再適用する必要があります。つまり、一部のリソースが使い果たされていなくても、積極的に解放する必要があるため、不可侵の状態が破壊されます。
スキーム2:特定のプロセスに必要なリソースが他のプロセスによって占有されている場合、オペレーティングシステムは、必要なリソースを強制的に奪うのを支援できます。この方法では、通常、各プロセスの優先度を考慮する必要があります(たとえば、優先度の高いプロセスで使用されるプロセッサリソースを強制的に奪う、スケジューリング方法の剥奪)。

この戦略のデメリット:
1。実装がより複雑になります。
⒉取得したリソースを解放すると、前の段階の作業が失敗する可能性があります。したがって、この方法は通常、CPUなど、状態の保存と復元が容易なリソースにのみ適しています。
3.リソースの適用と解放を繰り返すと、システムオーバーヘッドが増加し、システムスループットが低下します。
4.オプション1を採用した場合、特定のリソースが一時的に利用できない限り、以前に取得したリソースを放棄して、後で再適用する必要があることを意味します。これが常に発生すると、プロセスの枯渇につながります。

リクエストを中断して条件を保留

要求と保留の条件:プロセスは少なくとも1つのリソースを予約しましたが、新しいリソース要求を行い、リソースは他のプロセスによって占有されています。この時点で、要求しているプロセスはブロックされますが、既存のリソースを保持し続けます。 。

静的割り当て方法を使用できます。つまり、プロセスは実行前に一度に必要なすべてのリソースに適用され、リソースが満たされないまで実行できません。運用が開始されると、これらのリソースはそれによって所有され、プロセスは他のリソースを要求しません。

この戦略は簡単に実装できますが、明らかな欠点もあります。
一部のリソースは短時間しか使用する必要がないため、プロセスの実行期間全体にわたってすべてのリソースを維持すると、リソースの深刻な浪費が発生し、非常に低いリソース使用率さらに、この戦略は特定のプロセスの枯渇を引き起こす可能性もあります。

ループ待機条件を解除します

循環待機条件:プロセスリソースの循環待機チェーンがあり、チェーン内の各プロセスによって取得されたリソースは、同時に次のプロセスによって要求されます。

シーケンシャルリソース割り当て方式を使用できますまず、システム内のリソースに番号を付け、一度にアプリケーションを完了するには、各プロセスが同じタイプのリソース(つまり、同じ番号のリソース)を番号の昇順で要求する必要があることを規定します。

主成分分析:プロセスは、すでに小さい数のリソースを持っている場合にのみ、大きい数のリソースを申請する資格があります。このルールによれば、すでに多数のリソースを保持しているプロセスが戻ってきて、逆方向に少数のリソースを申請することは不可能であるため、ループ待機は発生しません。

システムに1、2、... 10の番号が付けられた10個のリソースがあるとします
ここに画像の説明を挿入します
。この戦略の欠点:
1。すべての番号を再割り当てする必要があるため、新しいデバイスを追加するのは便利ではありません
。2。順序プロセスで実際に使用されるリソースの数が異なる場合があります。順序の増加に一貫性がなく、リソースの浪費につながります
。3。リソースは所定の順序で申請する必要があり、ユーザーがプログラミングするのが面倒です。

デッドロックを回避する

銀行家のアルゴリズム

銀行家のアルゴリズムは、銀行が現金ローンを発行するときにすべての顧客のニーズを満たすことに失敗しないことを保証するために、銀行システムのためにオランダの学者ダイクストラによって設計されています。その後、デッドロックを回避するために、オペレーティングシステムでアルゴリズムが使用されました。

コアアイデア:プロセスがリソースアプリケーションを送信するとき、最初に、割り当てによってシステムが危険な状態になるかどうかを予測します。安全でない状態になった場合は、この要求の許可を一時的に拒否し、プロセスをブロックして最初に待機します。
ここに画像の説明を挿入します

この時点でシステムは安全な状態にありますか?
アイデア:安全なシーケンスを見つけてみてください... {P1、P3、PO、P2、P4}は、残りの利用可能なリソース(3、3、2)が各プロセスのニーズは
P1を満たすことができます必要に応じて、セキュリティシーケンスにP1を追加し、残りの利用可能なリソース値を(5、3、2)に更新し、残りの利用可能なリソース(
5、3、2)かどうかを順番に確認しますする需要は、P3の要件を満たす安全シーケンスにP3を追加し、(7,4,3)に、残りの使用可能なリソース値を更新することができます(セキュリティ上のシーケンスに参加しているプロセスを含まない)残りのプロセスを満たすことができる
かどうかを確認します残りの利用可能なリソース(7、4、3)は、残りのプロセスを満たすことができます(追加された安全シーケンスは含まれません)プロセスのニーズ)...
……。
類推すると、合計5つのループチェックで5つのプロセスを追加できます。セキュリティシーケンス、そして最後にセキュリティシーケンスを取得できます。このアルゴリズムはセキュリティアルゴリズムと呼ばれます。上記のプロセスはコードで簡単に実装でき、検査の各ラウンドは小さい数のプロセスから始まります。実際には、セキュリティシーケンスをより迅速に取得できます。

コアステップ

データ構造:
長さmの一次元アレイ利用可能で入手可能であるn個のいくつのリソースを示しM行列Maxは、各プロセスに必要なリソースの最大数を示し
、N
M行列の割り当てが、各プロセスに割り当てられているどのように多くのリソースを示し
=最大アロケーション必要なマトリックスは、各プロセスが最大で必要とするリソースの数を示しますか?長さmの1ビット配列要求を使用して、今回プロセスによって要求されたさまざまなリソースの数を示します

銀行家のアルゴリズムの手順:
①アプリケーションが以前に宣言された最大需要を超えているかどうかを確認します。②システム内の残りの使用可能なリソースがこの時点でまだ要求を満たすことができるかどうかを確認します。③データ構造の割り当てと変更を試みます。④
セキュリティアルゴリズムで確認します。この割り当てはありますかシステムを危険な状態にします

セキュリティアルゴリズムの手順:
現在残っている利用可能なリソースがプロセスの最大需要を満たすことができるかどうかを確認し、可能であれば、プロセスをセキュリティシーケンスに追加し、プロセスが保持するすべてのリソースを再利用します。
上記のプロセスを継続的に繰り返して、最終的にすべてのプロセスをセキュリティシーケンスに追加できるかどうかを確認します。

デッドロックの検出

システムがデッドロックしているかどうかを検出するには、次のことが必要です
。①特定のデータ構造を使用してリソース要求と割り当て情報を保存します
。②上記の情報を使用してシステムがデッドロック状態になっているかどうかを検出するアルゴリズムを提供します。

ここに画像の説明を挿入します
ここに画像の説明を挿入します

システム内に残っている利用可能なリソースの数がプロセスのニーズを満たすのに十分である場合、プロセスは当面ブロックされず、スムーズに実行できます。このプロセスの実行が終了し、リソースがシステムに返されると、リソースを待機している一部のプロセスがアクティブ化され、スムーズに実行される場合があります。
同様に、これらのアクティブ化されたプロセスが実行された後、一部のリソースが返され、他のブロックされたプロセスがアクティブ化される可能性があります...
上記のプロセスを分析し、最終的にすべてのエッジを削除すると、グラフを完全に簡略化できると言われます。このとき、デッドロックがあってはなりません(安全なシーケンスを見つけるのと同じです)。
最終的にすべてのエッジを削除できない場合は、この時点でデッドロックが発生しています。
結局、まだエッジに接続されているプロセスは、デッドロック状態にあるプロセスです。

ここに画像の説明を挿入します

デッドロックを検出するアルゴリズム:

1)リソース割り当てグラフで、ブロックされていない、または孤立点ではないプロセスPiを見つけます(つまり、それに接続されている有向エッジを見つけ、有向エッジに対応するリソースのアプリケーションの数がシステム内の空きリソース数量次の図に示すように、R1には空きリソースがなく、R2には1つの空きリソースがあります。プロセスに接続されているすべてのエッジが上記の条件を満たす場合、プロセスは完了するまで実行を継続できます。次に、占有しているすべてのリソースを解放します)。すべてのリクエストエッジと割り当ての変更を排除して、分離ノードにします。次の図では、P1はこの条件を満たすプロセスノードであるため、P1のすべてのエッジが削除されます。
2)プロセスPiによって解放されたリソースは、これらのリソースを待機することによってブロックされた一部のプロセスをウェイクアップする可能性があり、元のブロックプロセスが非ブロックプロセスになる可能性があります。次の図では、P2がこの条件を満たす。1)の方法による一連の簡略化の後、途中のすべてのエッジを削除できれば、グラフは完全に簡略化されていると言えます。
ここに画像の説明を挿入します
デッドロック理論:ある時点でのシステムのリソース割り当て図を完全に単純化できない場合、システムはこの時点でデッドロックになります。

デッドロックの除去

デッドロックが検出されたら、すぐにデッドロックを解除する必要があります。
補足:システム内のすべてのプロセスがデッドロックされているわけではありません。デッドロック検出アルゴリズムを使用してリソース割り当てグラフを簡略化した後、エッジに接続されたままのプロセスはデッドロックプロセスになります。

デッドロックを解除する主な方法は次のとおりです:
1。資源剥奪法。一部のデッドロックされたプロセスを一時停止(一時的に外部メモリに配置)し、そのリソースを取得して、これらのリソースを他のデッドロックされたプロセスに割り当てます。ただし、中断されたプロセスは、長期間リソースが不足しているために空腹になるのを防ぐ必要があります。
2.2。失効処理メソッド(または終了処理メソッドと呼ばれる)。一部またはすべてのデッドロックされたプロセスを強制的に取り消し、これらのプロセスからリソースを奪います。このアプローチの利点は、実装が簡単であるが、支払われる価格が高くなる可能性があることです。一部のプロセスは長時間実行されていて終了間近である可能性があるため、一度終了すると不足し、将来的に最初からやり直す必要があります。
3.3。プロセスロールバック方式。デッドロックを回避するために、1つ以上のデッドロックプロセスを十分にフォールバックさせます。これには、システムがプロセスの履歴情報を記録し、復元ポイントを設定する必要があります。

したがって、重要なのは、誰に対して行うか
です。1。プロセスの優先度、低い優先度
2.実行された時間
3.完了するまでにかかる時間
4.プロセスによって使用されたリソースの量と時間それが実行されたいくつかのリソースを持つ上で手を-
5バッチ処理へのハンズオン、プロセス対話型またはバッチベースです

おすすめ

転載: blog.csdn.net/Shangxingya/article/details/113801826