Билет №21

Тупики: Попередження виявлення розв’язка

Боротьба з тупиками включає три завдання:

• попередження тупиків - яку стратегію розподілу ресурсів вибрати, щоб безвихідь не виникала взагалі?

• виявлення тупиків - якщо не вдалося застосувати стратегію, яка б застерегла тупик, то як виявити виниклий тупик?

• розв'язка тупиків - якщо тупик виявлена, то як від нього позбавитися?

Можливі стратегії розподілу ресурсів розташовуються між двома полюсами - від найліберальніших до найконсервативніших. Чим ліберальніше стратегія, тим більш "охоче" ОС задовольняє запити на ресурси. Але за дуже ліберальну стратегію доводиться розплачуватися можливістю виникнення тупиків. Консервативні стратегії робить тупик неможливим в принципі, завдання виявлення і розв'язки при застосуванні таких стратегій не ставляться, але плата за це - часті відмови у виділенні ресурсів, отже, зниження рівня мультипрограмування, а отже, - і зниження пропускної спроможності. Нижче ми розглядатимемо стратегії запобігання, рухаючись від консервативного полюса до ліберального в такому порядку:

• послідовне виділення;

• залпове виділення;

• ієрархічне виділення;

• виділення по попередніх заявках.

Послідовне виділення

Будь-якими ресурсами може одночасно користуватися тільки один процес. Ця стратегія невиправдано знижує рівень мультипрограмування і неефективно використовує ресурси (вони теж простоюють), і може застосовуватися тільки в таких ОС, в яких і розрахунковий рівень мультипрограмування невисокий.

Залпове виділення

Процес винен запитувати/вивільняти всі використовувані ним ресурси відразу. В рамках залпової стратегії можливі два варіанти: виділяти всі ресурси при створенні процесу і звільняти при його завершенні або ж дозволити процесу запитувати/вивільняти ресурси кілька разів в ході свого виконання (але обов'язково все "залпом").

Ієрархічне виділення

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

Застосування цієї стратегії вимагає, щоб процес передав ОС "попередню заявку" (advanced claim) і в ній вказав максимальний об'єм ресурсів, який йому знадобиться. В ході виконання процес може в довільному порядку запитувати/вивільняти ресурси, не виходячи, проте, за межі заявленого об'єму. Ситуація в системі називається такою, що реалізовується, якщо:

• жодна заявка не перевищує загального числа ресурсів в системі;

• жоден процес не вимагає більшого числа ресурсів, чим їм заявлено;

• сумарне число вже розподілених всім процесам ресурсів не перевершує загального числа ресурсів в системі.

Ситуація називається безпечною, якщо процеси можна збудувати в таку послідовність, що:

• перший процес може нормально завершитися навіть, якщо він повністю вибере ресурси по своїй заявці;

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

• i-й процес може нормально завершитися навіть, якщо він повністю вибере ресурси по своїй заявці, за умови, що завершиться i-1-й процес і звільнить утримувані ним ресурси.

Інтерфейс користувача