1   2   3   4   5   6   7   8   9   10
Ім'я файлу: 1-126.pdf
Розширення: pdf
Розмір: 1940кб.
Дата: 12.12.2021
скачати
24. Інтерфейс прикладного програмування.
Інтерфейс прикладного програмування АРІ (application program interface) – призначений для використання прикладними програмами системних ресурсів ОС і функцій, які ОС реалізуються.
АРІ – описує сукупність функцій і процедур, які належать ядру або надбудовам
ОС. Тобто АРІ – це набір функцій, які надаються системою програмування розробнику прикладної програми і які орієнтовані на організацію взаємодії результуючої прикладної програми із сукупністю програмних та апаратних засобів, в оточенні яких виконується результуюча програма. Сама результуюча програма породжується системою програмування, ґрунтуючись на коді вихідної програми, створеної програмістом, а також об’єктних модулів і бібліотек, які входять до складу системи програмування.
АРІ використовується не тільки прикладними, а також і системними програмами як в складі ОС, так і в складі системи програмування.
Функції АРІ дозволяють розробнику будувати результуючу прикладну програму таким чином, щоби використати засоби обчислювальної системи для виконання типових операцій. При цьому розробник програми не повинен створювати вихідний код для виконання цих операцій.
Програмний інтерфейс АРІ включає в себе не тільки самі функції, але і домовленості про їх використання, які регламентуються ОС, архітектурою обчислювальної системи і системою.
Існує декілька варіантів реалізації АРІ:
1. Реалізація на рівні ОС.
2. Реалізація на рівні системи програмування.
3. Реалізація на рівні зовнішньої бібліотеки процедур і функцій.
В кожному з цих варіантів розробнику надаються засоби для підключення функцій АРІ до вихідного коду програми і організації їх викликів. Об’єктний код функцій АРІ підключається до результуючої програми компонувальником при необхідності.

25. Варіанти реалізації інтерфейсу прикладного програмування
Реалізація на рівні ОС
За виконання функцій АРІ відповідальність несе ОС. Об’єктний код, який виконує функції, або безпосередньо входить до складу ОС (або навіть ядра ОС), або входить до складу бібліотек, які динамічно завантажуються, і які розроблені для даної ОС.
Система програмування відповідає тільки за організацію інтерфейсу для виклику цього коду.
В цьому варіанті результуюча програма звертається безпосередньо до ОС. Тому досягається найбільша ефективність виконання функцій АРІ у порівнянні з усіма
іншими варіантами реалізації АРІ.
Недолік: відсутність можливості переносу не тільки коду результуючої програми, але і коду вихідної програми. Програма, створена для одної архітектури обчислювальної системи, не зможе виконуватись на обчислювальній системі іншої архітектури навіть після того, якщо її об’єктний код буде повністю перебудовано.
Частіше за все система програмування не зможе виконати перебудову вихідного коду для нової архітектури обчислювальної системи.
Можна уніфікувати функції АРІ в різних ОС. Але є корпоративні інтереси.
Приклад: Для ОС Microsoft Windows – WinAPI.
Але навіть всередині цього корпоративного АРІ існує певна невідповідність, яка дещо обмежує переносимість програм між різними ОС типу Windows.
Приклад: АРІ – набір сервісних функцій ОС для MS-DOS, який реалізовано у вигляді набору підпрограм обслуговування програмних переривань.
Реалізація на рівні системи програмування
В цьому випадку функції АРІ надаються користувачу у вигляді бібліотеки функцій відповідної мови програмування. Система програмування надає користувачу бібліотеку відповідної мови програмування і забезпечує підключення до відповідної програми об’єктного коду, що відповідає за виконання цих функцій.
Ефективність АРІ буде нижче, ніж у попередньому варіанті. Це тому, що для виконання багатьох функцій АРІ бібліотека мови програмування повинна все одно виконати звертання до функцій ОС.
Але переносимість буде самою високою, оскільки синтаксис і семантика всіх функцій будуть строго регламентовані в стандарті мови. Вони залежать від мови і не залежать від архітектури обчислювальної системи. Тому для виконання прикладної програми на новій архітектурі обчислювальної системи досить заново побудувати код
результуючої програми за допомогою відповідної системи програмування. Але є нестандартні бібліотеки.
Реалізація на рівні зовнішньої бібліотеки
У цьому варіанті функції АРІ надаються користувачу у вигляді бібліотеки процедур і функцій, яка може бути створена стороннім розробником.
Система програмування відповідала тільки за те, щоби підключити об’єктний код бібліотеки до результуючої програми, причому зовнішня бібліотека може бути і такою, що динамічно завантажується (тобто завантажується під час виконання програми).
З точки зору ефективності цей метод найгірший, оскільки зовнішня бібліотека звертається як до функцій ОС, так і до функцій мови програмування.
З точки зору переносимості, то тут тільки одна вимога – зовнішня бібліотека, яка використовується, повинна бути допустимою в довільній з архітектур обчислювальних систем, на які орієнтована прикладна програма. Це можливо, якщо бібліотека відповідає деякому прийнятому стандарту, а система програмування підтримує цей стандарт.
Бібліотека графічного інтерфейсу XLib підтримує стандарт графічного середовища
XWindow:
MFC (Microsoft foundation classes) (OC Windows);
VCL (Visual controls library), „Borland”; CLX, „Borland” (OC Linux, OC Windows).
Як правило АРІ не стандартизовані. В кожному конкретному випадку набір викликів АРІ визначається, перш за все, архітектурою ОС та її призначенням.
Робляться спроби стандартизувати деякий базовий набір функцій, оскільки це суттєво полегшує перенесення програм з одної ОС на іншу. Приклад: стандарт POSIX.
В ньому перераховано великий набір функцій, їх параметрів та значень, що повертаються. Стандартизуються не тільки звертання до АРІ, але і файлова система, організація доступу до зовнішніх пристроїв, набір системних команд.
Приклад: Внутрішній корпоративний стандарт Microsoft, WinAPI.
Win16, Win32
S
, Win32, WinCE. З точки зору WinAPI, базова задача – вікно. Тобто він орієнтований на роботу в графічному середовищі.

