Чому небезпечний стан не завжди викликає тупик?

Я читав Гальвін Операційні системи і натрапив на нижній рядок,

Однак, не всі небезпечні стани є тупиком. Небезпечний стан може призвести до тупикової ситуації

Може хтось, будь ласка, пояснить, як тупик! = Небезпечний стан? Я також зловив ту ж лінію тут

Якщо безпечної послідовності не існує, система перебуває в небезпечному стані, що МОЖЕ призвести до тупикової ситуації. (Усі безпечні стани безкоштовні, але не всі небезпечні стани призводять до тупикових ситуацій.)

Тупик означає що - то конкретне: є два (або більше) процесів, які в даний час блоковані чекаю один від одного.

У небезпечному стані ви також можете опинитися в ситуації, коли десь у майбутньому може виникнути глухий кут, але це ще не сталося, оскільки один або обидва процеси насправді не почали чекати.

Розглянемо наступний приклад:

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.

Просто для пояснення того, що говорила «Мандрівна логіка».

Скажімо, у мене є два потоки, яким обом потрібен доступ до 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) Цикл є обов'язковою умовою для тупикового зв'язку (як для одиночного, так і для кількох екземпляри ресурсів)

Отже, ми можемо довести, що існує цикл, який може не призвести до тупикового зв'язку цикл, як тільки процес P3 закінчується і відпускає його (пам’ятайте, що P3 не має ніякої залежності і не чекає будь-якого іншого ресурсу).

Тривіальний небезпечний стан: Нитка 1 бере блокування A, потім блокування B, а потім розблокує обидва. Нитка 2 приймає замок B, потім блокування A, потім розблокує обидва.

Це призведе до тупикової ситуації лише в тому випадку, якщо Нитка 2 зафіксує замок B просто між Ниткою 1, яка приймає замок A і намагається зняти замок B, або Нитка 1 зафіксує замок A прямо між Ниткою 2, яка приймає замок B і намагається зняти замок A.

Якщо Нитка 1 і Нитка 2 роблять це випадковим чином один раз на годину, і існує мікросекундний проміжок часу, який би фактично призвів до тупикової ситуації. це може працювати дуже довго в руці клієнтів, поки з часом випадково ви не отримаєте тупик.

Пройдіться по вулиці із закритими очима. Це небезпечно. Але тебе не завжди вбивають.