1.4. Обзор операционной системы реального времени QNX 4.25
Разработка комплекса программного обеспечения для создания отказоустойчивого кластера производилось для операционной системы реального времени QNX версии 4.25.
QNX — это POSIX-совместимая операционная система реального времени, предназначенная преимущественно для встраиваемых систем. QNX является коммерческим продуктом, то есть проприетарным программным обеспечением, а следовательно требует лицензии для установки на вычислительные машины и комплексы.
Как микроядерная операционная система, QNX основана на идее работы основной части своих компонентов как небольших задач, называемых сервисами. Это отличает ее от традиционных монолитных ядер, в которых ядро операционной системы – одна большая программа, состоящая из большого количества «частей», каждая со своими особенностями. Использование микроядра в QNX позволяет пользователям (разработчикам) отключить любую ненужную им функциональность, не изменяя ядро. Вместо этого можно просто не запускать определённый процесс. Система достаточно небольшая, вместе с этим она считается очень быстрой и должным образом «законченной» (практически не содержащей ошибок).
|
Рисунок 3. Схема архитектуры операционной системы QNX
|
QNX состоит из небольшого ядра, координирующего работу взаимодействующих процессов. Как показано на рисунке 3, структура больше напоминает не иерархию, а команду, в которой несколько игроков одного уровня взаимодействуют между собой и со своим "защитником" - ядром.
Микроядро операционной системы выполняет основные следующие функции:
передача сообщение – микроядро обеспечивает маршрутизацию всех сообщений между всеми процессами в системе;
диспетчеризация – планировщик - это часть микроядра, и он получает управление всякий раз, когда процесс изменяет свое состояние в результате получения сообщения или прерывания.
В отличие от всех остальных процессов, ядро никогда не получает управления в результате диспетчеризации. Входящий в состав ядра код выполняется только в результате прямых вызовов из процесса или аппаратного прерывания.
Все функции операционной системы, за исключением тех, которые выполняются ядром, в QNX предоставляются через стандартные процессы. Типичная конфигурация QNX имеет следующие системные процессы:
менеджер процессов;
менеджер файловой системы;
менеджер устройств;
менеджер сети.
Для разработки требуемого комплекса программного обеспечения важен принцип работы менеджера процессов, позволяющего производить межпроцессное взаимодействие через специальный механизм связи через сообщения QNX.
Менеджер процессов тесно взаимодействует с Микроядром, чтобы обеспечить услуги, составляющие сущность операционной системы. Хотя он и является единственным процессом, который использует то же адресное пространство, что и Микроядро, Менеджер процессов выполняется как истинный процесс. И он, как и все остальные процессы, подвергается диспетчеризации со стороны Ядра и использует предоставляемые Микроядром примитивы передачи сообщений для связи с другими процессами в системе.
Менеджер процессов отвечает за создание новых процессов в системе и за управление основными ресурсами, связанными с процессом. Все эти услуги предоставляются посредством сообщений. Так, например, если процесс хочет породить новый процесс, он делает это, посылая сообщение с указанием атрибутов создаваемого процесса. Обратите внимание, что т.к. сообщения передаются по сети, вы можете легко создать процесс на другом узле сети, послав сообщение Менеджеру процессов на этом узле.
Любому процессу, запускаемого в системе присваивается свой идентификационный номер – pid, который можно определить для каждого процесса системной функцией. После определения pid требуемого процесса, ему можно отравлять запросы. Стоит отметить, что при этом формат данных запроса должен полностью совпадать с форматом данных, используемых в запрашиваемом процесса.
Микроядро QNX поддерживает три важнейшие формы связи между процессами: сообщения, прокси и сигналы.
Сообщения - это основополагающая форма IPC в QNX. Они обеспечивают синхронную связь между взаимодействующими процессами, когда процессу, посылающему сообщение, требуется получить подтверждение того, что оно получено и, возможно, ответ.
Прокси - это особый вид сообщения. Они больше всего подходят для извещения о наступлении какого-либо события, когда процессу, посылающему сообщение, не требуется вступать в диалог с получателем.
Сигналы - это традиционная форма IPC. Они используются для асинхронной связи между процессами.
Для непосредственной связи друг с другом взаимодействующие процессы используют встроенные в систему функции языка программирования Си (табл. 2).
Функция языка Си
|
Назначение
|
Send()
|
посылка сообщений
|
Receive()
|
получение сообщений
|
Reply()
|
ответ процессу, пославшему сообщение
|
Таблица 2. Функции взаимодействия процессов
Однако рассмотренные выше функции работают с сообщениями, состоящими из непрерывной последовательности байт. На практике сообщения часто состоят из двух или более отдельных частей. Например, сообщение может иметь заголовок фиксированной длины, за которым следуют данные переменной длины. Для того чтобы избежать копирования частей такого сообщения во временные промежуточные буферы при передаче или приеме, может быть использовано составное сообщение, состоящее из двух или более отдельных буферов сообщений. Именно благодаря этой возможности менеджеры ввода/вывода QNX, такие как Dev и Fsys, достигают своей высокой производительности.
Следующие функции позволяют обрабатывать составные сообщения: Creceivemx(), Readmsgmx(), Receivemx(), Replymx(), Sendmx(), Writemsgmx(). Некоторые из них будут использоваться в блоке взаимодействия программного обеспечения с драйвером и со сторонним программным обеспечением. При этом составные сообщения описываются с помощью встроенной mx структуры.
1.4.1. Обзор технологий QNX 4.25 для создания кластерного программного комплекса
Операционная система реального времени QNX 4.25 изначально не располагает функциями параллельных вычислений и не предусматривает встроенных технологий резервирования данных между узлами кластерной сети. Однако, сама система предоставляет очень гибкие возможности для работы в сети. Это связано с тем, что в QNX реализован специальный механизм обмена сообщениями между процессами. Причем место работы процесса не имеет значения, т.к. каждый процесс, запущенный на узле, включенном в сеть, будет занесен в глобальную таблицу, используя которую любой другой процесс, как локальный, так и нет, сможет обратиться к первому. Таким образом, объединив узлы в сеть, появляется возможность мгновенного обмена сообщениями между узлами, а также между процессами одного узла. Именно за счет этой особенности рассматриваемое в данном дипломном проекте программное обеспечение может быть запущено с любого из узлов кластера, при этом никаких различий от запусков и работы с других узлов в системе не будет. Также, используя глобальную таблицу процессов, появляется возможность работы с удаленного терминала, подключенного к сети и удаляемого из нее после конфигурации кластера.
Еще одной особенностью, способствующей созданию кластера именно на QNX, является система мгновенных ответов и оповещений процессами друг друга, позволяющей моментально понять, находится процесс, к которому идет обращение, в работе, не активен или завис. Это позволяет свести время реакции программы на возникновение сбоев при выполнении к возможному минимуму, увеличив таким образом надежность системы в целом.
|
