Щоб попередити одночасне звернення процесів до ресурсу, програма обробки переривань, здавалося б, могла скористатися семафором, але через те, що вона не може призупиняти свою роботу (див. розділ 6), використовувати операцію P в цій програмі можна. Замість цього можна використовувати "циклічну блокування "(spin lock) і не переходити в стан приостанова, як у наступному прикладі:
while (! CP (semaphore));
Операція повторюється в циклі доти, поки значення семафора не перевищить 0; програма обробки переривань не призупиняв і цикл завершується тільки тоді, коли значення семафора стане позитивним, після чого це значення буде зменшено операцією CP. Щоб запобігти ситуації взаємного блокування, ядру потрібно заборонити всі переривання, що виконують "циклічну блокування". Інакше виконання процесу, який захопив семафор, буде перервано ще до того, як він зможе звільнити семафор; якщо програма обробки переривань спробує захопити цей семафор, використовуючи "циклічну блокування", ядро заблокує саме себе. Як приклад звернемося до малюнка:
В
p> У момент виникнення переривання значення семафора не перевищує 0, тому результатом виконання операції CP завжди буде "брехня". Проблема вирішується шляхом заборони всіх переривань на той час, поки семафор захоплений процесом.
3.4 Статті без ситуації
Розглянемо приклад глухого кута. Нехай двом процесам, що виконується в режимі мультипрограмування, для виконання їхньої роботи потрібно два ресурси, наприклад, принтер і диск. На малюнку показані фрагменти відповідних програм. br/>
В
Нехай після того, як процес А зайняв принтер (встановив блокуючу змінну), він був перерваний. Управління отримав процес В, який спочатку зайняв диск, але при виконанні наступної команди був заблокований, так як принтер виявився вже зайнятим процесом А. Управління знову отримав процес А, який у відповідності зі своєю програмою зробив спробу зайняти диск і був заблокований: диск вже розподілений процесу В. У такому положенні процеси А і В можуть знаходитися як завгодно довго.
Залежно від співвідношення швидкостей процесів, вони можуть або цілком незалежно використовувати колективні ресурси (г), або утворювати черзі до ресурсів, що (в), або взаємно блокувати один одного (б). Тупикові ситуації треба відрізняти від простих черг, хоча і ті й інші виникають при спільному використанні ресурсів і зовні виглядають схоже: процес призупиняється і чекає звільнення ресурсу. Однак чергу - це нормальне явище, невід'ємна ознака високого коефіцієнта використання ресурсів при випадковому надходження запитів. Вона виникає тоді, коли ресурс недоступний в даний момент, але через деякий час він звільняється, і процес продовжує своє виконання. Тупик ж, що видно з його назви, є в деякому роді нерозв'язною ситуацією. p> У розглянутих прикладах глухий кут був утворений двома процесами, але взаємно блокувати один одного можуть і більше число процесів. p> Проблема тупиків включає в себе такі завдання:
В· запобігання тупиків,
В· розпізнавання тупиків,
В· відновлення системи після тупиків.
Тупики можуть бути запобігти на стадії написання програм, тобто програми повинні бути написані таким чином, щоб безвихідь не міг виникнути ні при якому співвідношенні взаємних швидкостей процесів. Так, якби у попередньому прикладі процес А і процес У запитували ресурси в однаковій послідовності, то глухий кут був би в принципі неможливий. Другий підхід до запобігання тупиків називається динамічним і полягає у використанні певних правил при призначенні ресурсів процесам, наприклад, ресурси можуть виділятися в певній послідовності, загальною для всіх процесів.
У деяких випадках, коли тупикова ситуація утворена багатьма процесами, які використовують багато ресурсів, розпізнавання тупика є нетривіальним завданням. Існують формальні, програмно - реалізовані методи розпізнавання тупиків, засновані на веденні таблиць розподілу ресурсів і таблиць запитів до зайнятих ресурсів. Аналіз цих таблиць дозволяє виявити взаємні блокування.
Якщо ж тупикова ситуація виникла, то не обов'язково знімати з виконання всі заблоковані процеси. Можна зняти тільки частину з них, при цьому звільняються ресурси, очікувані іншими процесами, можна повернути деякі процеси в область свопінгу, можна зробити "відкат" деяких процесів до так званої контрольної точки, в якій запам'ятовується вся інформація, необхідна для відновлення виконання програми з даного місця. Контрольні точки розставляються в програмі в місцях, після яких можливе виникнення глухого кута. З усього вищесказаного ясно, що використовувати семафори потрібно дуже обережно, так як одна незначна помилка може призвести до останову системи. Для того щоб полегшити написання коректних програм, було запропоновано високорівневе засіб синхронізації, зване монітором. Монітор - це набір процедур, змінних і структур даних. Процеси м...
