Лекция 1
Режим реального времени
Термин в настоящее время не очень корректно используется в литературе. Системы реального времени и режим реального времени до сих пор не имеют универсального определения.
Рассмотрим наиболее частоупотребляемые:
Real-Time System -- система реального времени -- любая система, в которой существенную роль играет время генерации выходного сигнала (это определение связано с системами промышленной автоматизации).
Физико-химические процессы на предприятиях протекают с определенной скоростью. Полученные об этих процессах данные должны быть обработаны за время, соизмеримое со временем протекания самих процессов. Сама величина такого отклика может быть совершенно разной.
Рассмотрим самонаводящуюся ракету и печку, в которой булки пекут. Если возьмем время отклика, например, в секундах -- с булками ничего не будет (не пригорят даже), ракеты же успеют заметно изменить свое направление. А диспетчерская система управления движения пешеходами вообще требует время отклика с точностью до часов.
Время отклика определяется на стадии постановки задачи. В одних случаях его можно рассчитать, а в других случаях -- только практически определить какую-то практическую величину.
Real-Time Processing -- режим реального времени -- такой режим обработки данных, при котором обеспечивается взаимодействие вычислительной системы, в отношении к выполняемым действиям, в темпе, соизмеримым со скоростью самого процесса.
Один из действительно крупных ученых в этой области, Дональд Гиллельс , дал такое определение:
Системой реального времени является такая система, корректность функционирования которой определяется не только корректностью вычислений, но и временем, в которое получается требуемый результат.
Если не выполняется -- это авария, сбой системы. Желательной считается возможность получения в таких системах высокой степени использования ресурсов. Большинство таких систем строится на основе микропроцессоров и крайне редко на основе ПК. В них программная часть ограничена в объеме: в таких системах всегда ограничен объем оперативной памяти, количество внутренних ресурсов невелико, -- и это не позволяет сохранять контексты большого числа или сложных задач. В ряде случаев существенным является физический размер получаемого устройства.
Примеры систем реального времени (СРВ):
Роботизированное производство:
основа -- движущийся конвейер, робот позволяет определять действия для каждого экземпляра:
Риc.1 "Роботизированное производство"
-- необходимо обеспечивать физическое перемещение робота в нужную точку в нужное время.
Двойное ограничение: если плата не подошла -- ничего хорошего, если робот опоздал -- тоже брак. Такие системы дают экономический ущерб, здесь падает только качественное управление, а не вызывают фатальных последствий, но система будет относится к системе жесткого реального времени.
К таким системам относятся 99% военных АСУ и систем управления летательными аппаратами. Если датчик подачи топлива реактивного самолета сработает с большой задержкой или данные теряются, то качество управления падает (возможно, с самим самолетом).
Еще (пример: атомная энергетика, системы аварийной блокировки реакторов -- задержки на долю секунды дают неуправляемую ядерную реакцию.)
Еще одной интересной возм. выбора времени отклика являются системы с переходными процессами: снимает периодически какие-то состояния, через ЦАП идут на вычисления, а критерием выбора времени считается след. данных и получение результата по окончанию переходного процесса. Для стационарных процессов используется теорема Котельникова. Кроме этого существуют системы "мягкого" реального времени (СМРВ). В этих системах время отклика может изменяться в некоторых пределах или в каком-то проценте заданных случаев с запаздыванием. Для СМРВ определений четких еще не дано. С точки зрения теории они проработаны минимально, и для них критерии ограничений также выбираются так основе анализа предметной области в каждом конкретном случае. Примеры: аудиосистемы, например, автоматы выбора товаро в магазине (те самые, с кофе и сникерсами). Известная ошибка: причисление всех онлайн-систем к СРВ -- они интерактивные, но не обязательно СРВ (онлайн-заказы и т.п.) -- в них есть задержка, вносимая ОС, правда, совершенно незаметная клиенту в большинстве случаев. В настоящее время очень часто те системы, которые прост имеют высокое быстродействие, в рекламных целях называют СРВ. (Я знаю, и это отстой! -- прим. от меня). Для большинства промышленных систем время отклика порядка 100 мс. Если в системах реального времени должно выполняться все и всегда, притом за заданный интервал времени -- это жесткая система (иногда отклонения не допускаются), а если все и всегда, но с заданным возможным отклонением по времени -- то это мягкая система. Как правило, СРВ получают целый ряд ограничений в связи с необходимостью использовать определенные аппаратные средства.
Организация управления в срв
Все эти системы по определению многозадачные и многопоточные. Так или иначе, нужно управлять синхронизацтей, обменом между задачами, обращением к общим аппаратным ресурсам. Эти задачи решает ОС. До появления современных ОС уже существовали промышленные СРВ. При этом алгоритмы управления выполнялись жестко на аппаратном уровне. Если реализовывать относительно простые задачи, то при таком подходе очень экономится аппаратная часть, получается дешевле. Если использовать современные ОС и пытаться приспособить их для задач реального времени, то можно обнаружить, то большая часть функций будет не нужна -- таким образом, происходит переплата, занимается огромное количество ресурсов остальной части (можно уложиться в меньшее число) -- это нерационально. В большинстве систем выделяется ядро, которое выполняет необходимый минимум функций, а в специализированных ОС в составе ядра выделяется микроядро, в составе микроядра -- наноядро (для использования только тех ресурсов, что необходимы). Наращивание необходимого функционала происходит по модульному принципу, и заказчику можно быстро собрать систему минимального объема за минимальную стоимость, но при этом выполняющую все требуемые функции. На сегодняшний момент различают 3 стандартных вида структур систем реального времени:
с микроядром (см. рис. "Структура СРВ с микроядром")
Структура СРВ с микроядром
например: (32) -> (31) -- передача данных
монолитное ядро (см. рис. "Архитектура СРВ с монолитным ядром")
Архитектура СРВ с монолитным ядром
объектно-ориентированная структура (см. рис. "Объектно-ориент. архитектура СРВ")
Объектно-ориентированная архитектура СРВ
Выполняемые задачи и программы в такой системе внутри себя имеют потоки и ядро пользователя.
Лекция 2
(13/08/2012)
Особенности задач потоков и процессов в СРВ
В системах реального времени задачей называется набор операций, предназначенных для выполнения логически законченной функции системы. Все задачи в таких системах конкурируют за доступ к разделяемым ресурсам. Чаще всего это память, процессорное время и внешние устройства. Задачи делятся на потоки и процессы. Процесс -- всегда отдельно загружаемый модуль, имеющий независимые от других области памяти и данных. Потоки, в отличие от процессов, имеют общие области данных или программного кода. Эти особенности в одних случаях являются плюсами, в других -- минусами.
Плюсы потоков:
+ Несколько потоков могут быть размещены внутри одного модуля, это экономит занимаемое адресное пространство. Поскольку потоки имеют общие участки памяти или кода, то очень просто организуется межпоточный обмен какими-либо сообщениями. Обычно это реализуется с помощью указателей. У процессов, соответственно, сообщения с данными нужно копировать из одной области в другую, а размер сообщений может быть очень разным -- при больших объемах сообщений это очень затратно. Вообще говоря, можно организовать доступ от одного процесса к области другого процесса, но это довольно сложно алгоритмически и нужно самим такие механизмы разрабатывать и реализовывать (не является стандартной задачей).
+ Сравнительное время переключения между потоками и процессами: контекст потока (среднестатистический) меньше, чем процесса. Время сохранения контекста меньше -- переключение быстрее. -- Процесс отладки ПО достаточно сложный и трудоемкий. Отладчики работают обычно в пределах одного exe-модуля. Потоки можно упаковать в один exe-модуль. Иногда в этот же exe-модуль включается и само ядро ОС (процесс пошаговой отладки становится тогда существенно проще).
Минусы потоков:
- Потоки, прежде всего, как правило, не подгружаются динамически (теоретически это возможно, не нерационально). Чтобы добавить новый поток, надо изменить исходный текст и перекомпилировать его. Вообще говоря, система получается довольно-таки жесткой. Если мы работаем с процессами, то у них очень легко реализуется их динамическое подключение, а, значит, в процессе работы мы можем подключать и отключать процессы, получая достаточно гибкую систему. Кроме того, такой подход позволяет в ряде случаев обойтись минимальными аппаратными затрами (поскольку можно выгружать процессы), а для таких систем это очень важно. Кроме того, поскольку все модульное, то можно использовать уже готовые наработки или продукты других кампаний. Это существенно сокращает время разработки. (Например, работа с таймером уже написана для предыдущей системы -- модуль для новой системы можно не переписывать, а подключить). -- С одной стороны, общие области кода и данных -- вроде бы, удобно. С другой стороны, при этом очень вероятна ситуация, что один поток испортит данные другого. Напртимер, мы записываем данные четко в какой-то сектор диска: write sector N, где N -- номер сектора; У нас два потока -- один, например, пишет в пятый сектор, другой -- в седьмой. Подготовленны данные, с числом сектора 5 -- память ячеки процессора. Пусть тут приходит прерывание от более приоритетного потока (например, тот, который пишет в десять). Данные, которые должны были идти в сектор пять, запишутся уже поверх записанных в сектор 10 :( Такие варианты могут возникать достаточно часто, и интуитивно они ловятся программистом только достаточно опытным. Соответственно в процессах такие ситуации невозможны -- любая попытка залезть не в свою область вызывает прерывание :) Вопрос, что использовать, процессы или потоки. определяется разработчиком, исходя из условий поставленной задачи.