Стани процесів

В багатозадачній системі процес може знаходитися в одному з трьох основних станів: ВИКОНАННЯ - активний стан процесу, під час якого процес володіє всіма необхідними ресурсами і безпосередньо виконується МП; ОЧІКУВАННЯ - пасивний стан процесу, процес заблокований, він не може виконуватися по своїх внутрішніх причинах, він чекає виконання деякої події, наприклад, завершення операції вводу/виводу, одержання повідомлення від іншого процесу, звільнення якого-небудь необхідного йому ресурсу; ГОТОВНІСТЬ - також пасивний стан процесу, але в цьому випадку процес заблокований у зв'язку з зовнішніми стосовно нього обставинами: процес має всі необхідні для нього ресурси, він готовий виконуватися, однак МП зайнятий виконанням іншого процесу.

У ході життєвого циклу кожен процес переходить з одного стану в інший відповідно до алгоритму планування процесів, реалізованим у даній ОС. Типовий граф станів процесу показаний на рис. 4.2.

Прийнятий

Переривання

Помилка

Завершення вводу/виводу Очікування вводу/виводу Вихід

Рис 4.2 Граф станів процесу в багатозадачному середовищі

У стані ВИКОНАННЯ в однопроцесорній системі може знаходитися тільки один процес, а в кожному зі станів ОЧІКУВАННЯ і ГОТОВНІСТЬ - кілька процесів, ці процеси утворять черги відповідно очікуючих і готових процесів. Життєвий цикл процесу починається зі стану ГОТОВНІСТЬ, коли процес готовий до виконання і чекає своєї черги. При активізації процес переходить у стан ВИКОНАННЯ і знаходиться в ньому доти, доки або він сам звільнить МП, перейшовши в стан ОЧІКУВАННЯ якої-небудь події, або буде насильно "витиснутий" із процесора, наприклад, унаслідок вичерпання відведеного даному процесу кванта процесорного часу. В останньому випадку процес повертається в стан ГОТОВНІСТЬ. У цей же стан процес переходить зі стану ОЧІКУВАННЯ, після того, як очікуване подія відбудеться.

Отже, для однієї програми можуть бути створені декілька процесів в тому випадку, якщо за допомогою однієї програми в ЦП виконується декілька не співпадаючих послідовностей команд. За час існування процес багато разів змінює свій стан. Розрізняють наступні стани процесу: новий (процес тільки що створений); виконуваний (команди програми виконуються в МП); очікуваний (процес чекає завершення деякого випадку, найчастіші операції вводу/виводу); готовий (процес чекає звільнення МП); завершений (процес завершив свою роботу). Перехід з одного стану в інше не може виконуватися довільно.

Кожен процес представляється в ОС набором даних, так званою таблицею керування. У РСВ процес описується набором значень, параметрів, які характеризують його поточний стан і використовуваних ОС для керування проходження процесу через комп'ютер.

4.1.5 Розподілення ресурсів між процесами Виклик віддалених процедур

Виклик віддалених процедур (Remote procedure call, RPC) - протокол, якийо дозволяє програмі, запущеній на одному комп'ютері бути викликаною з іншого комп'ютераі без написання безпосередньо коду для цієї операції.

Ідея виклику віддалених процедур (Remote Procedure Call - RPC) полягає у розширенні добре відомого і зрозумілого механізму передачі керування і даних усередині програми, що виконується на одному комп'ютеру, на передачу керування і даних через КМ. Засоби віддаленого виклику процедур призначені для полегшення організації розподілених обчислень. Найбільша ефективність використання RPC досягається в тих програмах, в яких існує інтерактивний зв'язок між віддаленими компонентами з невеликим часом відповідей і відносно малою кількістю переданих даних. Такі програми називаються RPC-орієнтованими.

Існують багато технологій, що забезпечують RPC, такі як: Sun RPC (бінарний протокол на базі TCP та UDP); Net Remoting (бінарний протокол на базі TCP, UDP, HTTP); XML-RPC (текстовий протокол на базі HTTP); SOAP — Simple Object Access Protocol (текстовий протокол на базі HTTP); Java RMI — Java Remote Method Invocation; JSON-RPC JavaScript Object Remote Procedure Calls (текстовий, на базі HTTP).

Характерними рисами виклику локальних процедур є: асиметричність, де одна з взаємодіючих сторін є ініціатором; синхронність, де виконання викликаючої процедури призупиняється з моменту видачі запиту і відновлюється тільки після повернення з визваної процедури.

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

Але в реалізації RPC беруть участь як мінімум два процеси — по одному в кожному комп'ютері. Якщо один з них аварійно завершиться, то виникають такі ситуації: при помильці викликаної віддалено процедури стануть «осиротілими», а при помилковому завершенні віддалених процедур стануть «непотрібними» викликаючі процедури, які будуть безрезультатно чекати відповіді від віддалених процедур.

