Почему небезопасное государство не всегда вызывает тупик?

Я читал «Операционные системы» Гальвина и натолкнулся на следующую строчку:

Однако не все небезопасные государства находятся в тупике. Небезопасное состояние может привести к тупику

Может кто-нибудь объяснить, пожалуйста, как тупик! = Небезопасное состояние? Я также поймал ту же самую линию здесь

Если безопасной последовательности не существует, то система находится в небезопасном состоянии, что МОЖЕТ привести к тупиковой ситуации. (Все безопасные состояния свободны от тупиков, но не все небезопасные состояния приводят к тупикам.)

Deadlock означает что-то конкретное: есть два (или более) процесса, которые в настоящее время заблокированы и ждут друг друга.

В небезопасном состоянии вы также можете оказаться в ситуации, когда в будущем может произойти тупик, но этого еще не произошло, потому что один или оба процесса фактически не начали ждать.

Рассмотрим следующий пример:

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касается всех возможных исполнений программы, и это может быть не одно из выполнений, когда нам нужны все 10 дисков в P0.

Просто чтобы пояснить, что говорит Wandering Logic.

Скажем, у меня есть два потока, которым обоим нужен доступ к X и Y, и у меня нет синхронизации и нет механизма для устранения тупика. Это небезопасно, так как один может заблокировать 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
 ....

Этот сценарий не оказался в тупике, но мог бы. Из-за способа работы потоков нет заданного потока. ОС контролирует потоки, поэтому может произойти что-то вроде следующего:

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.

Безопасное состояние наверняка не блокируется, но если вы не можете выполнить все требования для предотвращения тупика, это может произойти. Например, если два потока могут зайти в тупик, когда они запускают поток A, то поток B, но когда они начинают противоположное (B, A), они будут работать нормально - позвольте мне предположить, что B приятнее;) Состояние системы небезопасно, но с удачной стартовой последовательностью это будет работать. Нет тупика, но это возможно. Если вы также синхронизируете их вручную - начинайте в хорошем порядке - это опасно - по какой-то причине они могут не срабатывать, как вам нравится - система все еще небезопасна (из-за возможного тупика), но вероятность этого мала. В случае некоторых внешних событий, таких как замораживание потоков или прерываний после продолжения, произойдет сбой.

Вы должны понимать - безопасное состояние является достаточным условием, чтобы избежать тупика, но небезопасное является лишь необходимым условием. Трудно написать код без головы прямо сейчас, но я могу искать некоторые. Я сталкивался с кодом в Ada, что более 99/100 раз он прекрасно работал в течение нескольких недель (а затем останавливался из-за перезапуска сервера, а не тупика), но время от времени он падал через несколько секунд в состояние тупика.

Позвольте мне добавить несколько простых примеров, сравнивая с делением: если ваша функция делит c / d и возвращает результат, не проверяя, равен ли d 0, может быть ошибка деления на ноль, поэтому код небезопасен (то же самое предназначение именования), но до Вы делаете такое деление, все в порядке, но после теоретического анализа код небезопасен и может привести к неопределенному поведению, не обработанному должным образом.

Вот мое понимание (пожалуйста, поправьте меня, если я ошибаюсь): (A) Если тупик, значит, существует цикл (одно из необходимых условий) (B) Цикл является обязательным условием для тупика (как для одиночного, так и для множественного ресурсы экземпляра)

Таким образом, теперь мы можем доказать, что существует цикл, который не может привести к взаимоблокировке. Здесь можно увидеть цикл, означающий, что обнаружено небезопасное состояние, но это не может привести к тупику, поскольку ресурс R2, участвующий в цикле, может прервать Цикл, как только процесс P3 завершает работу и освобождает его (помните, что P3 не имеет никакой зависимости или ожидает какой-либо другой ресурс).

Тривиальное небезопасное состояние: поток 1 захватывает блокировку A, затем блокирует B, а затем разблокирует оба. Поток 2 берет блокировку B, затем блокировку A, а затем разблокирует обе.

Это приведет только к взаимоблокировке, если поток 2 захватывает блокировку B непосредственно между потоком 1, захватившим блокировку A и пытающимся захватить блокировку B, или поток 1 захватывает блокировку A непосредственно между потоком 2, блокирующим блокировку B и пытающимся захватить блокировку A.

Если поток 1 и поток 2 делают это случайным образом один раз в час, и существует микросекундный промежуток времени, который фактически приведет к тупику. это может продлиться очень долго в руках клиентов, пока в конечном итоге вы случайно не зашли в тупик.

Идите по улице с закрытыми глазами. Это небезопасно. Но тебя не всегда убивают.