Смекни!
smekni.com

OC QNX (стр. 1 из 5)

1. Вступ.

QNX - це зареєстрована торгова марка фірми Quantum Software Systems, Canada. Фірма заснована в 1980 році. У той же самий час QNX - назва інтегрованої операційної системи, призначеної для підтримки роботи ЛВС у реальному масштабі часу і розробленою фірмою Quantum. В даний час QNX знаходить усе найбільш широкий попит на ринках Європи, Канади і США завдяки своїм унікальним властивостям. QNX - це багатозадачна багатокористувацька - операційна система, що працює на РС-совместительных комп'ютерах.

QNX - система реального часу, у якій реалізована концепція зв'язку між задачами на основі повідомлень, що посилаються від однієї задачі до іншої, причому задачі ці можуть знаходитися як на тому самому вузлі ЛВС, так і на різних. Реальний час і концепція зв'язку між задачами у виді повідомлень впливають на розроблювальне для QNX програмне забезпечення і на програміста, що прагне з максимальною вигодою використовувати переваги системи. У такий спосіб можна створювати загальні прикладні програми, що придатні для виконання в будь-який операционой середовищу, але в той же час можна створювати і такі програми, для яких QNX буде найбільш придатним операційним середовищем. Закінчуючи огляд ОС QNX, варто додати, що названа ОС може працювати в режимі захисту пам'яті, включає такі стандарти як POSIX і IEEE, а розроблювачі продовжують поповнювати її новими продуктами і властивостями. QNX може в даний час функціонувати на машинах із процесорами від і8088 до і80486, включаючи PS/2. QNX підтримує 255 вузлів мережі (процесорів), що можуть спільно використовувати програми, файли і периферійні пристрої. QNX у середньому виконує операції в 20 разів швидше, ніж UNIX, забезпечуючи цілком роботу мережі, при цьому вона вимагає 140КБ оперативної пам'яті. QNX мається эмулятор РС-DOS.

2. Функціональні можливості QNX.

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

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

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

3. Структура QNX.

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

1) Адміністратор задач (task) відповідає за розподілення пам'яті, запуск і закінчення задач у системі. Програма, що бажає створити задачу, посилає повідомлення Адміністратору задач і блокується для чекання відповіді. Якщо нова задача повинна виконуватися одночасно з її задачею, що породжує, Адміністратор задач створює її, і, відповідаючи, видає задачі, що породжує, ідентифікатор (id) створеної задачі. У противному випадку ніякого повідомлення не посилається доти, поки нова задача не закінчиться сама по собі. У цьому випадку у відповіді Адміністратора задач будуть міститися кінцеві характеристики задачі, що закінчилася.

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

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

4) Адміністратор неодруженої роботи (idle) системи "усмоктує" незайнятий час у системі. Він також виступає за замовчуванням як власник задач, своїх батьків, що пережили. Сам він ніколи не вмирає.

5) Мережний Адміністратор (net) забезпечує комунікації в мережі. Звичайно він викликається програмами й іншими задачами- адміністраторами у випадках, коли потрібен зв'язок з іншими вузлами (процесами).

6) Адміністратор-таймер (timer) дозволяє керувати програмами й асинхронними подіями, критичними вчасно, а також здійснювати повторний запуск програм.

7) Адміністратор черг (queue). Веде черга повідомлень між задачами як на одному вузлі, так і у всій мережі.

У QNX мається кілька інших задач-адміністраторів, що відповідають за доступ до різних ресурсів системи.

4. Особливості виконання задач у QNX.

QNX відрізняється тим, що деяка задача може бути частиною операційної системи і її чи середовища може бути "віртуальною" задачею. Остання має більшість атрибутів локальної задачі, у той час як виконується на інших процесорах (в інших вузлах мережі). Кожна задача, у тому числі і та, котра внутрішньо зв'язана з операційною системою, одержує унікальний ідентифікатор (tid). Щоб передати повідомлення іншій задачі, треба знати неї идентификатор. tid - це два байти, де в нижньому поміщений фактичний номер задачі (індекс, під яким вона поміщена в таблицю задач), а у верхньому - її послідовний номер і віртуальний прапор. Завдяки послідовному номеру, фактичний номер стає унікальним при вході в таблицю задач, якщо для двох різних задач використовується той самий вхід у таблиці. Для "дізнавання" імен (tid) задач у QNX існує два способи: порти і сервери імен.

а) порти - своєрідні крапки рандеву для задач, що позначаються невеликим цілим числом без знака. Типова конфігурація QNX має 28 портів у дійсному режимі і 40 - у захищеному. 16 з них резервуються самою операційною системою. Так, якщо задача - адміністратор бажає ідентифікувати себе для інших програм, вона виконує операцію приєднання до заздалегідь визначеного порту. Програми ж, від'єднуючи від даного порту, одержують tid задач-адміністратора, видаваною операційною системою. (В інших ОС порти називаються ще семафорами). Порти використовуються в QNX і як механізми переривання.

б) сервери імен - це задачі, що створюють список зареєстрованих імен програм і ідентифікаторів - tіd's - зв'язаних з іменами цих програм. Зареєстроване ім'я- це група до 8 символів, що задача за допомогою сервера може помістити в список. Будь-яка програма може довідатися це ім'я шляхом звертання до сервера імен; далі можна посилати повідомлення на це ім'я.

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

5. Віртуальні задачі і віртуальні ланцюги.

Завдяки такій властивості QNX, як можливість обміну посланнями між задачами і вузлами мережі, програми не піклуються про конкретне розміщення ресурсів у мережі. Ця властивість додає системі незвичайну гнучкість. Так, вузли можуть довільно додаватися і вилучатися із системи, не торкаючись системні програми. QNX здобуває цю конфігураційну незалежність завдяки застосуванню концепції "віртуальних" задач. У віртуальних задач безпосередній код і дані, будучи на одному з вилучених вузлів, виникають і поводяться так, ніби вони були локальними задачами якогось вузла з всіма атрибутами і привілеями. Програма, що посилає повідомлення в мережі, ніколи не посилає його точно. Спочатку вона відкриває "віртуальний ланцюжок". Віртуальний ланцюжок включає усі віртуальні задачі, зв'язані між собою. На обох кінцях такого зв'язку маються буфери, що дозволяють зберігати найбільше послання з тих, котрі ланцюжок може нести в даному сеансі зв'язку. Мережний адміністратор поміщає в ці буфери всі повідомлення для з'єднаних задач. Віртуальна задача, таким чином, займає усього лише простір, необхідний для буфера і входу в таблиці задач. Щоб відкрити зв'язок, необхідно знати ідентифікатор вузла і задачі, з яким установлюється зв'язок. Для цього необхідно знать ідентифікатор задачі- адміністратора, відповідального за дану чи функцію глобальне ім'я сервера. Не розкриваючи тут докладно механізм обміну посланнями, додамо лише, що наша задача може узагалі виконуватися на іншому вузлі, де, допустимо, мається більш зроблений процесор.