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

Обновлено: 04.07.2024

Существует несколько определений понятия реального времени, часто противоречащих друг другу, что не позволяет, к сожалению, принять единую терминологию. Близким к каноническому можно назвать следующее определение: "Система реального времени - это такая система, корректность работы которой зависит не только от выполнения неких заданий, но и от времени их выполнения. Если временные параметры задания нарушены - оно считается невыполненным". Дополнение к этому определению: "Следовательно, сама система должна иметь гарантированные временные параметры, т.е. поведение системы должно быть предсказуемым. Это позволяет минимизировать количество невыполненных (вследствие нарушения временных параметров) заданий".

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

Иногда системой реального времени называют интерактивную систему с малым временем отклика. Рассмотрим следующий пример: набор текста в программе WinWord 2.0 на компьютере с процессором Athlon 1GHz. Время отклика в данном случае - это промежуток времени между нажатием клавиши и отображением соответствующей буквы в окне программы. Кажется очевидным, что эта величина в данном случае не имеет значения - все равно человек печатает медленнее. Ошибка заключается в подмене понятий - высокая скорость отклика совсем не означает гарантированность отклика. Загружая компьютер большим количеством ресурсоемких задач, мы можем увеличивать время отклика до бесконечности. Проделай следующий опыт: поместив ярлыки всех установленных программ (желательно, чтобы среди них были такие монстрообразные приложения, как Borland Delphi, Microsoft Office, и пара-тройка 3D-шутеров) на рабочий стол Windows95 (желательно билд 450 или более ранний :), выдели их мышью и нажми Enter. После этого винда будет громыхать жестким диском, жонглируя данными между своп-файлом и памятью, и не реагируя на какие-либо внешние воздействия, пока ты не нажмешь кнопку Reset. Обычно этого достаточно, чтобы понять, что быстрая система - не обязательно система реального времени. С другой стороны, реальное время не означает скорость выполнения программы; более того, алгоритмы, гарантирующие конечное время отклика, часто менее эффективны, чем обычные.

В англоязычной литературе упоминаются "soft real-time systems" и "hard real-time systems", но в этом случае не подразумевается программная (software) или аппаратная (hardware) реализация системы реального времени. Термин hard означает, что время отклика (LT - latency time) жестко задано, т.е. является константой. Мягкая (soft) система реального времени (RTS - real-time system) может изменять LT, что увеличивает эффективность RTS, манипулирующей процессами с различными приоритетами. Например, для оцифровки одного кадра видеопотока достаточно LT=0.033с (30 кадров/сек), а для процесса управления сервоприводами необходимо достичь значения LT порядка десятков микросекунд. Иногда термином hard обозначают классическую (описанную выше) модель RTS, а термином soft - систему, не являющуюся RTS в чистом виде, но LT которой снижена до необходимого уровня, обеспечивающего требуемую скорость обработки данных. Например, если компьютер под управлением DOS обрабатывает данные с электронного осциллографа, то это - SoftRTS, т.к. DOS - однозадачная операционная система, и, при условии достаточной скорости компьютера и нормальной работы осциллографа, ничто не должно помешать нам обрабатывать данные с достаточной скоростью (но гарантировать этого мы не можем!). В многозадачных операционных системах также возможна реализация SoftRTS, причем применяемая обычно в мультимедийных приложениях и 3D-играх, т.к. они позволяют обеспечить требуемое LT путем ухудшения качества обработки данных (снижение битрейта, уменьшение FPS, изменение разрешения экрана и глубины цвета).

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

Понимание принципа действия и основных свойств операционных систем реального времени (RTOS - Real Time Operating System) требует введения таких базовых определений, как микроядро (microkernel) и макроядро (macrokernel).

Существует две основные школы ядростроителей (не смог подобрать более точного перевода для kernel
developers :): одна считает, что ядро операционной системы должно быть компактным и быстрым, а функциональность рассредоточена в процессах, другая проповедует более традиционный подход, предоставляя ядру все базовые функции ОС, а процессам - ничего, кроме возможности вызова этих самых функций. Для обозначения первого (по перечислению, а не по времени появления) типа архитектуры в 1989 году Ирой Голдштейн и Полом Дейлом был введен термин микроядро (microkernel). Первая (теперь - в хронологическом смысле) архитектура ядра (традиционная, или монолитная (monolithic), как ее называют в англоязычной литературе) получила название «макроядро» (что наглядно доказывает низкий уровень воображения у программистов, особенно системных).

