ожуть викликати процедури монітора, але не мають доступу до внутрішніх даних монітора. Монітори мають важливу властивість, яка робить їх корисними для досягнення взаємного виключення: тільки один процес може бути активним по відношенню до монітора. Компілятор обробляє виклики процедур монітора особливим чином. Зазвичай, коли процес викликає процедуру монітора, то перші кілька інструкцій цієї процедури перевіряють, не активний чи який-небудь інший процес по відношенню до цього монітора. Якщо так, то викликає процес призупиняється, поки інший процес не звільнить монітор. Таким чином, виключення входу декількох процесів в монітор реалізується ні програмістом, а компілятором, що робить помилки менш імовірними.
У розподілених системах, що складаються з декількох процесорів, кожен з яких має власну оперативну пам'ять, семафори і монітори виявляються непридатними. У таких системах синхронізація може бути реалізована тільки за допомогою обміну повідомленнями. br/>
3.5 Запобігання тупикових ситуацій
Для запобігання глухого кута необхідно використовувати ресурси таким способом, при якому ми не можемо увійти в глухий кут. У реальному житті аналог такого рішення це "ліві повороти занадто небезпечні, тому що ми робимо тільки праві повороти ". Це вимагає більше часу, щоб дістатися до місця призначення, але такий метод працює. У термінах тупиків, ми можемо утримувати використання ресурсів так, щоб не хвилюватися про можливість виникнення тупиків. Тут ми розглянемо цю ідею на кількох прикладах. br/>
3.5.1 Лінійне упорядкування ресурсів
Нехай всі ресурси повністю впорядковані від 1 до r. Ми можемо накласти наступне обмеження: процес не може запитувати ресурс R k , якщо він утримує ресурс R h і при цьому k
Просто бачити, що, використовуючи це правило, ми ніколи не будемо входити в тупики. (Для доказу застосуємо метод докази від протилежного).
Наведемо приклад того, як застосовується це правило. Нехай є процес, який використовує ресурси, впорядковані як A, B, C, D, E, наступним способом:
В
br/>
Тоді процес може робити наступне:
захопити (A); захопити (B); захопити (C);
використовувати C;
використовувати A, C;
використовувати A, B, C;
звільнити (A); звільнити (B); захопити (E);
використовувати C і E;
звільнити (C); звільнити (E); захопити (D);
використовувати D;
звільнити (D);
Стратегія цього типу може використовуватися, коли ми маємо кілька ресурсів. Цю стратегію просто застосовувати, при цьому ступінь паралелізму зменшується не занадто сильно.
3.5.2 Ієрархічне впорядкування ресурсів
Інша стратегія, яку ми можемо використовувати в разі, якщо ресурси ієрархічно структуровані, повинна блокувати їх в ієрархічному порядку. Нехай утримування ресурсів представлено організованим в дерево. Ми можемо блокувати будь-який вузол або групу вузлів у дереві. Ресурси, в яких ми зацікавлені - вузли в дереві, зазвичай самого нижнього рівня в деревовидному поданні ієрархії. Тоді наступне правило гарантує запобігання тупиків: вузли, в даний час блоковані процесом, повинні знайтися на всіх шляхах від кореня до бажаних ресурсів. Приклад використання цього правила, з блокуванням одиночного ресурсу одночасно:
В
p> Тоді якщо процес хоче використовувати ресурси e, f, i, k він повинен використовувати команди в наступній послідовності: br/>
блокування (A);
блокування (B);
блокування (H);
звільнення (A);
блокування (D);
звільнення (B);
блокування (I);
блокування (J);
звільнення (H);
блокування (K);
звільнення (J);
блокування (E);
блокування (F);
звільнення (D);
В
3.5.3 Алгоритм банкіра
Одна з причин, по якій цей алгоритм не використовується в реальному світі широко - щоб використовувати його, операційна система повинна знати максимальну кількість ресурсів, в яких кожен процес буде мати потребу будь-коли. Отже, наприклад, запущена на виконання програма повинна оголосити, що вона потребуватиме не більше ніж, скажімо, 400КБ пам'яті. Операційна система збереже обмеження 400КБ і буде використовувати його в обчисленнях з метою запобігання глухого кута. p> Алгоритм Банкіра намагається запобігати глухий кут, шляхом надання або відмови надання ресурсів системи. Щоразу, коли процес потребує якому або неподілювані ресурсі, цей запит має бути схвалений банкіром.
Банкір - консервативний. Щоразу, коли процес робить запит ресурсу ("просить позику"), банкір обережно розглядає "Банківські книги" і намагається визначати, може чи ні стан безвиході виникнути в майбутньому, якщо запит позички буде схвалений. p> Алгоритм симулює надання запитаного ресурсу і потім переглядає виникає в ре...
