Операционная система реального времени QNX

Размещено на http://www.allbest.ru/

Введение

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

Системы реального времени могут использоваться не только на промышленных производствах, но и в различных других областях деятельности человека. Например, в охранных системах, в системах медицинской электроники, в различных системах контроля протекания процессов (допустим, контроль протекания научных экспериментов) и т.д. Системы, применяемые во всех перечисленных областях должны иметь минимальный размер, так как они обычно выполняются в виде отдельного устройства. Зачастую устройства, содержащие подобные системы, имеют набор весьма специфического периферийного оборудования, такого как устройства ввода и отображения информации и т.д. Вследствие этого, в дополнение к минимальным размерам, система должна корректно работать с разного рода специфическим оборудованием. Таких требований к системам реального времени довольно много, и все перечислить просто нет возможности, поэтому мы остановимся только на одном, наиболее важном.

Основные принципы, которые позволяют создавать операционные системы реального времени:

§ Многозадачность - очевидно, что варианты с псевдомногозадачностью (как в системах Windows 3x и Novell Net Ware) неприемлемы, поскольку допускают возможность блокировки или даже полного развала системы одним неправильно работающим процессом. Для предотвращения блокировок вычислений операционная система реального времени должна использовать квантирование времени (то есть использовать вытесняющую, а не кооперативную многозадачность). Как известно, основная проблема, возникающая при создании многозадачных систем - это проблема планирования (диспетчеризации) выполнения задач в системе. Т.е. в любую многозадачную систему должен быть встроен механизм, обеспечивающий устойчивое взаимодействие между задачами, переключение системы между задачами, создание новых задач в системе и уничтожение отработавших задач, без последствий для работы остальной системы. Каждая система использует свой метод диспетчеризации, но наиболее популярные методы - это методы, основанные на приоритетах задач. Суть метода состоит в следующем: каждая задача при запуске получает некоторый приоритет, и в зависимости от используемого в системе алгоритма и приоритета, задача выбирается на исполнение.

§ Организация надежных вычислений - может быть эффективно решена за счет использования специальных аппаратных возможностей процессора.

§ Поддержка сетевых коммуникаций.

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

§ Желательно чтобы операционная система поддерживала многопоточность (не только мультипрограммный, но и мультизадачный режим).

§ Система должна быть способна работать на ограниченных аппаратных ресурсах, поскольку одна из основ ее применения - встроенные системы.

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

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

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

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

В данной курсовой работе рассматривается операционная система реального времени QNX.

1. Общие сведения об операционной системе QNX

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

Основным языком программирования в системе является C. Основная операционная система соответствует стандарту POSIX. Это позволяет с небольшими доработками переносить ранее разработанное программное обеспечение в QNX для организации работы в среде распределенной обработки.

Операционная система QNX будучи сетевой и мультизадачной, в то же время является многопользовательской. Кроме того, она масштабируема. С точки зрения пользовательского интерфейса и интерфейса прикладного программирования она очень похожа на Unix, поскольку выполняет требования стандарта POSIX. Однако QNX - это не версия Unix. Она была разработана «с нуля» канадской фирмой QNX Software Systems Limited в 1989 году по заказу министерества обороны США, причем соверщенно на иных архитектурных принципах, нежели использовались при создании Unix. За свою 15-летнюю историю она имеет сотни тысяч инсталляций во многих странах мира. Среди пользователей QNX значатся такие компании, как Du Pont, Eastman Kodak, General Mills, General Motors, Motorola, Texaco. Представительства и дистрибьюторы фирмы существуют более чем в 60 странах мира, в том числе в России.

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

1.1 Версии QNX

§ QNX 2.x - это ОС, выпущенная фирмой QSSL в середине 80-х. В настоящее время практически не применяется.

§ QNX 4.2x - наиболее популярная до последнего времени ОС, она же наиболее распространена в России. С ее помощью построено очень много встраиваемых систем, систем SCADA, она очень успешно применяется в решениях задач автоматизации и управления, там где необходима высокая надежность. Эта система была разработана специально для "mission critical appliances" - то есть для применения в критических ситуациях, там где на другие операционные системы нельзя рассчитывать.

§ Neutrino - это новое поколение систем реального времени, поcтpоенных на идеях и аpхитектypе QNX. Realtime Platform (RtP) - cвободно pаcпоcтpаняемый ваpиант QNX Neutrino, котоpый можно cвободно иcпользовать в некоммеpчеcких целях. То есть ее можно беcплатно иcпользовать для теcтиpования, опpобиpования идей, pазpаботки freeware и для пеpcонального пpименения.

