Мал. 7.2. Приклад надійного стану для системи з 3 користувачами і 11 пристроями.

Даний стан надійний. Подальші дії системи можуть бути такі. Спочатку задовольнити запити третього користувача, потім дочекатися, коли він закінчить роботу і звільнить свої три пристрої. Потім можна обслужити першого і другого користувачів. Тобто система задовольняє тільки ті запити, які залишають її в надійному стані, і відхиляє останні.

Термін ненадійний стан не припускає, що обов'язково виникне безвихідь. Він лише говорить про те, що у разі несприятливої послідовності подій система може зайти в безвихідь.

Даний алгоритм володіє тією гідністю, що при його використанні немає необхідності в перерозподілі ресурсів і відкоті процесів назад. Проте використання цього методу вимагає виконання ряду умов.

• Число користувачів і число ресурсів фіксоване.

• Число працюючих користувачів повинне залишатися постійним.

• Алгоритм вимагає, щоб клієнти гарантовано повертали ресурси.

• Мають бути заздалегідь вказані максимальні вимоги процесів до ресурсів. Найчастіше дана інформація відсутня.

Наявність таких жорстких і часто неприйнятних вимог може схилити розробників до вибору інших вирішень проблеми взаимоблокировки.

Запобігання тупикам за рахунок порушення умов виникнення безвиході

У відсутність інформації про майбутні запити єдиний спосіб уникнути взаимоблокировки – добитися невиконання хоч би одного з умов розділу «Умови виникнення безвиході».

Порушення умови взаємовиключення

У загальному випадку уникнути тих, що взаємовиключають неможливо. Доступ до деяких ресурсів має бути винятковим. Проте деякі пристрої вдається обобществить. Як приклад розглянемо принтер. Відомо, що намагатися здійснювати вивід на принтер можуть декілька процесів. Щоб уникнути хаосу організовують проміжне формування всіх вихідних даних процесу на диску, тобто пристрої, що розділяється. Лише один системний процес, званий сервісом або демоном принтера, відповідає за виведення документів на друк у міру звільнення принтера, реально з ним взаємодіє. Ця схема називається спулингом (spooling). Таким чином, принтер стає пристроєм, що розділяється, і безвихідь для нього усунена.

На жаль, не для всіх пристроїв і не для всіх даних можна організувати спулинг. Неприємним побічним наслідком такої моделі може бути потенційна тупикова ситуація із-за конкуренції за дисковий простір для буфера спулинга. Проте в тій або іншій формі ця ідея застосовується часто.

Порушення умови очікування додаткових ресурсів

Умови очікування ресурсів можна уникнути, зажадавши виконання стратегії двофазного захоплення.

• У першій фазі процес повинен запрошувати всі необхідні йому ресурси відразу. До тих пір, поки вони не надані, процес не може продовжувати виконання.

• Якщо в першій фазі деякі ресурси, які були потрібні даному процесору, вже зайняті іншими процесами, він звільняє всі ресурси, які були йому виділені, і намагається повторити першу фазу.

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

Таким чином, один із способів – змусити всі процеси зажадати потрібні ним ресурси перед виконанням («все або нічого»). Якщо система в змозі виділити процесу все необхідне, він може працювати до завершення. Якщо хоч би один з ресурсів зайнятий, процес чекатиме.

Дане рішення застосовується в пакетних мейнфреймах (mainframe), які вимагають від користувачів перерахувати всі необхідні його програмі ресурси. Іншим прикладом може служити механізм двофазної локалізації записів в СУБД. Проте в цілому подібний підхід не дуже привабливий і приводить до неефективного використання комп'ютера. Як вже наголошувалося, перелік майбутніх запитів до ресурсів рідко вдається спрогнозувати. Якщо така інформація є, то можна скористатися алгоритмом банкіра. Відмітимо також, що описуваний підхід противоречит парадигмі модульності в програмуванні, оскільки застосування повинне знати про передбачувані запити до ресурсів у всіх модулях.

