Лекция 5
1 окт 2012
Проблемы при выборе алгоритмов. Вообще, при подходе к СРВ принято считать так: если можно обойтись без СРВ, то нужно проектировать на простых средствах. Это будет экономия существенная на аппаратно-программных затратах.
Простейший пример:
Есть три переключателя, которые нужно опрашивать не реже 10 раз в секунду. В зависимости от их положения включать или выключать насос.
[рис. 1] -- потерял
-- особенность: мы не проводим никаких проверок по времени, потому что нет жесткой привязки по времени, а самый слабый современный процессов способен справляться с поставленными условиями.
Теперь пусть нам нужно производить тот же опрос строго 10 раз в секунду. Такие программы, чаще всего, пишутся на Си. Как известно, в Си есть функция установки какой-либо переменной в состояние, зависящее от таймера (по таймеру). Введем некоторую переменную t, которая будет устанавливаться в единицу каждые 100 мс. В этом случае придется модифицировать алгоритм:
[рис.2] -- потерял
-- вот такой алгоритм, в общем-то, как оценить? будет он успевать работать или нет? упростим его, вынесем определенную часть в подпрограмму:
[рис.3] -- потерял
-- работоспособность этого алгоритма будет определяться подпрограммой -- если она будет выполняться более 100 мс, получим типичные гонки (не успеем, будем терять данные) -- на простом микропроцессоре и жестком алгоритме мы уже результата не получим.
Стандарный метод решения проблемы: формировать в подпрограмме 3 рис. 3 только сообщения, а сообщения обрабатывать в другой части памяти и, получается, параллельно с обработкой самой системы. Также можно организовать очереди и приоритеты задач.
Как видим из второго примера, простейшее усложнение сильно меняет алгоритм.
Еще усложним задачу. К условию "опрашивать
ровно через 100 мс" нужно еще, кроме
положения переключателей, измерять
давление в технологических узлах, и,
например, при его величине больше 5
атмосфер открывать клапан, а при меньше
двух атмосфер -- включать насос. Т.о.,
должны держать: 
, 
.
По усливию 100 мс -- переключатели, 200 мс -- насос. Придется вводить еще одну переменную
[рис.4] -- первым запустим короткий цикл
(100 мс -- задача 1 -- задача опр./упр. 
)
Безупречно работавший ранее алгоритм
может стать некорректным даже при
незначительных изменениях.
Например, если увеличить число счетчиков до тысячи в первом случае.
Например, если нам нужно просчитывать и специально выбирать процессы.
Поэтому, хотя и простой циклический алгоритм является предпочтительным по реализации, к выбору такого алгоритма надо относиться крайне осторожно. Кроме того, такие алгоритмы очень критичны к минимальным изменениям.
Например, подключение еще одного дополнительного датчика.
Зато время выполнения написанных программ, особенно при нынешних интерпретаторах -- даже не требуют ассемблерных вставок.
Лекция 6
15/10/2012
RTLinux -- четко ориентирована на системы жесткого реального времени. Вторая модификация -- на разработку систем мягкого реального времени -- KURT. UTIME -- модуль работает с системными часами, он просто-напросто повышает тактовую частоту и за счет этого время работы (переключение контекстов) существенно повышается. Если стандартного кванта времени для решения задач хватает, UTIME использовать не надо. 10мс -- это вполне приемлемая реакция для большинства задач. Но если нужно поднять быстродействие с минимальными затратами, повысить тактовую частоту поможет UTIME.
Для KURT в ядро стандартного Linux внесено минимальное количество изменений. Самое главное: в этом проекте реализовано сразу 2 режима работы: Normal Mode и Real Time Mode. И можно переключаться с одного режима на другой. В некоторых источниках kurt называют планировщиком задач реального времени. Переключения из режима в режим могут происходить по событию или в заданных местах программы. Если работаем в режиме Normal -- стандартная логика, когда переходим в RealTime -- стандартная логика приостанавливается, и выполняется только задача реального времени, а потом продолжаем в Normal.
Если использовать только KURT, то время переключения не превышает 10мс, а если еще добавить UTIME, то можно уменьшить время переключения до 1мс.
API-интерфейсы в KURT разбиты на 2 большие группы: прикладные и системные. Системые реализуют планировщик задач и управляют пользовательскими процессами. Прикладная часть состоит всего из четырех функций:
set.rtparams // с помощью этой функции процесс переводится в режим выполнения в реальном времени
get num rtprocs // -- это установка идентификаторов процессов как таковых; чтобы их отличать друг от друга
rt suspend // -- приостановка процесса реального времени
get rt stats // -- позволяет установить процессу статус
// У планировщика задач СРВ существует таблица, по сути своей с приоритетами
Такой подход, в общем-то, для программирования предельно удобен и в основном используется для видео и аудио-процессов (мягкое реальное время). Для жесткого реального времени -- RTLinux.
Здесь совершенно другая идеология. Есть ядро реального времени. Базовый набор "linux-возможностей" запускается, как задача с более низким приоритетом. Все прерывания обрабатываются ядром реального времени. Для того, чтобы не было всяких там "смертельных захватов", имеется специальный драйвер, представляющий собой систему управления прерывания. Если не выполняется задача реального времени, то управленение передается стандартной конфигурации Linux. Все прерывания без исключения обрабатываются ядром реального времени. Прерывание анализируется и по особым признакам определяется, относится ли оно к реальному времени или нет -- драйвер их классифицирует на две группы. Прерывания реального времени обрабатываются ядром. Если нет -- задача передается в "базовую часть" Linux. Ядро реального времени никогда не ждет освобождения контекстов. // тут написано, каким образом. Для обмена данными между двумя этими частями ОС чаще всего используют разделяемые области памяти и подход "псевдоустройств" (задачи можно описывать несуществующими физическими устройствами). На ядро реального времени возлагается минимум задач: обработка прерываний и планирование задач реального времени. Все остальные системные задачи решает стандартное ядро Linux. С точки зрения модульности (чтобы иметь расширяемость) все процессы реального времени описываются как подгружаемые модули. Получается, что любую задачу реального времени выполняет как ядро релаьного времени, так и обыкновенные Linux-приложения. Если у нас речь идет о получении внешних каких-нибудь данных, то ядро реального времени фактически будет считывать их и помещать в очередь для стандартной части Linux и там будет происходить обработка этих данных. Этот подход теперь считается стандартным и для других ОС. Соответственно, в зависимости от того, какая задача, выбирается конкретная реализация ядра.
Очень многие крупные фирмы используют Linux для систем реального времени -- там удобная работа с API-интерфейсов. Кроме того, все это прекрасно отдокументировано на сегодняшний день. Лучше всего подходит для систем обработки в режиме реального времени аудио и видео, а также используется в системах промышленной реализации (но там RTL). iOS и Macintosh на основе Unix тоже.