Neutrino изначально задyмывалаcь как операционная система для глyбоко вcтpаиваимых cиcтем, вcе делалоcь c тем pаcчетом, чтобы она могла гpyзитьcя откyда yгодно (хоть из постоянного запоминающего устройства), должна pаботать на большом pазнообpазии компьютеpных аpхитектyp. Поэтомy изменена cиcтема загpyзки. Тепеpь вмеcто отдельного ядpа c оcновными пpоцеccами и cкpипта sysinit вcе заделано в один загpyжаемый модyль. Пpичем cиcтема полyчилаcь наcтолько гибкой, что даже можно обойтиcь без менеджеpа пpоцеccов, еcли они не нyжны, оcтавив только одно микpоядpо. В RtP pеализована загpyзка чеpез diskboot, добавлена cиcтема pепозитаpиев. Следует отметить революционную концепцию наноядра, размером всего в 32 Кб.

1.2 Достоинства QNX

§ Предсказуемость - применимость системы к задачам жесткого реального времени. QNX является операционной системой, которая дает гарантию того, что процесс с наивысшим приоритетом начнет выполняться практически немедленно, а критически важное событие никогда не будет потеряно.

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

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

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

Эта технология выражается в следующих принципах.

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

Пользователю нет никакой необходимости вникать в сетевой протокол, который, кстати, не является тайной, вплоть до его структуры. Он содержит пакеты, которые применяются также и для передачи сообщений. Сетевой администратор распознает эти пакеты и переправляет их микроядру, которое, в свою очередь, переправляет их в шину локальных сообщений. QNX способна распознавать не только пакеты сообщений QNX-процессов. Вы можете легко обращаться к сетевому администратору для передачи таких пакетных протоколов, как TCP/IP, SMB и других. Возможно обращение к различным сетевым администраторам через один кабель. Операционная система QNX объединяет всю сеть персональных компьютеров в единый набор ресурсов с абсолютной прозрачностью доступа к ним. Узлы могут добавляться и исключаться из сети, не влияя на целостность системы. Сетевая обработка данных в QNX является гибкой настолько, что вы можете объединить в одну сеть любой разнородный набор Intel совместимых компьютеров, соединенных через Arcnet, Ethernet, Token Ring или через последовательный порт, к которому также может быть подключен модем. Причем возможно участие компьютера одновременно в 3 сетях, и если одна из них окажется перегруженной или выйдет из строя, то QNX автоматически будет использовать другие доступные сети без потери информации.

§ Компактная графическая система Photon, построенная на тех же принципах модульности, что и сама операционная система, позволяет получить полнофункциональный интерфейс GUI, работающий с POSIX-совместимой операционной системой всего в 4 Мегабайтах памяти начиная с i80386 процессора.

Исходники системы открыты лишь в необходимом для разработчика количестве. Так например "сердце" системы - ядро и основные менеджеры закрыты, дабы сохранить "целостность" системы. Открыты драйвера устройств и некоторые графические приложения.

Она была создана для yпpавления технологическими пpоцессами (напpимеp, конфетной фабpикой), втоpое пpизвание QNX - встpоенные системы (напpимеp, стиpальная машина). Эти обязанности поpyчили QNX потомy что она является надежной, маленькой и является операционной системой реального времени.

Ресурсов баз данных в QNX тоже более чем достаточно. В качестве представителя сетевых баз выступает db_Vista, а реляционные базы представлены продуктами Watcom SQL и Faircom C-tree. Для любителей dBase существует полностью совместимая со стандартом dBase III/IV база данных OnCmd,которая по причине совместимости с упомянутым пакетом работает недостаточно быстро для QNX, хотя значительно быстрее, чем в DOS. Последнее достижение фирмы Empress - одноименная база данных, которая предоставляет возможности, близкие к Oracle.

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

2. Архитектура операционной системы QNX

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

Микроядро QNX имеет объем в несколько десятков килобайт (в разных версиях 10Кб, 32Кб и 46Кб). В этом объеме совершаются:

§ связь между процессами (IPC). Ядро обеспечивает три формы IPC (сообщения, proxy (прокси) и сигналы);

§ сетевое взаимодействие нижнего уровня. Ядро передает все сообщения, предназначенные процессам на другом узле;