Також, існує ряд проблем, пов'язаних з неоднорідністю мов програмування і ОС: структури даних і структури виклику процедур, підтримувані в будь-якому однією мовою програмування, не підтримуються точно так само у всіх інших мовах.

Ці та інші проблеми вирішує технологія RPC, що лежить в основі багатьох розподілених ОС, наприклад Plan 9.

Розглянемо базові операції RPC.

Спочатку розглянемо виконання виклику локальної процедури у автономному комп'ютері. Нехай це, наприклад, буде системний виклик: count = read (fd, buf, nbytes); де fd - ціле число, buf - масив символів, nbytes - ціле число.

Щоб здійснити виклик, викликаюча процедура (П1) записує параметри в стек у зворотному порядку. Після того, як виклик read виконаний, він поміщає значення, які повертаються в регістр, переміщує адресу повернення і повертає керування викликаючій процедурі, яка вибирає параметри з стека, повертаючи його в початковий стан. Відомо, що в мові С параметри можуть викликатися по посиланню (by name) або за значенням (by value). По відношенню до викликаючої процедури параметри-значення є ініціалізованими локальними змінними. Викликана процедура може змінити їх, і це не вплине на значення оригіналів цих змінних в викликаючій процедурі. Якщо в визвану процедуру передається покажчик на змінну, то зміна значення цієї змінної визваної процедури тягне зміну значення цієї змінної і для викликаючої процедури. Цей факт дуже істотний для RPC.

Існує також інший механізм передачі параметрів, який не використовується в мові С. Він називається call-by-copy/restore і полягає в необхідності копіювання викликаючою програмою змінних в стек у вигляді значень, а потім копіювання назад після виконання виклику поверх оригінальних значень викликаючої процедури.

Рішення про те, який механізм передачі параметрів використовувати, приймається розробниками мови. Іноді це залежить від типу переданих даних. У мові С, наприклад, цілі та інші скалярні дані завжди передаються за значенням, а масиви - по посиланню.

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

RPC досягає прозорості наступним шляхом. Коли викликана процедура дійсно є віддалена, в бібліотеку поміщається замість локальної процедури інша версія процедури, яка називається клієнтським стабом (stub - заглушка). Подібно оригінальної процедурі, стаб викликається з використанням викликаючої послідовності, так само відбувається переривання при зверненні до ядра. Тільки на відміну від оригінальної процедури він не поміщає параметри в регістри і не запитує у ядра дані, замість цього він формує повідомлення для відправки ядру віддаленому комп'ютеру.

4.3.2 Етапи виконання RPC

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

Потім параметри повинні бути перетворені у відповідний формат і вставлені в буфер повідомлення. До цього моменту повідомлення готове до передачі, тому виконується переривання за викликом ядра.

Коли ядро отримує керування, воно перемикає контексти, зберігає регістри МП і карту пам'яті (дескриптори сторінок), встановлює нову карту пам'яті, яка буде використовуватися для роботи в режимі ядра. Оскільки контексти ядра і користувача розрізняються, ядро має точно скопіювати повідомлення в свій власний адресний простір, так, щоб мати до нього доступ, запам'ятати адресу призначення (а, можливо, і інші поля заголовка), а також воно має передати його мережевому інтерфейсу. На цьому завершується робота на клієнтській стороні. Включається таймер передачі, і ядро може або виконувати циклічне опитування наявності відповіді, або передати керування планувальником, який обере будь-який інший процес на виконання. У першому випадку прискорюється виконання запиту, але відсутнє мультипрограмування.

На стороні сервера біти, що надходять, поміщаються приймаючої апаратурою або у вбудований буфер, або в ОП. Коли вся інформація буде отримана, генерується переривання. Обробник переривання перевіряє правильність даних пакету і визначає, якому стабу слід їх передати. Якщо жоден із стабів не очікує цей пакет, обробник повинен помістити його в буфер або взагалі відмовитися від нього. Якщо є очікуючий стаб, то повідомлення копіюється йому. Нарешті, виконується переключення контекстів, в результаті чого відновлюються регістри і карта пам'яті, приймаючи ті значення, які вони мали в момент, коли стаб зробив виклик receive.

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

Існує 14 таких етапів виконання RPC:

Клієнт 1. Виклик стабу 2. Підготувати буфер 3. Упакувати параметри 4. Заповнити поле заголовка 5. Обчислити контрольну суму в повідомленні 6. Переривання до ядра 7. Черга пакету на виконання 8. Передача повідомлення контролеру по шині QBUS 9. Час передачі по КМ Ethernet. Сервер 10. Отримати пакет від контролера 11. Процедура обробки переривання 12. Обчислення контрольної суми 13. Переключення контексту в простір користувача 14. Виконання серверного стабу