26. Особливості базової архітектури ОС UNIX.
UNIX є прикладом досить простої архітектури ОС. Більша частина функціональності цієї системи міститься в ядрі, ядро спілкується із прикладними програмами за допомогою системних викликів. Базова структура класичного ядра UNIX зображена на рис. 2.3. Система складається із трьох основних компонентів: підсистеми керування процесами, файлової підсистеми та підсистеми введення/виведення.
Підсистема керування процесами контролює створення та вилученняпроцесів, розподілення системних ресурсів між ними, міжпроцесову взаємодію, керування пам’яттю.
Файлова підсистема забезпечує єдиний інтерфейс доступу до даних,
розташованих на дискових накопичувачах, і до периферійних пристроїв. Такий
інтерфейс є однією з найважливіших особливостей UNIX. Одні й ті самі системні виклики використовують як для обміну даними із диском, так і для виведення на термінал або принтер (програма працює із принтером так само, як із файлом). При цьому файлова система переадресовує запити відповідним модулям підсистеми введення/ виведення, а ті — безпосередньо периферійним пристроям. Крім того, файлова підсистема контролює права доступу до файлів, які значною мірою визначають привілеї користувача в системі.
Підсистема введення-виведення виконує запити файлової підсистеми,взаємо діючи з драйверами пристроїв. В UNIX розрізняють два типи пристроїв: символьні
(наприклад , принтер) і блокові (наприклад, жорсткий диск). Основна відмінність між ними полягає в тому, що блоковий пристрій допускає прямий доступ. Для підвищення продуктивності роботи із блоковими пристроями використовують буферний кеш — ділянку пам ’яті, у якій зберігаються дані, зчитані з диска останніми. Під час наступних звертань до цих даних вони можуть бути отримані з кешу.

Рис. 2.3. Типова архітектура UNIX

27. Призначення ядра ОС Linux та його особливості.
Linux реалізує технологію монолітного ядра. Весь код і структури даних ядра перебувають в одному адресному просторі. У ядрі можна виділити кілька функціональних компонентів.
Планувальник процесів —відповідає за реалізацію багатозадачності всистемі
(обробка переривань, робота з таймером, створення і завершення процесів, перемикання контексту).
Менеджер пам’яті —виділяє окремий адресний простір для кожногопроцесу і реалізує підтримку віртуальної пам’яті.
Віртуальна файлова система —надає універсальний інтерфейс взаємодіїз різними файловими системами та пристроями введення/виведення.
Драйвери пристроїв —забезпечують безпосередню роботу зпериферійними пристроями. Доступ до них здійснюється через інтерфейс віртуальної файлової системи.
Мережний інтерфейс —забезпечує доступ до реалізації мережнихпротоколів і драйверів мережних пристроїв.
Підсистема міжпроцесової взаємодії —пропонує механізми,які даютьзмогу різним процесам у системі обмінюватися даними між собою.
Деякі із цих підсистем є логічними компонентами системи, вони завантажуються у пам’ять разом із ядром і залишаються там постійно. Компоненти інших підсистем
(наприклад, драйвери пристроїв) вигідно реалізовувати так, щоб їхній код міг завантажуватися у пам’ять на вимогу. Для розв’язання цього завдання Linux підтримує концепцію модулів ядра.