§ планирование процессов. Планировщик ядра определяет, какой процесс будет выполняться следующим;

§ первичную обработку прерываний. Все прерывания и сбои аппаратного обеспечения сначала обрабатываются в ядре, а затем передаются соответствующему драйверу или системному администратору.

Рисунок 1. Микроядро.

Ядро QNX поддреживает три типа связи между процессами: сообщениями, proxy и сигналами.

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

Связь посредством proxy представляет собой особый вид передачи сообщений. Этот вид связи специально предназначен для оповещения о событиях, при которых процесс-отправитель не нуждается во взаимодействии с процессом-получателем.

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

2.1 Связь между процессами посредством сообщений

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

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

Для прямой связи друг с другом взаимодействующие процессы используют следующие функции языка C:

Таблица 1. Функции языка C для связи процессов.

C-функция	Назначение
Send ()	Для посылки сообщений;
Receive ()	Для приема сообщений;
Reply ()	Для ответа процессу, пославшему сообщение.

Эти функции могут использоваться локально или по всей сети.

Для прямой связи процессов друг с другом необязательно использование функций Send(), Receive() и Reply(). Система библиотечных функций QNX надстроена над системой обмена сообщениями, поэтому процессы могут использовать передачу сообщений косвенно при использовании стандартных сервисных средств, например программных каналов.

Рисунок 2. Процесс А посылает сообщение процессу В.

Самый простой пример взаимодействия двух процессов с использованием функций Send(), Receive() и Reply() состоит в следующем:

1. Процесс А посылает сообщение процессу В, выдав ядру запрос Send(). С этого момента процесс А становится SEND-блокированным до тех пор, пока процесс В не выдаст Receive(), подтверждая получение сообщения.

2. Процесс В выдает Receive() процессу А, ожидающему сообщения. Процесс А изменяет свое состояние на REPLY-блокированное. поскольку от процесса В ожидается сообщение, он не блокируется. Если бы процесс В выдал Receive() до отправления ему сообщения, он оставался бы RECEIVE-блокированным до момента приема сообщения. В этом случает процесс А (отправитель) перешел бы сразу в REPLY-блокированное состояние после отправления сообщения процессу В.

3. Процесс В выполняет необходимую обработку, определяемую полученным от процесса А сообщением, и выдает Reply(). Процесс А получает ответное сообщение и разблокировывается. Процесс В тоже разблокировывается. Какой из процессов начнет выполняться первым, зависит от их относительных приоритетов.

Передача сообщений служит не только для обмена данными, но и для синхронизации выполнения нескольких взаимодействующих процессов. Рассматривая пример, приведенный выше: после того, как процесс А выдаст запрос Send(), он не может выполняться до тех пор, пока не получит ответное сообщение. Это служит гарантией того, что обработка данных, выполняемая процессом В для процесса А завершится до того, как процесс А сможет продолжить свою работу. В свою очередь процесс В после выдачи запроса Receive() может продолжать свою работу до поступления другого сообщения.

Блокировка - состояние, когда выполнение процесса запрещено до момента завершения некоторой части протокола обмена сообщениями.

Таблица 2. Состояния блокировок процессов.

Если процесс выдал	Процесс является
Запрос Send(), и отправленное им сообщение еще не получено процессом-получателем	SEND-блокированным
Запрос Send(), и отправленное им сообщение получено процессом-получателем, но ответ еще не выдан	REPLY-блокированным
Запрос Receive(), но сам еще не получил сообщение	RECEIVE-блокированным

2.1.1 Использование функций Send(), Receive() и Reply()

Использование функции Send().

Предположим, что процесс А выдает запрос на передачу сообщения процессу В. Запрос оформляется вызовом функции Send():

Send (pid, smsg, rmsg, smsg_bn, rmsg_len);

Функция Send() имеет следующие аргументы:

pid - идентификатор процесса-получателя сообщения (то есть процесса В);

pid - это идентификатор, посредством которого процесс опознается операционной системой и другими процессами;

smsg - буфер сообщения (т.е. посылаемого сообщения);

rmsg - буфер ответа (в который помещается ответ процесса В);

smsg_len - длина посылаемого сообщения;

rmsg_len - максимальная длина ответа, который должен получить процесс А.

В сообщении будет передано не более, чем smsg_len байт и принято в ответе не более, чем rmsg_len байт, - это служит гарантией того, что буферы никогда не будут переполнены.

