Что такое функционирование в «Реальном масштабе времени»

Что такое время реакции системы

Время реакции системы – это время от получения внешнего события до начала выполнения первой программы обработчика этого события.

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

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

Что такое «жесткое» и «мягкое» реальное время.

Принято различать системы «жест­кого» и «мягкого» реального времени. Эти различия не связаны с органолептическими свойствами систем.

1. Системой «жесткого» реального времени называется система, где не­способность обеспечить реакцию на какие-либо события в заданное время является отказом и ведет к невозмож­ности решения поставленной задачи.

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

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

2. Точного определения для «мягкого» реального времени не существует, поэтому будем считать, что сюда отно­сятся все системы реального времени, не попадающие в категорию «жестких». Так как система «мягкого» реального времени может не успевать все делать ВСЕГДА в заданное время, возникает проблема определения критериев ус­пешности (нормальности) ее функционирования. Вопрос этот совсем не простой, так как в зависимости от функций системы это может быть мак­симальная задержка в выполнении каких-либо операций, средняя своевре­менность отработки событий и т. п. Бо­лее того, эти критерии влияют на то, какой алгоритм планирования задач является оптимальным. Вообще говоря, системы «мягкого» реального времени проработаны теоретически далеко не до конца.

Рис. 2.3. Объектно-ориентированная ОС РВ

 

Кроме того, возможна следующая классификация ОСРВ:

1. Ядро РВ (ядро ОС, спроектированное специально для задач РВ). Этот тип ОС обычно не приспособлен для разработки ПО. Конфигурирование ОС этого типа осуществляется с помощью инструм. ОС.

2. Unix, адаптированный для задач РВ. Внутренняя структура Unix близка к СРВ и он доступен в исходных кодах.

3.Расширение ОС для задач РВ. Берется Windows NT или Linux и поверх его устанавливается специальный расширитель РВ.

Требования к ОСРВ

Большинство систем реального времени поддер­живают ядро или микроядро. Рассмотрим требования к операционной системе реального времени. Итак, операционная система реального времени должна:

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

2. реализовывать вытесняющее планирование с приоритетами. Это означает, в частности, что у каждой задачи должен быть свой приоритет;  

3. предоставлять механизмы синхронизации и обмена информацией между задачами;

4. давать задачам возможности захвата памяти. В СРВ с жесткими временными ограничениями парал.задачи обычно на­ходятся в памяти целиком. Это устраняет неопределенность и разброс во времени отклика, обусловленные подкачкой страниц. Механизм захвата па­мяти позволяет задаче с жесткими ограничениями по времени выполнения разместиться в оперативной памяти, не опасаясь, что ОС выгрузит ее;    

5. включать механизм наследования приоритета. Когда задача А входит в кри­тическую секцию, ее приоритет должен быть повышен. В про­тивном случае задача А может быть вытеснена другой высокоприоритетной задачей, которая не сумеет войти в эту же критическую секцию, поскольку она занята задачей А. Таким образом, высокоприоритетная задача окажется навечно заблокированной;

6. иметь предсказуемое поведение (например, при выполнении контекстного переключения, синхронизации задач и обработке прерываний). Это означа­ет, что максимальное время отклика должно быть прогнозируемо при лю­бой ожидаемой нагрузке на систему. Т.е. разработчики ОС должны специфицировать такие временные характеристики, как "задержка обработки прерывания" (interrupt latency), максимальное время маскировки прерываний, а также максимальное время исполнения всех системных вызовов. ОС должна обеспечивать предсказуемые механизмы для синхронизации между нитями и взаимодействия процессов, разрешающие проблему "инверсии приоритетов". Это означает, что как при передаче данных, так и при синхронизации нитей должно обеспечиваться "наследование приоритетов" (или эквивалентный механизм).

7. поддерживать вытесняющую многопоточность (preemptive multi-threading) и мультипроцессорные архитектуры.

8. Аппаратная арх-ра должна поддерживать несколько уровней прерываний (interrupt levels), а ОС должна обеспечивать вытеснение (preemption) обработчиков прерываний.

9. Способность работать в огранич.ресурсах, особенно это касается оперативной памяти.

10. Стоимость системы при массовых тиражах должна быть достаточно низкой.

11. обеспечивать API и "нижележащий" сервис, соответствующий по структуре и реализации требованиям систем реального времени.

Задачи, процессы, потоки