Порушення принципу відсутності перерозподілу

Якби можна було відбирати ресурси у утримуючих їх процесів до завершення цих процесів, то вдалося б добитися невиконання третьої умови виникнення безвиході. Перерахуємо мінуси даного підходу.

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

Все питання в ціні подібного рішення, яка може бути дуже високою, якщо необхідність відбирати ресурси виникає часто.

Порушення умови кругового очікування

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

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

Одін з небагатьох прикладів впорядковування ресурсів – створення ієрархії спин-блокувань в Windows 2000. Спин-блокування – простий спосіб синхронізації (питання синхронізації процесів розглянуті у відповідній лекції). Спин-блокування може бути захоплена і звільнена процесом. Класична тупикова ситуація виникає, коли процес P1 захоплює спин-блокування S1 і претендує на спин-блокування S2, а процес P2, захоплює спин-блокування S2 і хоче додатково захопити спин-блокування S1. Щоб цього уникнути, всі спин-блокировки поміщаються у впорядкований список. Захоплення може здійснюватися тільки в порядку, вказаному в списку.

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

Таким чином, технологія запобігання циклічному очікуванню, як правило, неефективна і може без необхідності закривати доступ до ресурсів.

Виявлення взаимоблокировки зводиться до фіксації тупикової ситуації і виявлення залучених в неї процесів. Для цього проводиться перевірка наявності циклічного очікування у випадках, коли виконано перші три умови виникнення безвиході. Методи виявлення активно використовують графи розподілу ресурсів.

Розглянемо модельну ситуацію.

• Процес P1 чекає ресурс R1.

• Процес P2 утримує ресурс R2 і чекає ресурс R1.

• Процес P3 утримує ресурс R1 і чекає ресурс R3.

• Процес P4 чекає ресурс R2.

• Процес P5 утримує ресурс R3 і чекає ресурс R2.

Питання полягає в тому, чи є дана ситуація тупиковою, і якщо так, то які процеси в ній беруть участь. Для відповіді на це питання можна сконструювати граф ресурсів, як показано на мал. 7.2. З малюнка видно, що є цикл, що моделює умову кругового очікування, і що процеси P2,P3,P5, а може бути, та інші знаходяться в тупиковій ситуації.

Рис. 7.3. Граф ресурсів

Візуально легко виявити наявність безвиході, але потрібні також формальні алгоритми, що реалізовуються на комп'ютері.

Одін з таких алгоритмів описаний в [Таненбаум, 2002], там же можна знайти посилання на інші алгоритми.

Існують і інші способи виявлення безвиході, застосовні також в ситуаціях, коли є декілька ресурсів кожного типу. Так в [Дейтел, 1987] описаний спосіб, званий редукцією графа розподілу ресурсів, а в [Таненбаум, 2002] – матричний алгоритм.

Відновлення після тупиків

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

Складність відновлення обумовлена рядом чинників.

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

• Якщо навіть такі засоби є, то їх використання вимагає витрат і уваги оператора.

• Відновлення після безвиході може зажадати значних зусиль.

Найпростіший і найбільш поширений спосіб усунути безвихідь – завершити виконання одне або більш за процеси, щоб згодом використовувати його ресурси. Тоді у разі успіху решта процесів зможе виконуватися. Якщо це не допомагає, можна ліквідовувати ще декілька процесів. Після кожної ліквідації повинен запускатися алгоритм виявлення безвиході.

По можливості краще ліквідовувати той процес, який може бути без збитку повернений до початку (такі процеси називаються ідемпотентними). Прикладом такого процесу може служити компіляція. З іншого боку, процес, який змінює вміст бази даних, не завжди може бути коректно запущений повторно.

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

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

Коли безвихідь виявлена, видно, які ресурси залучені в цикл кругового очікування. Щоб здійснити відновлення, процес, який володіє таким ресурсом, має бути відкинутий до моменту часу, передуванню його запиту на цей ресурс.

Висновок

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

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