Использование функции Receive().

Процесс В может принять запрос Send(), выданный процессом А, с помощью функции Receive():

pid = Receive (0, msg, msg_len);

Функция Receive() имеет следующие аргументы:

pid - идентификатор процесса, пославшего сообщение (то есть процесса А);

0 - (ноль) указывает на то, что процесс В готов принять сообщение от любого процесса;

msg - буфер, в который будет принято сообщение;

msg_len максимальное количество байт данных, которое может поместиться в приемном буфере.

В том случае, если значения smsg_len в функции Send() и msg_len в функции Receive() различаются, то количество передаваемых данных будет определяться наименьшим из них.

Использование функции Reply().

После успешного приема сообщения от процесса А процесс В должен ответить ему, используя функцию Reply():

Reply (pid, reply, reply_len)

Функция Reply имеет следующие аргументы:с от процесса А сообщением, и выдает щения. причем задачи могут

pid - идентификатор процесса, которому направляется ответ (то есть процесса А);

reply - буфер ответа;

reply_len - длина сообщения, передаваемого в ответе.

Если значения reply_len в функции Reply() и rmsg_len в функции Send() различаются, то количество передаваемых данных определяется наименьшим из них.

Reply-управляемая передача сообщений:

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

Существует еще и другой, менее распространенный, чем Send-управляемый, но в отдельных случаях более предпочтительный способ передачи сообщений, а именно Reply-управляемый, при котором работа инициируется функцией Reply(). В соответствии с этим способом "рабочий" процесс посылает сообщение обслуживающему процессу, указывая на то, что он готов к работе. Обслуживающий процесс фиксирует, что "рабочий" процесс послал ему сообщение, но не отвечает ему немедленно. Через некоторое время обслуживающий процесс может ответить "рабочему" процессу. "Рабочий" процесс выполняет свою работу, а затем, завершив ее, посылает обслуживающему процессу сообщение, содержащее результаты.

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

§ При выдаче запроса Reply() данные, содержащиеся в ответном сообщении, передаются от отвечающего процесса REPLY-блокированному процессу за одну операцию. Функция Reply() не блокирует отвечающий процесс, так как REPLY-блокированный процесс разблокировывается сразу после того, как данные скопируются в его адресное пространство.

§ Процессу-отправителю нет никакой необходимости "знать" что-либо о состоянии процесса-получателя, которому он посылает сообщение. В том случае, если процесс-получатель будет не готов к приему сообщения, то процесс-отправитель после отправления сообщения просто перейдет в SEND-блокированное состояние.

§ При необходимости любой процесс может посылать сообщение нулевой длины, ответ нулевой длины, либо то и другое.

§ С точки зрения разработчика выдача запроса Send() обслуживающему процессу - это практически то же самое, что и обращение к библиотеке подпрограмм. В обоих случаях разработчик формирует некоторые наборы данных, а затем выдает Send() или обращается к библиотечной функции. После этого, между двумя определенными точками программы Receive() и Reply() - в одном случае, либо между входом функции и оператором return - в другом, управление передается сервисным программам, при этом ваша программа ожидает завершения их выполнения. После того как сервисные программы отработали, ваша программа "знает", где находятся результаты их работы, и может затем анализировать коды ошибок, обрабатывать результаты и т.д.

§ Несмотря на это кажущееся сходство, процесс передачи сообщения намного сложнее обычного вызова библиотечной функции. Например, Send() может по сети обратиться к другой машине, где действительно будет выполняться сервисная программа. Кроме того, может быть организована параллельная обработка данных без создания нового процесса. Обслуживающий процесс выдает Reply(), позволяя вызывающему процессу продолжать выполняться, и затем продолжает свою работу.

§ Несколько процессов могут посылать сообщения одному процессу. Обычно процесс-получатель принимает сообщения в порядке их поступления, однако, может быть установлен режим приема сообщений в порядке приоритетов процессов-отправителей, представленный на рисунке 3.

Рисунок 3. Режим приемов сообщений в порядке приоритетов.

2.1.2 Дополнительные возможности передачи сообщений

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

§ условный прием сообщений;

§ чтение и запись части сообщения;

§ передача составных сообщений.

Условный прием сообщений.

Обычно для приема сообщения используется функция Receive(). Этот способ приема сообщений в большинстве случаев является наиболее предпочтительным.

