Page 113 - 4868

111 Ошибка! Стиль не определен.

доступу до бази даних. Сама база даних є глобальною по відношенню до
читачів і письменників. Вона може зберігатися, наприклад, в розподіленій
пам’яті або в зовнішньому файлі.
У задачі про читачів та письменників монітор надає доступ до бази
даних для процесів-читачів та процесів-письменників. Для цього необхідно,
щоб процеси інформували монітор про своє бажання отримати доступ і про
завершення роботи з базою даних. Існує два типи процесів і по два види дій
на процес, тому в результаті отримуємо чотири процедури монітора:
request_read, release_read, request_write, release_write. Процес-
читач перед зчитуванням бази даних повинен викликати процедуру

request_read, а після зчитування процедуру release_read. Те ж чаме
стосується процесу-пильменника.
Для синхронізації доступу до бази даних необхідно вести облік числа
записуючих і зчитуючих процесів. Як і раніше, нехай значення змінної nr –
це число читачів, a nw – письменників. Вони являють собою постійні змінні
монітора і при правильній синхронізації повинні задовольняти наступному
інваріанту монітора:
RW: (nr == 0 nw == 0)  nw <= 1

У початковому стані змінні nrта nwрівні 0. Їхні значення збільшуються
при виклику процедур запиту і зменшуються при виклику процедур
вивільнення.
У лістингу 1.27 представлений монітор, що відповідає описаній вище
специфікації. Для реалізації інваріанта RW використовуються цикли while
та оператори wait. На початку виконання процедури request_read процес-
читач повинен призупинитися, поки значення nw не стане рівним нулю. Дана

затримка відбувається на умовній змінній oktoread. Аналогічно, процес-
письменник на початку виконання процедури request_writeповинен
призупинитися на умовній змінній oktowriteдо обнулення змінних nr та
nw. У процедурі release_read для процеса-письменника генерується
сигнал, коли значення змінної nr дорівнює нулю. Оскільки письменники
виконують перепровірку умови своєї затримки, то дане рішення є
правильним, навіть у випадку якщо процеси-письменники завжди отримують
сигнал. Однак дане рішення буде менш ефективним, оскільки отримавши
сигнал процес-письменник при нульовому значенні змінної nr повинен знову
призупинити своє виконання. З іншого боку, в кінці процедури
release_write точно відомо, що значення обох змінних nr та nw
дорівнюють нулю. Отже, може продовжити роботу будь-який призупинений
процес. Рішення з лістингу 1.27 не встановлює порядок чергування процесів-
читачів і процесів-письменників. Замість цього дана програма запускає всі
призупинені процеси і дозволяє стратегії планування процесів визначити,
який з них першим отримає доступ до бази даних. Якщо це процес-
письменник, то будуть призупинені всі процеси-читачі. Якщо ж першим
отримає доступ процес-читач, то призупиниться запущений процес-
письменник.