28. Концепція модулів ядра в ОС Linux.
Ядро Linux дає можливість на вимогу завантажувати у пам'ять і вивантажувати з неї окремі секції коду. Такі секції називають модулями ядра (kernel modules) [ЗО] і виконують у привілейованому режимі. Модулі ядра надають низку переваг. Код модулів може завантажуватися в пам'ять у процесі роботи системи, що спрощує налагодження компонентів ядра, насамперед драйверів.
З’являється можливість змінювати набір компонентів ядра під час виконання: ті з них, які в цей момент не використовуються, можна не завантажувати у пам'ять.
Модулі є винятком із правила, за яким код, що розширює функції ядра, відповідно до ліцензії Linux має бути відкритим. Це дає змогу виробникам апаратного забезпечення розробляти драйвери під Linux, навіть якщо не заплановано надавати доступ до їхнього вихідного коду.Підтримка модулів у Linux складається із трьох компонентів.
Засоби керування модулями дають можливість завантажувати модулі у пам’ять і здійснювати обмін даними між модулями та іншою частиною ядра.
Засоби реєстрації драйверів дозволяють модулям повідомляти іншу частину ядра про те, що новий драйвер став доступним.
Засоби розв’язання конфліктів дають змогу драйверам пристроїв резервувати апаратні ресурси і захищати їх від випадкового використання іншими драйверами.
Один модуль може зареєструвати кілька драйверів, якщо це потрібно (на приклад, для двох різних механізмів доступу до пристрою).
Модулі можуть бути завантажені заздалегідь — під час старту системи
(завантажувальні модулі) або у процесі виконання програми , яка викликає їхні функції. Після завантаження код модуля перебуває в тому ж самому адресному просторі, що й інший код ядра. Помилка в модулі є критичною для системи.

29. Основні компоненти архітектури ОС Windows
Основні компоненти:
-режим користувача
-режим ядра
-рівень апаратури
30. Призначення рівня абстрагування від апаратури в ОС Windows.
У Windows XP рівень абстрагування від устаткування називають HAL (hardware abstraction layer). Для різних апаратних конфігурацій фірма Microsoft або сторонні розробники можуть постачати різні реалізації HAL.
Хоча код HAL є дуже ефективним, його використання може знижувати продуктивність застосувань. Тому для мультимедіа використовують спеціальний пакет DirectX, який дає змогу прикладним програмам звертатися безпосередньо до апаратного забезпечення, обминаючи HAL та інші рівні системи.

31. Основні компоненти підсистеми виконання в ОС Windows.
Підсистеми середовища надають застосуванням користувача доступ до служб операційної системи, створюючи відповідний АРІ. Слід виділити дві підсистеми середовища: Win32 і POSIX. Підсистема Win32, яка реалізує Win32 АРІ, є обов’язковим компонентом Windows XP. До неї входять такі компоненти:
- процес підсистеми Win32 (csrss.exe), що відповідає, зокрема, за реалізацію текстового (консольного) введення/виведення, створення і знищення процесів та потоків;
- бібліотеки підсистеми Win32, які надають прикладним програмам функції Win32
АРІ. Найчастіше використовують бібліотеки gdi32.dll (графічні функції низького рівневня, незалежні від пристрою), user32.dll (функції інтерфейсу користувача) і kernel32.dll (функції, реалізовані у ВС і ядрі). Підсистеми середовища надають застосуванням користувача доступ до служб операційної системи, створюючи відповідний АРІ. Слід виділити дві підсистеми середовища: Win32 і POSIX.
Підсистема Win32, яка реалізує Win32 АРІ, є обов’язковим компонентом Windows XP.
До неї входять такі компоненти:
- процес підсистеми Win32 (csrss.exe), що відповідає, зокрема, за реалізацію текстового (консольного) введення/виведення, створення і знищення процесів та потоків;
- бібліотеки підсистеми Win32, які надають прикладним програмам функції Win32
АРІ. Найчастіше використовують бібліотеки gdi32.dll (графічні функції низького рівневня, незалежні від пристрою), user32.dll (функції інтерфейсу користувача) і kernel32.dll (функції, реалізовані у ВС і ядрі).
32. Об’єктна модель архітектури ОС Windows:
Керування ресурсами у Windows XP реалізується із застосуванням концепції об’єктів.
Об’єкти надають універсальний інтерфейс для доступу до системних ресурсів, для яких передбачено спільне використання, зокрема таких, як процеси, потоки, файли і пам’ять, що розподіляється. Концепція об’єктів забезпечує важливі переваги. Імена об’єктів організовані в єдиний простір імен, де їх легко знаходити. Доступ до всіх об’єктів здійснюється однаково. Після створення нового об’єкту або після отримання доступу до наявного менеджер об’єктів повертає у застосування дескриптор об’єкту
(object handle). Забезпечено захист ресурсів. Кожну спробу доступу до об’єкту розглядає підсистема захисту — без неї доступ до об’єкту, а отже і до ресурсу, отримати неможливо. Менеджер об’єктів відповідає за створення, підтримку та ліквідацію об’єктів, задає єдині правила для їхнього іменування, збереження й забезпечення захисту. Підсистеми середовища звертаються до менеджера об’єктів безпосередньо або через інші сервіси ВС. Наприклад, під час запуску застосування підсистема Win32 викликає менеджер процесів для створення нового процесу. В свою чергу менеджер процесів звертається до менеджера об’єктів для створення об’єкту, що представляє процес. Об’єкти реалізовано як структури даних в адресному просторі ядра. При перезавантаженні системи вміст усіх об’єктів губиться.