Существуют различные оп­ределения термина «задача» для многозадачной ОС РВ. Мы будем считать задачей набор операций (машинных инструкций), предназначен­ный для выполнения логи­чески законченной функции системы. При этом задача конкурирует с другими задачами за получение контроля над ресурсами вычислительной системы. Принято различать две разно­видности задач: процессы и пото­ки. Процесс представляет собой отдельно загружаемый программный модуль (файл), который, как правило, во время исполнения имеет в памяти свои независимые области для кода и данных. В отличие от этого потоки мо­гут пользоваться общими участками кода и данных в рамках единого про­граммного модуля. Хорошим примером многопоточ­ной программы является редактор текста WORD, где в рамках одного приложения может одновременно происходить и набор текста, и провер­ки правописания.

Преимущества потоков.

1. Так как множество потоков способ­но размещаться внутри одного EXE-модуля, это позволяет экономить ре­сурсы как внешней, так и внутрен­ней памяти. 2. Использование потоками общей об­ласти памяти позволяет эффективно организовать межзадачный обмен сообщениями (достаточно передать указатель на сообщение). Процессы не имеют общей области памяти. По­этому ОС должна либо целиком скопировать сообщение из области па­мяти одной задачи в область памяти другой (что для больших сообщений весьма накладно), либо предусмот­реть специальные механизмы, кото­рые позволили бы одной задаче по­лучить доступ к сообщению из об­ласти памяти другой задачи.

3. Как правило, контекст потоков меньше, чем контекст проц-в, а значит, время переключ-я м/у задачами-потоками меньше, чем м/у задачами-проц-ми. 4. Так как все потоки, а иногда и само ядро РВ размещаются в одном ЕХЕ-модуле, значительно упрощается ис­пользование программ-отладчиков (debugger).

Недостатки потоков.

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

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

Реализация механизмов управления процессами и потоками, возможность их взаимного сосуществования и взаи­модействия определяются конкрет­ным ПО РВ.

Основные свойства задач.

Как правило, вся важная, с точки зре­ния операционной системы, информа­ция о задаче хранится в унифициро­ванной структуре данных – управляющем блоке (Task Control Block , TCB). В блоке хранятся такие параметры, как имя и номер задачи, верхняя и нижняя границы стека, ссылка на очередь сооб­щений, статус задачи, приоритет и т. п.

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

Контекст задачи – это набор дан­ных, содержащий всю необходимую информацию для возобновления вы­полнения задачи с того места, где она была ранее прервана. Часто контекст хранится в TCB и включает в себя такие данные, как счетчик команд, указатель стека, регистры CPU и FPU и т. п. Плани­ровщик задач в случае необходимости сохраняет контекст текущей активной задачи и восстанавливает контекст за­дачи, назначенной к исполнению. Та­кое переключение контекстов и явля­ется, по сути, основным механизмом ОС РВ при переходе от выполнения од­ной задачи к выполнению другой.

Состояние (статус) задачи. С точ­ки зрения операционной системы, за­дача может находиться в нескольких состояниях. Число и название этих со­стояний различаются от одной ОС к другой. По-видимому, наибольшее чис­ло состояний задачи определено в язы­ке Ada. Тем не менее, практически в лю­бой ОС РВ загруженная на выполнение задача может находиться, по крайней мере, в трех состояниях.

1. Активная задача – это задача, выпол­няемая системой в текущий момент времени.

2. Готовая задача – это задача, готовая к выполнению и ожидающая у плани­ровщика своей «очереди».

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

8. Основные свойства задач. [ 2 ]

Пустая задача (Idle Task) – это зада­ча, запускаемая самой операционной системой в момент инициализации и выполняемая только тогда, когда в сис­теме нег других готовых для выполнения задач. Пустая задача запускается с самым низким приоритетом и, как пра­вило, представляет собой бесконечный цикл «ничего не делать». Наличие пус­той задачи предоставляет операцион­ной системе удобный механизм отра­ботки ситуаций, когда нет ни одной го­товой к выполнению задачи.

Многократный запускзадач. Как правило, многозадачные ОС позволя­ют запускать несколько копий одной и той же задачи. При этом для каждой та­кой копии создается свой TCB и выде­ляется своя область памяти. В целях экономии памяти может быть предус­мотрено совместное использ-е одного и того же исполняемого кода для всех запущенных копий. В этом случае прога должна обеспечивать повторную входимость (реентера­бельность). Кроме того, прога не должна использовать временные фай­лы с фиксир.именами и должна корректно осущ-ть до­ступ к глобальным ресурсам.

Реентерабельность (повторная входимость) означает возможность без негативных последствий временно пре­рвать выполнение какой-либо функции или подпрограммы, а затем вызвать эту функцию или подпрограмму снова. Частным проявлением реентерабельности является рекурсия, когда тело подпрограммы содержит вызов самой себя. Классическим примером нереентерабельной системы является DOS, a типичной причиной нереентерабель­ности служит использование глобаль­ных переменных.

