Семантика rpc при відмовах

В ідеалі RPC повинен функціонувати правильно і у випадку відмов. Розглянемо наступні класи відмов: 1. Клієнт не може визначити місцезнаходження сервера, наприклад, у разі відмови потрібного сервера, або через те, що програма клієнта була скомпільована давно і використовувала стару версію інтерфейсу сервера. У цьому випадку у відповідь на запит клієнта надходить повідомлення, з кодом помилки. 2. Втрачено запит від клієнта до сервера. Найпростіше рішення - через певний час повторити запит. 3. Втрачено повідомлення-відповідь від сервера до клієнта. Цей варіант складніший від попереднього, так як деякі процедури не є ідемпотентними. Ідемпотентною називається процедура, запит на виконання якої можна повторити кілька разів, і результат при цьому не зміниться. Прикладом такої процедури може бути читання файлу. Але ось процедура зняття деякої суми з банківського рахунку не є ідемпотентною, і в разі втрати відповіді повторний запит може істотно змінити стан рахунку клієнта. Одним з можливих рішень є приведення всіх процедур до ідемпотентного виду. Однак на практиці це не завжди вдається, тому може бути використаний інший метод - послідовна нумерація всіх запитів клієнтським ядром. Ядро сервера запам'ятовує номер самого останнього запиту від кожного з клієнтів, і при отриманні кожного запиту виконує аналіз: є цей запит первинним чи повторним. 4. Сервер зазнав аварію після отримання запиту. Тут також важливо властивість Ідемпотентний, але не може бути застосований підхід з нумерацією запитів. У даному випадку має значення, коли відбулася відмова - до чи після виконання операції. Але клієнтське ядро не може розпізнати ці ситуації, для нього відомо тільки те, що час відповіді вичерпано.

Існує три підходи до вирішення цієї проблеми: 1) Чекати до тих пір, поки сервер не перезавантажиться і намагатися виконати операцію знову. Цей підхід гарантує, що RPC був виконаний до кінця принаймні один раз, а можливо і більше. 2) Відразу повідомити додатка про помилку, що гарантує, що RPC був виконаний не більше одного разу. 3) Третій підхід не гарантує нічого. Коли сервер відмовляє, клієнтові не надається ніякої підтримки. RPC може бути або не виконано взагалі, чи виконано багато разів.

Примітиви керування процесами

В деяких ОС передбачається невелика кількість примітивів керування процесами. Більшість з них виконується шляхом посилки повідомлення ядру через порт процесу. (див. табл. 4.1).

Таблия 4.1 Виклики примітивів керування процесами

Виклик	Опис
Create	Створює новий процес, що успадковує деякої властивості
Termіnate	Завершує визначений процес
Suspend	Нарощує лічильник припинень
Resume	Зменшує лічильник припинень; якщо він = 0, то розблокує процес
Prіorіty	Встановлює пріоритет для існуючих / майбутніх ниток
Assіgn	Говорить, на якому МП повинні виконуватися нові нитки
Іnfo	Повертає інформацію про час виконання, використовуваної пам'яті і т.д.
Threads	Повертає список ниток процесу

Процеси можуть бути припинені і відновлені за допомогою програмного керування. Кожен процес має лічильник, нарощуваний викликом Suspend і зменшуваний викликом Resume, що можуть блокувати і розблокувати його. Коли лічильник дорівнює 0, то процес може виконуватися. Наявність лічильника дозволяє уникнути проблем.

Виклики Prіorіty і Assіgn дозволяють програмісту керувати тим, як і де нитки виконуються в багатопроцесорній системі. Планування CPU виконується на основі пріоритетів, так що програміст може визначати, які нитки більш важливі, а які - менш важливі.