安全でない状態が常にデッドロックを引き起こさないのはなぜですか？

私はGalvinのオペレーティングシステムを読んでいて、以下の行に出くわしました。

ただし、すべての安全でない状態がデッドロックであるとは限りません。安全でない状態はデッドロックにつながる可能性があります

誰かがどのようにデッドロックを説明できますか！=安全でない状態？ここでも同じラインを捉えました

安全なシーケンスが存在しない場合、システムは危険な状態にあり、デッドロックを引き起こす可能性があります。（すべての安全な状態でデッドロックは発生しませんが、すべての安全でない状態がデッドロックを引き起こすわけではありません。）

デッドロックは特定のことを意味します：現在お互いを待ってブロックされている2つ（またはそれ以上）のプロセスがあります。

で危険な状態あなたもそこな状況にあることができるかもしれない将来のデッドロックいつかあってもよいが、プロセスの一方または両方が実際に待って開始していないので、それはまだ起きていません。

次の例について考えてみます。

Process A                  Process B
lock X                     lock Y           # state is "unsafe"
                           unlock Y
lock Y                                      # state is back to "safe" (no deadlock this time.  We got lucky.)

あなたが与えたリンクのセクション7.5.1にもっと興味深い例があります：

以下を備えた12台のテープドライブを備えたシステムを考えます。

Process       Max Need       Current
P0:             10              5
P2:              9              3

これは危険な状態です。しかし、私たちは行き詰まっているわけではありません。空きドライブは4つしかないため、たとえば、P0 が追加の5を要求し、P2 が追加の1を要求する場合、デッドロックが発生しますが、まだ発生していません。そして、P0はそれ以上のドライブを要求しないかもしれませんが、代わりにすでに持っているドライブを解放するかもしれません。Max needプログラムのすべての可能な実行上で、これは我々がP0内のすべての10台のドライブを必要とする実行の1ではないかもしれません。

Wandering Logicの発言を詳しく説明します。

XとYへのアクセスを必要とする2つのスレッドがあり、同期もデッドロックを修正するメカニズムもないとします。XとYをロックし、どちらも続行できないため、これは安全ではありません。しかし、それは保証されていません。

Thread 1                    Thread 2
Lock X                      
Lock Y
OS Interrupts Thread 1 and passes control to Thread 2
                            Unable to lock needed resources.
OS Interrupts Thread 2 and passes control to Thread 1
Unlock X                    
Unlock Y                    
                            Lock Y
                            Lock X
 ....

このシナリオはデッドロックに陥りませんでしたが、発生する可能性があります。スレッド処理の仕組みにより、セットフローはありません。OSがスレッドを制御するため、次のようなことが発生する可能性があります。

Thread 1                    Thread 2
Lock X        
OS Interrupts Thread 1 and passes control to Thread 2
                            Lock Y              
DEADLOCK Thread 1 needs Y, Thread 2 needs X. Neither knows to back down and simply waits.

安全な状態では確実にデッドロックは発生しませんが、デッドロックを防止するためのすべての要件を満たせない場合、発生する可能性があります。たとえば、2つのスレッドがスレッドA、スレッドBを開始したときにデッドロックになる可能性があるが、反対のスレッド（B、A）を開始した場合、それらは正常に機能します。Bの方がいいと思います;）システムの状態は安全ではありません。しかし幸運な開始シーケンスでそれは機能します。デッドロックはありませんが、可能です。それらを手動で同期する場合-順序どおりに開始する-危険です-何らかの理由で期待どおりに起動されない可能性があります-システムはまだ安全ではありません（デッドロックの可能性があるため）が、その可能性は低いです。継続後のスレッドの凍結や中断などの外部イベントの場合、失敗します。

安全な状態はデッドロックを回避するのに十分な状態ですが、安全でない状態は必須の状態にすぎないことを理解する必要があります。現在、頭からコードを書くのは難しいですが、いくつか検索できます。私はAdaで99/100回以上コードが数週間完全に機能していた（そしてサーバーの再起動によりデッドロックではなく停止した）コードに遭遇しましたが、たまに数秒後にデッドロック状態になってクラッシュしました。

除算と比較して簡単な例をいくつか挙げてみましょう：関数がc / dを除算して結果を返す場合、dが0に等しいかどうかをチェックせずに、ゼロ除算エラーが発生する可能性があるため、コードは安全ではありません（同じ名前付けが意図されています）。あなたがそのような除算を行うと、すべてがうまくいきますが、理論的な分析コードは安全ではなく、適切に処理されない未定義の動作に陥る可能性があります。

これについての私の理解は次のとおりです（間違っている場合は修正してください）：（A）デッドロックの場合、サイクルが存在することを意味します（必要な条件の1つ）（B）サイクルはデッドロックの必須条件です（シングルとマルチの両方の場合）インスタンスリソース）

これで、デッドロックにつながらない可能性のあるサイクルが存在することを証明 できます。ここでは、安全でない状態が検出されたことを意味するサイクルが存在することがわかります。ただし、サイクルに参加しているリソースR2がプロセスP3が完了して解放するとすぐにサイクルします（P3には依存関係がないか、他のリソースを待機していないことに注意してください）。

ささいな危険な状態：スレッド1はロックAを取得し、次にロックBを取得してから、両方をロック解除します。スレッド2はロックB、Aをロックし、両方をロック解除します。

スレッド2がロックBをとる場合にのみデッドロックにつながるだけでロックAを取るスレッド1ロックAを取って、ロックBを取るしようとしている間、または1スレッドだけロックBを取って、ロックAを取るしようとしているスレッド2間

スレッド1とスレッド2がこれを1時間に1回ランダムに行い、実際にデッドロックにつながるマイクロ秒の時間のギャップがある場合。これは、最終的に偶然にデッドロックが発生するまで、顧客の手元で非常に長い時間実行される可能性があります。

目を閉じて通りを渡ります。安全ではありません。しかし、あなたはいつも殺されるとは限りません。