Однако, иногда процессу требуется предварительно "знать", было ли ему послано сообщение, чтобы не ожидать поступления сообщения в RECEIVE-блокированном состоянии. Например, процессу требуется обслуживать несколько высокоскоростных устройств, не способных генерировать прерывания, и кроме того, процесс должен отвечать на сообщения, поступающие от других процессов. В этом случае используется функция Creceive(), которая считывает сообщение, если оно становится доступным, или немедленно возвращает управление процессу, если нет ни одного отправленного сообщения.

По возможности следует избегать использования функции Creceive(), так как она позволяет процессу непрерывно загружать процессор на соответствующем приоритетном уровне.

Чтение или запись части сообщения.

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

Например, администратор ввода/вывода может принимать для записи сообщения, состоящие из заголовка фиксированной длины и переменного количества данных. Заголовок содержит значение количества байт данных (от 0 до 64 Кбайт). Администратор ввода/вывода может принимать сначала только заголовок, а затем, используя функцию Readmsg(), считывать данные переменной длины в соответствующий буфер. Если количество посылаемых данных превышает размер буфера, администратор ввода/вывода может вызывать функцию Readmsg() несколько раз, передавая данные по мере освобождения буфера. Аналогично, функцию Writemsg() можно использовать для сбора и копирования данных в буфер отправителя по мере его освобождения, снижая таким образом требования к размеру внутреннего буфера администратора ввода/вывода.

Передача составных сообщений.

До сих пор мы рассматривали сообщения как единый пакет байтов. Однако, как правило, сообщения состоят из нескольких дискретных частей. Например, сообщение может иметь заголовок фиксированной длины, за которым следуют данные переменной длины. Для того, чтобы части сообщения эффективно передавались и принимались без копирования во временный рабочий буфер, составное сообщение может формироваться в нескольких раздельных буферах. Этот метод позволяет администраторам ввода/вывода системы QNX Dev и Fsys, обеспечивать высокую производительность.

Для работы с составными сообщениями используются следующие функции:

§ Creceivemx()

§ Readmsgmx()

§ Receivemx()

§ Replymx()

§ Sendmx()

§ Writemsgmx()

Рисунок 4. Составное сообщение может быть описано с помощью управляющей структуры. Ядро собирает части сообщения в единый поток данных.

Зарезервированные коды сообщений:

Все сообщения в системе QNX начинаются с 16-битового слова, которое называется кодом сообщения. Системные процессы QNX используют следующие коды сообщений:

Таблица 3. Коды системных сообщений в QNX.

0X0000 - 0X00FF	сообщения Администратора процессов;
0X0100 - 0X01FF	сообщения ввода/вывода (для всех обслуживающих программ);
0X0200 - 0X02FF	сообщения Администратора файловой системы;
0X0300 - 0X03FF	сообщения Администратора устройств;
0X0400 - 0X04FF	сообщения Сетевого администратора;
0X0500 - 0X0FFF	зарезервировано для системных процессов, которые могут появиться в будущем.

2.2 Связь между процессами посредством proxy

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

Благодаря использованию proxy, процесс или обработчик прерываний может послать сообщение другому процессу, не блокируясь и не ожидая ответа. Ниже приведены некоторые примеры использования proxy:

§ процесс оповещает другой процесс о наступлении некоторого события, не желая при этом оставаться SEND-блокированным до тех пор, пока получатель не выдаст Receive() и Reply();

§ процесс посылает данные другому процессу, но не требует ни ответа, ни другого подтверждения о том, что получатель принял сообщение;

§ обработчик прерываний оповещает процесс о том, что некоторые данные доступны для обработки.

Proxy создаются с помощью функции qnx_proxy_attach(). Любой процесс или обработчик прерываний, которому известен идентификатор proxy, может воспользоваться функцией Trigger() для того, чтобы выдать заранее определенное сообщение. Запросами Trigger() управляет ядро.

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

Рисунок 5. Обслуживаемый процесс трижды обратился к proxy, в результате чего обслуживающий процесс получил три "законсервированных" сообщения от proxy.

2.3 Связь между процессами посредством сигналов

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

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

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

Таблица 4. Работа с сигналами в QNX.

Если вы хотите	Используйте
Сгенерировать сигнал из интерпретатора Shell	Утилиты kill или slay
Сгенерировать сигнал из процесса	Функции kill() или raise()

В зависимости от того, каким образом был определен способ обработки сигнала, возможны три варианта его приема:

1. Если процессу не предписано выполнять каких-либо специальных действия по обработке сигнала, то по умолчанию поступление сигнала прекращает выполнение процесса;

2. Процесс может проигнорировать сигнал. В этом случае выдача сигнала не влияет на работу процесса (обратите внимание на то, что сигналы SIGCONT, SIGKILL и SIGSTOP не могут быть проигнорированы при обычных условиях);

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

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

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

Таблица 5. Стандартные сигналы.

Таблица 6. Сигналы, управляющие работой процессов.

Таблица 7. Специальные сигналы QNX.

Таблица 8. Исторически оставшиеся сигналы Unix.

Условные обозначения:

* обслуживающий процесс может "защитить" себя от этого сигнала посредством функции qnx_pflags(). Для этого обслуживающий процесс должен иметь уровень суперпользователя;

** процесс завершается в случае возникновения второго сбоя во время обработки процессом первого;

*** этот сигнал оставлен для исторической совместимости с некоторыми версиями системы UNIX, он не генерируется никакими компонентами системы QNX.

2.3.1 Обработка сигналов

Для задания способа обработки сигнала следует воспользоваться функцией ANSI C signal() или функцией POSIX sigaction().

Функция sigaction() предоставляет больше возможностей по управлению средой обработки сигнала.

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

Отметим некоторые особенности работы процессов, которые "ловят" сигналы с помощью обработчика сигналов.

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

Если процессу не требуется возврата управления от обработчика сигналов в прерванную точку, то в этом случае в обработчике сигналов может быть использована функция siglongjmp() или longjmp(). Причем siglongjmp() предпочтительнее, т.к. в случае использования longjmp() сигнал остается блокированным.

Рекомендуемые функции для обработчиков сигналов.

Приведенные ниже библиотечные функции стандартов POSIX и ANSI C рекомендуются к использованию в обработчиках сигналов. Не следует пытаться использовать другие библиотечные функции, так как результаты этого могут быть непредсказуемы. Функции пользователя, используемые в вашей программе, должны быть обязательно повторно входимыми.

_exit() getegid() rmdir() tcdrain()

access() geteuid() setgid() tcflow()

alarm() getgid() setpgid() tcflush()

cfgetispeed() getgroups() setsid() tcgetattr()

cfgetospeed() getpgrp() setnid() tcgetpgrp()

cfsetispeed() getpid() sigaction() tcsendbreak()

cfsetospeed() getppid() sigaddset() tcsetattr()

chdir() getuid() sigdelset() tcgetgrp()

chmod() kill() sigemptyset() time()

chown() link() sigfillset() times()

close() lseek() sigismember() umask()

creat() mkdir() signal() uname()

dup2() mkfifo() sigpending() unlink()

dup() open() sigprocmask() ustat()

execle() pathconf() sigsuspend() utime()

execve() pause() slup() wait()

fcntl() pipe() stat() waitpid()

fork() read() sysconf() write()

fstat() rename()

Блокировка сигналов.

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

Во время работы обработчика сигналов QNX автоматически блокирует обрабатываемый сигнал. Это означает, что не требуется организовывать вложенные вызовы обработчика сигналов. Каждый вызов обработчика сигналов непрерываем остальными сигналами данного типа. При нормальном возврате управления от обработчика, сигнал автоматически разблокируется.

В некоторых версиях системы UNIX работа с обработчиком сигналов организована некорректно, так как в них не предусмотрена блокировка сигналов. В результате в некоторых приложениях, работающих под управлением UNIX, используется функция signal() внутри обработчика прерываний с целью "перевзвода" обработчика. В этом случае может возникнуть одна из двух аварийных ситуаций. Во-первых, если другой сигнал поступает, во время работы обработчика, но вызова функции signal() еще не было, то программа будет снята с обработки. Во-вторых, если сигнал поступает сразу же после вызова обработчиком функции signal(), то обработчик будет запускаться рекурсивно. В QNX выполняется блокировка сигналов, поэтому указанные выше проблемы не могут возникнуть. Нет необходимости вызывать signal() из обработчика. Если требуется выйти из любой точки обработчика, то следует воспользоваться функцией siglongjmp().

Сигналы и сообщения.

Существует важная взаимосвязь между сигналами и сообщениями. Если при генерации сигнала ваш процесс окажется SEND-блокированным или RECEIVE-блокированным (причем имеется обработчик сигналов), то будут выполняться следующие действия:

1. процесс разблокировывается;

2. выполняется обработка сигнала;

3. функции Send() или Receive() возвращают управление с кодом ошибки.

Если процесс был SEND-блокированным, то проблемы не возникает, так как получатель не получит сообщение. Но если процесс был REPLY-блокированным, то неизвестно, было обработано отправленное сообщение или нет, а следовательно неизвестно, нужно ли еще раз выдавать Send().

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

1. нормально завершить первоначальный запрос: отправитель будет уведомлен о том, что сообщение было обработано надлежащим образом;

2. освободить все закрепленные ресурсы и возвратить управление с кодом ошибки, указывающим на то, что процесс был разблокирован сигналом: отправитель получит чистый код ошибки.

Когда обслуживающий процесс сообщает другому процессу, что он SIGNAL-блокирован, сигнал выдается немедленно после возврата управления функцией Send().

2.4 Связь между процессами в сети

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

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

Виртуальные каналы (ВК) способствуют эффективному использованию ресурсов во всей сети QNX по нескольким причинам:

1. при создании виртуального канала имеется возможность задать работу с сообщениями определенной длины: это означает, что вы можете распределить ресурсы для обработки сообщения. Тем не менее, если потребуется послать сообщение, длина которого превышает максимально заданную, виртуальный канал автоматически изменит установленный максимальный размер буфера в соответствии с длиной передаваемого сообщения;

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

3. если процесс подключается к существующему разделенному виртуальному каналу и запрашивает размер буфера больший, чем тот, который используется в данное время, размер буфера автоматически увеличивается;

4. когда процесс завершается, все связанные с ним виртуальные каналы освобождаются.

операционный система реальный время

2.4.1 Виртуальные процессы

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

Например, на рисунке 6 виртуальный канал соединяет процессы PID1 и PID2. На узле 20, где находится PID1, VID2 представляет PID2. На узле 40, где находится PID2, VID1 представляет PID1. PID1 и PID2 могут относиться к виртуальному процессу на своем узле, как к любому другому локальному процессу: посылать и принимать сообщения, выдавать сигналы, ожидать и т.п. Так, например, PID1 может послать сообщение к VID на своем конце виртуального канала, которое будет передано по сети к VID на другом конце виртуального канала, представляющему там PID1. Там VID1 передает сообщение PID2.

Рисунок 6. Связь в сети посредством виртуальных каналов.

Каждый VID обеспечивает соединение, которое содержит следующую информацию:

§ локальный pid;

§ удаленный pid;

§ удаленный nid (идентификатор узла);

§ удаленный vid.

Если приложению требуется, например, получить доступ к удаленному ресурсу ввода/вывода, то виртуальный канал создается вызываемой библиотечной функцией open(). Приложения непосредственно не участвуют в создании или использовании виртуального канала. Если приложение определяет нахождение обслуживающего его процесса с помощью функции qnx_name_locate(), то виртуальный канал создается автоматически при вызове функции. Для приложения виртуальный канал просто отождествляется с PID.

Существует несколько причин, по которым процесс не может осуществлять связь по установленным виртуальным каналам, а именно:

§ произошло отключение питания компьютера, на котором выполняется процесс;

§ был отсоединен кабель сети от компьютера;

§ был завершен удаленный процесс, с которым установлена связь.

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

На каждом узле Администратор процессов проверяет целостность виртуального канала. Это делается следующим образом:

1. Каждый раз при успешной передаче по виртуальному каналу, обновляется временная метка, связанная с данным виртуальным каналом, для фиксации времени последней активности;

2. Через интервалы времени, устанавливаемые при инсталляции, Администратор процессов просматривает каждый виртуальный канал. В том случае, если в виртуальном канале нет активности, Администратор процессов посылает сетевой пакет проверки целостности канала Администратору процессов другого узла;

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

4. Если попытки восстановления закончились безуспешно, виртуальный канал "отключается". Все процессы, блокированные на данном канале, переходят в состояние ГOTOB (READY). (Процессы анализируют возвращаемый код сбоя виртуального канала.)

Для управления параметрами, связанными с проверкой целостности виртуального канала, используется утилита netpoll.

2.5 Планирование процессов

Планировщик ядра запускается в следующих случаях:

§ после разблокировки процесса;