Споры о том, какая архитектура лучше, идут до сих пор. Большинство реализаций ОС UNIX построены на макроядре, в том числе наиболее популярные на сегодняшний день - Linux и FreeBSD. На микроядре построены такие операционные системы, как Mach и QNX. Впрочем, некоторые системщики не относят Mach к микрокернелам по причине большого размера ядра (оно включает в себя драйвера устройств, что типично скорее для макрокернелов). С ядром QNX сложилась обратная ситуация - оно настолько мало (и по размеру, и по
функциональности), что пришлось ввести новый термин - наноядро (nanokernel). Думаю, что споры вокруг Mach можно было бы решить тем же путем, т.е. изменением терминологии - но, судя по всему, слова сантикернел и децикернел показались программистам недостаточно благозвучными. Следует понимать, что разграничение ОС на микроядра и макроядра производится вовсе не по размеру ядра, а по его архитектуре, т.е. по соотношению между количеством функций, реализованных в ядре, и функций, реализованных вовне ядра. Другие параметры (производительность, гибкость, работа в реальном времени) не могут быть признаками такого разграничения. Кроме того, граница между макрокернелами и микрокернелами становится все более размытой благодаря тому, что многие современные монолитные ядра содержат так называемые нити (threads) и обладают способностью к «мелкозернистому» распараллериванию (а как еще перевести fine-grained parallerism?). Архитектурно такие ядра подобны микрокернелам с большим количеством процессов, работающих в разделяемой (shared) памяти.

Возможность операционной системы работать в реальном времени в значительной степени определяется архитектурой ядра. Наиболее удобными в этом плане являются микроядра (собственно, для этого они и разрабатывались), но это не означает, что все микрокернелы работают в реальном времени (Mach - микроядро, не работающее в реальном времени, что вовсе не умаляет других достоинств этой операционной системы, породившей множество потомков, в том числе NeXTStep, Hurd, BeOS и MacOSX). Существование макрокернела с полноценной поддержкой работы в реальном времени все еще под вопросом (я не нашел никаких сведений о подобном проекте, кроме, разве что, Sun Solaris 2.x, но по моему мнению (не претендующему на компетентность), это скорее SoftRTS, а не HardRTS), а вот частичная реализация - обычное дело. Например, в Linux активно внедряются упоминавшиеся ранее межпроцессорные (от слова процесс, а не процессор) нити, причем уже существует большое количество приложений (первым был Web-сервер Apache), пользующихся этим интерфейсом.

QNX RTOS

Другие характеристики тебя вряд ли заинтересуют - они и не каждому QNX-профи известны и нужны. Поэтому про 12 возможных вызовов микроядра, 32 уровня приоритета и три алгоритма разделения времени (FIFO, круговой и адаптивный) я даже и не заикаюсь.

А вот требования к оборудованию очень советую почитать внимательно:

CPU: 8088, 80286, 80386 и выше
RAM: менее 640Кб (для исполнения), 2Mб (для разработки)
HDD: 5Мб для ОС и утилит (для системы программирования
- еще 4Мб); возможна бездисковая конфигурация.

Только не думай, что требования такие скромные, потому что система примитивная. Самая современная версия QNX (Neutrino 6.2.1) почти такая же жадная до ресурсов, как ХР. Что, испугался? 🙂 Я же сказал - почти! К тому же никто не мешает тебе установить QNX4 на 386 и наслаждаться. Препарируй на здоровье!

Еще раз о Windows и реальном времени

Одна из типичных ситуаций: ноутбук с 64-разрядной Windows 7, на котором работает прикладная программа, обрабатывающая данные, регулярно приходящие из сети или от некоторой аппаратуры. Все функционирует, как задумано, кроме того, что иногда возникают непредсказуемые задержки, связанные с работой самой Windows, т.е. планировщика. Это ожидаемо, так как и Windows не система реального времени (больше подходит название «система мягкого реального времени»), да и ноутбук вовсе не специальный сервер, предназначенный для транзакций в реальном времени.

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

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

Аппаратная поддержка

Разработчики архитектуры х86 предусмотрели некоторую поддержку подобных ситуаций [1]. Речь идет об уровне привилегий ввода-вывода IOPL (биты 12 и 13) регистра флагов EFLAGS. Если установить оба этих бита в единицу (т.е. сделать IOPL=3), то обычная прикладная программа сможет напрямую обращаться к портам ввода-вывода и, главное, сможет прямо задавать команды CLI/STI , закрывающие и открывающие прерывания.

