Windows это система реального времени

Начать хочу с благодарности Антону, который открыл тему и сформулировал очень сложные вопросы ответы на некоторые из которых (на многие, как мне кажется) мне представляются очевидными, хотя и объемными в изложении в соответствии с этой своей сложностью. Собственно, я и хочу изложить эти ответы и продемонстрировать их очевидность, а также откуда берется и с чем связана указанная сложность, которая трансформируется в объем и как и почему она в него трансформируется.

Исходная статья лежит здесь

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

системы управления автоматической системой усиления на основе измерения мощности по периодическим прерываниям АЦП и выводом рассчитанного коэффициента в ЦАП на фоне постоянного статусного-управляющего обмена по последовательной шине,

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

Еще очень впечатляют и восхищают вот такие заявления:

«Вы путаете Embedded OS и RTOS, между ними нет строгого знака равенства. Отсюда и весь посыл статьи заведомо ошибочен.»

Хочется спросить, а вы на какие определения того и другого опираетесь, а вы уверены, что они придуманы не для того, чтобы их путать? Ведь если между ними нет строгого знака равенства, это значит между ними есть НЕ строгий знак равенства. А раз есть хоть какой-то знак равенства то почему же их не спутать? Получается заявление противоречит само себе: утверждает, что они очень похожи, но запрещает их путать. Заявление достойно какой то блондинки, а блондинки всегда у меня вызывают восхищение .

Про термины и их определения

Дело в том, что термины всегда вводятся с какой-то целью и самая естественная цель — это сократить объем документации в которой используется термин за счет того, что не надо повторять разные составляющие определения этого термина. Я думаю (наверно даже знаю) ОСРВ это что-то гораздо больше термина который предполагается использовать в таких целях. ОСРВ скорее тянет на название стандарта, описывающего такой тип Операционных Систем или … на термин из области маркетинга, цель которого просто обратить внимание – выделить позиционируемый под таким названием продукт, воспользоваться модным названием, полное значение которого надо неделю изучать по иностранным (поскольку отечественных не существует), а значит малодоступные стандартам. Поэтому строгого определения, скажем на пол страницы, для ОСРВ не существует, существуют стандарты, которые определяют такое понятие страниц на 10-50-100, я не проверял. Причем какой-нибудь медицинский стандарт по этому поводу может быть совершенно не согласованным с подобным авиационным стандартом.

Multimedia systems некоторые определяют как SOFT системы реального времени

Теперь давайте вернемся к провокационному вопросу в заголовке, Windows тоже RTOS? Конечно, одна из целей такого провокационного вопроса в заголовке привлечь внимание к статье (иначе зачем я ее пишу, если не надеюсь на интерес аудитории!)

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

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

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

По поводу предлагаемой к рассмотрению задачи: я с удивлением нашел у Антона в статье что в иностранной практике multimedia systems тоже рассматриваются как системы реального времени:

Another kind of real-time system is a soft real-time system, in which missing an occasional deadline, while not desirable, is acceptable and does not cause any permanent damage. Digital audio or multimedia systems fall in this category. Digital telephones are also soft real-time systems.

Я одно время очень плотно и успешно работал над этой всем известной задачей, которая, как, надеюсь будет видно из моего опыта, очень близка (как минимум) к задачам реального времени, это задача декодирования-проигрывания видео. Не все осознают, что цель этой задачи именно управление «железом»: устройствами отображения и воспроизведения звука именно в реальном времени, хотя, по-моему, это очевидно. Задача задает четкие требования по времени отображения очередного кадра и синхронизации отображения кадров со звуком. Если у вас кино записано с частотой, скажем, 25 (а бывает и 50, и 60) кадров в секунду, это значит у вас есть 1000/25 = 40 мс чтобы:

1. прочитать данные из файла (из источника данных)

2. разделить потоки видео и аудио

3. декодировать аудио фрейм

4. декодировать достаточно аудио данных

5. записать видео данные в аппаратный буфер отображающего устройства (циркулярный буфер фреймов видеокарты)

