2.2.2.3. Разделение данных.

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

2.2.2.4. Обработка запросов внешних устройств.

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

2.2.2.5. Обработка особых ситуаций.

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

2.2.3. Пикоядро.

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

· Не имеет каких-либо состояний (начальных, конечных или промежуточных), ядро без состояния. Не требует инициализации и деинициализации.

· Реализует и содержит в себе очень малое количество функций и данных - только функции для работы с объектами.

· Предоставляет объектно-ориентированный интерфейс системе в виде небольшого количества системных вызовов для работы с объектами.

· Является полностью пассивной частью кода операционной системы - код ядра выполняется только во время системных вызовов.

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

2.3. Методы управления задачами в ОС РВ.

2.3.1. Классификация подходов.

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

2.3.1.1. Статическое планирование.

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

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

2.3.1.2. Динамическое планирование.

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

2.3.1.3. Планирование, основанное на времени.

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

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

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

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

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

2.3.1.4. Планирование апериодических задач

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

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

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

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

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

2.3.2. Обзор методов.

2.3.2.1. Rate-monotonic (RM).

Метод назначает статические приоритеты задачам основываясь на их периодах. В этом методе приоритеты определяются следующим образом: задача с самым маленьким периодом получает самый высокий приоритет.

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

Исходный RM подход имеет ряд ограничений:

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

· Все задачи должны быть периодическими.

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

· Время выполнения постоянно.

· Для задач определено время выполнения в худшем случае.

· Все задачи имеют крайний срок, эквивалентный их периоду.

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

Так в протоколе приоритетных границ (Priority Ceiling Protocol) и некоторых других похожих (Stack Resource Protocol) удалось избавиться от ограничения на взаимодействие задач. Также было предложено много методов приведения непериодических задач к периодическим.

2.3.2.2. Deadline Monotonic (DM).

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

Такой метод расстановки приоритетов будет оптимальным, если выполняются следующие условия:

· множество задач - фиксированное множество жёстких задач;

· задачи периодические или спорадические;

· задачи имеют определённое (известное) время выполнения в худшем случае;

· для задач определён критический момент, то есть время выполнения в худшем случае.

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10