Имея нужный уровень IOPL, прикладная программа могла бы выполнить очередную транзакцию гарантированно без переключений в это время на другие задачи. В предельном случае прикладная программа вообще могла бы провести целый сеанс, выключив, точнее «заморозив» Windows, а затем включив ее снова. Это вполне возможно, хотя и потребует после такой «разморозки» ОС некоторых дополнительных действий, вроде коррекции программных часов Windows по аппаратным часам компьютера. В любом случае приостанавливается работа планировщика, и влияние Windows в этот момент полностью исключается.

Таким образом, не используя надстройки или другие ОС, и не разрабатывая драйверы, можно было бы вернуться в некотором роде к временам Windows-98 или даже MS-DOS, когда прикладная программа могла в принципе делать что угодно (и поэтому зависание и крах системы были обычным делом), однако сложностей с реальным временем, по сути, не было.

Исправление ядра

Прежде всего, исправлять придется ядро Windows 7 в его 64-разрядном варианте, т.е. файл ntoskrnl.exe из папки Windows\system32 , причем после загрузки под этим именем там находится совсем другой файл – 32-х разрядная версия ядра, которая вообще не используется на 64-х разрядных процессорах. Можете сами в этом убедиться, сделав себя владельцем этого файла и переименовав или даже стерев его. 64-разрядная Windows 7 после перезагрузки будет работать, как ни в чем не бывало и 32-х разрядные приложения нормально выполняются. То же справедливо и для файла ntkrnlpa.exe (32-х разрядной версии ядра для памяти более 3 Гбайт): т.е. и он присутствует, но никак не используется.

Для доступа к файлу настоящего ядра нужно, например, загрузить другую ОС с компакт-диска, используя удобные специальные сборки типа «Реаниматор», обеспечивающие доступ к исходным дискам C:, D: и т.д.

Кроме этого, в Windows 7 имеется документированный способ подключить другое ядро, например, файл с именем nt1skrnl.exe с помощью директивы:

Откуда возьмется другое ядро? Для начала можно просто скопировать в системной папке под таким именем исходное. Теперь все опыты можно вести с копией в nt1skrnl.exe , не трогая исходного ядра. И всегда можно вернуться к исходному ядру, опять скопировав его под этим именем или выполнив директиву подключения стандартного ядра:

Файл ntoskrnl.exe представляет собой несколько мегабайт команд в 64-разрядном режиме. Куда же в нем вставлять команды установки IOPL?

Подсказку дает необходимость в Windows следить за содержимым регистра флагов у прикладных задач. Ядро постоянно «приводит в порядок» флаги задачи пользовательского уровня, гася запрещенные по маске-константе. Младшая часть этой константы 0DD5 и «выдает» работу с флагами пользовательской программы, например:

Здесь ядро погасило запрещенные биты, в том числе и IOPL, а затем принудительно разрешило флаг прерываний. Достаточно заменить одну команду на другую:

и при выходе из ядра в пользовательский уровень IOPL станет равным 3.

Таких мест в ядре оказалось несколько и, методом проб и ошибок, был найден соседний фрагмент, который в данном случае и используется:

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

ничуть не длиннее. Используя эту команду, устанавливаем заодно и максимальный уровень IOPL:

Поскольку изменились байты, контрольная сумма по адресу 00000140 (которую можно рассчитать с помощью CheckSumMappedFile) также должна поменяться, в данном случае с 5553E5 на 55С260

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

Тестирование исправления

Теперь можно производить перезагрузку Windows 7 с входом в расширенное меню по нажатию F8 и выбора режима «отключение обязательной проверки подписи драйверов», поскольку цифровая подпись уже не совпадает. В результате исправленное ядро из файла nt1skrnl.exe будет загружено и запущено.

Проверим работу исправления ядра на примере простейшей 32-разрядной тестовой программы на языке PL/1 [2]:

Заключение

Итак, на том же самом компьютере, на той же самой ОС, и почти не меняя прикладной программы (были только добавлены команды CLI/STI ), удалось решить поставленную задачу за счет нетривиальной, но примитивной «доработки» самой ОС. При этом был получен режим «реального времени» в том смысле, что исключено вмешательство планировщика и служебных процессов во время работы прикладной программы. Конечно, подобного же эффекта можно достичь и через аппарат драйверов, но это требует значительно больших изменений в построении ПО, а кроме этого, не используется аппаратная поддержка, предусмотренная разработчиками архитектуры х86 для прикладных программ в подобных случаях. Причем такая поддержка позволяет не переходить с пользовательского режима на уровень ядра.

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

Содержание

Системы жёсткого и мягкого реального времени