6. записать аудио данные в аппаратный циркулярный буфер звукового устройства (вовремя записать!)

7. в нужный момент, в соответствии с периодом (40 мс) дать команду видеокарте на переключение отображаемого фрейма

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

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

Еще для справки, очень среднего разрешения кино имеет фрейм размером 640 х 480 = 307 200 х 4 байта для передачи цвета = 1,228,800 байт – больше Мега байта данных надо пересылать в видео буфер каждые 40 мс, это уже не какая то мгновенная операция копирования, потом надо еще учитывать задержку аппаратуры, копируем, все таки, в аппаратный буфер.

У нас для задачи четко определен интервал времени, который должен быть выдержан для того, чтобы работа программы реализующей задачу была успешной, но с какой точностью мы должны выдерживать этот интервал? Какие отклонения от среднего допустимы, 5 мс, 10 мс, … можно позволить? Как это выбрать?

Как не странно это звучит у человеческого глаза тоже есть технические характеристики , мы не замечаем пульсации света примерно меньше 1/7 секунды, собственно отсюда и взялись 25 кадров в секунду – это с запасом для особо чувствительных. Получается, что можно в принципе даже один фрейм иногда пропустить если получится сделать это так, что программа при этом не упадет (для тех, кто понимает сложность реализации такой фичи).

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

Что же в этом сложного? Дело в том, что чтобы измерять время нужно время! И это не тавтология — это рефлексия, это замкнутый круг, в который тем не менее надо в начале корректно войти, корректно отсчитывать периоды, и в конце корректно выйти.

А где же катастрофа? или критерий критичности задачи

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

Но представьте, что вы занимаетесь техническим обеспечением трансляции важного выступления уважаемого руководителя в очередном 37 году. Задача станет не только задачей реального времени во всех смыслах этого словосочетания, задача станет задачей фатальной ответственности. Таким образом, можно видеть, что критичность задачи — параметр достаточно условный, и я бы даже сказал очень субъективный – то что для одного будет безделицей для другого легко может стать трагедией и катастрофой. Вряд ли можно ориентироваться на такой субъективный параметр в технических вопросах, задачу в любом случае надо решать надежно и эффективно. А если есть задача ее решение должно обеспечить стабильность и эффективность использования системных и аппаратных ресурсов.

Про Операционную Систему саму по себе

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

Как говорил Мюллер Штирлицу: «Никому нельзя верить, Мне можно!», но в данном случае мне можно верить, потому что я начинаю с определения.

Так вот можно попробовать сформулировать что такое Операционная Система (ОС) вообще. Мне нравится мое определение (не только по понятной причине, но и по тому к каким очевидным выводам оно ведет):

ОС — это программа, которая определяет доступные пользователю операции из расширяемого списка, для примера:

1. открыть-запустить на исполнение файл

2. все операции с файлами: копировать, удалить, …

3. Создать/удалить поток (thread)

4. Создать/удалить семафор

5. Стандартные операции ввода в стандартной консоли или все возможные операции с окнами

6. Поддержка операций copy/past между исполняемыми модулями (поверьте имеет очень интересную реализацию на системном уровне)

7. Удалите все что вам не нравится

8. Добавьте свое

с сущностями, которые определены в этой ОС для операций пользователем или исполняемым модулем из расширяемого списка, для примера:

1. Файлы данных

2. Файлы исполняемые (я, и многие я думаю, знают примеры ОС которые не работают с файлами)

3. Файлы библиотек (статических, динамических)

4. Устройства и их программы обслуживания-доступа, известные как драйвера,

5. Семафоры, потоки, мутексы, …

6. Задачи, процессы, исполняемые модули (исполняемые в данный момент, либо в любом другом состоянии из списка состояний определенным данной ОС, опять же!)

7. Консоли, Окна, любые объекты для визуального взаимодействия с ОС

8. Удалите все что вам не нравится

9. Добавьте свое

Мы видим, что при определении ОС нам тоже не обойтись без рефлексии. ОС определяется тем, что сама эта ОС может делать, и тем, что она определяет как управляемые сущности в рамках себя самой!

Если мы вводим какое-то уточненное название как Real Time ОС понятно, что мы должны уточнить это общее определение для просто ОС.

Что же мы можем уточнить в общем определении ОС что бы было понятно, что имеется в виду именно РТОС? По-моему, совершенно очевидно: мы должны внести в расширяемый список операций тот набор обязательных операций, которые должна поддерживать РТОС!!!

Почему-то никто даже не пытается посмотреть на Операционную Систему с точки зрения вот этих самых операций, для которых она и есть система, система с операциями, система в которой существуют(живут) операции!

Как же добиться характеристик реального времени (или универсальность математики)

Такой интересный заголовок (без добавки) есть у Антона в статье.

Я думаю, Антон хотел сказать что-то вроде:

Так чем же все-таки определяется принадлежность ОС к разряду Операционных Систем реального времени?

И предлагается ответ, с которым трудно не согласиться: «Это время и предсказуемость.»

Единственное, мне кажется тут следует дополнить или где-то даже поправить это заключение.

Принадлежность к ОСРВ определяется все-таки не просто временем (временем чего?), а предоставленной системой возможностью контролировать время:

1. измерять время

2. задавать периоды

3. назначать время событий, исполнения процедур, … — чего угодно из того, что определено в ОС (см. список сущностей ОС)

И очень интересно получается с предсказуемостью:

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

Покажем, что предсказуемость считается через разрешение по времени (кстати тут опять рефлексия или как это здесь называется? Разрешение по времени — это производная величина от времени которая имеет размерность времени).

Поясню на примере: если мы задаем время некоторого события скажем в мили секундах как Т мс от текущего времени мы можем ожидать что:

Событие произойдет через время Treal такое что Т <= Treal < (T+1 МИЛЛИ секунда), то есть в этом случае мы исходим из того что разрешение по времени которое обеспечивает нам система это 1 мили секунда!

Но ведь вполне может оказаться что Т <= Treal < (T+1 МИКРО секунда), так как система обеспечивает нам разрешение по времени в МИКРО секундах. Никто же не может запретить нам использовать миллисекунды если можно использовать ДАЖЕ микросекунды!

Я думаю, всем понятно, что предсказуемость момента события в течение 1 мкс в 1000 раз выше, чем предсказуемость момента события в течение миллисекунды.

Из этого примера видно, что предсказуемость — это не абсолютная величина – это величина отношения разрешений по времени! Предсказуемость момента события в первой системе в 1000 раз меньше, чем предсказуемость момента события во второй системе и зависит это от разного разрешения по времени которое обеспечивают эти две системы, точнее от отношения этих разрешений.

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

P.S.

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

Несмотря на то, что сегодня Windows NT не отвечает в полной мере требованиям, предъявляемым к операционной системе реального времени, давление рынка привело к появлению коммерческих решений, расширяющих NT возможностями обработки в реальном времени.

1. «Жесткие» и «мягкие» системы реального времени

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

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

Еще одним важным требованием к СРВ является одновременная обработка событий: если несколько событий происходят одновременно, все они должны быть обработаны своевременно. Это означает, что имманентным свойством системы реального времени должен быть параллелизм. Чтобы этого добиться, необходимо установить более одного процессора или придерживаться многозадачного подхода.

В зависимости от отношения к опозданиям системы реального времени делятся на «жесткие» (hard) и «мягкие» (soft).

В жесткой системе:

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

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

В мягкой системе реального времени:

• повышается стоимость опоздания;
• допускается низкая производительность в случае опоздания.

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

Итак, разница между жесткой и мягкой системами зависит от предъявляемых к ним требований. Система называется жесткой, если «система не должна опаздывать никогда», и мягкой, если «система не должна опаздывать, как правило».

Не следует путать операционную систему реального времени (ОС РВ) с системой реального времени. Первая ОС используется для создания системы реального времени. ОС РВ должна быть предсказуемой — это не значит, что она должна быть быстрой, это означает, что при построении СРВ можно добиться того, чтобы максимальное время, затрачиваемое на определенную работу, укладывалось в заранее установленный лимит, сравнимый с требованиями приложения. Windows 3.11, например, даже на сколь угодно быстром процессоре бесполезна для построения СРВ, поскольку любое приложение может захватить управление и заблокировать все остальное.