Дальше идет пример, его, думаю, можно не писать:

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

Планирование циклических задач, кооперативная многозадачность

Важной частью любой ОС РВ являет­ся планировщик задач. Несмотря на то, что в разных источниках он может на­зываться по-разному (диспетчер задач, супервизор и т. п.), его функции оста­ются теми же: определить, какая из за­дач должна выполняться в системе в каждый конкретный момент времени. Самым простым методом планирова­ния, не требующим никакого специ­ального ПО и планировщика как тако­вого, является использование цикли­ческого алгоритма стиле round robin .

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

1. Подпрограммы не должны содер­жать циклов ожидания

2. Подпрограммы должны выполнять свою работу как можно быстрее, что­бы дать возможность работать следу­ющей подпрограмме.

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

Можно отметить следующие преиму­щества циклического алгоритма.

1. Простота использования и прозрач­ность для понимания.

2. Если исключить из рассмотрения прерывания, система полностью де­терминирована. Задачи всегда вызы­ваются в одной и той же последова­тельности, что позволяет достаточно просто произвести анализ «наихуд­шего случая» и вычислить макси­мальную задержку.

3. Минимальные размеры кода и дан­ных. Кроме того, в отличие от алго­ритмов с вытеснением, для всех задач необходим только один стек.

4. Отсутствуют ошибки, обусловлен­ные «гонками».

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

Кооперативная многозадачность – это еще один алгоритм переключе­ния задач, с которым широкие массы компьютерной общественности знакомы по oперационной системе Windows .. Задача, получившая управление, выполняется до тех пор, пока она сама по своей инициативе не передаст уп­равление другой задаче. По сути это продолжение идеологии round robin, и в чистом виде мало применяется в системах реального времени.

Планирование в режиме разделения времени

Одним из самых распространенных подходов к организации планирования является планирование в режиме разделения времени.

Существуют различные реализации в рамках этого алгоритма, и некоторые западные специалисты даже различают такие, в общем-то идентичные для нас понятия, как time - slicing (нарезание времени) и time - sharing (разделение времени). Как правило, алго­ритм реализуется следующим образом: каждой задаче отводится определен­ное количество квантов времени (обычно кратно 1 мс), в течение кото­рых задача может монопольно зани­мать процессорное время. После того как заданный интервал времени исте­кает, управление передается следую­щей готовой к выполнению задаче, имеющей наивысший приоритет. Та, в свою очередь, выполняется в течение отведенного для нее промежутка вре­мени, после чего все повторяется в сти­ле round robin. Легко заметить, что та­кой алгоритм работы может привести к определенным проблемам. Предста­вим, что в системе работают 7 задач, 3 из которых имеют высокий приоритет, а 4 – низкий. Низкоприоритетные за­дачи могут никогда не получить управ­ление, так как три высокоприоритет­ные задачи будут делить все процес­сорное время между собой. Единственную возможность для низкоприоритетных задач получить управление предоставляет ситуация, когда все высокоприоритетные задачи находятся в блокированном состоянии.

Для решения этой проблемы применяется прием, получивший название равнодоступность (fairness). При этом реализуется принцип адаптивной приоритетности, когда приоритет за­дачи, которая выполняется слишком долго, постепенно уменьшается, позво­ляя менее приоритетным задачам по­лучить свою долю процессорного времени. Равнодоступность применяется главным образом в многопользовательских системах и редко применяется в системах реального времени.

11. Алгоритм планирования – приоритетная задача с вытеснением

Приоритетная многозадачность с вытеснением – это, по-видимому, наиболее часто используемый в ОС РВ принцип планирования. Основная идея состоит в том, что высокоприо­ритетная задача как только для нее появляется работа, немедленно прерыва­ет (вытесняет) низкоприоритетную. Другими словами, если какая-либо задача переходит в состояние готовнос­ти, она немедленно получает управле­ние, если текущая активная задача имеет более низкий приоритет. Такое «вытеснение» происходит, например, когда высокоприоритетная задача по­лучила ожидаемое сообщение, освободился запрошенный ею ресурс, про­изошло связанное с ней внешнее со­бытие, исчерпался заданный интервал времени и т. п.

Виды синхронизации задач

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

1. Функции, выполняемые различны­ми задачами, связаны друг с другом. Например, если одна задача подго­тавливает исходные данные для дру­гой, то последняя не выполняется до тех пор, пока не получит от первой задачи соответствующего сообще­ния.

