Архитектура системы QNX

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

Микроядро имеет объем в несколько десятков килобайт (в одной из версий – 10 Кбайт, в другой – менее 32 Кбайт), то есть это одно из самых маленьких ядер среди всех существующих операционных систем. В этом объеме помещаются [54]:

¨ механизм передачи сообщений между процессами (IPC);

¨ редиректор3 прерываний;

¨ блок планирования выполнения задач;

¨ сетевой интерфейс для перенаправления сообщений (менеджер Net).

Механизм передачи межпроцессных сообщений занимается пересылкой сообще­ний между процессами и является одной из важнейших частей операционной системы, так как всё общение между процессами, в том числе и системными, происходит через сообщения. Сообщение в QNX – это последовательность бай­тов произвольной длины (0–65 535 байтов) произвольного формата. Протокол обмена сообщениями выглядит таким образом. Например, задача блокируется для ожидания сообщения. Другая же задача посылает первой сообщение и при этом блокируется сама, ожидая ответа. Первая задача разблокируется, обрабаты­вает сообщение и отвечает, разблокируя при этом вторую задачу.

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

Представители используются в случаях, когда процесс должен передать сообщение, но не должен при этом блокироваться на передачу. В таком случае вызывается функция qnx_proxy_attach( ) и создаётся представитель. Он накапливает в себе сообщения, которые должны быть доставлены другим процессам. Лю­бой процесс, знающий идентификатор представителя, может вызвать функцию Trigger( ), после чего будет доставлено первое в очереди сообщение. Функция Trigger ( ) может вызываться несколько раз, и каждый раз представитель будет доставлять следующее сообщение. При этом представитель содержит буфер, в котором может храниться до 65 535 сообщений. Как известно, сигналы уже давно используются в ОС UNIX. Система QNX под­держивает множество сигналов, совместимых с POSIX, большое количество сигналов, традиционно использовавшихся в UNIX (поддержка этих сигналов реа­лизована для совместимости с переносимыми приложениями, и ни один из сис­темных процессов QNX их не генерирует), а также несколько сигналов, специ­фичных для самой QNX. По умолчанию любой сигнал, полученный процессом, приводит к завершению процесса (кроме нескольких сигналов, которые по умол­чанию игнорируются). Но процесс с приоритетом уровня «superuser» может за­щититься от нежелательных сигналов. В любом случае процесс может содержать обработчик для каждого возможного сигнала. Сигналы удобно рассматривать как разновидность программных прерываний.

Редиректор прерываний является частью ядра и занимается перенаправлением аппаратных прерываний в связанные с ними процессы. Благодаря такому подхо­ду возникает один побочный эффект – с аппаратной частью компьютера работа­ет ядро, оно перенаправляет прерывания процессам – обработчикам прерыва­ний. Обработчики прерываний обычно встроены в процессы, хотя каждый из них исполняется асинхронно с процессом, в который он встроен. Обработчик исполняется в контексте процесса и имеет доступ ко всем глобальным переменным процесса. При работе обработчика прерываний прерывания разрешены, но обра­ботчик приостанавливается только в том случае, если произошло более высоко­приоритетное прерывание. Если это позволяется аппаратной частью, к одному прерыванию может быть подключено несколько обработчиков, и каждый из них получит управление при возникновении прерывания.

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

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

К выполнению своих функций как диспетчера ядро приступает в следующих случаях:

¨ какой-либо процесс вышел из блокированного состояния;

¨ истёк квант времени для процесса, владеющего CPU;

¨ работающий процесс прерван каким-либо событием.

Диспетчер выбирает процесс для запуска среди неблокированных процессов в порядке значений их приоритетов, которые располагаются в диапазоне от 0 (наименьший) до 31 (наибольший). Обслуживание каждого из процессов зависит от метода диспетчеризации, с которым он работает (уровень приоритета и метод диспетчеризации могут динамически меняться во время работы). В QNX существуют три метода диспетчеризации: FIFO (первым пришел – первым об­служен), round–robin (процессу выделяется определенный квант времени для ра­боты) и адаптив-ный, который является наиболее используемым.

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

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

¨ Когда процесс полностью использовал выделенный ему квант времени, его приоритет снижается на 1, если в системе есть процессы с тем же уровнем приоритета, готовые к исполнению.

¨ Если процесс с пониженным приоритетом остаётся не обслуженным в течение секунды, его приоритет увеличивается на 1.

Если процесс блокируется, ему возвращается оригинальное значение приоритета.

По умолчанию процессы запускаются в режиме адаптивной многозадачности. В этом же режиме работают все системные утилиты QNX. Процессы, работаю­щие в разных режимах многозадачности, могут одновременно находиться в па­мяти и исполняться. Важный элемент реализации многозадачности – это при­оритет процесса. Обычно приоритет процесса устанавливается при его запуске. Но есть дополнительная возможность, называемая «вызываемый клиентом при­оритет». Как правило, она реализуется для серверных процессов (исполняющих запросы на какое-либо обслуживание). При этом приоритет процесса-сервера устанавливается только на время обработки запроса и становится равным при­оритету процесса–клиента.

Сетевой интерфейс в системе QNX является неотъемлемой частью ядра. Он, ко­нечно, взаимодействует с сетевым адаптером через сетевой драйвер, но базовые сетевые сервисы реализованы на уровне ядра. При этом передача сообщения процессу, находящемуся на другом компьютере, ничем не отличается с точки зрения приложения от передачи сообщения процессу, выполняющемуся на том же компьютере. Благодаря такой организации сеть превращается в однородную вычислительную среду. При этом для большинства приложений не имеет зна­чения, с какого компьютера они были запущены, на каком исполняются и куда поступают результаты их работы. Такое решение принципиально отличает QNX от остальных ОС, которые тоже имеют все необходимые средства для работы в сети, и делает системы, работающие под её управлением, по-настоящему рас­пределёнными.

Все сервисы QNX, не реализованные непосредственно в ядре, работают как стандартные процессы в полном соответствии с основными концепциями микроядерной архитектуры. С точки зрения операционной системы системные про­цессы ничем не отличаются от всех остальных. Как, впрочем, и драйверы уст­ройств. Единственное, что нужно сделать, написав новый драйвер устройства в QNX, чтобы он стал частью операционной системы, – это изменить конфигура­ционный файл системы так, чтобы драйвер запускался при загрузке.