2. Удовлетворяет ли Windows NT требованиям, предъявляемым к ОС РВ?

2.1. Нити и приоритеты

Очевидно, что NT — многонитевая ОС, она позволяет вытеснение и тем самым удовлетворяет требованию 1 (см. врезку).

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

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

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

Еще одна проблема обусловлена реализацией некоторых вызовов системы GUI. Они обрабатываются синхронно (вызывающая нить приостанавливается, пока не завершится системный вызов) процессом, выполняемым с более низким приоритетом (динамического класса). В результате нить может помешать нити с более высоким приоритетом — возникает инверсия приоритета.

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

2.2. Предсказуемость системных вызовов Win32 API

Для тестирования системных вызовов был написан процесс (принадлежащий классу реального времени), содержащий вызовы системы синхронизации нитей, и измерялось время, затраченное на каждый вызов. При запуске на Pentium 100 МГц с 24 Мбайт памяти оказалось, что максимальное значение на вызове mutex достигает 670 мкс при среднем времени 35 мкс. Это произошло потому, что во время работы теста происходили обращения к диску и по сети. Если компьютер искусственно загрузить обращениями к диску и сетевой обработкой, то задержки возрастают аж до нескольких миллисекунд. Win32 API очень богат, но не предназначен для реального времени. Например, запросы mutex обрабатываются в порядке поступления, а не в порядке приоритетов, что снижает предсказуемость. Для синхронизации нитей в одном процессе критические секции следует предпочесть всем другим способам (этот вызов затрачивает всего несколько мкс по сравнению с 35 мкс на вызов mutex).

Несмотря на все достоинства API, ядро и менеджер ввода/вывода Windows NT недостаточно приспособлены к обработке событий реального времени на уровне приложений.

2.3. Управление прерываниями в NT

В Windows NT единственный способ управления аппаратурой — через драйвер устройства. Поскольку приложение реального времени имеет дело с внешними событиями, разработчик должен написать и включить в ядро драйвер устройства, дающий доступ к аппаратуре. Этот драйвер реагирует на прерывания, генерируемые соответствующим устройством.

Прерывания обрабатываются в два этапа. Сначала выполняется очень короткая программа обслуживания прерываний (ISR). Впоследствии работа завершается выполнением DPC — процедуры отложенного вызова. Возникает следующий поток событий:

• Происходит прерывание.
• Процессор сохраняет PC, SP и вызывает диспетчер.
• ОС сохраняет контекст и вызывает ISR.
• В ISR выполняется критическая работа (чтение/запись аппаратных регистров).
• DPC ставится в очередь.
• ОС восстанавливает контекст.
• Процессор восстанавливает PC, SP.
• Ожидающие в очереди DPC выполняются на уровне приоритета DISPATCH_LEVEL.
• После завершения всех DPC ОС переходит к выполнению приложений.

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

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

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

2.4. Управление памятью в NT

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

3. Может ли Windows NT использоваться в качестве ОС РВ?

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

• загрузка CPU низка (DPC имеют достаточно времени);
• критическая работа (или даже вся) делается на уровне DPC или (еще лучше) на уровне ISR. В таком случае непонятно, зачем вообще нужна ОС.

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

a) Класс процессов реального времени должен иметь больше уровней.

б) Необходимо решить проблему инверсии приоритетов.

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

г) Система прерываний должна быть заменена целиком:

• DPC должны иметь много уровней приоритетов.
• DPC должны быть вытесняемыми более приоритетными DPC.
• Драйверы от третьих фирм и системные драйверы должны быть настраиваемыми (уровни прерываний ISR, уровни прерываний DPC)
• Драйверы от третьих фирм должны быть открыты для разработчиков, должно быть известно по крайней мере максимальное время, затрачиваемое на работу ISR и DPC.
• Должно быть известно время маскирования прерываний.

Готовы ли разработчики Microsoft ввести эти усовершенствования в NT или они полагают, что рынок слишком мал, и оставят его свободным для третьих фирм?

4. Коммерческие решения, расширяющие NT возможностями обработки в реальном времени

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

• Использование NT как она есть для построения мягкой системы реального времени.
• Реализация Win32 API над другой ОС РВ.
• Совместная работа на одном процессоре NT и другой ОС РВ (или ее части).
• Использование мультипроцессорной архитектуры, когда NT выполняется на одном процессоре (или более), а часть реального времени — на остальных.

Во многих решениях производители модифицируют HAL или ядро NT. Политика Microsoft заключается в том, чтобы не допускать никаких модификаций ядра NT, кроме драйверов устройств. Это единственно возможный способ связи с ядром. Политика компании относительно HAL другая. HAL (Hardware Abstraction Layer) — уровень аппаратных абстракций — уровень, лежащий ниже программного обеспечения, который виртуализирует интерфейс NT с аппаратурой, допуская переносимость NT с одной аппаратной платформы на другую. Такие модификации HAL, как манипуляции с часами или замена методов обработки прерываний, представляются беспримерно незаконным использованием HAL. Они создают нестандартную среду и могут привести к проблемам сопровождения, если, например, Microsoft изменит HAL в следующих версиях. Поэтому различие в решениях, предлагаемых поставщиками, заключается в попытках сделать модификации HAL минимальными.

Также возможен перехват HAL посредством трюков с процессором Intel. Однако это можно реализовать только на платформе Intel. Механизмы перехвата посредством обработки исключительных ситуаций на уровне устройства поглощают определенную вычислительную мощность.

4.1. Использование NT как таковой

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

Иногда вводят усовершенствования в механизм обработки прерываний. Единственный способ сделать это — перехватить прерывание, для чего необходимо добавить специальное аппаратное расширение. LP-Elektronik, например, перехватывает прерывание и использует затем NMI (немаскируемое прерывание, не используемое на уровне NT) для обработки событий реального времени. Этот подход применим только тогда, когда процессор имеет отдельный стек прерываний. Программа NMI должна быть написана аккуратно: в ней нельзя использовать вызовы ОС и она должна быть как можно короче, чтобы не потерять другие прерывания. Такое решение дает минимальную задержку прерывания, но требует дополнительной аппаратуры. Как и в других решениях, здесь необходим дополнительный механизм связи между NT и частью реального времени. Разница в том, что при этом требуется большая аккуратность в использовании NMI.

4.2. Реализация Win32 API над другой ОС РВ

Добавление Win32 API к ОС, предназначенной для обработки в реальном времени, избавляет от необходимости модифицировать HAL или использовать другие трюки с NT. Преимущества такого подхода:

• имеется переносимость,
• небольшой след,
• поведение ОС РВ известно.

Недостатки:

• нельзя использовать стандартные приложения NT,
• невозможно смешивание с драйверами устройств NT, поэтому весь мир коммуникаций NT недоступен,
• другие драйверы графических устройств и приложения NT невозможно или трудно использовать;
• ограничена возможность расширения в будущем,
• необходимо использовать специальные средства разработки и компиляторы.

Среди коммерческих реализаций этого подхода — QNX и VxWorks, использующие библиотеку Willows.

4.3. Совместная работа на одном процессоре NT и ОС РВ

Мощность современных процессоров достаточна для одновременного функционирования NT и программ реального времени. Возможны две разновидности такого подхода:

• модификация HAL c перехватом прерываний и включением небольшого диспетчера или ОС РВ;
• выполнение NT, как одной из задач над (супервизором) ОС РВ.

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

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

В обоих случаях необходим механизм связи между частями реального времени и NT. Он может быть выполнен одним из двух способов. Первый заключается во введении альтернативного механизма межпроцессорных связей (IPC). Проще всего реализовать IPC с помощью разделяемой памяти. Недостатком такого протокола IPC является уровень приоритета, на котором выполняются пользовательские приложения NT. При втором способе интерфейс реализуется с помощью драйвера устройства, в результате чего у NT создается впечатление, что подсистема реального времени — это устройство.

