
- •Процеси та потоки Процеси
- •Модель процесу
- •Створення процесу
- •Завершення процесу
- •Ієрархія процесів
- •Стани процесу
- •Реалізація процесу
- •Класична модель потоків
- •Реалізація потоків в просторі користувача
- •Реалізація потоків в просторі ядра
- •Активація планувальника
- •Спливаючі потоки
- •Взаємодія процесів
- •Змагання між процесами
- •Критична секція
- •Блокуючі змінні
- •Строге чергування
- •Алгоритм Петерсона
- •Команда tsl
- •Завдання виробника і споживача. Sleep і wakeup.
- •Семафори
- •М’ютекси
- •Монітори
- •Завдання алгоритму планування
Завдання виробника і споживача. Sleep і wakeup.
Як приклад використання двома процесами спільної пам’яті розглянемо задачу виробника і споживача. Проілюструємо її кодом
Системний виклик sleep блокує процес, що здійснив його виклик і він припиняється до тих пір, поки його НЕ активізує інший процес. Активізуючий виклик wakeup використовує один аргумент – процес, що необхідно активізувати. Завдяки блокуванню, яке здійснюється системними викликами sleep і wakeup, процес уникає активного очікування і пов’язаних з ним проблем. Проте все ще може виникнути змагання між процесами.
Припустимо буфер порожній, і споживач тільки що зчитав count, і побачив, що його значення дорівнює 0. У цей самий момент планувальник вирішує тимчасово призупинити виконання процесу споживача і відновити виконання процесу виробника. Виробник поміщає запис в буфер, збільшує значення лічильника count, і зауважує, що тепер воно дорівнює 1. Взявши до уваги, що тільки що лічильник мав нульове значення, при якому споживач повинен знаходитися в заблокованому стані, виробник викликає процедуру makeup, щоб активізувати виконання процесу споживача. Нажаль, з точки зору логіки програма споживач не була в недіючому стані, тому сигнал на активізацію буде втрачений. Коли підійде черга відновити виконання процесу споживача, він перевірить раніше зчитане значення лічильника, визначить, що воно було дорівнює 0, і знову перейде в заблокований стан. Рано чи пізно виробник заповнить буфер і теж перейде в заблокований стан. І обидва процеси впадуть у вічну сплячку.
Швидко усунути проблему дозволить зміна правил за рахунок додавання до картини подій біта очікування активізації. Цей біт встановлюється, коли стосовно процесу, який не перебуває у стані бездіяльності, викликається процедура makeup. Потім, коли процес спробує заблокуватися при встановленому біті очікування активізації, цей біт знімається, але процес не блокується. Біт очікування активізації стає своєрідною скарбничкою, що зберігає сигнали активізації.
Семафори
Ще одним механізмом здійснення синхронізації процесів є використання семафорів. Використання семафорів виключає активне очікування. Використовуючи блокування семафори вирішують завдання виробника-споживача. Семафор – це целочисельна змінна для підрахунку кількості активізацій, відкладених на майбутнє.
Значення семафора може дорівнювати 0, що буде свідчити про відсутність збережених активізацій або мати яке-небудь позитивне значення, якщо очікується не менше однієї активізації.
Було запропоновано використовувати дві операції, domn і up. Операція down з'ясовує, чи відрізняється значення семафора від 0. Якщо відрізняється, вона зменшує це значення на 1 (тобто використовує одну збережену активізацію) і продовжує свою роботу. Якщо значення дорівнює 0, процес призупиняється, не завершуючи цього разу операцію down. І перевірка значення, і його зміна, і, можливо, припинення процесу здійснюються як єдине і неподільне атомарному дію.
Операція up збільшує значення, що адресується семафором, на 1. Якщо з цим семафором пов'язані один або більше призупинених процесів, здатних завершити раніше розпочаті операції down, система вибирає один з них і дозволяє йому завершити його операцію down. Таким чином, після застосування операції up щодо семафора, з яким були пов'язані призупинені процеси, значення семафора так і залишиться нульовим, але кількість припинених процесів зменшиться на 1.