spz / spz

Принципи побудови інтерфейсів операційних систем

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

1.Керування процесами, що містить у собі наступний набір основних функцій:

а) запуск, приостанов і зняття задачі з виконання; б) задання або зміну пріоритету задачі;

в) взаємодію задач між собою (механізми сигналів, семафорні примітиви, черги, конвеєри, поштові скриньки); г) віддалений виклик підпрограм.

2. Керування пам'яттю:

а) запит на виділення блоку пам'яті; б) звільнення пам'яті;

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

3. Керування введенням/виведенням:

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

створення, зміну і видалення даних, організованих у файли).

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

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

основного інтерфейсу системи. Звичайно ці модулі називають інтерпретатором команд. Так, наприклад, функції такого інтерпретатора в МS-DOS виконує модуль СОММАМ.СОМ. Одержавши від користувача команду, такий модуль після лексичного і синтаксичного аналізу або сам виконує дію, або звертається до інших модулів ОС, використовуючи механізм АРІ (application program interfase, інтерфейс прикладного програмування).

В останні роки велику популярність одержали графічні інтерфейси (GUI), у яких задіяні відповідні маніпулятори типу «миша» чи «трекбол».

Така інтерфейсная підсистема транслює «команди» користувача в звертання до ОС.

Є два основних підходи до керування задачами.

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

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

Так, наприклад, в операційній системі МS-DOS, що розроблялася для однозадачного режиму (оскільки процесор i8086 не підтримував мультипрограмування), використовувався механізм програмних переривань. При цьому основний набір функцій АРІ був доступний через точку входу оброблювача int 21h.

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

Інтерфейс прикладного програмування

Необхідно однозначно розділити загальний термін АРІ (application program interfase, інтерфейс прикладного програмування) на наступні напрямки:

•АРІ як інтерфейс високого рівня, що належить до бібліотек RTL (run time library) — бібліотека часу виконання; вона містить у собі ті стандартні підпрограми, що система програмування підставляє на етапі компіляції)

•АРI прикладних і системних програм, що входять у постачання операційної системи;

•інші API.

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

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

Далі мова йтиме про функції API з погляду розроблювача прикладної програми.

Існує кілька варіантів реалізації API:

•реалізація на рівні ОС;

•реалізація на рівні системи програмування;

•реалізація на рівні зовнішньої бібліотеки процедур і функцій.

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

Можливості API можна оцінювати з наступних позицій:

•ефективність виконання функцій API — містить у собі швидкість виконання функцій і обсяг обчислювальних ресурсів, необхідних для їхнього виконання;

•широта наданих можливостей;

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

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

Реалізація функцій API на рівні ОС

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

У такому варіанті результуюча програма звертається безпосередньо до

ОС.

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

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

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

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

Переміщення можна було б домогтися, якщо уніфікувати функції API у різних ОС.

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

Реалізація функцій API на рівні системи програмування

Якщо функції API реалізуються на рівні системи програмування, вони даються користувачу у виді бібліотеки функцій відповідного мови програмування. Звичайно мова йде про бібліотеку часу виконання —RTL (run time library). Система програмування надає користувачу бібліотеку відповідної мови програмування і забезпечує підключення до результуючої програми об'єктного коду, відповідального за виконання цих функцій.

Очевидно, що ефективність функцій API у такому варіанті буде трохи нижче, ніж при безпосередньому звертанні до функцій ОС. Так відбувається, оскільки для виконання багатьох функцій API бібліотека RTL (run time library) мови програмування повинна все рівно виконувати звертання до функцій ОС. Наявність усіх необхідних викликів і звертань до функцій ОС в об'єктному коді RTL (run time library) , забезпечує система програмування.

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

Тому для виконання прикладної програми на новій архітектурі обчислювальної системи досить заново побудувати код результуючої програми за допомогою відповідної системи програмування.

