Взаємодія процесів

Механізми паралельних обчислень в UNIX

Відновлення після тупиків

Виявивши глухий кут, можна вивести з нього систему, порушивши одну з умов існування тупика. При цьому, можливо, декілька процесів частково або повністю втратять результати виконаної роботи. Складність відновлення обумовлена низкою факторів.

У більшості систем немає достатньо ефективних засобів, щоб призупинити процес, вивести його з системи і відновити згодом з того місця, де він був зупинений. Якщо навіть такі кошти є, то їх використання вимагає витрат і уваги оператора.

Відновлення після тупика може вимагати значних зусиль. Найпростіший і найбільш поширений спосіб усунути глухий кут - завершити виконання одного або більше процесів, щоб згодом використовувати його ресурси. Тоді у випадку удачі інші процеси зможуть виконуватися. Якщо це не допомагає, можна ліквідувати ще кілька процесів. Після кожної ліквідації повинен запускатися алгоритм виявлення тупика.

По можливості краще ліквідувати той процес, який може бути без збитку повернуто до початку. Прикладом такого процесу може служити компіляція. З іншого боку, процес, який змінює вміст бази даних, не завжди може бути коректно запущений повторно.

У деяких випадках можна тимчасово забрати ресурс у поточного власника і передати його іншому процесу. Можливість забрати ресурс у процесу, дати його іншому процесу і потім без шкоди повернути назад сильно залежить від природи ресурсу. Подібне відновлення часто важко, якщо не неможливо.

У ряді систем реалізовані засоби відкату і перезапуску або рестарту з контрольної точки (збереження стану системи в якийсь момент часу). Якщо проектувальники системи знають, що тупик ймовірний, вони можуть періодично організовувати для процесів контрольні точки. Іноді це доводиться робити розробникам прикладних програм.

Коли тупик виявлений, видно, які ресурси залучені до цикл кругового очікування. Щоб здійснити відновлення, процес, який володіє таким ресурсом, повинен бути відкинутий до моменту часу, що передувало його запитом на цей ресурс.

Кожен процес в ОС UNIX виконується у власній віртуальної пам'яті, тобто якщо не вживати додаткових зусиль, то навіть процеси-близнюки, утворені в результаті виконання системного виклику fork (), насправді повністю ізольовані один від одного (якщо не рахувати того, що процес-нащадок успадковує від процесу-предка всі відкриті файли). Тим самим, в ранніх варіантах ОС UNIX підтримувалися дуже слабкі можливості взаємодії процесів, навіть входять у загальну ієрархію породження (тобто мають спільного предка).

Дуже слабкі засоби підтримувалися і для взаємної синхронізації процесів. Практично, все обмежувалося можливістю реакції на сигнали, і найбільш поширеним видом синхронізації була реакція процесу-предка на сигнал про завершення процесу-нащадка.

Мабуть, застосування такого підходу було реакцією на надмірно складні механізми взаємодії і синхронізації паралельних процесів, що існували в історично попередньої UNIX ОС Multics. В ОС Multics підтримувалася сегментно-сторінкова організація віртуальної пам'яті, і в загальній віртуальної пам'яті могло виконуватися кілька паралельних процесів, які, природно, могли взаємодіяти через загальну пам'ять. За рахунок можливості включення одного й того ж сегменту в різну віртуальну пам'ять аналогічна можливість взаємодій існувала і для процесів, які виконуються не в загальній віртуальної пам'яті.

Для синхронізації таких взаємодій процесів підтримувався загальний механізм семафорів, що дозволяє, зокрема, організовувати взаємне виключення процесів у критичних ділянках їх виконання (наприклад, при взаємно-виключає доступ до поділюваного пам'яті). Цей стиль паралельного програмування в принципі забезпечує більшу гнучкість та ефективність, але є дуже важким для використання. Часто в програмах з'являються важко виявляються і рідко відтворювані синхронізаційних помилки; використання явною синхронізації, не пов'язаної нерозривно з тими об'єктами, доступ до яких синхрон, робить логіку програм важко збагненною, а текст програми - важко читається.

Зрозуміло, що стиль ранніх варіантів ОС UNIX стимулював істотно більш просте програмування. У найбільш простих випадках процес-нащадок утворювався тільки для того, щоб асинхронно з основним процесом виконати будь-яке просте дію (наприклад, запис у файл). У складніших випадках процеси, пов'язані ієрархією спорідненості, створювали обробні "конвеєри" з використанням техніки програмних каналів (pipes).

Довгий час батьки-засновники ОС UNIX вважали, що в тій області, для якої призначався UNIX (розробка програмного забезпечення, підготовка та супровід технічної документації тощо) цих можливостей цілком достатньо. Однак поступове поширення системи в інших областях і порівняльна простота нарощування її можливостей привели до того, що з часом в різних варіантах ОС UNIX з'явився явно надлишковий набір системних засобів, призначених для забезпечення можливості взаємодії та синхронізації процесів, які не обов'язково пов'язані ставленням спорідненості. Світ ОС UNIX ці кошти зазвичай називають IPC від Inter-Process Communication Facilities. З появою UNIX System V Release 4.0 (і більш старшої версії 4.2) всі ці кошти були узаконені і увійшли до фактичний стандарт ОС UNIX сучасного зразка.

Починаємо з пакету засобів IPC, які з'явилися в UNIX System V Release 3.0. Цей пакет включає:

• засоби, що забезпечують можливість наявності загальної для процесів пам'яті (сегменти розділяється пам'яті - shared memory segments);

• засоби, що забезпечують можливість синхронізації процесів при доступі до спільно використовуваних ресурсів, наприклад, до поділюваного пам'яті (семафори - semaphores);

• засоби, що забезпечують можливість посилки процесом повідомлень іншому безпідставного процесу (черги повідомлень - message queues).

Ці механізми об'єднуються в єдиний пакет, тому що відповідні системні виклики володіють близькими інтерфейсами, а в їх реалізації використовуються багато спільні підпрограми. Ось основні загальні властивості всіх трьох механізмів:

1. Для кожного механізму підтримується загальносистемна таблиця, елементи якої описують всіх існуючих в даний момент представників механізму (конкретні сегменти, семафори або черги повідомлень).

2. Елемент таблиці містить деякий числовий ключ, який є вибраним користувачем ім'ям представника відповідного механізму. Іншими словами, щоб два чи більше процесу могли використовувати деякий механізм, вони повинні заздалегідь домовитися про іменуванні використовуваного представника цього механізму і добитися того, щоб той же представник не використовувався іншими процесами.

3. Процес, який бажає почати користуватися одним з механізмів, звертається до системи з системним викликом із сімейства "get", прямими параметрами якого є ключ об'єкту і додаткові прапори, а відповідним параметром є числовий дескриптор, який використовується в подальших системних викликах подібно до того, як використовується дескриптор файлу при роботі з файловою системою.

Перейдемо до більш детального вивчення конкретних механізмів цього сімейства.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Виявлення тупиків	\|	Семафори

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.015 сек.