Параметры осрв
Время реакции системы
Интервал времени от момента возникновения события на объекте до выполнения первой команды в программе обработки этого события принято считать временем реакции системы на событие. Проектировщики СРВ должны уметь вычислять этот интервал.
Время реакции СРВ включает две компоненты:
1 компонента: Время выполнения цепочки действий от события на объекте до генерации прерывания никак не зависит от ОСРВ и целиком определяется аппаратурой.
2 компонента: Интервал времени от возникновения запроса на прерывание до выполнения первой команды его обработчика определяется целиком свойствами ОСРВ и архитектурой компьютера. Это время нужно уметь оценивать в худшей для СРВ ситуации, т.е. когда процессор загружен и в это же время может происходить другое прерывание, кроме того, СРВ может выполнять какие-либо действия, которые вообще блокируют прерывание.
Время переключения контекста
В ОСРВ изначально заложен параллелизм, т.е. возможность одновременной обработки нескольких событий. Поэтому все ОСРВ являются многозадачными (многопроцессными или многонитевыми). Для того чтобы уметь оценить накладные расходы ОСРВ при разработке параллельных событий крайне важно знать время, которое затрачивается на передачу управления от задачи к задаче (от процесса к процессу, от нити к нити).
Размеры системы
Для ОСРВ очень важным параметром является размер системы исполнения, а именно суммарный размер минимально необходимого для работы прикладных программ приложения системного набора (системное ядро, системные модули, драйверы). С течением времени значение этого параметра снижается. Тем не менее, он остается важным, и производители ОСРВ стремятся к тому, чтобы этот параметр был не велик (например, ОСРВ OS9 – 22 Кбайт, VxWorks – 16 Кбайт).
Возможность исполнения ОСРВ из ПЗУ
Это свойство ОСРВ одно из базовых, поскольку указанная возможность позволяет создавать компактные встроенные СРВ повышенной надежности с ограниченным энергопотреблением без внешних накопителей.
Механизмы ОСРВ (система приоритетов, алгоритмы диспетчеризации, методы межзадачного взаимодействия, средства для работы с таймерами)
Требования к ОСРВ изложены в группе международных стандартов POSIX (переносимый интерфейс ОС), разработанных одним из рабочих комитетов международного, профессионального объединения технических специалистов IEEE.
Краткий обзор и классификация осрв
В настоящее время имеется более 60 ОСРВ.
Версии ОС UNIX, являясь широко распространенными в научной и технической сферах, были в конце 70-х – начале 80-х годов адаптированы к задачам РВ. Причем первоначально UNIX системы не требовали лицензии. На затем ситуация изменилась. Это, в свою очередь, стало стимулом для таких крупных фирм, как IBM, DEC, HP, отреагировать на данное событие путем создания OSF, которая предназначалась для создания ОСРВ с тем, чтобы не зависеть от одного или единственного поставщика ОСРВ (UNIX). Эта организация разработала ряд программных средств по ОСРВ, основной из которых была система OSF/1. Вместе с тем широкое распространение персональных компьютеров (ПК), обусловило широкую популярность ОС MS DOS и Windows компании Microsoft. MS DOS имела весьма ограниченное использование для задач ОСРВ, а Windows (особенноWindows NT) имеет достаточно развитые механизмы ОСРВ: управление потоками, семафоры и, что особенно важно, механизмы, поддерживающие безопасную и отказоустойчивую работу СРВ, например, поддержку зеркального диска. Специально в качестве ОСРВ были созданы:
OS9 (написана на С для микропроцессорных наборов фирмы Motorola);
WAX/VMS (написана для процессоров WAX фирмы DEC);
QNX (разработана канадской фирмой QNX Soft Where System).
QNX за свою более чем 20 летную историю имеет 100 тысяч инсталляций во многих странах мира и считается наиболее распространенной сетевой ОСРВ.
Простейшие ОСРВ, например, OSIK или RTX предоставляют только базовые средства по диспетчеризации задач и обработке прерываний. Подобные системы, часто называемые базовыми, не поддерживают стандартных интерфейсов разработки ПО, зафиксированных в POSIX, и не предоставляют механизмов защиты памяти. Достоинствами базовых ОСРВ являются компактность, открытость исходного кода и обеспечение гарантированного времени реакции системы. Недостатками таких ОСРВ являются их низкая масштабируемость; сложность интеграции компонентов системы в единое целое; сложность повторного использования приложений, разработанных для других проектов; ограниченность средств отладки.
Более сложные ОСРВ (например, QNX, Linux) предоставляют не только базовые средства, но и широкий набор дополнительных средств по организации межзадачного взаимодействия, по локализации сбоев в прикладном ПО и т.п. Такие ОСРВ, часто называемые расширенными, поддерживают стандартные интерфейсы, разработки прикладного ПО, а также имеют развитые системы защиты памяти, хорошо масштабируются и включают богатые средства отладки прикладного ПО. К недостаткам этих ОСРВ относят: повышенные требования к ресурсам целевой аппаратной платформы и увеличение времени реакции.
В настоящее время просматривается тенденция к переходу от базовых ОСРВ к расширенным, а также к решению задачи перевода прикладного ПО встроенных СРВ с базовой ОСРВ на расширенную с сохранением существующих функций продукта, реализуемых с использованием базовой ОСРВ.
Задача интеграции разнородных частей прикладного ПО не является новой. Пути решения задачи различаются в зависимости от использования одноядерной или двуядерной ОСРВ. В первом случае ядро ОСРВ, например, Linux, должно быть расширено средствами повышения скорости реакции системы на входные воздействия. Во втором случае (двуядерный подход) компактное ядро РВ осуществляет диспетчеризацию задач РВ и обработку информации от устройств ввода/вывода. А ядро Linux осуществляет диспетчеризацию задач Linux, не критичных ко времени реакции системы на входные воздействия.
Двуядерный подход позволяет осуществить интеграцию наследуемого прикладного ПО и нового ПО с наименьшими трудозатратами, т.к. не требуется переработки прикладного ПО.
Кроме того, двуядерный подход дает гарантию, что реактивные характеристики заимствованного прикладного ПО не ухудшатся после переноса на новую программную платформу, т.к. базовая ОСРВ (первое ядро ОСРВ) будет иметь наивысший приоритет по сравнению с расширенной ОСРВ (второе ядро ОСРВ).
Рисунок 45 – Архитектуры СРВ на основе Linux
Ключевым вопросом в двуядерном подходе является формирование оптимальной схемы распределения приоритетов, при которой обработчики прерываний Linux, ядро Linux и процессы, работающие под управлением Linux, должны иметь более низкий приоритет, чем обработчики прерываний ОСРВ, ядро ОСРВ и задачи ОСРВ.
Рисунок 46 – Логическое распределение приоритетов.
Представленная на Рисунке 46 схема распределения приоритетов является идеальной, но не всегда может быть реализована на используемой аппаратной платформе. Трудности могут возникнуть, например, в области обработчиков прерываний, работающих под управлением Linux. С одной стороны, необходимо обеспечить целостность данных, с которыми работают обработчики прерываний, а с другой стороны, необходимо приостанавливать исполнение кода обработчика прерывания Linux при возникновении запросов на обработку прерываний инициирующих задачи ОСРВ.
В некоторых случаях приходится иметь дело с так называемым эффектом инверсии приоритетов в области обработчика прерывания Linux и задач ОСРВ.
Интеграция двух ОС, т.е. заимствованные ОСРВ и системы Linux, требует внесения некоторых изменений в ПО обеих систем.
Часть изменений, связанных с интеграцией высокоприоритетного ядра ОСРВ, уже сделаны в ОС Linux версий 2.4.х и выше.
Существуют механизмы встраивания вызовов функций внешнего кода из кода инициализации ядра Linux, из кода обработки прерываний и непосредственно из ядра. Перечисленные и другие свойства ядра Linux могут быть вполне успешно использованы при его интеграции с заимствованной ОСРВ.