користання функції wakeup означає: дане системне умова більш не задовольняється, отже, всі призупинені за умовою процеси повинні вийти з стану приостанова. Так, наприклад, процеси, припинені у зв'язку з зайнятістю буфера, не повинні далі перебувати в цьому стані, якщо буфер більше не використовується, тому вони поновлюються ядром. Ще один приклад: якщо кілька процесів виводять дані на термінал за допомогою функції write, термінальний драйвер може перевести їх у стан приостанова у зв'язку з неможливістю обробки великих обсягів інформації. Пізніше, коли драйвер буде готовий до прийому наступної порції даних, він відновить всі призупинені їм процеси. Використання операцій P і V в тих випадках, коли встановлюють блокування процеси отримують доступ до ресурсу по черзі, а всі інші процеси - у порядку надходження запитів, є кращим. У порівняно з однопроцесорній процедурою блокування (sleep-lock) дана схема зазвичай виграє, тому що якщо при настанні події всі процеси поновлюються, більшість з них може знову наткнутися на блокування і знову перейти в стан приостанова. З іншого боку, у тих випадках, коли потрібно вивести зі стану приостанова всі процеси одночасно, використання операцій P і V представляє відому складність. Якщо операція повертає значення семафора, є вона еквівалентної функції wakeup?
while (value (semaphore) <0)
{
V (semaphore);
};
Якщо втручання з боку інших процесів немає, ядро ​​повторює цикл доти, поки значення семафора чи не стане більше або дорівнює 0, бо це означає, що в стані приостанова по семафору немає більше жодного процесу. Тим не менше, не можна виключити і таку можливість, що відразу після того, як процес A при тестуванні семафора на однойменному процесорі виявив нульове значення семафора, процес B на своєму процесорі виконує операцію P, зменшуючи значення семафора до -1.
В
Процес A продовжить своє виконання, думаючи, що їм відновлені усі призупинені по семафору процеси. Таким чином, цикл виконання операції не дає гарантії відновлення всіх призупинених процесів, оскільки він не є елементарним. Розглянемо ще один феномен, пов'язаний з використанням семафорів в однопроцесорній системі. Припустимо, що два процеси, A і B, конкурують за семафор. Процес A виявляє, що семафор вільний і що процес B призупинений; значення семафора дорівнює -1. Коли за допомогою операції V процес A звільняє семафор, він виводить тим самим процес B зі стану приостанова і знову робить значення семафора нульовим. Тепер припустимо, що процес A, як і раніше виконуючись в режимі ядра, намагається знову заблокувати семафор. Виробляючи операцію P, процес призупиниться, оскільки семафор має нульове значення, незважаючи на те, що ресурс поки що вільний. Системі доведеться "Розщедритися" на додаткове перемикання контексту. З іншого боку, якби блокування була реалізована на основі однопроцесорній схеми (Sleep-lock), процес A отримав би право на повторне використання ресурсу, оскільки за цей час жоден з процесів не зміг би заблокувати його. Для цього випадку схема sleep-lock більш підходить, ніж схема з використанням семафорів. Коли блокуються відразу кілька семафорів, черговість блокування повинна виключати виникнення тупикових ситуацій. В якості прикладу розглянемо два семафора, A і B, і два а лгорітма, що вимагають одночасної блокування семафорів. Якби алгоритми встановлювали блокування на семафори у зворотному порядку, як випливає з малюнка,
В
br/>
послідувало б виникнення тупикової ситуації; процес A на однойменному процесорі захоплює семафор SA, в той час як процес B на своєму процесорі захоплює семафор SB. Процес A намагається захопити і семафор SB, але в результаті операції P переходить в стан приостанова, оскільки значення семафора SB не перевищує 0. Те ж саме відбувається з процесом B, коли останній намагається захопити семафор SA. Ні той, ні інший процеси продовжуватися вже не можуть. Для запобігання виникнення подібних ситуацій використовуються відповідні алгоритми виявлення небезпеки взаємної блокування, що встановлюють наявність небезпечної ситуації і ліквідують її. Тим не менше, використання таких алгоритмів "важчою" ядро. Оскільки число ситуацій, в яких процес повинен одночасно захоплювати кілька семафорів, досить обмежена, легше було б реалізувати алгоритми, що попереджають виникнення тупикових ситуацій ще до того, як вони будуть мати місце. Якщо, наприклад, якийсь набір семафорів завжди блокується в одному і тому ж порядку, тупикова ситуація ніколи не виникне. Але в тому випадку, коли захоплення семафорів у зворотному порядку уникнути не вдається, операція CP запобігає виникненню тупикової ситуації:
В
br/>
якщо операція завершиться невдало, процес B звільнить свої ресурси, щоб уникнути взаємного блокування, і пізніше запустить алгоритм на виконання повторно, швидше за все, тоді, коли процес A завершить роботу з ресурсом....