Однакове виконання функцій мови забезпечується системою програмування. При орієнтації на різні архітектури цільової обчислювальної системи в системі програмування можуть знадобитися різні комбінації викликів функцій ОС для виконання тих самих функцій вихідної мови. Це повинно бути враховане в коді RTL (run time library). У загальному випадку для кожної архітектури цільової обчислювальної системи буде вимагатися свій код RTL (run time library) мови програмування. Вибір того чи іншого об'єктного коду RTL (run time library) для підключення до результуючої програми система програмування забезпечує автоматично.

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

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

Реалізація функцій API за допомогою зовнішніх бібліотек

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

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

З погляду ефективності виконання цей метод реалізації API має найнижчі результати, оскільки зовнішня бібліотека звертається як до функцій ОС, так і до функцій RTL (run time library), мови програмування. Тільки при дуже високій якості зовнішньої бібліотеки її ефективність стає порівнянною з бібліотекою RTL (run time library).

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

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

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

наприклад, бібліотека СLХ виробництва фірми Воr1аd орієнтована на архітектуру ОС типу Unix і ОС типу Windows.

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

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

Тому розроблювачі системних програм змушені залишатися в досить вузьких рамках обмежень стандартних бібліотек мов програмування.

Що стосується прикладних програм, то набагато велику перспективу для них надають технології, зв'язані з розробками в рамках архітектури «клієнт-сервер» чи створення додатків. У цьому напрямку ведучі виробники ОС, СУБД і систем програмування скоріше досягнуть угод, чим у напрямку стандартизації API.

Отже, нами були розглянуті основні принципи, мети і підходи до реалізації системних API.

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

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

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

Проектування паралельних взаємодіючих обчислювальних процесів

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

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

Незалежні і взаємодіючі обчислювальні процеси

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

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

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

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

Взаємодіючі процеси спільно використовують деякі (загальні) перемінні, і виконання одного процесу може вплинути на виконання іншого. При виконанні обчислювальні процеси розділяють ресурси системи.

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

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

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

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

співробітничають (сотрудничающими).

Як приклад розглянемо роботу двох процесів Р1 і Р2 із загальною змінною X. Нехай обидва процеси асинхронно, незалежно один від іншого, змінюють (збільшують) значення перемінної X, зчитуючи її значення в локальну область пам'яті Ri, при цьому кожен процес виконує деякі послідовності операцій у часі (мал.1).

Процес Р1	Процес Р2
№	№
оператора	оператора

1	R1:=Х	4	R2:=Х
2	R1:=R1+1	5	R2:=R2+1
3	Х:=R1	6	Х:=R2

Рис. 1 Приклад конкуруючих процесів

Оскільки при мультипрограмуванні процеси можуть мати різні швидкості виконання, то може мати місце будь-яка послідовність виконання операцій у часі. Якщо спочатку будуть виконані всі операції процесу Р1, а уже потом — всі операції процесу Р2 (чи, навпаки, спочатку операції 4-6, а потім — операції 1-3), то в підсумку перемінна Х одержить значення, рівне Х+2 (мал. 2).

Однак, якщо в проміжок часу між виконанням операцій 1 і 3 буде виконана хоча б одна з операцій 4-6 (мал. 6.3), то значення перемінної Х після виконання всіх операцій буде не (Х+2), а (Х+1).

Р1: (1)R1:=Х; (2) R1:=R1+1; (3)Х:=R1;

Р2:	(4) R2:=Х; (5) R2:=R2+1; (6) Х:=R2;

Рис. 2. Перший варіант розвитку подій при виконанні процесів

Р1:	(1)R1:=Х;	(2) R1:=R1+1;		(3)Х:=R1;
Р1:	(4) R2:=Х		(5) R2:=R2+1;		(6)Х:=R2;

Рис. 3. Другий варіант розвитку подій при виконанні процесів

Зрозуміло, що це дуже серйозна помилка. Наприклад, якби процеси Р1 і Р2 здійснювали продаж квитків і перемінна Х фіксувала кількість вже проданих, то в результаті некоректної взаємодії було б продане декілька квитків на те саме місце.