оцесів.
Для захисту критичних секцій, в які за визначенням в будь-який момент часу може входити тільки один процес, використовуються двійкові семафори, також звані mutex (від mutual exclusion- взаємне виняток).
У цьому випадку не можна використовувати звичайні семафори, так як їх значення може перевищувати 1 і, отже, кілька програм можуть отримати доступ до ресурсу, зменшуючи значення семафора. Операція signal над двійковим семафором завжди встановлює його значення в 1. Операція wait зменшує це значення з 1 до 0 і дозволяє процесу продовжуватися далі . Якщо семафор має значення 0, то процес, що виконує wait , повинен чекати до тих пір, поки значення семафора не зміниться.
Помилки синхронізації, пов'язані з неправильним використанням семафорів, важко виявляються. Процес, який не виконує операцію wait , може увійти в критичну секцію одночасно з іншим процесом, що призведе до непередбачуваних результатів. Природно, не можна говорити, що така помилка виявиться при тестуванні; вона навіть може ніколи не відбутися за весь час існування системи. Легше знайти протилежну помилку - відсутня операція signal може в певний момент призвести до зупинки, принаймні, одного з процесів, що достатньо просто виявити. Компілятор не має можливості перевірити, чи правильно використовуються семафори, тобто, чи узгоджені операції wait з операціями signal в інших модулях і пов'язані Чи семафори з відповідними ресурсами, оскільки це залежить від логіки алгоритму. Більш того, розміщення семафорів в програмі, як і інших команд, довільно. Турбота про перевірку правильності програми лежить на програмістові. Використання структурного програмування істотно полегшує вирішення цього завдання.
Семафори є зручним засобом високого рівня для заміщення операції test_and_set і допомагають уникнути циклів зайнятого очікування. Проте їх неправильне використання може призвести до ситуації гонок і до тупикам. 4. Події У деяких випадках кілька процесів, що мають доступ до загальних даних, повинні працювати з ними тільки при виконанні деяких умов, необов'язково пов'язаних з даними і різних для кожного процесу. Умовою, наприклад, може бути надходження нових даних на вхідний порт. Всі процеси мають наступну структуру
begin wait until condition; modify data; end Програма ділиться на дві основні частини. Спочатку перевіряються умови, а потім виробляються операції над даними. Процедура перевірки умови не змінює даних і тому не вимагає будь-якої спеціальної захисту доступу.
Однак доступ до даних для модифікації повинен бути координований між процесами. Якщо використовувати семафори, то їх потрібно два: один - для контролю доступу в захищену область з даними, а інший - для індикації зміни загальних даних і, відповідно, необхідності повторної перевірки умов. Застосування першого семафора просто, а для другого необхідно стежити за числом чекаючих процесів і забезпечити, що при зміні умови очікують процеси будуть активізовані з метою його перевірки, тобто генерацію сигналів семафора, число яких дорівнює числу очі...