Основые свойства задач.
Прежде всего, вся информация о задачах для ОС хранится в унифицированной структуре данных Task Control Block (TCB -- управляющем блоке). Абсолютно все параметры: имя задачи, ее номер, статус, приоритет, ссылка на очереди сообщений, границы стеков, состояния регистров, -- полный набор данных, который позволяет запустить задачу с того же самого места. Вот этот набор данных, который позволяет запустить задачу с места остановки, называют контекстом задачи. Его, как правило, тоже записывают в TCB, и это не только состояния регистров в момент прерывания, а еще и дополнительные данные, вроде счетчкика команд, указатели стеков и т.д. Функции остановки выполняет планировщик задач. Переключение между задачами с сохранением контекста -- это основной механизм работы ОС РВ и многопроцессорных систем.
В СРВ невозможно обойтись без приоритетов. Приоритет -- целое число, присваиваемое задаче, характеризующее ее важность в сравнении с другими. Приоритет может быть статическим и динамическим. Статические задаются жестко на этапе разработки и конфигурирования системы, динамические могут изменяться в процессе работы в зависимости от алгоритма функционирования. Приоритеты используют планировщик задач для выбора той задачи из числа готовых, которую следует выполнять в следующий момент времени. Опять же, система приоритетов -- один из основных механизмов СРВ. Теперь немного о сотоянии или статусе задачи: (это понятие из ОС) минимальное количество состояний задачи -- три. Активная задача -- та, которая в текущий момент времени выполняется. Готовая задача -- готовая к выполнению, стоящая в очереди к планировщику. Блокированная задача -- та, выполнение которой приостановлено до наступления какого-либо события. Для ОС наиболее характерно: блокированная задача -- ожидает освобождение какого-либо ресурса. В СРВ событиями являются прерывания. Например, от внешних исполнительных устройств. Второй по частоте случай: выдержка определенного итервала времени. Таких три состояния задачи имеются во всех ОС. В каждой конкретной ОС может быть предусмотрено большее количество возможных состояний задачи. Для примера, можно различать готовую и поставленную в очередь задачу, и готовую, но еще не поставленну -- чтобы, например, ограничить размер очереди от "потерь". Самое большое количество состояний задачи в языке Ада.
В СРВ обязательным элементом является наличие так называемой "пустой задачи" -- она запускается при инициализации системы, а также в те моменты, когда нет готовых к выполнению задач. (обычно это пустой бесконечный цикл с условием остановки). Это дает синхронизацию, а, во-вторых, нет необходимости каким-либо образом модернизировать работу планировщика для раличения между собой пауз и работающих задач. Для СРВ важна возможность многократного запуска задачи. Скажем, два различных физически, но по сути одинаковых датчика температуры должны обрабатываться одинаково -- не писать же две разных программы. Для каждой запущенной копии задачи нужно писать свой TCB. Кроме этого, запрещено использовать файлы с зарезервированными именами в тексте программы, и важно обращать внимание на работу с глобальными ресурасами -- разные копии могут мешать друг другу, если имена глобальных переменных одинаковые. Также важно свойство реинтеррабельности (повторная входимость) -- возможность вызова себя самой. Чаще всего этому мешает использование глобальных переменных, и, потому что нет реинтеррабельности, не используется (как ОС) DOS.
Лекция 3
(17/09/2012)
Планирование задач.
Существует несколько стандартных алгоритмов для планирования задач (планирование -- очередность вызова и запуска задач). Модуль, который управляет такими процессами -- диспетчер задач (супервизор). Наиболее простой вариант -- циклический алгоритм:
Рис. 1 "Циклический алгоритм диспетчера задач"
-- последовательный вызов всех задач. Каждая последующая задача начинает выполняться по окончанию предыдущей. При использовании такого алгоритма нужно учитывать 3 правила:
ни одна задача (подрограмма) не должна содержать в себе циклов ожидания чего-либо -- иначе мы не гаранитируем время выполнения
любая задача, при необходимости, должна иметь возможность сохранить свое состояние для продолжения работы при следующем проходе цикла.
надо стремиться к тому, чтобы время выполнения каждой задачи было минимальным.
+Главный плюс такого алгоритма: все просто, все понятно и несложно отлаживается. Если ни одна из задач не содержит работы с прерываниями, то система 100%-но предсказуема, и мы можем просчитать наихудший случай (наибольшую задержку выдачи сигнала). Код получается небольшого размера, для всех задач можно использовать один единственный стек. И здесь принципиально отсутствуют гонки (ошибки, обусловленные и несовпадением временных интервалов).
-Минусы такого алгоритма тоже очевидны: невозможно задать какие-либо приоритеты, нельзя организовать очереди. Последовательность вызова задач жестко задана и не способна меняться (пример: опрашиваем 10 датчиков: 9 медленных и 1 быстрый -- значит, впустую будем опрашивать 9 медленных датчиков, когда информация на них еще не поменяется). Тем не менее, очень много промышленных систем работают именно по этому алгоритму. Это своего рода конечный автомат. Вся ответственность за работоспособность лежит на программисте.
Вторым стандартным методом является планирование в режиме разделения времени (time-slicing, time-sharing):
Берется определенный временной интервал. Чаще всего, его берут кратным 1 мс. Задача работает в течении выделенного временного интервала. Если за это время задача не выполнилась, контекст задачи сохраняется и управление передается готовой задаче с наивысшим приоритетом. Из готовых задач должна быть предварительно сформирована очередь.
Алгоритм имеет целый ряд "подводных камней":
Пусть, например, алгоритм составляют 10 задач: 3 -- с наивысшим приоритетом, а 7 -- со средним и низким. Если длинные и наиболее часто вызываемые -- задачи с высшим приоритетом, то диспетчер всегда будет выбирать задачи с более высоким приоритетом, низкие задачи могут вообще не получить ресурсов. Стандартный выход из этой ситуации: организация равнодоступности. Это метод адаптивных приоритетов. Общий принцип: первый запуск программы прошел -- ее приоритет динамически понижается на единицу. В рассмотреном примере: максимум три цикла -- и задач с высшим приоритетом не останется. Второй вариант: в зависимости от времени ожидания в очереди начинать повышать приорите у задач, которые долго находятся в ожидании. Результат примерно тот же самый: ничего не может бесконечно ожидать освобождения ресурсов.
Этот метод является типовым для многопользовательских, в системах реального времени же недопустимо так "легко" менять приоритеты, применяется крайне редко. Еще есть корпоративная многозадачность, используемая Windows: Приоритеты у задач есть, но, если задача получила ресурс или управление, она будет выполняться до тех пор, пока не закончится.
Характерна же для СРВ -- приоритетная многозадачность с вытестнением: При выполнении какой-то задачи, если становится готовой задача с более высоким приоритетом, активная задача сохраняет свой контекст, а управление сразу же передается более приоритетной задаче. Вытеснение задачи может происходить как результат обработки прерывания, истечение заданного интервала времени, получение какого-либо сообщения (по внешнему событию).
Кроме того, из стандартных алгоритмов для конкретной системы может создаваться некоторый "микс": отдельные подсистемы могут работать каждая по своему алгоритму. Общий подход к выбору подхода: стараться реализовывать наиболее простой, которым можно обойтись. (Критерий выбора: оптимальность функционирования).
Одним из популярных алгоритмов, EDF (Earliest Deadline First), заключается в следующем:
управляющие воздействия сортируются по времени до наступления события (*не совсем так, но так понятней*). Кроме того, при планировании в реальной системе стоит выделить те задачи, которые относятся к режиму действительно жесткого времени и те задачи, которые легко и безболезненно можно отнести к режиму "мягкого" времени. Проведя такой анализ и разбив их на две группы, к каждой из них нужно применить свой алгоритм управления. Поэтому в реальных СРВ можно обнаружить несколько супервизоров. Что касается приоритетов: если без них можно обойтись, то от них следует отказаться. Если можно обойтись без специализированного ПО СРВ, то тоже от этого нужно отказываться.
Пример:
все испытательное оборудование относится к СРВ. Рассмотрим термо-барокамеры (температура, влажность, давление) -- делаются они на основе программируеммых микроконтроллеров. Одно необходимое прерывание: при опасности перегрева. Задачи: подогрев (можно обойтись без прерывания -- рассчитать по времени, когда необходимо остановить нагрев), влажность. Никакие задачи не вытесняют друг друга. Приоритеты не нужны. Ядро ОС СРВ (дорогое) не требуется, можно обойтись обычным (cpp, asm).