SWD Software Ltd. - официальный дистрибьютор QNX на территории России и стран бывшего СССР Операционная система реального времени QNX
Инструменты для создания надёжных встраиваемых систем и
интеллектуальных устройств любой сложности
QNX Software Systems - разработчик встраиваемой операционной системы QNX
Информационные брошюры
Статьи и публикации
Обзоры
Операционные системы
Графические интерфейсы
Средства разработки
Прикладные системы на базе ОС QNX
Разное
Конкурсные статьи
Техническая литература
Материалы конференций QNX-Россия
Полезные ссылки
Блог QNX
Главная страница > Материалы > Статьи и публикации > Обзоры > Оценочный обзор QNX 4.25 Сделать страницу стартовой Послать ссылку коллеге Версия для печати

Оценочный обзор QNX 4.25

Д-р Мартин Тиммерман (Martin Timmerman), директор, и Барт Ван Бенеден (Bart Van Beneden), специалист по программному обеспечению, компания Dedicated Systems Experts

Летом 1998 г. компания Real-Time Consult официально дала старт программе оценивания ОСРВ. Вначале была исследована ОС Windows NT и расширения реального времени для неё. Частью этой программы стал отчет об оценке продукта QNX 4.25, производства компании QNX Software Systems Ltd.

Введение

Летом 1998 г. компания Real-Time Consult официально дала старт программе оценивания ОСРВ. Вначале была исследована ОС Windows NT и расширения реального времени для неё. В настоящее время можно получить отчеты об оценке следующих продуктов:

  • RTX 4.2 от VenturCom, Inc.;
  • INtime 1.20 от Radisys Corporation Ltd.;
  • Hyperkernel 4.3 от Imagination Systems, Inc.;
  • VxWorks/x86 5.3.1 от WindRiver Systems Inc.;
  • pSOSystem/x86 2.2.6 от Integrated Systems Inc.;
  • QNX 4.25 от QNX Software Systems Ltd.
Эти отчеты по оценке и сравнению продуктов, отражающие информацию, важную для принятия решений, можно получить на нашем веб-сайте.

Архитектура

ОСРВ QNX 4.25 имеет клиент-серверную архитектуру, состоящую из небольшого микроядра, в котором реализованы только базовые службы и дополнительные взаимодействующие с микроядром процессы. Само по себе ядро не содержит планировщика внутри. Код исполняется только при возникновении вызовов ядра, аппаратных прерываний или обработки процессорных исключительных ситуаций.

QNX 4.25 является операционной системой, в основе которой лежит обмен сообщениями. Передача сообщений является фундаментальным средством межзадачного взаимодействия (IPC). Служба передачи сообщений основана на клиент-серверной модели: клиент (например, прикладной процесс) посылает сообщение серверу (например, диспетчеру устройства), и в ответ сервер отсылает результат по запросу.

У клиент-серверной архитектуры есть много преимуществ, одной из которых является устойчивость к нежелательным, но возможным воздействиям, или робастность. Каждая управляющая программа (за исключением администратора процессов) и каждый драйвер устройства работают в своем адресном пространстве, в результате получается структура надежной и отказоустойчивой системы. Платой за это является производительность: исполнение системных вызовов требует наличия нескольких контекстных переключателей (приводящими к издержкам, происходящим из-за работы механизма защиты памяти), что дает в итоге некоторое уменьшение производительности.

Благодаря своей архитектуре и сильной степени интеграции процессов передачи сообщений и сетевого обмена сообщениями, ОСРВ QNX классифицируется как полностью распределенная операционная система.

Задачи

QNX 4.25 является многопроцессорной системой. В самой QNX 4.25 отсутствуют потоки (threads), но они реализованы несколько необычным образом и существенно отличаются от потоков POSIX.

Потоки в QNX 4.25 ведут себя скорее как дочерние процессы, порожденные родительским процессом, чем как фактические потоки. Когда поток QNX создается некоторым процессом, то для него будет использоваться тот же сегмент кода и данных, как и для родительского процесса, что имеет место и в случае обычных потоков. Тем не менее, к некоторым специальным объектам, создаваемым родительским процессом, таким как таймеры и дескрипторы файлов, доступ со стороны потока невозможен.

Память

В ОСРВ QNX 4.25 для каждого процесса выделяется собственная виртуальная память, кодовый сегмент и сегмент данных и, соответственно, создается собственная локальная таблица дескрипторов (LDT). В процессорах семейства Intel виртуальная память поддерживается механизмом страничной организации (процессор работает в защищенном режиме).

У каждого процесса есть собственный сегмент кода и данных, поэтому при удалении процесса удаляются и эти сегменты. Следовательно, чрезвычайно важно использовать сегменты фиксированного размера. При использовании сегментов переменного размера пространство памяти оказалось бы фрагментированным из-за постоянного создания и удаления блоков памяти переменного размера.


Рис. 1. Микроканальная архитектура QNX 4.25.

QNX 4.25
Модель Только процессы
Уровни приоритетов 32 (0->31)
Макс. число задач 2 000 (500 по умолчанию)
Политики планирования
  • Планирование FIFO с приоритетами
  • Планирование с круговым обслуживанием
  • Адаптивное планирование
Число документированных состояний 9

Таблица 1. Свойства идентификатора задач (Task Handling) в QNX 4.25.

Прерывания

Во время работы обработчика прерываний сами прерывания не отключаются, поэтому процессор всегда способен воспринять сигнал нового прерывания от контроллера прерывания (PIC, Programmable Interrupt Controller). Однако, прерывания с тем же самым или с более низким уровнем приоритета оказываются в режиме ожидания, пока не закончит работу текущий обработчик. Работа текущего обработчика прерывания может быть вытеснена лишь появлением прерывания более высокого уровня.

Связь "прерывание-задача" носит ограниченный характер. Могут использоваться только объекты типа "прокси". В ситуациях, когда со стороны обработчика прерывания ожидается запуск потока, эти прокси-объекты оказываются менее мощным средством, чем семафоры.

QNX 4.25
Блок MMU Необходим
Физический размер страницы 4 Кбайт
Страничная организация/Свопинг Да/Нет
Модели защиты памяти Каждый процесс запускается в собственном виртуальном пространстве.
Виртуальная память Да

Таблица 2. Свойства блока управления памятью в QNX 4.25.

QNX 4.25
Тип обработчика Вложенный, с приоритетами
Связь "прерывание-задача" Носит ограниченный характер. Только прокси-объекты.
Стек Стек ядра
Контекст Контекст процесса, который прикреплен к обработчику
Минимум ОЗУ ?

Таблица 3. Свойства обработчика прерываний в QNX 4.25.

Богатые возможности API

Для получения доступа к богатым возможностям API мы создали список функциональных возможностей для большинства общесистемных вызовов и сравнили этот список с доступными системными вызовами в ОСРВ QNX 4.25. В табл. 4 приводятся сводные результаты для всех категорий с полученными для них баллами (в процентах). Классификация категорий по отдельным функциональным возможностям и системным вызовам может быть найдена в соответствующем отчете об оценке.

Приведённую таблицу следует толковать правильно. В ОСРВ QNX 4.25 имеются системные вызовы, отсутствующие в нашем списке, и поэтому они не нашли отражение в табл. 4.

Среднее процентное соотношение равнялось 40 %. При расчете значения не использовались никакие весовые коэффициенты, это простое среднее по всем категориям. Из табл. 4 видно, что в интерфейсе API QNX 4.25 отсутствуют некоторые базовые примитивы, такие как мутексы и флаги событий. Для ОС pSOSystem/x86 2.2.6 компании Integrated Systems Inc., среднее процентное соотношение, например, получается равным 44%.

Механизм Богатство возможностей
Управление потоком 50%
Синхронизация 86%
Интервальный таймер 83%
Разбиение памяти на блоки фиксированного размера 0%
Обработка прерываний с пулом памяти с блоками нефиксированного размера 55%
Обработка прерываний 75%
Счетный семафор 60%
Двоичный семафор 0%
Мутекс 0%
Условная переменная 0%
Флаги событий 0%
Сигналы POSIX 89%
Очередь сообщений 63%
Почтовый ящик 0%
СРЕДНИЙ ПРОЦЕНТ 40%

Таблица 4. Богатство возможностей API.

Тесты производительности

Времена ожидания при обработке прерывания

В данном тесте мы измеряли два времени ожидания:

  • Время входа в прерывание, Interrupt Latency, (от задачи до начала обработки прерывания): время, которое проходит между исполнением последней инструкции прерываемого потока и первой инструкции в обработчике прерываний.
  • Время выхода из прерывания, Interrupt Dispatch Latency, (от конца обработки прерывания до задачи): время, которое проходит от выполнения последней инструкции обработчика прерывания до запуска следующей стоящей в очереди задачи.
На рис. 2 и 3 показаны минимальное, максимальное и среднее значения для обоих приведенных времён ожидания.

Рис. 2. Время входа в прерывание (Interrupt Latency) для QNX 4.25.

Рис. 3. Время выхода из прерывания (Interrupt Dispatch Latency) для QNX 4.25.

Наследование приоритетов

Тест наследования приоритета обычно выполняется с использованием мутекса. Однако в QNX 4.25 мутексы не используются, хотя эту процедуру можно смоделировать через потоки (или процессы), используя примитивы передачи сообщений. Благодаря механизму приоритетов клиентской стороны, которая используется при передаче сообщений, можно смоделировать безопасный мутекс c инверсией приоритетов. Подробнее о том, как это реализовано и исполнено, можно прочесть в полном отчете об оценке.

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

Рис. 4. Наследование приоритета (Priority Inheritance)

Результаты тестирования показаны на рис. 4. Были получены худшие результаты, чем для конкурентных продуктов, использующих объекты типа "мутекс". Моделирование мутекса с помощью потока оказывается более медленной процедурой, потому что каждый раз при манипулировании с мутексом требуется переключение контекста.

Инструменты и метод разработки

В ОСРВ QNX 4.25 используется линейка инструментальных средств Watcom, где имеется большинство обычно используемых инструментов. Однако эти инструменты не интегрированы в единую среду разработки IDE, окружая весь процесс разработки. Инструменты доступны только из командной строки. В QNX изначально используется только подход типа "хост = целевая система" (то есть, хост и целевая система являют собой один и тот же компьютер). Преимущество такого подхода состоит в том, что пользователь имеет возможность выполнять все действия на одном компьютере: приложение может тестироваться на том же компьютере, где оно разрабатывалось, отладка проводиться локально и т.д.

Сейчас поддерживается также кросс-разработка, что делает возможным для разработчика компилировать и отлаживать код на хосте с ОС MS Windows. Во время проведения нашей оценки кросс-разработка не тестировалась.

Документация и техническая поддержка

Документация написана ясным языком и читается легко, но иногда не хватает "углубленной" информации. В некоторых местах замечена неадекватность в описании вызовов API.

Качество получаемой нами технической поддержки следует считать посредственным. Мы несколько раз связывались со службой технической поддержки по электронной почте и в некоторых случаях были разочарованы как временем, проходящим до ответа, так и собственно содержимым ответа.

Заключение

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

ОСРВ QNX 4.25 является многопроцессорной системой, но в ней отсутствуют традиционные потоки POSIX. В QNX нет объектов, называемых "потоки", но они реализованы несколько необычным образом и ведут себя скорее как процессы. Документацию относительно спецификации этих потоков нельзя назвать ясной.

В ОСРВ QNX 4.25 отсутствуют мутексы. Могут быть смоделированы безопасные мутексы с инверсией приоритетов посредством использования служб передачи сообщений и потоков, но это осуществляется за счет уменьшения производительности и гибкости. Следует ввести поддержку объектов типа "мутекс".

В распоряжении имеется большинство из обычно используемых инструментов, но они не интегрированы в IDE. Вместо этого инструменты доступны для использования через командную строку.

Другие публикации и услуги

Как отмечалось в начале, отчеты об оценке для продуктов Windows NT 4.0, RTX 4.2, Hyperkernel 4.3 и INtime 1.20 были выставлены на продажу на нашем веб-сайте с начала 1999 г.

В компании Real-Time Consult была также произведена оценка продуктов VxWorks/x86 5.3.1, QNX 4.25 и pSOSystem/x86 2.2.6. Отчеты об оценке этих продуктов доступны с 20 апреля 1999 г.

Отчеты об оценке предназначены для всех, кто тем или иным образом связан с технологиями специализированных систем. Это, безусловно, касается системных инженеров-разработчиков и разработчиков приложений, для которых важно иметь детальное представление о том, как тот или иной продукт ведет себя при работе в среде реального времени. Целевая аудитория включает также менеджеров и руководителей разработок, которым нужно принимать стратегические решения о том, какую ОСРВ использовать, и как принятое решение будет влиять на реализацию проекта в целом.

В заключение скажем, что компания Real-Time Consult может также выполнять исследования пригодности и аттестацию продуктов по запросам клиентов. Дополнительную информацию можно получить в наших офисах.

Д-р Мартин Тиммерман имеет степень в области техники дальней связи (Telecommunications Engineering) от Королевской военной Академии (Royal Military Academy, RMA) в Брюсселе, а в 1982 г. он получил степень доктора в области прикладных наук от Гентского государственного университета (Gent State University) в Бельгии. В 1983 он начал работать в области вычислительной техники и организовал в RMA Центр системных разработок (System Development Centre, SDC). Он читает общие курсы по компьютерным платформам и специализированные курсы по методологии системных разработок. Он является консультантом Генштаба Вооруженных сил Бельгии в области методологии информационных систем и инструментов CASE, а также является представителем в нескольких технических комиссиях НАТО. Вне пределов RMA Мартин известен по своей аудиторской деятельности, обзорам и семинарам, и своей компании Dedicated Systems Experts (Эксперты по Специализированным Системам), где он использует свои обширные знания из мира специализированных разработок. Компания Dedicated Systems Experts занимается ещё издательским делом, выпуская международный журнал Dedicated Systems Magazine, освещающий вопросы разработки специализированных систем. Компания Dedicated Systems Experts оказывает услуги по технической поддержке аппаратуры и программного обеспечения и участвует в инженерных разработках проектов для компании Dedicated Systems. Барт Ван Бенеден сотрудничает с компанией Dedicated Systems Experts с 1998 г., когда он был привлечен к программе оценки ОСРВ в журнале Dedicated Systems Magazine в качестве менеджера проектов. Он получил степень в области компьютерных наук в Свободном университете Брюсселя (Free University of Brussels). Перед началом работы в компании Dedicated Systems Experts он занимался разработкой мультимедийных приложений в компании LaserMedia Inc.

Рассказать друзьям:

     Рейтинг@Mail.ru