Тема: система QNX. Мікроядро

Лабораторна робота №5

Тема: СИСТЕМА QNX. МІКРОЯДРО

Теоретичні відомості

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

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

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

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

Унікальна ефективність, модульна і простота системи QNX визначається:

· архітектурою ядра;

· взаємодією між процесами за допомогою повідомлень.

Архітектура ядра системи QNX

Система QNX складається з невеликого ядра (мікроядра) і набору взаємодіючих процесів. Як показано на рисунку 1, система не має ієрархічної структури, її організація швидше нагадує "спортивну команду", в якій гравці (процеси), що мають рівну значущість, взаємодіють один з одним і з своїм "провідним гравцем" (ядром).

Рисунок 1 Мікроядро системи QNX координує роботу системних адміністраторів.

Ядро системи QNX

Ядро є "серцем" будь-якої операційної системи. В деяких системах на ядро покладена така кількість функцій, що, по суті справи, воно саме є повною операційною системою.

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

· передача повідомлень (ядро реалізує передачу всіх повідомлень між всіма процесами у всій системі);

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

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

Системні процеси

Всі функції, виконувані операційною системою QNX, за винятком функцій ядра, реалізуються стандартними процесами. В типовій конфігурації системи QNX є наступні системні процеси:

· Адміністратор процесів (Proc);

· Адміністратор файлової системи (Fsys);

· Адміністратор пристроїв (Dev);

· Мережний адміністратор (Net).

Системні процеси і процеси користувача

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

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

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

Припустимо, що ви написали сервер бази даних. Як слід класифікувати цю програму?

Сервер бази даних повинен виконувати функції, аналогічні функціям Адміністратора файлової системи, який одержує запити (повідомлення) на відкриття файлів і читання або запис даних. Не дивлячись на те, що запити до серверу бази даних можуть бути складнішими, і в тому і в іншому випадку формується набір примітивів (за допомогою повідомлень), внаслідок чого забезпечується доступ до системного ресурсу. В обох випадках йдеться про процеси, які можуть бути написаний кінцевим користувачем і виконуватися з потреби. Таким чином, сервер бази даних можна розглядати як системний процес в одному випадку і як прикладний в іншому. Фактично немає ніякої різниці. Важливо відзначити, що в системі QNX подібні процеси включаються без яких би те ні було модифікацій інших компонентів операційної системи.

Драйвери пристроїв

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

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

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

Зв'язок між процесами

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

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

QNX як мережа

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

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

 

Мікроядро

Ядро операційної системи QNX, представлене на рисунку 2, виконує наступні функції:

· зв'язок між процесами (IPC). Ядро забезпечує три форми IPC (повідомлення, proxy і сигнали);

· мережна взаємодія нижнього рівня. Ядро передає всі повідомлення, призначені процесам на іншому вузлі;

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

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

Рисунок 2 Мікроядро

Зв'язок між процесами

Ядро QNX підтримує три типи зв'язку між процесами: повідомленнями, proxy і сигналами.

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

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

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

Передача повідомлень

Для прямого зв'язку один з одним взаємодіючі процеси використовують наступні функції мови Сі:

C-функция	Призначення
Send()	для посилки повідомлень;
Receive()	для прийому повідомлень;
Reply()	для відповіді процесу, що послав повідомлення.

Ці функції можуть використовуватися локально або по всій мережі.

Зверніть увагу на те, що для прямого зв'язку процесів один з одним необов'язкове використовування функцій Send(), Receive() і Reply(). Система бібліотечних функцій QNX надбудована над системою обміну повідомленнями, тому процеси можуть використовувати передачу повідомлень побічно при використовуванні стандартних сервісних засобів, наприклад, програмних каналів (pipe).

Рисунок 3 Процес А посилає повідомлення процесу В, який приймає його, обробляє і передає відповідь.

Приведений вище рис. 3 ілюструє простий приклад використовування функцій Send(), Receive() і Reply() при взаємодії двох процесів - А і В:

1. Процес А посилає повідомлення процесу В, видавши ядру запит Send(). З цієї миті процес А стає SEND-блокованим до тих пір, поки процес В не видасть Receive(), підтверджуючи отримання повідомлення;

2. Процес У видає Receive() процесу А, чекаючому повідомлення. Процес А змінює свій стан на REPLY-блокований. Оскільки від процесу В очікується повідомлення, він не блокується.

3. Процес У виконує необхідну обробку, визначувану отриманим від процесу А повідомленням, і видає Reply(). Процес А одержує у відповідь повідомлення і розблоковується. Процес В також розблоковується. Який з процесів почне виконуватися першим, залежить від їх відносних пріоритетів.

Синхронізація процесів

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

Давайте звернемося знову до приведеного вище рисунку 3. Після того, як процес А видасть запит Send(), він не зможе виконуватися до тих пір, поки не отримає відповіді на передане їм повідомлення. Це служить гарантією того, що обробка даних, виконувана процесом В для процесу А завершиться до того, як процес А зможе продовжити свою роботу. У свою чергу процес В після видачі запиту Receive() може продовжувати свою роботу до надходження іншого повідомлення.

Стани блокувань

Коли виконання процесу заборонено до моменту завершення деякої частини протоколу обміну повідомленнями, говорять, що процес "блокований". Стани блокувань процесів приведені в наступній таблиці.

	Якщо процес видав	Процес є
1.	Запит Send(), і відправлене їм повідомлення ще не отримано процесом-одержувачем	SEND-блокованим
2.	Запит Send(), і відправлене їм повідомлення отримано процесом-одержувачем, але відповідь ще не видана	REPLY-блокованим
3.	Запит Receive(), але сам ще не отримав повідомлення	RECEIVE-блокованим

Рисунок 4 Стани процесу в типовій транзакції Send-Receive-Reply

Порядок виконання роботи

1. Ознайомитись з теоретичними відомостями.

2. Вивчити основні складові операційної системи.

3. Вивчити основи мікроядра.

4. Оформити звіт по лабораторній роботі.

 

Контрольні питання

1. Що таке операційна система QNX?

2. З чого складається система?

3. Що є основою операційної системи?

4. QNX як мережа.

5. Операційна система з передачею повідомлень.

6. Системні процеси і процеси користувача.

7. Драйвери пристроїв.

8. Зв'язок між процесами.

9. За що відповідає мікро ядро?

10. Що таке сигнал?

11. Що таке повідомлення?

12. Використовування функції Reply()

13. Використовування функції Receive()

14. Використовування функції Send()

 

Лабораторна робота №5

Тема: СИСТЕМА QNX. МІКРОЯДРО

Теоретичні відомості

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

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

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

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

Унікальна ефективність, модульна і простота системи QNX визначається:

· архітектурою ядра;

· взаємодією між процесами за допомогою повідомлень.