22 - hal (Ответы на экзаменационные билеты), страница 5

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

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

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

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

Однако на уровне драйвера устройства своппинг может быть исключен.

1. Другие вопросы

При попытке использовать ОС для проектирования СРВ или встраиваемых систем еще несколько вопросов нуждаются в рассмотрении:

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

Большую часть времени не требуется дисплей или клавиатура.

При покупке больших серий лицензия Windows NT слишком дорогая - $319 ($250 для очень больших партий!!!)

1. Коммерческая сторона

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

1. Заключение: может ли Windows NT использоваться как ОСРВ?

Мы показали в данной работе, что Windows NT в своем оригинальном виде, ориентированном главным образом на классические приложения, не являются хорошей платформой для приложений реального времени:

• число приоритетов реального времени слишком мало для СРВ;

• не решена проблема инверсии приоритетов (для процессов класса реального времени);

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

• драйверы устройств имеют очень медленные DPC и не допускают прерываний другими DPC.

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

• в мягких СРВ, которые допускают нарушение временных ограничений (время от времени);

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

• нагрузка на CPU всегда остается малой (системные DPC имеют время для выполнения);

• используется мало драйверов, алгоритм которых неизвестен, или, по крайней мере, качество этих драйверов гарантировано;

• критические заявки (или даже все) выполняются на уровне DPC, а еще лучше прямо в ISR.

Последний пункт делает бессмысленным использование ОС.

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

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

• использование DPC - хорошая идея, но нужно обеспечить для них больше приоритетных уровней;

• приоритеты DPC должны быть абсолютными, а не относительными;

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

• драйверы от третьих поставщиков должны быть документированы, по меньшей мере нужно знать сколько времени тратит драйвер на отработку ISR и DPC;

• время, в течение которого ОС маскирует прерывание, также должно быть известно разработчику;

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

Желает ли Microsoft и готова ли улучшить таким образом Windows NT или она считает рынок слишком маленьким, чтобы допускать на него третьи стороны

 

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

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

1. Использование NT как она есть для построения мягкой системы реального времени.

1. Реализация Win32 API над другой операционной системе реального времени.

1. Совместная работа на одном процессоре NT и другой операционной системе реального времени (или ее части).

1. Использование мультипроцессорной архитектуры, когда NT выполняется на одном процессоре (или более), а часть реального времени - на остальных.

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

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

1. Совместная работа на одном процессоре NT и ОС реального времени

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

1. модификация HAL с перехватом прерываний и включением небольшого диспетчера или ОС реального времени;

1. выполнение 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.

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

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

• Нет модификаций каждой ОС;

• Можно применять в больших сложных системах;

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

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

Недостатки:

• Высокая стоимость;

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

• Среды разработки относятся к разным мирам.

1. Реализация Win32 API над другой ОС реального времени

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

• имеется переносимость,

• небольшой след,

• поведение ОС РВ известно.

Недостатки:

• нельзя использовать стандартные приложения NT,

• невозможно смешивание с драйверами устройств NT, поэтому весь мир коммуникаций NT недоступен,

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

• ограничена возможность расширения в будущем,

• необходимо использовать специальные средства разработки и компиляторы.

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

1. Выводы

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

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

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

1. Тестирование RTOS: Практическая оценка

Практическая оценка отвечает на различные вопросы.

1. Возможно ли уменьшить размер ядра до минимального и построить систему, используя только необходимые компоненты.

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

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

4. В конце концов, исследования могут ратифицировать информацию на системную архитектуру, накопленную (информацию) во время предыдущей технической оценки.

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