2. Необходимо упорядочить доступ не­скольких задач к разделяемому ре­сурсу.

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

4. Необходима синхронизация задачи по времени. Диапазон различ.ва­риантов в этом случае достаточно широк, от привязки момента выдачи какого-л. воздействия к точному астрономич.времени до про­стой задержки выполнения задачи на опред.интервал времени. Для решения этих вопросов использ-ся спец.аппарат.средства - таймеры.

Связанные задачи. Взаимное согласование задач с по­мощью сообщ-й является одним из важнейших принципов ОС РВ. Способы реализации межзадач.обмена от­лич-ся большим разнообразием.

Объем инфо, передаваемой в сообщ-ях, может меняться от 1 бита до всей свободной емкости памяти системы. Во многих ОС РВ компо­ненты ОС, так же как и пользоват.задачи, способ­ны принимать и передавать сообщ-я. Сообщения м.б. асинхронными (до­ставка сообщений задаче производится после того, как она в плановом порядке получит управление) и синхронными (циркуляция сообщений оказывает не­посредственное влияние на планирова­ние задач). Н-р, задача, пославшая сообщение, немедленно блокируется, если для продолжения ра­боты ей необходимо дождаться ответа, или если низкоприоритетная задача шлет высокоприор.задаче со­общ-е, к-рого последняя ожидает, то высокоприор.задача, если используется приоритетная многозадачность с вытеснением, не­медленно получит управление.

Иногда сообщения передаются через отведенный для этого буфер опред.размера («почтовый ящик»). При этом новое сообще­ние затирает старое, даже если послед­нее не было обработано.

Однако наиболее часто используется принцип, когда каждая задача имеет свою очередь сообщ-й, в конец ко­торой ставится всякое вновь получен­ное сообщ-е. Стандартный принцип обработки очереди сообщ-й по принципу «первым вошел, первым вы­шел» (FIFO) не всегда оптимально со­отв-т поставл.задаче. В нек-рых ОС РВ предусматривается та­кая возм-ть, когда сообщ-е от высокоприоритетной задачи обраб-ся в первую очередь (говорят, что сообщ-е наследует приоритет пославшей его задачи).

Иногда полезным оказывается не­посредств.управление приорите­том сообщений. Представим, что зада­ча послала серверу (драйверу) принте­ра несколько сообщений, содержащих данные для печати. Если теперь задача хочет отменить всю печать, ей надо послать соотв.сообщ-е с более высоким приоритетом, чтобы оно встало в очередь впереди всех по­сланных ранее заданий на печать.

Сообщение может содержать как са­ми данные, предназначенные для пере­дачи, так и указатель на такие данные. В последнем случае обмен может; производиться с помощью разделяемых облас­тей памяти, разделяемых файлов и т. п.

Синхронизация во времени

Как правило, в ОС РВ задается эталон­ный интервал (квант) времени, кото­рый иногда называют тиком (Tick) и ко­торый используется в качестве базовой единицы измерения времени. Размерность этой единицы для разных ОС рв может быть разной, как, впрочем, раз­ными могут быть набор функций и ме­ханизмы взаимодействия с таймером. Функции по работе с таймером используют для приостановки выполнения за­дачи на какое-то время, для запуска за­дачи в определенное время, для относи­тельной синхронизации нескольких задач по времени и т.п. Если в программе для ОС РВ вы увидите операнд delay (50), то, скорее всего, это обозначает, что в этом месте задача должна прер­ваться (блокироваться), а через 50 мс возобновить свое выполнение, а точнее, перейти в состояние готовности. Все это время процессор не простаивает, а решает другие задачи, если таковые имеются. Множество задач одновре­менно могут запросить сервис таймера, поэтому если для каждого такого запро­са используется элемент в таблице вре­менных интервалов, то накладные рас­ходы системы по обработке прерыва­ний от аппаратного таймера растут пропорционально размерности этой таблицы и могут стать недопустимыми. Для решения этой проблемы можно вместо таблицы использовать связный список и алгоритм так называемого дифференциального таймера, когда во время каждого тика уменьшается только один счетчик интервала времени. Для точной синхронизации таймера вычислительной системы с астрономическим временем могут применять­ся специальные часы с подстройкой по радиосигналам точного времени или навигационные приемники GPS, кото­рые позволяют воспользоваться атом­ными часами на борту орбитальных космических аппаратов, запущенных по программе Navstar.

20. Linux реального времени.

Для задач реального времени сообщество разработчиков Linux активно применяет специальные расширения – RTLinux, KURT и UTIME, позволяющие получить устойчивую среду реального времени. RTLinux представляет собой систему «жесткого» реального времени, а KURT (KU Real Time Linux) относится к системам «мягкого» реального времени. Linux-расширение UTIME, входящее в состав KURT, позволяет добиться увеличения частоты системных часов, что приводит к более быстрому переключению контекста задач.

Проект KURT характеризуется минимальными изменениями ядра Linux и предусматривает два режима работы – нормальный (normal mode) и режим реального времени (real-time mode). Процесс, использующий библиотеку API-интерфейсов KURT, в любые моменты времени может переключаться между этими двумя режимами. Программный пакет KURT оформлен в виде отдельного системного модуля Linux – RTMod, который становится дополнительным планировщиком реального времени. Данный планировщик доступен в нескольких вариантах и может тактироваться от любого системного таймера или от прерываний стандартного параллельного порта. Программист может переключаться из одного режима в другой по событиям, либо в определенных местах программы. При переключении в режим РВ все процессы в системе «засыпают» до момента освобождения ветви процесса реального времени. Это довольно удобно при реализации задач с большим объемом вычислений, по своей сути требующих механизмов реального времени, например в задачах обработки аудио- и видеоинфо.

Стандартно такты планировщика RTMod задаются от системного таймера – время переключения контекста задач реального времени (time slice) равно 10 мс. Используя же KURT совместно с UTIME, можно довести время переключения контекста задач до 1 мс. Прерывания обрабатываются стандартным для ОС Linux образом – через механизм драйверов.

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

Простота использования KURT позволяет с максимальным комфортом программировать задачи, требующие как функций реального времени, так и всего многообразия API-интерфейса Unix. Использ-е «мягкого» РВ обычно подходит для реализации мультимедийных задач, а также при обработке разного рода потоков инфо, где критично время получения результата. Совершенно другой подход применен при реализации в Linux «жесткого» РВ.

20. Linux реального времени. [2]

 

RTLinux – это дополнение к ядру Linux, реализующее режим «жесткого» реального времени, которое позволяет управлять различными чувствительными ко времени реакции системы процессами. По сути дела, RTLinux – это операционная система, в которой маленькое ядро реального времени сосуществует со стандартным POSIX-ядром Linux.

Разработчики RTLinux пошли по пути запуска из ядра реального времени Linux-ядра как задачи с наименьшим приоритетом. В RTLinux все прерывания обрабатываются ядром реального времени, а в случае отсутствия обработчика реального времени — передаются Linux-ядру. Фактически Linux-ядро является простаивающей (idle) задачей операционной системы реального времени, запускаемой только в том случае, если никакая задача реального времени не исполняется. При этом на Linux-задачу накладываются определенные ограничения, которые, впрочем, для программиста прозрачны.

Для обмена данными между операционными системами реального времени и Linux могут использоваться следующие механизмы: разделяемые области памяти; псевдоустройства, предоставляющие возможность обмена данными с приложениями реального времени.

Ключевой принцип построения RTLinux – как можно больше использовать Linux и как можно меньше собственно RTLinux. Действительно, именно Linux заботится об инициализации системы и устройств, а также о динамическом выделении ресурсов. «На плечи» RTLinux ложится только планирование задач реального времени и обработка прерываний.

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

21. Операционные системы реального времени и Windows

Сегодня становится широко распространенным желание потребителей использовать Windows NT в СРВ. Для этого имеется ряд весомых, на первый взгляд, причин: Win32 API считается стандартом, а на его базе разработано огромное количество программ; графический интерфейс стал сегодня очень популярным; для NT имеется немало готовых решений для коммерческих применений; в среду NT включены многие виды средств разработки.

NT – многонитевая ОС, она позволяет вытеснение, что удовлетворяет одному из требований к ОСРВ.

2-ое требование к ОСРВ связано с тем, что диспетчеризация должна осуществляться по приоритетам. В Windows NT имеются два класса приоритетов: класс реального времени и динамический класс. Процессы в классе реального времени имеют фиксированный приоритет, менять который может лишь само приложение, тогда как приоритет процессов динамического класса может меняться диспетчером. Процесс имеет базовый уровень приоритета. Нить в процессе может иметь приоритет в диапазоне плюс/минус 2 около баз.ур-ня или один из двух крайних ур-ней класса (16 или 31 для реального времени). Очевидно, что гарантировать предсказуемость системы можно только при использ-и процессов первого класса.

Казалось бы, 2-е требование также удовлетворено. Но малое число возможных уровней препятствует реализации СРВ на базе NT. Больш-во соврем. ОС РВ позволяет иметь по крайней мере 256 различных ур-ней. Чем больше имеется ур-ней, тем более предсказуемо поведение системы. В Windows NT имеется только 7 различных ур-ней для нити в данном процессе. В рез-те многие нити будут выполняться с одинаковыми приоритетами и, как следствие, предсказуемость поведения системы будет посредственной.

В ОС РВ вызовы системы синхронизации (семафоры или критические секции) должны уметь управлять наследованием приоритетов. В Windows NT это невозможно, поэтому это требование к ОСРВ не удовлетворяется.

Таким образом, малое число приоритетов и невозможность решить проблему инверсии делают Windows NT пригодной только для очень простых СРВ.

Т.о. даже поверхностный анализ Windows NT показывает, что эта система не годится для построения систем жесткого РВ (система непредсказуема - время выполнения системных вызовов и время реакции на прерывания сильно зависит от загрузки системы; система велика; нет механизмов защиты от зависаний и пр.). Поэтому даже в системах мягкого РВ Windows NT м.б. использована только при выполнении ряда рекомендаций и ограничений.

21. Операционные системы реального времени и Windows [2]

Разработчики расширений пошли двумя путями:

– использовали ядра классических операционных систем реального времени в качестве дополнения к ядру Windows NT. Таковы решения фирм "LP Eleknroniks" и "Radisys". В первом случае параллельно с Windows NT (на одном компьютере!) работает операционная система VxWorks, во-втором случае - InTime. Кроме того, предоставляется набор функций для связи приложений реального времени и приложений Windows NT. Технология использования двух систем на одном компьютере понятна - работу с объектом выполняет приложение реального времени, передавая затем результаты приложениям Windows NT для обработки, передачи в сеть, архивирования и пр.

– вариант расширений реального времени фирмы VenturCom выглядит иначе: здесь сделана попытка "интегрировать" реальное время в Windows NT путем исследования причин задержек и зависаний и устранения этих причин с помощью подсистемы реального времени. Предложения VenturCom характерны еще и тем, что они предоставляют совершенно экзотическую для NT возможность, а именно - возможность конфигурирования Windows NT и создания встроенных конфигураций (без дисков, клавиатуры и монитора).

Область применения расширений реального времени - большие системы реального времени, где требуется визуализация, работа с базами данных, доступ в интернет и пр.

22. Операционная система QNX.

ОС QNX была создана программистами компании QNX Software System Ltd. в 1981 году и с этого момента она заняла лидирующее место среди СРВ, существующих на тот момент на рынке. ОС QNX смогла занять лидирующее положение благодаря многим особенностям, присущим только ей.

QNX – это первая коммерческая ОС, построенная на принципах микроядра и обмена сообщениями. Система реализована в виде совокупности независимых (но взаимодействующих через обмен сообщениями) процессов различного уровня (менеджеры и драйверы), каждый из которых реализует определенный вид сервиса. Эти идеи обеспечили ряд важнейших преимуществ.

Предсказуемость, означающую ее применимость к задачам жесткого реального времени. Ни одна версия Unix не может достичь подобного качества, поскольку нереентерабельный код ядра слишком велик. Любой системный вызов в Unix может привести к непредсказуемой задержке. То же самое относится к Windows NT, где реальное время заканчивается между ISR (первичный обработчик прерывания) и DPC (вызов отложенной процедуры).

Масштабируемость и эффективность, достигаемую оптимальным использованием ресурсов и означающую ее применимость для встроенных (embedded) систем. В каталоге /dev нет огромной кучи файлов, соответствующих ненужным драйверам. Драйверы и менеджеры можно запускать просто из командной строки. И удалять (кроме файловой системы J) динамически. Можно иметь только тот сервис или те модули, к-рые реально нужны, причем это не требует серьезных усилий и не порождает проблемы.

Расширяемость и надежность одновременно, поскольку написанный вами драйвер не нужно компилировать в ядро, рискуя вызвать нестабильность системы. Менеджеры ресурсов (сервис логического уровня) работают в кольце 3, при этом можно добавлять свои, не опасаясь за систему. Драйверы работают в кольце 1 и могут вызвать проблемы, но не фатального характера. Кроме того, их достаточно просто писать и отлаживать. Например, постоянная головная боль разработчиков драйверов для Linux – получение физически непрерывного блока памяти для DMA-устройств – устраняется просто и элегантно, через функцию mmap().

Быстрый сетевой протокол FLEET, прозрачный для обмена сообщениями, автоматически обеспечивающий отказоустойчивость, балансирование нагрузки и маршрутизацию между альтернативными путями доступа. Он не так универсален, как TCP/IP, но гораздо проще в использовании и эффективнее.

22. Операционная система QNX. [2]

Богатый выбор графических подсистем, включающий QNX Windows, X11R5 и Photon, что позволяет разработчикам выбирать ту, которая лучше подходит для их целей. Для типичных областей применения QNX традиционная система X11 слишком тяжеловесна, но система Photon, построенная на тех же принципах модульности, что и сама QNX, позволяет получить полнофункциональный GUI (типа Motif 2.0), работающий вместе с POSIX-совместимой ОС всего в 4 Мбайт памяти.

Недостатки:

– нет поддержки SMP;

– нет своппинга виртуальной памяти на диск;

– неэффективная и нестандартная поддержка нитей (threads);

– нет поддержки Java (как следствие предыдущего пункта);

– нет поддержки отображения файлов в память;

– многочисленные ограничения файловой системы;

– нет поддержки Unix - domain sockets;

– слабые средства разграничения и контроля доступа пользователей;

– отсутствие средств безопасности в рамках собственного сетевого протокола.

Стандарт POSIX.

Стандарт POSIX. POSIX (Portable Operating System Interface Standard – стандарт переносимо­го интерфейса операционной системы) – это стандарт разработки программного обеспечения операционных систем, принятый IEEE. Обычно его называют POSIX 1003. POSIX основан на операционной системе UNIX – наиболее распространен­ной переносимой ОС. POSIX 1003.1 определяет базовые сервисы операционной системы, POSIX 1003. b – расширения для режима реального времени, а POSIX 1003.1с – расширения для параллельной обработки.

Как следует из названия, POSIX - это стандарт на сопряжение (интерфейс) между операционной системой и прикладной программой. В тексте POSIX неоднократно подчеркивается, что стандарт не выдвигает никаких требований к деталям реализации операционной системы; его можно рассматривать как совокупность договоренностей между прикладными программистами и разработчиками операционных систем.

Одним из важнейших свойств стандарта POSIX является то, что он определяет "стандартизованный программный интерфейс", которого должны придерживаться разработчики сложных программно-аппаратных систем.

Стандарт POSIX 1003.1 задает библиотечные функции, которые должна поддер­живать любая POSIX-совместимая система UNIX, например open , read и fork. POSIX 1003.1b определяет стандартный интерфейс операционной системы реаль­ного времени: системные вызовы, списки параметров и информацию о состоянии, возвращаемую каждым вызовом.

 

В стандарте POSIX 1003.1b указаны следующие сервисы:

1. Сервисы для управления параллельными задачами. Следующие три сервиса предоставляют средства для обмена информацией между задачами и для синхронизации:

– двоичные семафоры;

– сигналы реального времени;

– передача сообщений. Этот сервис позволяет задаче с наивысшим приори­тетом получать процессор по первому запросу, а значит, гарантирует быс­трую реакцию для наиболее критичных по времени задач;

– вытесняющее планирование с приоритетами;

2. Сервисы времени.

Следующий сервис важен для реализации событий таймера с высоким раз­решением и выполнения измерений в системах реального времени:

– часы и таймеры реального времени;

24. Стандарт POSIX. [2]

 

3. Сервисы управления памятью:

– захват памяти задачей (см. следующий раздел);

– файлы, проецируемые на память, и разделяемая память;

4. сервисы ввода/вывода:                                        

– синхронный ввод/вывод;                  

– асинхронный ввод/вывод. Этот сервис необходим для реализации пере­крытия между процессорными вычислениями и вводом/выводом.

Стандарт POSIX 1003.1с добавляет к POSIX спецификацию параллельных потоков, которые позволяют программе запускать несколько экземпляров проце­дуры, выполняемых в раздельных потоках управления (задачах). Исполняемая программа представляет собой тяжеловесный процесс, имеющий собственное ад­ресное пространство. Поток внутри него – это облегченный процесс.

В терминологии POSIX тяжеловесные процессы называются просто процес­сами, а облегченные процессы – потоками (thread). Все потоки внутри данного процесса функционируют в одном и том же адресном пространстве.

Системы реального времени

1. Что такое функционирование в «Реальном масштабе времени»

2. Приведите примеры функционирования в реальном масштабе времени.

3. Что такое время реакции системы.

4. Что такое «жесткое» и «мягкое» реальное время.

5. Классификация операционных систем реального времени.

6. Требования к операционной системе реального времени.

7. Задачи, процессы, потоки

8. Основные свойства задач

9. Планирование циклических задач, кооперативная многозадачность.

10. Планирование в режиме разделения времени.

11. Алгоритм планирования – приоритетная многозадачность с вытеснением.

12. Виды синхронизации задач

14. Синхронизация доступа задач к общему ресурсу.

15. Семафоры.

16. Критические секции, мутексы.

17. Смертельный захват, инверсия приоритетов.

18. Синхронизация задач с внешними событиями.

19. Синхронизация по времени.

20. Linux реального времени

21. Операционные системы реального времени и Windows

22. Операционная система QNX .

23. Контекстное переключение задач.

24. Стандарт POSIX.

 

Вопросы по алфавиту:

Linux реального времени (20. )

Алгоритм планирования – приоритетная многозадачность с вытеснением. (11.)

Виды синхронизации задач (12. )

Задачи, процессы, потоки (7. )

Классификация операционных систем реального времени. (5.)

Контекстное переключение задач. (23. )

Критические секции, мутексы. (16. )

Операционная система QNX. (22. )

Операц-е с-мы реального времени и Windows (21)

Основные свойства задач (8. )

Планирование в режиме разделения времени. (10. )

Планирование циклических задач, кооперативная многозадачность. (9. )

Приведите примеры функционирования в реальном масштабе времени. (2. )

Семафоры. (15. )

Синхронизация доступа задач к общему ресурсу (14. )

Синхронизация задач с внешними событиями. (18. )

Синхронизация по времени. (19. )

Смертельный захват, инверсия приоритетов. (17. )

Стандарт POSIX. (24. )

Требования к операционной СРВ (6. )

Что такое «жесткое» и «мягкое» реальное время. (4. )

Что такое время реакции системы. (3. )

Что такое функционирование в «Реальном масштабе времени» (1. )

 

Что такое функционирование в «Реальном масштабе времени»

Существует множество определений СРВ.

Толковый словарь по вычислительным системам дает такое определение:

СРВ – любая система, в которой существенную роль играет время генерации выходного сигнала. Это обычно связано с тем, что входной сигнал соответствует каким-то изменениям в физическом процессе, и выходной сигнал должен быть связан с этими же изменениями. Временная задержка от получения входного сигнала до выдачи выходного сигнала должна быть небольшой, чтобы обеспечить приемлемое время реакции. Время реакции является системной характеристикой: при управлении ракетой требуется реакция в течении нескольких миллисекунд, тогда как для диспетчерского управления движением пароходов требуется время реакции, измеряемое днями. Системы обычно считаются системами реального времени, если время их реакции имеет порядок миллисекунд; диалоговыми считаются системы со временем реакции порядка нескольких секунд, а в системах пакетной обработки время реакции измеряется часами или днями. Примерами систем реального времени являются системы управления физическими процессами с применением вычислительных машин, системы торговых автоматов, автоматизированные системы контроля и автоматизированные испытательные комплексы.

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

Каноническое определение системы реального времени дано Дональдом Гиллиесом и выглядит так:

«Системой реального времени является такая система, корректность функционирования которой определяется не только корректностью выполнения вычислений, но и временем, в которое получен требуемый результат. Если требования по времени не выполняются, то считается, что произошел отказ системы». Другие добавляют: «Поэтому необходимо, чтобы было гарантировано [аппаратными и программными средствами и алгоритмами обработки] выполнение требований по времени. Гарантия выполнения требований по времени необходима, чтобы поведение системы было предсказуемо. Также желательно, чтобы система обеспечивала высокую степень использования ресурсов, чтобы удовлетворять требованиям по времени [с минимальными затратами]».

Термин «система реального времени» не означает, что система дает ответ на воздействие мгновенно – задержка может достигать секунд и более – но означает тот факт, что гарантируется некоторая максимально возможная величина задержки ответа, что позволяет системе решать поставленную задачу.

Термин «система реального времени» в настоящее время может быть записан так: “Системой реального времени является такая система, корректность функционирования которой определяется не только корректностью выполнения вычислений, но и временем, в которое получен требуемый результат. Если требования по времени не выполняются, то считается, что произошел отказ системы”.

2. Приведите примеры функционирования в реальном масштабе времени

Примерами систем реального времени являются системы управления физическими процессами с применением вычислительных машин, системы торговых автоматов, автоматизированные системы контроля и автоматизированные испытательные комплексы.

Хорошим примером является робот, который должен брать что-либо с ленты конвейера. Объекты на конвейере движутся, и робот имеет некоторый небольшой интервал времени для того, чтобы схватить объект. Если робот опоздает, то объекта уже не будет на месте, и поэтому работа будет неверной, даже если робот переместил захват в правильное положение. Если робот поспешит, то объекта там еще не будет, более того, робот может заблокировать движение объектов.

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

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

12345Следующая ⇒

Поделиться: