Властивості ресурсів і їх уявлення

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

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

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

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

Ми називатимемо класом ресурсу пул ідентичних неіменованих одиниць ресурсу. Неіменованими ми рахуємо їх в тому сенсі, що процес при запиті ресурсу не указує, яку саме одиницю з пулу він хоче отримати, всі одиниці ресурсу однакові. Всі ресурси одного класу управляються одним менеджером.

З визначень ОС (як з погляду розробника, так і з погляду користувача), яких ми дали в першому розділі, однозначно витікає, що процес у жодному випадку не може самостійно оволодіти ресурсом - а тільки через посредство ОС. Для надання процесам такої можливості у складі API ОС повинні бути системні виклики типу:

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

Другий виклик відчеплює від процесу раніше виділений йому ресурс. Можливо, форма виділення/звільнення ресурсу нагадала вам знайомі операції відкриття / закриття файлу - і недаремно. Оскільки файли також є ресурсами, операції open/close є окремими випадками операцій getResource/releaseResource. Як правило, в реальних API ОС немає загальних операцій виділення/звільнення ресурсів, але для кожного ресурсу є своя пара операцій, що відрізняється від інших назвою і, можливо, складом параметрів.

Третій, необов'язковий параметр операції getResource задає дії ОС за ситуації, коли виділити ресурс неможливо (не все ОС надають процесам можливості такого вибору). По-перше (і ця дія зазвичай виконується за умовчанням), ОС може заблокувати процес, що видав запит, до звільнення необхідного ресурсу. По-друге, ОС може не блокувати процес, а повернути йому відмову - відразу або після деякої тимчасової витримки (timeout), в цьому випадку "розумний" процес може поки зайнятися іншою роботою, яку він може виконати і без цього ресурсу, а пізніше повторити запит. Як ОС повинна реагувати на запит, який взагалі не може бути виконаний (необхідного об'єму ресурсів просто немає в системі)? На наше переконання, такий запит повинен приводити до аварійного завершення процесу, що видав його. Але якщо ОС допускає динамічну реконфигурацию ресурсів, то запит може бути поставлений в чергу в очікуванні моменту, коли ресурс буде введений в систему. Такі запити, що не реалізовуються, можуть складати серйозну неприємність в роботі ОС, оскільки ресурс може ніколи і не бути введений. Для уникнення таких запитів доцільно мати у складі API виклик, що повертає загальне число ресурсів даного класу. Нарешті, при неможливості задовольнити запит ОС може зажадати від процесу звільнити вже наявні в його розпорядженні ресурси. Якщо така можливість є, то вона може бути дуже корисна для розв'язки тупиків (див. нижчий).

Для кожного класу ресурсів ОС повинна підтримувати дескриптор класу, в який повинні входити:

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

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

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

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