Механизмы реального времени.

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

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

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

Для реализации режима реального времени в ОС РВ используют следующие основные механизмы:

• систему приоритетов и алгоритмы диспетчеризации;

• механизмы межзадачного взаимодействия;

• средства для работы с таймерами.

Система приоритетов и алгоритмы диспетчеризации.

Базовыми инструментами разработки сценария работы системы являются система приоритетов процессов (задач) и алгоритмы планирования (диспетчеризации) ОСРВ.

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

Алгоритмы круговой диспетчеризации в чистом виде в ОСРВ неприменимы. Основной недостаток — непрерывный квант времени, в течение которого процессором владеет только один процесс.

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

Механизмы межзадачного взаимодействия.

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

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

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

Средства для работы с таймерами.

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

Средства работы с таймерами позволяют:

- измерять и задавать различные промежутки времени (от 1 мкс и выше);

- генерировать прерывания по истечении временных интервалов;

- создавать разовые и циклические будильники.

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

Лекция 2. Общая характеристика ОС РВ QNX 6. Структура и концепция ОС РВ QNX 6

QNX6

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

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

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

Концепция QNX

QNX базируется на двух фундаментальных принципах:

• архитектура на основе микроядра;

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

QNX NEUTRINO RTOS v6.2 имеет клиент - серверную архитектуру, состоящую из микроядра и сгруппированных вокруг него взаимодействующих процессов. Микроядро включает в себя только сервисы ядра, такие как нити, сигналы, передача сообщений, синхронизация, планирование заданий и таймер. Микроядро само по себе не подвергается планировке. Его код выполняется только в результате вызова ядра или возникновения аппаратного прерывания.

Дополнительные функциональные возможности осуществляются взаимодействующими процессами, которые действуют как серверные процессы и отвечают на запросы процессов клиентов (например, прикладного процесса). К серверным процессам - менеджер файловой системы, менеджер процесса, менеджер устройств, менеджер сети, и т.д. Ядро запускается на 0 уровне привилегий процессора Intel, менеджеры и драйверы устройств запускаются на уровнях 1 и 2 (для исполнения действий ввода/вывода). Прикладные процессы запускаются на 3 уровне привилегий и поэтому могут выполнять только общие команды процессора.

QNX - операционная система, основанная на передаче сообщений. Обработка передачи сообщений является фундаментальным средством взаимодействия процессов (IPC) в ОС QNX. Она основана на клиент-серверной модели: клиент (например, прикладной процесс) посылает сообщение серверу (например, менеджеру устройства), который возвращает результат. Многие запросы QNX NEUTRINO RTOS API используют данный механизм передачи сообщений. Например, когда прикладной процесс хочет открыть файл, запрос к системе переводится в сообщение, которое посылается менеджеру файловой системы. Менеджер файловой системы (после доступа к диску через его драйверы устройств) отвечает обработчиком файла. Этот механизм передачи сообщений является прозрачным относительно сети, то есть, система может быть распределена между более чем несколькими сетевыми узлами, без необходимости каких-либо изменений в коде приложения.

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

Архитектура QNX 6

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

Микроядро - имеет очень маленький размер и выполняет две функции:

• передача сообщений – (Микроядро обеспечивает маршрутизацию всех сообщений между всеми процессами в системе);

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

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

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

• Менеджер (Администратор) процессов (Proc);

• Менеджер (Администратор) файловой системы (Fsys);

• Менеджер (Администратор) устройств (Dev);

• Менеджер (Администратор) сети (Net).

Микроядро Neutrino скомпоновано с администратором процессов в единый модуль procnto, который часто называют "системным процессом".

Существуют различные дополнительные варианты модуля procnto (не говоря о версиях для разных процессоров):

• procnto-amp — вариант модуля procnto с поддержкой симметричной многопроцессорности;

• procnto-instr — вариант модуля procnto, оборудованный средствами трассировки событий;

• procnto-smp-instr – сами догадайтесь для чего

Менеджеры файловой системы, менеджер устройств, менеджер сети называют администраторами ресурсов.

Системные и пользовательские процессы

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

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

Драйверы устройств

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

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

Связь между процессами (IPC)

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

Основным механизмом связи между процессами в QNX являются сообщения.

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

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

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

QNX как сеть

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

В некоторых отношениях QNX сеть напоминает скорее большую ЭВМ, нежели набор мини-компьютеров.

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

Связь между процессами осуществляется единообразно, независимо от их местоположения в сети.

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

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

В основе такой прозрачной поддержки сети в QNX лежит всеобъемлющая концепция IPC на основе передачи сообщений.

Лекция 3. ФАЙЛОВАЯ СИСТЕМА QNX 6