Краткий обзор и классификация ОСРВ
В настоящее время имеется более 60 ОСРВ.
Версии ОС UNIX, являясь широко распространенными в научной и технической сферах, были в конце 70-х – начале 80-х годов адаптированы к задачам РВ. Причем первоначально UNIX системы не требовали лицензии. На затем ситуация изменилась. Это, в свою очередь, стало стимулом для таких крупных фирм, как IBM, DEC, HP, отреагировать на данное событие путем создания OSF, которая предназначалась для создания ОСРВ с тем, чтобы не зависеть от одного или единственного поставщика ОСРВ (UNIX). Эта организация разработала ряд программных средств по ОСРВ, основной из которых была система OSF/1. Вместе с тем широкое распространение персональных компьютеров (ПК), обусловило широкую популярность ОС MS DOS и Windows компании Microsoft. MS DOS имела весьма ограниченное использование для задач ОСРВ, а Windows (особенноWindows NT) имеет достаточно развитые механизмы ОСРВ: управление потоками, семафоры и, что особенно важно, механизмы, поддерживающие безопасную и отказоустойчивую работу СРВ, например, поддержку зеркального диска. Специально в качестве ОСРВ были созданы:
1.OS9 (написана на С для микропроцессорных наборов фирмы Motorola);
2.WAX/VMS (написана для процессоров WAX фирмы DEC);
3.QNX (разработана канадской фирмой QNX Soft Where System).
QNX за свою более чем 20 летную историю имеет 100 тысяч инсталляций во многих странах мира и считается наиболее распространенной сетевой ОСРВ.
Простейшие ОСРВ, например, OSIK или RTX предоставляют только базовые средства по диспетчеризации задач и обработке прерываний. Подобные системы, часто называемые базовыми, не поддерживают стандартных интерфейсов разработки ПО, зафиксированных в POSIX, и не предоставляют механизмов защиты памяти. Достоинствами базовых ОСРВ являются компактность, открытость исходного кода и обеспечение гарантированного времени реакции системы. Недостатками таких ОСРВ являются их низкая масштабируемость; сложность интеграции компонентов системы в единое целое; сложность повторного использования приложений, разработанных для других проектов; ограниченность средств отладки.
|
|
|
Более сложные ОСРВ (например, QNX, Linux) предоставляют не только базовые средства, но и широкий набор дополнительных средств по организации межзадачного взаимодействия, по локализации сбоев в прикладном ПО и т.п. Такие ОСРВ, часто называемые расширенными, поддерживают стандартные интерфейсы, разработки прикладного ПО, а также имеют развитые системы защиты памяти, хорошо масштабируются и включают богатые средства отладки прикладного ПО. К недостаткам этих ОСРВ относят: повышенные требования к ресурсам целевой аппаратной платформы и увеличение времени реакции.
|
|
|
В настоящее время просматривается тенденция к переходу от базовых ОСРВ к расширенным, а также к решению задачи перевода прикладного ПО встроенных СРВ с базовой ОСРВ на расширенную с сохранением существующих функций продукта, реализуемых с использованием базовой ОСРВ.
Задача интеграции разнородных частей прикладного ПО не является новой. Пути решения задачи различаются в зависимости от использования одноядерной или двуядерной ОСРВ. В первом случае ядро ОСРВ, например, Linux, должно быть расширено средствами повышения скорости реакции системы на входные воздействия. Во втором случае (двуядерный подход) компактное ядро РВ осуществляет диспетчеризацию задач РВ и обработку информации от устройств ввода/вывода. А ядро Linux осуществляет диспетчеризацию задач Linux, не критичных ко времени реакции системы на входные воздействия.
Двуядерный подход позволяет осуществить интеграцию наследуемого прикладного ПО и нового ПО с наименьшими трудозатратами, т.к. не требуется переработки прикладного ПО.
Кроме того, двуядерный подход дает гарантию, что реактивные характеристики заимствованного прикладного ПО не ухудшатся после переноса на новую программную платформу, т.к. базовая ОСРВ (первое ядро ОСРВ) будет иметь наивысший приоритет по сравнению с расширенной ОСРВ (второе ядро ОСРВ).
|
|
|
Рис. 4.2.1. Архитектуры СРВ на основе Linux
Ключевым вопросом в двуядерном подходе является формирование оптимальной схемы распределения приоритетов, при которой обработчики прерываний Linux, ядро Linux и процессы, работающие под управлением Linux, должны иметь более низкий приоритет, чем обработчики прерываний ОСРВ, ядро ОСРВ и задачи ОСРВ.
Рис. 4.2.2. Логическое распределение приоритетов
Представленная на рисунке (Рис. 4.2.2.) схема распределения приоритетов является идеальной, но не всегда может быть реализована на используемой аппаратной платформе. Трудности могут возникнуть, например, в области обработчиков прерываний, работающих под управлением Linux. С одной стороны, необходимо обеспечить целостность данных, с которыми работают обработчики прерываний, а с другой стороны, необходимо приостанавливать исполнение кода обработчика прерывания Linux при возникновении запросов на обработку прерываний инициирующих задачи ОСРВ.
В некоторых случаях приходится иметь дело с так называемым эффектом инверсии приоритетов в области обработчика прерывания Linux и задач ОСРВ.
|
|
|
Интеграция двух ОС, т.е. заимствованные ОСРВ и системы Linux, требует внесения некоторых изменений в ПО обеих систем.
Часть изменений, связанных с интеграцией высокоприоритетного ядра ОСРВ, уже сделаны в ОС Linux версий 2.4.х и выше.
Существуют механизмы встраивания вызовов функций внешнего кода из кода инициализации ядра Linux, из кода обработки прерываний и непосредственно из ядра. Перечисленные и другие свойства ядра Linux могут быть вполне успешно использованы при его интеграции с заимствованной ОСРВ.
Требования к языкам РВ
программирование в РВ требует специальных средств, которые не в полном объеме встречаются в обычных языках. Язык для программирования в РВ в совокупности с ОСРВ должен предоставлять следующие возможности:
1.Описание параллельных процессов;
2.Переключение процессов на основе динамических приоритетов;
3.Синхронизация процессов;
4.Обмен данными между процессами;
5.Функции, связанные с часами и таймерами, абсолютное и относительное время ожидания;
6.Прямой доступ к внешним аппаратным портам;
7.Обработка прерываний;
8.Обработка исключений.
Некоторые компании разрабатывали специальные языки для поддержки своих собственных аппаратных средств. Они не претендуют на универсальность и ориентированы на конкретные компьютеры и их интерфейсы. Обычно подобные языки базируются на существующих (FORTRAN, BASIC) с расширениями, включающими функции РВ, о чем свидетельствует их название типа «Process Basic» или «Real-Time Fortran». Некоторые языки не поддерживают программирование в РВ в строгом смысле, но они легко расширяются (С++).
В 70-е годы выдвигалась концепция единого переносимого многоцелевого языка программирования в РВ, а именно языка ADA. Его главная идея состоит в том, что среда программирования должна быть полностью отделена от аппаратных средств. Программист не должен сталкиваться с деталями аппаратного уровня, а работать только в терминах абстрактных структур и типов данных. Опыт показал (не реалистичность) низкую эффективность этого подхода. Поскольку универсальные сильно типизированные языки существенно ограничивают гибкость. А быстрое развитие технических средств диктует новые требования, которые не могут быть предусмотрены в типизированном универсальном языке.
Вывод: Не существует наилучшего языка программирования в РВ, поскольку для каждого приложения и программно-аппаратной платформы необходимо подбирать свои средства (инструменты), учитывая квалификацию и предпочтения разработчиков.
С и С++
С 80-х годов эти языки стали популярными для всех приложений, требующих высокой эффективности, в частности, для программ РВ.
С – слаботипизированный язык и позволяет программисту делать почти все, вплоть до манипуляции с регистрами и битами. Поскольку наиболее распространенными ОС в приложениях автоматического управления процессами являются UNIX-системы, язык С является практически вынужденным выбором при разработке программ РВ.
С++ – представляет собой еще более мощный инструмент и, хотя программирование в РВ непосредственно на С++ не поддерживается, может быть реализован программирование задач РВ с помощью специально разработанных программных модулей и библиотек.
Basic
Простота этого языка часто критикуется, поскольку он не является хорошим средством для создания больших структурных систем. Однако на Basic можно разработать приложения значительно быстрее, чем на других языках. Кроме того, Basic имеется почти на всех мини и микро компьютерах.
Следовательно, удобен для разработки небольших приложений, которые могут входить в крупные системы, но его не следует использовать для приложений, превышающих 1000 строк.
FORTRAN
Благодаря тому, что Fortran имеет устойчивое применение в научных приложениях, нередко информация в СРВ обрабатывается существующими Fortran-программами, а новые программы анализа и статистики также пишутся на Fortran.
Pascal и Modula 2
Эти языки предполагают, что программист постоянно остается в ограниченной среде, предоставленной программой, что совсем не соответствует реальной практике. Гибкость использования этих языков существенно выше, если программы для специальных приложений (обработчики прерываний, драйверы и др.) написаны на языке Assembler. Оба языка поддерживают подключение внешних модулей на Assembler, Pascal и Modula 2 являются хорошим средством для разработки встроенных систем, но не подходят для сложных приложений в распределенных компьютерных системах.
Структура программ СРВ
Разработка специального ПО РВ начинается с анализа и описания задач СРВ. Функции СРВ декомпозируются на достаточно простые части, с каждой из которых связывается программный модуль.
Принципиальной особенностью программ РВ является постоянная готовность и отсутствие условий нормального, а не аварийного завершения. Если программа не исполняется, она остается в режиме ожидания прерывания (событие) или истечение некоторого интервала времени. По сути, программы РВ – последовательный код, исполняемый в бесконечном цикле.
В каком-то месте программы есть оператор, приостанавливающий ее исполнение до наступления внешнего события или истечения интервала времени.
При разработке каждого программного модуля должны быть четко выделены области (участки) кода, в котором происходит обращение к защищенным ресурсам, т.е. критической секции. Вход и выход из этих областей координируется каким-либо методом синхронизации или межпрограммных коммуникаций, например, семафор.
В общем случае, если процесс находится в критической секции, можно считать, что данные, с которыми он работает, не изменяя каким-либо другим процессам. Кроме того прерывание исполнения процесса не должно оказать влияние на защищенные ресурсы. Эти требования снижают риск системных ошибок для гарантии живучести программы РВ нештатной ситуации, которая может блокировать или аварийно завершать процесс, должна своевременно распознаваться и исправляться, причем лучше всего в рамках самой программы.
Эффективность исполнения является наиболее важным параметром СРВ. Процессы должны выполняться быстро и часто приходится искать компромисс между ясностью и структурностью программы и ее быстродействием. Опыт создания СРВ показывает, что если для достижения цели нужно чем-то пожертвовать, то это обычно делается, но если структурность программы должна быть принесена в жертву ее эффективности, то совершенно необходимо тщательно документировать все принятые решения, связанные с разработкой приложения. Такой подход обеспечивает возможность дальнейшего сопровождения программы.
Дата добавления: 2018-08-06; просмотров: 586; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!