Задачи реального времени используют собственный интерфейс с системой, в большинстве случаев отличный от Win32 API. Среда разработки может быть обычной для используемой ОС РВ средой и может взаимодействовать со средой NT. Задачи реального времени будут выполняться, не получая преимуществ от механизма защиты памяти NT. Особо аккуратно следует продолжать выполнение частей реального времени, когда NT рухнет и сгенерирует голубой экран. След памяти — это комбинация следа NT (8 Мбайт в стандартной конфигурации) плюс минимальные требования для части ОС РВ.

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

• Сохранение (почти) всей среды NT нетронутой означает, что все программное обеспечение, устройства и драйверы устройств NT можно использовать (чтобы выполнять части приложения, не связанные с реальным временем). Поддерживается совместимость с NT;
• Можно включить защиту для задач реального времени, зависящую от используемой ОС РВ.

Недостатки:

• Отсутствует переносимость между реальным временем и средой NT, за исключением случая, когда RT-API разработан на базе Win32;
• драйверы устройств NT нельзя использовать в части реального времени;
• Среда разработки усложняется, если для задач реального времени требуется отдельная среда;
• Может быть много уровней задач и поэтому много уровней определений контекста. Переключение этих контекстов требует времени.

Известны следующие коммерческие реализации подхода, не требующего модификации аппаратуры: IMAGINATION с HyperKERNEL; RADISYS с комбинацией iRMX/NT; VenturCom с RTX, KPX и RTAPI.

В реализации фирмы RadiSys ОС РВ iRMX работает, как первичная ОС, загружающая Windows NT в качестве низкоприоритетной задачи. Пользователь работает только с NT, не видя и не чувствуя iRMX. Все управляющие функции выполняются, как высокоприоритетные задачи iRMX, изолированные в памяти от приложений и драйверов NT. Используя функции защиты памяти внутри процессора Intel, Windows NT защищена от задач реального времени.

Комбинация iRMX/NT преодолела трудности, которые возникают при модификации HAL и оставляют пользователя уязвимым при сбоях жесткого диска, сбоях драйверов и системных сбоях NT («голубой экран смерти»). В этом решении управляющая программа в случае краха NT может либо продолжить нормальное выполнение, либо произвести правильное закрытие системы (shutdown).

Реализация фирмы VenturCom состоит из двух этапов. На первом — мягкая реализация RTX 3.1 содержит интерфейс прикладной программы реального времени RTAPI, который дает время реакции 1-5 мск. RTAPI 1.0 работает со стандартным NT. Единственное изменение, обеспечивающее лучшую синхронизацию событий реального времени, внесено в часы. Так как в Windows NT имеются некоторые плохо предсказуемые процессы, то RTAPI позволит построить только мягкую СРВ с небольшим временем отклика, но недостаточно предсказуемую. Впрочем, большую часть непредсказуемости NT можно устранить, ограничив доступ к системному диску и сети.

Чтобы сделать NT более предсказуемой, необходимо прерывать ее внутренние задачи. В основе второй жесткой реализации RTX 4.1 лежит модификация HAL. В обеспечении детерминизма важную роль играют программируемые часы. В каждый тик часов — аппаратное прерывание с регулярными интервалами времени — предпочтение отдается задаче реального времени. Оставшееся время предоставляется процессам NT, в том числе и процессам мягкого реального времени. Чем чаще тикают часы, тем больше возможностей у процессора для выполнения задач реального времени. Необходимо добиться баланса между многими факторами: частота тиков, время, выделенное для обработки в реальном времени, время, выделенное для выполнения задач NT.

4.4. Использование многопроцессорной архитектуры

Простое решение здесь состоит в том, что NT выполняется на одной группе процессоров, а часть реального времени — на другой. Возможно применение архитектур параллельной шины с VMEbus, PCI, PMC или архитектур последовательной шины с Ethernet. Если необходимо, подсистемы могут быть связаны механизмом IPC и процедурами удаленного вызова. Преимущества такого решения:

• Нет модификаций каждой ОС;
• Можно применять в больших сложных системах;
• Для каждой подсистемы можно выбрать свою, наиболее подходящую ОС РВ;
• Можно использовать имеющиеся среды разработки.

Недостатки:

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

***

Чудес не бывает. Если вы хотите сохранить высокую совместимость с NT, то надо будет заплатить и более высокую цену. Если вы интересуетесь только частью интерфейса Win32 API, то можете работать с ОС РВ, имеющей этот интерфейс.

Имеется множество запросов на комбинации NT и РВ. Даже если это и не лучшее решение, рынок должен следовать желаниям заказчика. Разумеется, лучше всего было бы регулярное модифицировать саму Windows NT. Но пока компания Microsoft оставляет эту нишу свободной и она спонтанно заполняется производителями, зачастую использующими разные трюки, приводящие к несовместимости. Следует помнить, что использование трюков может в будущем привести к проблемам сопровождения.

---

Необходимые требования к ОС для обеспечения предсказуемости

Требование 1. ОС РВ должна быть многонитевой и допускать вытеснение (preemtible).

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

Требование 2. Диспетчеризация должна осуществляться на базе приоритетов.

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

Требование 3. Механизм синхронизации нитей должен быть предсказуемым.

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

Требование 4. Должна существовать система наследования приоритетов.

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

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

Требование 5. Временные характеристики ОС должны быть предсказуемы и известны.

Разработчик СРВ должен знать, сколько времени затрачивается на ту или иную системную работу. Кроме того, должны быть известны уровни системных прерываний и уровни IRQ (линий запросов прерываний) драйверов устройств, максимальное время, которое они затрачивают и т.п.

Евгений Хухлаев — сотрудник Института прикладной математики имени М.В. Келдыша РАН, (Москва).

Содержание

1. Какой пример операционной системы реального времени?
2. Какая операционная система является операционной системой реального времени?
3. Является ли Windows 10 распространенной операционной системой?
4. Что не является программным обеспечением для работы в реальном времени?
5. Сколько существует типов систем реального времени?
6. Чем RTOS отличается от General Os?
7. Каковы характеристики операционных систем реального времени?
8. Какая версия Windows 10 лучше?
9. Сколько стоит операционная система Windows 10?

Microsoft Windows, MacOS, Unix и Linux не работают в режиме реального времени. Часто они полностью не отвечают на несколько секунд. … Операционные системы реального времени — это операционные системы, которые всегда будут реагировать на событие в течение гарантированного периода времени, не в секундах или миллисекундах, а в микросекундах или наносекундах.

Какой пример операционной системы реального времени?

Примеры операционных систем реального времени: Системы управления воздушным движением, Системы командного управления, Система бронирования авиакомпаний, Heart Peacemaker, Сетевые мультимедийные системы, Робот и т. Д. Операционная система жесткого реального времени: Эти операционные системы гарантируют, что критические задачи будут выполнены в течение определенного периода времени.

Какая операционная система является операционной системой реального времени?

Что такое ОСРВ и как она работает? Операционная система реального времени (RTOS) — это операционная система с двумя ключевыми характеристиками: предсказуемостью и детерминизмом. В ОСРВ повторяющиеся задачи выполняются в сжатые сроки, в то время как в операционной системе общего назначения это не обязательно.

Microsoft Windows

Было много разных версий Windows, но самыми последними из них являются Windows 10 (выпущена в 2015 году), Windows 8 (2012), Windows 7 (2009) и Windows Vista (2007 г.). Windows поставляется с предустановленной загрузкой на большинстве новых ПК, что делает ее самой популярной операционной системой в мире.

Что не является программным обеспечением для работы в реальном времени?

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

Сколько существует типов систем реального времени?

Существует два типа систем реального времени: реактивные и встроенные. Реактивная система реального времени постоянно взаимодействует с окружающей средой (например, пилот, управляющий самолетом).

Чем RTOS отличается от General Os?

​​

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

Каковы характеристики операционных систем реального времени?

