Операционная система QNX

В последнее время система QNX быстро развивалась, превращаясь из узкоспециализированной ОС для систем реального времени в более-менее универсальную систему [3]. Однако ее разработчики отказались от попыток «добавить еще одну функцию» в QNX, поскольку этот путь ведет в тупик.

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

С точки зрения пользовательского интерфейса и API, эта ОС очень похожа на Unix. Если вы знакомы с Unix на уровне пользователя, то вероятно сможете работать с QNX без проблем — в ней присутствует практически весь набор стандартных утилит и сохраняется большая часть семантики. Конечно, есть и X Window, равно как и TCP/IP. Если вы программист, знающий Unix, то для вас не составит большого труда перенести собственные или GNU/Free-приложения в QNX. Например, Apache и Mosaic хорошо демонстрируют степень совместимости API.

Однако QNX — это не версия Unix. Она была разработана с нуля и построена на совершенно других архитектурных принципах, но с учетом группы стандартов POSIX, которые возникли в результате обобщения существующей практики в различных версиях системы Unix. Разработка ведется канадской фирмой QNX Software Systems Limited (далее — QSSL).

QNX — это первая коммерческая ОС, построенная на принципах микроядра и обмена сообщениями. Система реализована в виде совокупности независимых (но взаимодействующих через обмен сообщениями) процессов различного уровня (менеджеры и драйверы), каждый из которых реализует определенный вид сервиса. Эти идеи обеспечили ряд важнейших преимуществ.

Предсказуемость, означающую ее применимость к задачам жесткого реального времени. Ни одна версия Unix не может достичь подобного качества, поскольку нереентрабельный код ядра слишком велик. Любой системный вызов в Unix может привести к непредсказуемой задержке. То же самое относится к Windows NT, где реальное время заканчивается между ISR (первичный обработчик прерывания) и DPC (вызов отложенной процедуры).

Масштабируемость и эффективность, достигаемую оптимальным использованием ресурсов и означающую ее применимость для встроенных (embedded) систем. В каталоге /dev нет огромной кучи файлов, соответствующих ненужным драйверам. Драйверы и менеджеры можно запускать просто из командной строки. И удалять (кроме файловой системы J) динамически. Можно иметь только тот сервис или те модули, которые реально нужны, причем это не требует серьезных усилий и не порождает проблемы.

Расширяемость и надежность одновременно, поскольку написанный вами драйвер не нужно компилировать в ядро, рискуя вызвать нестабильность системы. Менеджеры ресурсов (сервис логического уровня) работают в кольце 3, при этом можно добавлять свои, не опасаясь за систему. Драйверы работают в кольце 1 и могут вызвать проблемы, но не фатального характера. Кроме того, их достаточно просто писать и отлаживать. Например, постоянная головная боль разработчиков драйверов для Linux — получение физически непрерывного блока памяти для DMA-устройств — устраняется просто и элегантно, через функцию mmap ().

Быстрый сетевой протокол FLEET, прозрачный для обмена сообщениями, автоматически обеспечивающий отказоустойчивость, балансирование нагрузки и маршрутизацию между альтернативными путями доступа. Он не так универсален, как TCP/IP, но гораздо проще в использовании и эффективнее.

Богатый выбор графических подсистем, включающий QNX Windows, X11R5 и Photon, что позволяет разработчикам выбирать ту, которая лучше подходит для их целей. Для типичных областей применения QNX традиционная система X11 слишком тяжеловесна, но система Photon, построенная на тех же принципах модульности, что и сама QNX, позволяет получить полнофункциональный GUI (типа Motif 2.0), работающий вместе с POSIX-совместимой ОС всего в 4 Мбайт памяти.

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

• — нет поддержки SMP;
• — нет своппинга виртуальной памяти на диск;
• — неэффективная и нестандартная поддержка нитей (threads);
• — нет поддержки Java (как следствие предыдущего пункта);
• — нет поддержки отображения файлов в память;
• — многочисленные ограничения файловой системы;
• — нет поддержки Unix-domain sockets;
• — слабые средства разграничения и контроля доступа пользователей;
• — отсутствие средств безопасности в рамках собственного сетевого протокола.

Хотя этот список содержит достаточно важные пункты, не все они являются критичными для рынка QNX, поскольку она не проектировалась для конкуренции с Unix. Но, что гораздо более важно, некоторые пункты этого списка, а также другие ограничения QNX, являются серьезными недостатками с точки зрения теории систем реального времени. И это притом, что QNX является лидером этого рынка!

Что же это за недостатки? Чтобы понять, нужно определить требования к ОС, предназначенной для реализации систем реального времени. Именно этот смысл я вкладываю в общеупотребительный термин «ОС реального времени» (Real Time OS). Использование какой-либо ОС еще не гарантирует получения результата. Можно взять любую ОС такого типа и создать на ее базе некую систему, предназначенную для работы в реальном времени (далее — «система реального времени»), но не способную на это фактически. Чем отличается система реального времени? Есть два основных требования.

— Система должна реагировать на события, успевая обработать их за фиксированное время или к фиксированному моменту времени (далее — «временные рамки»).

Для выполнения этого требования система должна обладать предсказуемостью, которую не следует путать с производительностью. Никакой процессор не сделает Windows предсказуемой.

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

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

Однако можно взять ту или иную ОС и на ее основе создать систему реального времени. При условии, что такая ОС отвечает по крайней мере следующим требованиям.

• 1. ОС должна поддерживать вытесняющую многопоточность (preemptive multi-threading) и мультипроцессорные архитектуры.
• 2. Аппаратная архитектура должна поддерживать несколько уровней прерываний (interrupt levels), а ОС должна обеспечивать вытеснение (preemption) обработчиков прерываний.
• 3. Каждая нить управления (thread) должна иметь способ выражения собственной важности. В идеале планировщик должен предоставлять процессор той нити, у которой осталось меньше всего времени до исчерпания своих временных рамок (алгоритм, известный как EDF — Earliest Deadline First). Но учитывая сложность реализации такой схемы, можно ограничиться наличием приоритетов у нитей, при условии поддержки достаточно большого количества уровней приоритетов.
• 4. ОС должна обеспечивать предсказуемые механизмы для синхронизации между нитями и взаимодействия процессов, разрешающие проблему «инверсии приоритетов». Это означает, что как при передаче данных, так и при синхронизации нитей должно обеспечиваться «наследование приоритетов» (или эквивалентный механизм).
• 5. Поведение самой ОС после системных вызовов и наступления событий должно быть предсказуемо и известно заранее. Это означает, что разработчики ОС должны специфицировать такие временные характеристики, как «задержка обработки прерывания» (interrupt latency), максимальное время маскировки прерываний, а также максимальное время исполнения всех системных вызовов.
• 6. ОС должна быть способна работать в ограниченных ресурсах, особенно это касается оперативной памяти.
• 7. Стоимость системы при массовых тиражах должна быть достаточно низкой.
• 8. ОС должна обеспечивать API и «нижележащий» сервис, соответствующий по структуре и реализации требованиям систем реального времени.

Немногие ОС способны выполнить хотя бы часть этих требований, хотя не все из них одинаково важны. Например, Windows NT абсолютно не соответствует критическим требованиям 2 и 4 и весьма слабо — условимя, изложенным в п.п. 3, 5, 6, 7 и 8. В свою очередь заметим, что QNX так же не вполне отвечает всем требованиям. В частности, она имеет следующие серьезные недостатки:

• — неадекватная поддержка нитей и отсутствие поддержки симметричных мультипроцессорных архитектур (SMP);
• — ограниченное количество уровней прерываний (32);
• — отсутствие поддержки «наследования приоритетов» для механизмов синхронизации (семафоров);
• — неспособность работать на системах с объемом памяти менее 512 Kбайт, а с графическими возможностями потребности еще больше;
• — относительно высокие цены, даже при больших объемах закупок.

Некоторые из указанных недостатков в определенной степени компенсируются достоинствами QNX. Например, практическое отсутствие нитей и SMP отчасти уравновешивается очень малым временем переключения контекста между процессами, а высокие цены — возможностью модульного лицензирования. Семафоры же вообще являются «пятым колесом в телеге» для QNX.