§ по истечении временного кванта для выполняющегося процесса;

§ после выгрузки выполняющегося процесса.

В системе QNX каждому процессу присваивается приоритет. Планировщик выбирает для выполнения процессы, находящиеся в состоянии ГОТОВ, в соответствии с их приоритетами. (Центральный процессор может использовать только процесс, находящийся в состоянии ГОТОВ.) Для выполнения выбирается процесс, имеющий наивысший приоритет.

Рисунок 7. Пример выполнения процессов в соответствии с приоритетом.

Процессам присваиваются приоритеты в диапазоне от 0 (низший) до 31 (высший). По умолчанию процесс наследует приоритет от породившего его процесса; обычно он равен 10 для приложений, запускаемых из интерпретатора Shell.

Таблица 9. Работа с приоритетами процессов в QNX.

Если вы хотите	Используйте
Определить приоритет процесса	Функцию getprio()
Задать приоритет процессу	Функцию setprio()

2.5.1 Методы планирования

Для удовлетворения потребностей разных приложений в системе QNX реализованы три метода планирования:

§ планирование по принципу простой очереди (первым пришел_

§ первым обслужен);

§ круговой метод планирования;

§ адаптивное планирование.

Каждый процесс в системе может выполняться, используя любой из этих методов. Они эффективны применительно к одному процессу, а не ко всем процессам на узле.

Данные методы планирования используются только тогда, когда два или более процессов, разделяющих один и тот же приоритет, находятся в состоянии ГОТОВ (то есть процессы непосредственно конкурируют друг с другом). Если в состояние ГОТОВ переходит процесс, имеющий более высокий приоритет, он немедленно выгружает все процессы с меньшим приоритетом.



Рисунок 8. Очередь процессов.

Метод планирования наследуется от порождающего процесса, однако, он может быть изменен

Таблица 10. Функции для работы с планированием процессов в QNX.

Если вы хотите	Используйте
Определить метод планирования для процесса	Функцию getscheduler()
Установить метод планирования для процесса	Функцию setscheduler()

Планирование по принципу простой очереди.

При планировании по принципу простой очереди процесс, выбранный для выполнения, продолжает работать до тех пор, пока он:

§ не передаст управление сам (например, блокируется);

§ не будет снят с выполнения (выгружен из памяти) процессом с более высоким приоритетом.

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

Круговой метод планирования.

При круговом методе планирования процесс, выбранный для выполнения, продолжает работать до тех пор, пока он:

§ не передаст управления сам;

§ не будет снят с выполнения (выгружен из памяти) процессом с более высоким приоритетом;

§ не истечет его квант времени (timeslice).

Квант времени - это единица временного интервала, закрепляемая за каждым процессом. По истечении кванта времени, процесс выгружается, и управление передается процессу, находящемуся на том же уровне приоритета в состоянии ГОТОВ. Квант времени равен 100 миллисекундам.

За исключением квантования времени круговой метод планирования идентичен планированию по принципу простой очереди.

Адаптивное планирование.

При адаптивном планировании процесс ведет себя следующим образом:

§ по истечении кванта времени (при условии, что процесс не блокировался), его приоритет уменьшается на 1, если другой процесс с таким же приоритетом находится в состоянии ГОТОВ. Это называется понижением приоритета;

§ если процесс с пониженным приоритетом не выполняется в течение одной секунды, его приоритет повышается на 1 (процесс никогда не может повысить приоритет выше начального);

§ если процесс блокируется, ему немедленно возвращается начальный приоритет.

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

Программы, запущенные из интерпретатора Shell, используют по умолчанию адаптивный метод планирования.



Рисунок 9. Адаптивное планирование.

Приоритет, управляемый клиентом.

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

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

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

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

При выборе для сервера клиентов, управляемых приоритетами следует позаботиться о том, чтобы сообщения доставлялись в порядке приоритетов (а не в порядке времени поступления).

Для установки приоритета, управляемого клиентом, воспользуйтесь функцией qnx_pflags().

2.6 Работа в реальном времени

Как бы нам этого не хотелось, но компьютер не может иметь бесконечное быстродействие. В системе реального времени крайне важно, использовать все циклы работы центрального процессора. Также важно минимизировать интервал времени между возникновением внешнего события и фактическим началом выполнения программы, реализующей ответную реакцию на это событие. Это время называется задержкой или временем ожидания (latency). В системе QNX можно определить несколько типов задержки.