Ниже приведены некоторые характеристики системы реального времени:

• Временные ограничения: временные ограничения, связанные с системами реального времени, просто означают, что временной интервал выделено для ответа на текущую программу. …
• Правильность:…
• Встроено:…
• Безопасность:…
• Параллелизм:…
• Распределено:…
• Стабильность:

Какая версия Windows 10 лучше?

Сравните выпуски Windows 10

• Windows 10 Домашняя. Самая лучшая Windows становится все лучше. …
• Windows 10 Pro. Прочный фундамент для любого бизнеса. …
• Windows 10 Pro для рабочих станций. Предназначен для людей с расширенными рабочими нагрузками или потребностями в данных. …
• Windows 10 Корпоративная. Для организаций с повышенными требованиями к безопасности и управлению.

Сколько стоит операционная система Windows 10?

Вы можете выбрать одну из трех версий операционной системы Windows 10. Windows 10 Home стоит 139 долларов и подходит для домашнего компьютера или игр. Windows 10 Pro стоит 199,99 долларов и подходит для предприятий или крупных предприятий.

.

Сегодня
становится широко распространенным
желание потребителей использовать
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
и создания встроенных конфигураций
(без дисков, клавиатуры и монитора).

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Microsoft Windows, MacOS, Unix и Linux не работают в режиме реального времени. Они часто полностью не отвечают в течение нескольких секунд. … Операционные системы реального времени — это операционные системы, которые всегда будут реагировать на событие в течение гарантированного периода времени, не в секундах или миллисекундах, а в микросекундах или наносекундах.

Что является примером операционной системы реального времени?

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

Какая операционная система является операционной системой реального времени?

Что такое RTOS и как она работает? Операционная система реального времени (RTOS) — это операционная система с двумя ключевыми функциями: предсказуемость и детерминизм. В RTOS повторяющиеся задачи выполняются в сжатые сроки, а в операционной системе общего назначения это не обязательно так.

Является ли Windows 10 распространенной операционной системой?

Майкрософт Виндоус

Было много разных версий Windows, но самыми последними из них являются Windows 10 (выпущена в 2015 г.), Windows 8 (2012 г.), Windows 7 (2009 г.) и Windows Vista (2007 г.). Windows поставляется с предустановленной системой на большинстве новых ПК, что помогает это самая популярная операционная система в мире.

Какое программное обеспечение не работает в режиме реального времени?

Объяснение: Операционная система Palm не считается операционной системой реального времени. Эта форма системы представляет собой особую форму системного программного обеспечения, которое управляет программными ресурсами, аппаратным обеспечением компьютера и даже предлагает различные другие сопутствующие услуги, в основном для компьютерного программирования.

Сколько типов систем реального времени существует?

Есть Два типа систем реального времени: реактивных и встроенных. Реактивная система реального времени постоянно взаимодействует со своей средой (например, пилот, управляющий самолетом).

Чем RTOS отличается от General Os?

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

Каковы характеристики операционных систем реального времени?

Ниже приведены некоторые характеристики системы реального времени:

• Ограничения по времени: Ограничения по времени, связанные с системами реального времени, просто означают, что интервал времени отводится для ответа текущей программы. …
• Правильность: …
• Встроенный: …
• Безопасность: …
• Параллельность: …
• Распространено: …
• Стабильность:

Какая версия Windows 10 лучше?

Сравните выпуски Windows 10

• Виндовс 10 Домашняя. Лучшая Windows становится все лучше. …
• Виндовс 10 Про. Надежная основа для любого бизнеса. …
• Windows 10 Pro для рабочих станций. Предназначен для людей с расширенными рабочими нагрузками или потребностями в данных. …
• Windows 10 Корпоративная. Для организаций с повышенными требованиями к безопасности и управлению.

Сколько стоит операционная система Windows 10?

Вы можете выбрать одну из трех версий операционной системы Windows 10. Окна 10. Дом стоит 139 долларов. и подходит для домашнего компьютера или игр. Windows 10 Pro стоит 199,99 долларов и подходит для бизнеса или крупных предприятий.