Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Операционные системы реального времени и технологии разработки кроссплатформенного программного обеспечения. Ч.1. Учебное пособие
.pdf
2.6. Параметры и характеристики операционной системы реального времени
41
Определив эти черты операционной системы реального времени,
можно немного перефразировать определение, данное ранее.
Так, более точно ОС РВ можно определить как совокупность связанных между собой элементов, выполняющих определенные функции и реагирующих на внешние события в течение определенных интервалов времени.
2.6. Параметры и характеристики операционной
системы реального времени
ОС РВ должна успевать реагировать на все внешние события и оп-
тимально распоряжаться программными и аппаратными ресурсами. При
этом время реакции является критичным, и его величина является характеристикой задачи, которая должна быть выполнена.
В связи с этим можно выделить следующие основные характери-
стики ОС РВ.
1. Время реакции системы.
2. Время переключения контекста.
3. Время перезагрузки системы.
4. Размер системы выполнения.
5. Система приоритетов.
6. Средства диспетчеризации.
7. Механизмы взаимодействия между задачами.
8. Средства работы с тайминговыми системами.
9. Наличие драйверов устройств, в том числе специфических.
10. Поддержка микропроцессорных модулей различной архитектуры.
11. Наличие средств нативной и кроссплатформенной разработки.
12. Поддержка специфических средств ввода-вывода.
Время реакции системы будем понимать как интервал времени
между моментом возникновения события и моментом выполнения первой
команды в программном стеке для обработки этого события. Это время реакции складывается:
из времени реакции системы на внешнее событие (временной ин-
тервал выполнения цепочки действий от начала события на внешнем источнике до момента генерации прерывания);
2. Основные положения
42
времени между возникновением запроса на прерывание и момен-
том выполнения первой команды обработчика.
Время реакции системы напрямую зависит от особенностей аппара-
туры и слабо зависит от операционной системы. Исключением может являться только такой специфический базис, как микроконтроллер, в котором
без операционной системы (на чистом ассемблере) можно получить задержку входа в прерывание, равную 4-м тактам процессора, а с операционной системой – около 30-ти тактов.
Для оценки эффективности ОС берется наихудшая оценка для всех
возможных вариантов, т.е. ситуация, когда микропроцессор полностью загружен, в очереди задач присутствуют задачи на выполнение и постоянно
поступают новые запросы на обработку прерываний.
Время переключения контекста как параметр ОС РВ следует из
того факта, что современные ОС всегда проектируются как многопоточные системы, которые допускают одновременное выполнение нескольких
задач. При этом время переключения между потоками может быть рассчитано заранее и определено стандартом, т.е. этот параметр считается
прогнозируемым.
Время перезагрузки системы является критическим параметром для
тех ситуаций, когда требуется непрерывная и надежная работа системы.
В ОС РВ даже размещаются специальные ловушки, которые отслеживают
зависания, превышение критических значений временных параметров и
т.п. Время перезагрузки можно регулировать в некоторых пределах, изменяя стартовые последовательности. Современные ОС РВ, основанные на
Linux и размещенные на твердотельных накопителях, загружаются всего
несколько секунд, а отдельные образцы с минимальными функциями –
меньше секунды. Это время меньше, чем время стартовой настройки (инициализации) оборудования.
Размер системы исполнения напрямую влияет на скорость загрузки
системы и на емкость требуемых носителей (ОЗУ и ПЗУ). В базовом варианте это множество программных инструментов, состоящее из ядра системы, системных модулей и драйверов. При этом систему можно вполне
эффективно пересобрать прямо на целевом оборудовании, оставив только
самые необходимые модули и драйвера. Заодно остается только один вариант ядра системы и оптимальный набор программного обеспечения с нужной архитектурой.
2.7. Особенности программирования операционных систем реального времени
43
Если говорить о размерах, то современные Linux-системы могут
иметь размер в несколько мегабайт, а специализированные дистрибутивы
и того меньше: ОСРВ OS9 – 22 Кбайт, VxWorks – 16 Кбайт.
Решению проблемы минимизации помогают такие возможности
ОС, как:
возможность полного размещения ОС в ОЗУ и нормальной ра-
боты оттуда же;
специальные механизмы управления потоками и задачами.
Наличие таких специальных программных компонент, как драйвера
внешних и периферийных устройств или драйвера устройств ввода-вывода,
также являются важными характеристиками. Никто не будет использовать
в реальной ситуации такую ОС, в которой отсутствуют драйвера для
устройств, которые используются на практике. То же самое может быть
сказано и об архитектурах микропроцессоров. ОС РВ должна поддерживать различные модели и архитектуры процессоров и, что особенно важно,
должна уметь использовать заложенные в микропроцессор алгоритмы с аппаратной реализацией.
Инструментарий разработки и кроссплатформенного программиро-
вания применяется для разработки новых программ или модификации существующих.
2.7. Особенности программирования операционных
систем реального времени
Согласно современным подходам к программированию, разра-
ботку программного обеспечения для ОС РВ можно разделить на три основных вида.
1. Последовательное программирование.
2. Программирование систем реального времени.
3. Параллельное программирование.
Последовательное программирование – это почти “канонический”
вид программирования, когда программа выполняется последовательно на
одном ядре и на одном процессоре. В данном случае программа работает
как система фильтров для наборов данных, поэтапно изменяя последние.
Результат работы однозначно определяется заложенными алгоритмами и
2. Основные положения
44
входными данными. В этом случае, требования ко времени выполнения не
выходят на передний план. При этом соблюдается следующая закономерность: вне зависимости от мощности аппаратуры и инструментальных
средств программирования, результат выполнения не меняется. Результат
работы зависит только от заложенных алгоритмов.
Программирование для систем реального времени – это отдельный
подход к программированию. Здесь самым важным моментом является
учет особенностей той среды, в которой будет выполняться программа.
Программы для ОС РВ, работающие в теплице, и программы для реактивного самолета, работающие с разной скоростью, но по одним и тем же
принципам. В любом случае, программы для систем реального времени
должны быстро реагировать на сигналы внешней среды и находиться в
рамках временных ограничений.
Следует отметить, что чрезвычайно сложно соблюсти все особенности работы ОС реального времени только при помощи стандартных приемов программирования. Как минимум, стандартные программы не умеют
запускать процессы или потоки для параллельной обработки данных. Для
этого существует особый подход, который называется “параллельное программирование”. Параллельное программирование делает упор на одновременное выполнение программного кода и на правильное взаимодействие между отдельными участками исполняемого кода.
При этом параллельное выполнение алгоритмов может происходить
как на одном компьютере, так и в компьютерной сети. Этот эффект называется “распределенные вычисления”.
Различия между программами, разработанными при помощи стандартных средств и подходом, и параллельными решениями можно свести к
следующему списку.
1. Логика решения задачи может быть одинаковая, но может разли-
чаться кардинально, причем под влиянием внешних событий и самой природы решаемой проблемы.
2. Параллельная программа может не только обрабатывать сразу
несколько потоков данных, но несколько источников внешних сигналов.
Примерами могут являться внешние события или сигналы с датчиков.
3. Логика решения задачи может явно зависеть от времени. Напри-
мер, если система не может обработать сигналы от нескольких датчиков в
2.7. Особенности программирования операционных систем реального времени
45
установленных временных интервалах и обработчики не зависят друг от
друга, то можно смело применять параллельный подход.
4. Исходя из предыдущего пункта, ясно, что подобные системы ра-
ботают в условиях жесткого времени и любая задержка может быть воспринята как ошибка или неверный результат вычислений.
5. Результат работы параллельной системы зависит от возможно-
стей и общего состояния системы и его иногда невозможно предсказать
заранее.
6. Для параллельной системы очень важно правильное разграниче-
ние ответственности между решающими модулями и важны процедуры
синхронизации и обмена данными.
7. Система всегда ориентирована на получение и обработку новых
данных, так что состояние простоя – это всегда состояние ожидания.
Здесь следует упомянуть, что фактор времени не равен фактору производительности системы. В жестких временных рамках важнее стабильность работы, быстрота реагирования и достаточность скорости решения
задачи. Именно достаточность определяет качество системы. “Медленные”
системы могут отлично справляться с задачами своего масштаба.
Поэтому скорость выполнения программ рассматривается не в контексте единиц времени, а в контексте и относительно решаемой задачи.
При параллельном программировании применяются техники, отличающиеся от классических. Наиболее важными из них являются методы,
ориентированные на эффективное решение следующих задач.
1. Перехват внешних событий.
2. Быстрый вызов реакции на внешнее событие, т.е. передача управ-
ления на обработчик события с минимальными задержками.
3. Обработка исключительных ситуаций и ошибок.
4. Возможность прямого вызова функций операционной системы
(например, обращение к ядру или к драйверу, минуя “прослойки” и стандартные средства вызова).
Очень часто программы для ОС РВ строятся не по “монолитной”
схеме (когда есть один большой блок исполняемого кода с вызовами и переходами), а по схеме “сервер-клиент”.
Этот подход является удачным решением благодаря следующим
особенностям.
2. Основные положения
46
1. Каждый поток выполняет свою определенную функцию.
2. Каждый поток является “клоном” соседних, если они решают одну
и ту же задачу. При этом их можно запускать просто путем клонирования.
3. При обнаружении ошибки или внештатной ситуации в парал-
лельном потоке, последний можно попросту “отключить” от сервера и запустить заново.
4. Надежность системы типа “сервер-клиент” выше за счет того, что
при “падении” клиента, сервер остается работоспособным.
5. Клиенты могут быть с минимальными изменениями запущены как
на одной машине, так и на разных машинах в локальной или глобальной сети.
6. Система постоянно “готова” к запуску клиентов.
7. Состояние простоя системы является просто состоянием отсут-
ствия запущенных клиентов.
8. У системы отсутствует состояние аварийного завершения – это
состояние есть только у отдельных клиентов.
9. Каждому отдельному клиенту достаточно легко установить “кри-
тические секции”, т.е. области ответственности и ограничения потребляемых ресурсов. В условиях недостатков ресурсов для параллельного выполнения можно просто уменьшить число параллельно работающих клиентов,
сведя систему до “гибридного” состояния (когда большое количество задач
решается последовательно небольшим числом параллельно запущенных
потоков).
10. Прерывание работы клиенты не сказывается на его ресурсах и
данных, так как другие клиенты не изменяют их.
Конечно, в реальных системах всегда ищут компромисс. Например,
не все 100 % задач или входных сигналов обрабатываются своим клиентом.
Большое количество запущенных параллельно обработчиков сильно грузят
систему. Процессы должны выполняться быстро, так что часто приходится
принимать решение и выбирать между чистой архитектурой, ясностью
программного кода и эффективностью. Обычно выбор склоняется к последнему. Не всегда в конечном решении присутствует “чистый” код и “чистая” архитектура.
Поэтому здесь и говорится отдельно о программировании для си-
стем реального времени и чистом параллельном программировании.
2.7. Особенности программирования операционных систем реального времени
47
Параллельное программирование – это скорее абстрактный процесс
разработки программ и отдельный способ мышления. Во главу угла здесь
как раз поставлена чистота архитектуры, разделение ответственности
между исполнителями.
Чисто спроектированная параллельная программа должна работать
параллельно вне зависимости от программной среды и от аппаратуры.
Этот подход может доводить до абсолюта, когда говорится, что каждый параллельный поток должен запускаться на своем процессоре, пусть
даже и виртуальном.
При всем этом параллельные программы требуют не только специальных методов проектирования и программирования, специальных библиотек, средств сборки и компиляции, но даже специальных способов отладки и методов тестирования.
3. Архитектура ОС РВ
48
3. АРХИТЕКТУРА ОС РВ
3.1. Ядро ОС РВ
Программы для первых вычислительных устройств создавались чисто на машинных кодах, каждая программа была уникальной и специализировалась на решении одной конкретной задачи. Собственно, для этого
программы и разрабатывались – не было тогда еще программного обеспечения универсального или общего назначения.
Любые изменения в аппаратуре, модификация состава устройства,
изменение системы команд или внесение новых элементов архитектуры
приводили к необходимости существенной переработки старых программ
или к созданию новых.
Однако вскоре разработчики пришли к выводу, что целесообразно
дополнительно создавать и программное обеспечение общего назначения.
Первыми попытками в этом направлении была базовая система
ввода-вывода (BIOS). Параллельно с этим процессом унифицировалось и
оборудование, появлялись общие части, не зависящие от конкретной аппаратуры.
Постепенно стали выделяться и обобщенные методы разработки
программного обеспечения. Возникли такие понятия, как файл, комплекс
программ, система ввода-вывода и т.п.
Постепенно выделился набор программного обеспечения, который
содержал универсальные программы и специальные программы. Этот комплекс программ стал называться операционной системой (ОС).
Впоследствии обобщенная часть ОС стала называться ядром ОС. Его
дополнили планировщиком и другими системными утилитами, а также разделили на несколько уровней абстракции, которые помогли отделить аппаратуру со своими особенностями от программного обеспечения.
Ядро операционной системы (kernel) имеет самый низкий уровень
абстракции в системе и имеет прямой доступ к ресурсам, необходимым для
обработки информации. Как правило, именно ядро системы предоставляет
исполняемым процессам доступ к ресурсам при помощи механизмов прямого доступа, механизмов межпроцессного взаимодействия и системного
вызова.
3.1. Ядро ОС РВ
49
Абстрактный уровень ядра операционной системы предоставляет сле-
дующие категории сервисов для прикладного программного обеспечения:
сервис управления задачами. Относится к основной группе сер-
висов и позволяет разработчикам разрабатывать программы как совокупность отдельных фрагментов или компонентов. При этом каждый объект
может относиться к своей предметной области, разделяя свою определенную ответственность. Фрагмент может иметь свой собственный квант времени. Программный код, занимающий этот квант, называется задачей. Задачами управляет планировщик при помощи арбитражного алгоритма, очереди задач и системы приоритетов. Он же и следит за выполнением текущих задач, запускает их в соответствующие периоды времени и отслеживает состояние;
система динамического распределения памяти. Относится к спе-
циальной группе сервисов для управления взаимодействием между задачами и областями оперативной памяти. Под управлением данной системы
задачам назначается один или несколько участков памяти “во временное
пользование”. После окончания работы задачи и выделенная ей память возвращается в доступную всем область;
система управления таймерами. Относится к специальной группе
сервисов, следящих за работой таймеров и счетчиков. Группа задает режимы работы таймеров, следит за их работой, отмеряет лимиты времени, в
пределах которых должна выполняться задача. Кроме всего прочего, эти
сервисы позволяют генерировать прерывания, создают одноразовые и периодические будильники и сторожевые таймеры;
система управления взаимодействием между задачами. Отно-
сится к специальной группе сервисов, деятельность которых направлена на
обмен данными между задачами и обеспечение ее защищенности;
система контроля устройств ввода-вывода. Относится к специ-
альной группе сервисов, обеспечивающей работу программного интерфейса. Обмен командами и данными через программный интерфейс может охватывать как прикладное программное обеспечение, так и группу
драйверов;
система управления файлами. Относится к общей группе сервисов
и занимается управлением файловой системой, контролем целостности файлов, созданием, удалением, модификацией объектов файловой системы;
3. Архитектура ОС РВ
50
система управления сетевыми соединениями. Относится к общей
группе сервисов и занимается созданием и поддержанием сетевых соединений, соблюдением протоколов различного уровня, преобразованием
форматов данных, формированием пакетов информации и т.п.;
система управления базами данных. Относится к общей группе
сервисов и занимается управлением доступа к структурированным хранилищам информации, т.е. к базам данных;
система управления графическим интерфейсом пользователя.
Относится к общей группе сервисов для организации отображения информации для пользователя или администратора системы в воспринимаемом
ими виде. Интерфейсы могут быть текстовыми или графическими. Могут
подразумевать обратную связь с пользователями или нет (являться чисто
информационными).
Рассмотрим далее особенности архитектуры стандартной операционной системы реального времени.
3.2. Архитектура ОС РВ
На самом деле, четкого разделения между как таковым ядром операционной системы и другими составляющими ее программами нет. Это разделение скорее условное и зависит оно от набора функциональных возможностей конкретного ПО.
Для определенности принято считать, что ядро операционной системы реального времени предоставляет пользователю базовые функции, а
“полная” операционная система также дополняет эти функции другими
возможностями (например, работой с файловой системой, поддержкой сетевых соединений, интерфейса взаимодействия с оператором и т.п.).
По своей структуре и принципам функционирования, операционные
системы можно условно разделить:
на монолитные;
системы с микроядром;
слоистые или многоуровневые;
клиент-серверные;
объектно-ориентированные.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]