33. Розкрийте поняття „обчислювальний процес”.:
Поняття „обчислювальний процес” є одним із основних при вивченні операційних систем. Притримуємось такого визначення: Процес (або задача) – це програма під час виконання на процесорі із послідовним виконанням команд. Сам процес розглядається в двох аспектах:
1) Він є носієм даних;
2) Виконує операції, пов’язані з обробкою цих даних.
Процесом може бути: виконання утиліти; виконання прикладної програми; трансляція вихідної програми (одної програми – один процес, іншої програми – інший процес).
Процесом називають сукупність одного або декількох потоків і захищеного адресного простору, у якому ці потоки виконуються.
34. Основні стани обчислювального процесу.
Процес знаходиться в стані виконання, якщо в біжучий момент йому надається центральний процесор (CPU). Процес знаходиться в стані готовності, якщо він міг би одразу використати CPU, який знаходиться в його розпорядженні. Процес знаходиться в стані блокування, якщо він очікує на деяку подію (наприклад, завершення операції вводу/виводу) для того, щоби отримати можливість продовжити виконання.
35. Умови переходу обчислювального процесу із стану в стан.
Процес із пасивного стану може перейти в стан готовності в таких випадках:
1. За командою користувача. Це має місце в тих інтерактивних (діалогових) ОС, де програма може мати статус задачі, а не просто бути файлом виконання. І тільки на час виконання вона може отримувати статус задачі, тобто процесу.
2. При виборі з черги планувальником процесів.
3. За викликом із іншої задачі (один процес може створити, ініціювати, призупинити, зупинити, знищити інший процес).
4. За перериванням від зовнішнього пристрою (сигнал від виконання деякої події може запустити відповідну задачу).
5. При надходженні запланованого часу запуску програми.
Із стану виконання процес може вийти з таких причин:
1. Процес завершується, при цьому він передає керування ОС і повідомляє про своє завершення. В результаті процес або переходить в пасивний стан, або знищується.
Знищується не сама програма, а саме активний процес, який відповідав виконанню деякої програми. В пасивний стан процес може бути переведений примусово за командою оператора.
2. Процес переводиться ОС в стан готовності у зв’язку з виникненням задачі з вищим пріоритетом або через завершення виділеного кванту часу.
3. Процес блокується або через запит операції вводу/виводу, або через те, що йому неможливо надати ресурс, на який виник запит, або за командою оператора на призупинення задачі.

36. Призначення та основні функції блоку керування процесами (PCB).
Блоком керування процесом (Program Control Block, PCB), або дескриптором процесу, або описувачем задачі. В загальному випадку РСВ вміщує таку інформацію:
1. Ідентифікатор процесу (PID – process identifier).
2. Тип (або клас) процесу, який визначає для ОС деякі правила надання ресурсів.
3. Пріоритет процесу, відповідно до якого ОС надає ресурси. В рамках одного класу процесів у першу чергу обслуговуються процеси з вищим пріоритетом.
4. Змінну стану, яка визначає, в якому стані знаходиться процес (стані готовності, стані виконання, стані блокування).
5. Адресу захищеної ділянки пам’яті, в якій зберігаються біжучі значення регістрів процесора, якщо процес призупиняється (або переривається) не завершивши роботи.
Ця інформація називається контекстом задачі.
6. Інформація про ресурси, якими володіє процес або має право користуватись.
7. Адреса місця для організації спілкування з іншими процесами. 8. Параметри часу запуску (момент часу, коли процес повинен активізуватись та періодичність цієї процедури).
9. Для диск–резидентних задач, які постійно знаходяться у зовнішній пам’яті і завантажуються в основну пам’ять тільки на час виконання зберігається адреса задачі на диску в її вихідному стані

1   2   3   4   5   6   7   8   9   10

скачати

© Усі права захищені
написати до нас