オペレーティングシステム-8デッドロックおよびプロセス間通信

1デッドロック

1.1デッドロックの問題

ここに画像の説明を挿入
日常生活の中で:
ここに画像の説明を挿入
OSの中で:
ここに画像の説明を挿入

1.2デッドロックモデル

需要側:プロセスは、
必要なリソース(CPU、メモリユニット、IOリソース、および共有変数)を表します。
次のように、各プロセスで使用されるリソースはn個あります。

  • アイドル状態のリソース、適用される可能性がある、適用されない可能性がある
  • 使用状態、他のリソースはこのリソースを使用できません
  • アイドル状態のリソース。プロセスがこのリソースの使用を終了すると、リソースが解放されます。

ここに画像の説明を挿入
ここに画像の説明を挿入
ここに画像の説明を挿入
P I - > RのJ:プロセスは、リソースのニーズ
のR jは- > P I:現在のリソースがプロセスで使用される1つのリソース。
ここに画像の説明を挿入
ここに画像の説明を挿入
R 2がPに与えられる1、および他のリソースがPに与えられる2のみリソース
R 1 Pに与えられる2、P 1が望むのリソースR 1のみ(スリープ)を待つことができる唯一のリソース
R 3はPに与えられる3、及びP 2が望むのリソースR 3は(だけ待つことができますスリープ)
一定期間後のプロセスP 3により、リソースが使い果たされると解放されるため、デッドロックは発生しません
ここに画像の説明を挿入
。1つのエッジを追加した後、P 3にはR 2のリソースが必要です(リングを形成します)
。プロセスと必要なリソースとの間のリンク関係に形成されたリング:デッドロックの特徴
ここに画像の説明を挿入
ここに画像の説明を挿入
P回ためそこ環であるが、ないデッドロック、2またはP 4。リソースが解放されると、P 1またはP 3は、リソースを取得し、実行します。
だから、デッドロックのループが存在しますが、ループが存在する場合、必ずしもデッドロックがない可能性があります。
ここに画像の説明を挿入

1.3デッドロック特性

ここに画像の説明を挿入

デッドロックに必要な4つの条件デッドロックは上記の4を引き起こします
が、上記の4は必ずしもデッドロックを引き起こすとは限りません。
ここに画像の説明を挿入
右のP2とP4は保持されますが、待機しません。

1.4デッドロック処理方法

ここに画像の説明を挿入
このデッドロックを無視する設計があるのはなぜですか?
1.デッドロックの回復には非常にコストがかかります
。2。OSがデッドロック状態にならないように一連の制約を設定すると、OSの機能が大幅に制限され、アプリケーションとOSの機能を完全に実行できなくなります。仮定では無視されます。よく使用されるデッドロックの問題には、小さなオーバーヘッドがあります。

1.4.1デッドロックの防止

デッドロックの4つの条件のいずれかを破ると、それが合理的な破れである限り、デッドロック防止効果があり
ここに画像の説明を挿入
ます。リソースへのアクセスの相互排除は保証されないため、実行が不確実になり、あまり得意
ここに画像の説明を挿入
はありません。最初はプロセスに必要なすべてのリソースを占有しますが、各リソースを使用するプロセス間の間隔が非常に大きいため、システムの効率が非常に低くなり、
ここに画像の説明を挿入
相互に排他的なリソースが不足する可能性があります。プリエンプションを使用すると、つまり、プリエンプションに変更しても機能しません。
ここに画像の説明を挿入
リソースを並べ替え、シーケンス番号が増減するリソースにのみ適用して、プロセスがリングを形成しないようにします。
水中システムでより多く使用されます

1.4.2デッドロックの回避

リソースを申請するときは、デッドロックが発生するかどうかを判断します。デッドロックが発生する可能性がある場合は、リソースが使用され、システムに追加の事前情報が必要です。
ここに画像の説明を挿入
ここに画像の説明を挿入
リソースの
割り当て後にリソースがデッドロックを発生しない場合、リソースがされに割り当てられた危険な状態の後に環を形成してもよく、それは危険な状態であり、
危険な状態がデッドロック状態に含ま
仮定はPを回す:プロセスのシーケンスに従って順次安全な状態に行われるiがPその後、実行を0 PにI .1-使用リソースの解放後、実行されたP iを満たすためにリソースを使用できなかった場合、すべてのプロセスは通常の操作であり、デッドロックは発生しません
ここに画像の説明を挿入
ここに画像の説明を挿入

銀行家のアルゴリズム

ここに画像の説明を挿入
ここに画像の説明を挿入
デッドロックを判断するのは面倒なので、安全でないかどうかを判断するように変更されます。
ここに画像の説明を挿入
セキュリティ状態検出アルゴリズム:
ここに画像の説明を挿入
ここに画像の説明を挿入
バンカーアルゴリズム:
リクエストベクトル:各プロセスに必要な各リソースの数
ここに画像の説明を挿入
。上記で安全なシーケンスを見つけることができますか。図?
P1からP4までの4つのプロセスが終了していないと仮定して、各プロセスを正常に終了できる実行シーケンスがある
かどうかを確認します。プロセスの必要性が使用可能なベクトル0、1、1、およびP2よりも小さいかどうかを確認します。満足、セット完了[2]が真である場合、リソースが使い尽くされた後にP2が解除され、AにおけるP2の(6、1、2)のVに追加される(0、
ここに画像の説明を挿入
ここに画像の説明を挿入
ここに画像の説明を挿入
1、1 )の利用可能、次のようになります。すべての1つの安全なシーケンスが見つかりました:P2、P1、P3、P4
ここに画像の説明を挿入
P1が要求1、0、1を送信すると仮定すると、銀行家のアルゴリズムはそれを受け入れますか?
1、0、1をP1に割り当てた
ここに画像の説明を挿入
後、使用可能な0、1、1はどのプロセスのニーズも満たさないため、銀行家のアルゴリズムはP1によって発行された1、0、1の要求を満たしません。

1.4.3デッドロックの検出

リラックスした状態

  • デッドロックの回避とは、デッドロックがないことを意味します。安全でない状態であることが判明すると、リソースの申請を続行できなくなります。
  • デッドロック検出とは、システムをデッドロック状態にすることで、ある段階でデッドロックの有無を判断し、デッドロックが検出されると復旧メカニズムを開始します。デッドロックの検出をシステムに移動しても、要求が行われるたびに判断されることはなくなりました。
    ここに画像の説明を挿入
    ここに画像の説明を挿入
    ここに画像の説明を挿入
    このアルゴリズムは、システムのデッドロックが
    高額かどうかを確認するために定期的に実行されます。各プロセスに必要なリソースの最大数を知る必要があります。デッドロックの検出には
    ここに画像の説明を挿入
    P0-> P2-> P1-> P3-> P4がよく使用さ
    ここに画像の説明を挿入
    ここに画像の説明を挿入
    ますが、どのプロセスを強制終了するかを検討する必要があり、どのプロセスを選択するのが難しいか明確な規定がないため、検出アルゴリズムは開発段階でより使用されます

1.4.4デッドロックからの回復

どのプロセスを強制終了するか、スキームは次のとおりです(プロセスを終了します)。
ここに画像の説明を挿入
リソースのプリエンプション:
ここに画像の説明を挿入

2プロセス間通信(IPC)

ここに画像の説明を挿入

2.1概要

ここに画像の説明を挿入
ここに画像の説明を挿入
(A):プロセス間の間接通信
(b):プロセス間の直接通信
ここに画像の説明を挿入
リンク確立には、osのサポートが必要です(osはすべてのコンピューターリソースにアクセスしてこのパスを確立できます)。これは、リンクがプロセス間の分離と
ここに画像の説明を挿入
ここに画像の説明を挿入
ここに画像の説明を挿入
ブロックを解除するためです。:メッセージを送信したい場合は、終了できない場合はブロックします。送信した後、戻って次の手順を実行します。
非ブロック:メッセージを送信したい場合は、成功か失敗かに関係なく、これ操作はすぐに戻ります。成功と終了の時間と送信と返送の時間の間に大きなギャップがあるかもしれません。これは非同期の現れです。

2.2プロセス間通信方式

メッセージがキャッシュに保存されている場合、キャッシュの主な目的は、送信者と受信者の間の不一致を回避するために効率を向上させることです(メッセージはすばやく送信されて非常に遅く受信されるか、非常に速く受信されて非常に遅く送信される可能性があります)。効率を上げるために処理できない送信者と受信者の情報を保存します。
ここに画像の説明を挿入
データがない場合、受信者は待機する必要があります。
ここに画像の説明を挿入

シグナル(通知)

ここに画像の説明を挿入
信号はハードウェア割り込みとは異なり、ハードウェアがCPUに処理させ、ハードウェア割り込み(割り込み)が生成されます。信号は、
何らかの理由でアプリケーションに信号を送信するソフトウェアosです。アプリケーションはどのように処理しますか?

  • キャッチ:
  • ingore:処理なし
  • マスク:

柔軟性があり効率的です。信号はほんの少しの噛み付きで、通知の効果があり、データを送信できません。処理後、中断したプログラムに直接戻り、再実行し
ます。上記の機能を実行するために、OSはどのような手段を提供していますか?
ここに画像の説明を挿入

  1. アプリケーションは単一のシグナルを処理します。プログラムが起動したら、シグナルのハンドルを登録し、これをシステムコールとしてosに送信します。osは、シグナルが生成されると、アプリケーションを呼び出すことを認識します。シグナル処理関数が記述されています。プログラムによって
  2. このシグナルが生成されたら、OSは現在実行中のプロセスを停止し、シグナル処理機能にジャンプして実行するにはどうすればよいですか?OSがこの信号を受信すると、カーネル状態になります。カーネル状態からユーザー状態に戻って、どのプログラムを事前に準備する必要があるかを信号に応答する場合、戻り点を信号のエントリに変更する必要があります。システムコールと組み合わせた処理機能アプリケーションソフトウェアのスタックを変更して、最初にシステムコールに返された次のステートメントが信号処理機能のエントリになり、アドレスが次のようになるようにする必要があることがわかります。信号処理機能が後続のリターンアドレスとして使用された後に実行されます。これにより、カーネルからアプリケーションプログラムの実行に戻り、信号処理関数のエントリにジャンプして残りのスタック情報に従って実行し、この関数のユーザーモードが実行された後、ユーザーモードに戻ります。 、呼び出しに戻ります。関数は中断され、実行を続行します。通常、ユーザープログラムのスタックは変更されず、トロイの木馬は変更されます。

パイプライン(データ交換)

非常に初期のメカニズムであるUNIXエキスパートの設計では、各小さなプログラムに1つの小さな機能を実装し、それらを柔軟に組み合わせて複雑な機能を実現したいと考えています。あるプログラムの出力は別のプログラムの入力に
ここに画像の説明を挿入
送られます。シェルはプロセスです。このプロセスがls | moreを受信すると、これが2つのコマンドの組み合わせであることを認識し、2つのプロセス(ls以上)を作成します。次に、lsの出力を特別な処理で処理し、出力を画面ではなくパイプ(メモリ内のバッファに相当)にリダイレクトします。その後、より多くのプロセスがパイプからデータを取得します。
パイプは制限されます。lsがフェッチするには遅すぎる場合、パイプラインへの出力はブロックされます

メッセージキュー(データ交換)

メッセージ処理とパイプライン

  • パイプラインは、子プロセスの親プロセスによって確立されたチャネルです。プロセス間に親子関係がない場合、パイプラインは機能しません。
  • パイプラインのデータはバイトストリームであり、構造体で表されていません
  • メッセージキューは、プロセス間の親子関係をサポートできません
  • 構造化データを送受信することで、複雑なプログラムをより柔軟かつ便利に作成できます。また、データ
    ここに画像の説明を挿入
    がいっぱいまたは空になります。

共有メモリ

ここに画像の説明を挿入
各プロセスは
、メモリを直接読み書きしてデータ共有を完了すること
ここに画像の説明を挿入
ができます。共有メモリを実現するにはどうすればよいですか。
物理メモリの同じブロックを、異なるプロセスの同じまたは異なるアドレス空間にマップします

おすすめ

転載: blog.csdn.net/qq_42713936/article/details/105586542