Принято различать системы мягкого (soft) и жесткого (hard) реального времени. Жесткая ОС реального времени имеет меньше джиттера [Источник 2] . , чем мягкая операционная система реального времени.В системах жесткого реального времени неспособность обеспечить реакцию на какие-либо события в заданное время ведет к отказам и невозможности выполнения поставленной задачи. В большинстве русскоязычной литературы такие системы называют системами с детерминированным временем. При практическом применении время реакции должно быть минимальным. Системами мягкого реального времени называются системы, не попадающие под определение "жесткие", т.к. в литературе четкого определения для них пока нет. Системы мягкого реального времени могут не успевать решать задачу, но это не приводит к отказу системы в целом. В системах реального времени необходимо введение некоторого директивного срока (в англоязычной литературе – deadline), до истечения которого задача должна обязательно (для систем мягкого реального времени – желательно) выполниться. Этот директивный срок используется планировщиком задач как для назначения приоритета задачи при ее запуске, так и при выборе задачи на выполнение.

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

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

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

Отличительные черты RTOS

Таблица сравнения операционных систем реального времени (ОСРВ) и обычных операционных систем.

ОС реального времени	ОС общего назначения
Основная задача	Успеть среагировать на события, происходящие на оборудовании	Оптимально распределить ресурсы компьютера между пользователями и задачами
На что ориентирована	Обработка внешних событий	Обработка действий пользователя
Как позиционируется	Инструмент для создания конкретного аппаратно-программного комплекса реального времени	Воспринимается пользователем как набор приложений, готовых к использованию
Кому предназначена	Квалифицированный разработчик	Пользователь средней квалификации

Архитектура

Cтруктура ОСРВ эволюционировала от монолитной к многослойной структуре ОС и далее к архитектуре клиент-сервер:

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

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

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

Особенности ядра

Все ОСРВ сегодня являются многозадачными системами. Задачи делят между собой ресурсы вычислительной системы, в том числе и процессорное время [Источник 4] .

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

Важной частью любой ОСРВ является планировщик задач, чья функция - определить, какая из задач должна выполняться в системе в каждый конкретный момент времени. К основным методам планирования обычно относят: циклический алгоритм (в стиле round robin), разделение времени с равнодоступностью (time sharing with fairness), кооперативную многозадачность. Наиболее часто используемый в ОСРВ принцип планирования - приоритетная многозадачность с вытеснением. Основная идея состоит в том, что высокоприоритетная задача, как только для нее появляется работа, немедленно прерывает (вытесняет) низкоприоритетную. Однако диапазон систем реального времени весьма широк, начиная от полностью статических систем, где все задачи и их приоритеты заранее определены, до динамических систем, где набор выполняемых задач, их приоритеты и даже алгоритмы планирования могут меняться в процессе функционирования. Существуют, например, системы, где каждая отдельная задача может участвовать в любом из трех алгоритмов планирования или их комбинации (вытеснение, разделение времени, кооперативность). Кроме того, приоритеты тоже можно назначать по-разному. В общем случае алгоритмы планирования должны соответствовать критериям оптимальности функционирования системы. Однако, если для систем жесткого реального времени такой критерий очевиден , то для систем мягкого реального времени это может быть, например, минимальное максимальное запаздывание или средневзвешенная своевременность завершения операций. В зависимости от критериев оптимальности могут применяться алгоритмы планирования задач, отличные от рассмотренных. Например, может оказаться, что планировщик должен анализировать момент выдачи критичных по времени управляющих воздействий и запускать на выполнение ту задачу, которая отвечает за ближайшее из них (алгоритм earliest deadline first, EDF).

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

Планирование задач

Работа планировщика

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

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

Выполнение задачи

В обычных ОСРВ, задача имеет три состояния

Выполняется
Готова к выполнению
Заблокирована

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

Алгоритмы планирования

В настоящее время для решения задачи эффективного планирования в ОСРВ наиболее интенсивно развиваются два подхода [Источник 5] ..

Статические алгоритмы планирования (RMS, Rate Monotonic Scheduling). Используют приоритетное вытесняющее планирование. Приоритет присваивается каждой задаче до того, как она начала выполняться. Преимущество отдается задачам с самыми короткими периодами выполнения.
Динамические алгоритмы планирования (EDF, Earliest Deadline First Scheduling). Приоритет задачам присваивается динамически, причем предпочтение отдается задачам с наиболее ранним предельным временем начала (завершения) выполнения.

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

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

Вытесняющее планирование с использованием круговой стратегии

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

Невытесняющее планирование на основе приоритетов

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

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

Вытесняющее планирование на основе приоритетов с точками вытеснения

Наиболее приемлемый подход состоит в комбинировании приоритетов с прерываниями таймера. При этом точки вытеснения равноудалены друг от друга. При достижении точки вытеснения выполняющееся в настоящий момент задание вытесняется, если в наличии имеется более высокоприоритетное задание в состоянии ожидания; таким образом, вытеснение заданий в этом случае оказывается частью ядра ОС. Здесь задержки могут быть порядка нескольких миллисекунд. Для ряда приложений RT задержки такого уровня вполне приемлемы.

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

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

Взаимодействие между задачами и разделение ресурсов

Многозадачным системам необходимо распределять доступ к ресурсам. Одновременный доступ двух и более процессов к какой-либо области памяти или другим ресурсам представляет определённую угрозу. А именно Deadloc и Priority inversionСуществует три способа решения этой проблемы:

Временное блокирование прерываний
Двоичные семафоры
Посылка сигналов.

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

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

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

Распределение (Выделение) памяти

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

Простой алгоритм с фиксированной длиной участков памяти очень хорошо работает в несложных встроенных системах.

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

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

Поскольку Windows не допускает управляемой установки приоритетов IRQ-запросов устройств и приложений пользовательского уровня только в случае пребывания процессорного IRQL-уровня в пассивном состоянии, Windows обычно не подходит в качестве операционной системы реального времени. В конечном счете, наибольшие задержки определяются не Windows, а устройствами системы и драйверами устройств. Этот фактор становится проблемой, когда разработчики систем реального времени используют какое-нибудь стандартное оборудование.

У конструкторов могут возникнуть сложности в определении продолжительности наихудших задержек ISR или DPC стандартных устройств. Даже после тестирования конструктор не может гарантировать, что частный случай в живой системе не заставит эту систему пропустить критический срок. Более того, суммарное значение всех задержек системных DPC и ISR может существенно превышать значение, допустимое для чувствительной ко времени системы.

Хотя требования реального времени есть у многих типов встроенных систем (например, у принтеров и автомобильных компьютеров), у Windows Embedded Standard 7 характеристики реального времени отсутствуют. Это просто одна из разновидностей Windows 7, позволяющая выпускать компактные версии этой операционной системы, подходящие для запуска на устройствах с ограниченными ресурсами. Например, устройство без сетевых возможностей опустит все компоненты Windows 7, связанные с работой в сети, включая средства управления сетью, а также адаптер и драйвера устройств стека протокола.

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

Связывание ISR с конкретным уровнем прерывания называется подключением объекта прерывания, а разобщение ISR и записи IDT называется отключением объекта прерывания. Эти операции, выполняемые путем вызова функций ядра IoConnectInterruptEx и IoDisconnectInterruptEx, позволяют драйверу устройства «включать» ISR при загрузке драйвера в систему и «выключать» ISR, если драйвер выгружается.

Использование объекта прерывания для регистрации ISR препятствует тому, чтобы драйверы устройства возились непосредственно с аппаратными средствами прерывания (имеющими отличия, связанные с архитектурами процессоров), и избавляет от необходимости знать обо всех подробностях IDT. Это свойство ядра помогает в создании переносимых драйверов устройств, поскольку оно исключает необходимость программировать на языке ассемблера или отражать разнообразие процессоров в драйверах устройств.

Объекты прерываний предоставляют также и другие преимущества. За счет использования объекта прерывания ядро может синхронизировать выполнение ISR с другими частями драйвера устройства, которые могут использовать с IRS общие данные.

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

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

Так сложилось, что на системе, где была запущена команда, этот вектор соответствовал встроенному карт-ридеру 7-в-1, представляющему собой комбинацию из устройств чтения флеш-карт Secure Digital (SD), Compact Flash (CF), MultiMedia Card (MMC) и карт других типов, и у каждого устройства имелось свое собственное прерывание. Поскольку они были сгруппированы производителем в одно устройство, вполне разумно было его прерываниям использовать один и тот же вектор.

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

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

Еще одна проблема, связанная с генерированием прерываний по IRQ-линии, заключается в том, что неправильное управление IRQ-сигналом может привести к недопустимому пику прерываний (interrupt storms) или к возникновению других разновидностей взаимных блокировок, поскольку пока ISR-процедура не подтвердит получение сигнала, он выставляется на «высоком» или «низком» уровне. Более того, контроллер прерываний должен, как правило, получать также и сигнал завершения прерывания EOI.

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

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

Читайте также: