Размещено на http://www.allbest.ru/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- загрузка CPU низка (DPC имеют достаточно времени);

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

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

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

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

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

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

- DPC должны иметь много уровней приоритетов;

- DPC должны быть вытесняемыми более приоритетными DPC.

- драйверы от третьих фирм и системные драйверы должны быть настраиваемыми (уровни прерываний ISR, уровни прерываний DPC) ;

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

- должно быть известно время маскирования прерываний.

Коммерческие решения, расширяющие 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. Механизмы перехвата посредством обработки исключительных ситуаций на уровне устройства поглощают определенную вычислительную мощность.

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

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

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

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

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

Преимущества такого подхода:

- имеется переносимость;

- небольшой след;

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

Недостатки:

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

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

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

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

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

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

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

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

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

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

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

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

- нет модификаций каждой ОС;

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

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

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

Недостатки:

- высокая стоимость;

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

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

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

В последнее время система QNX быстро развивалась, превращаясь из узкоспециализированной ОС для систем реального времени в более-менее универсальную систему [3]. Однако ее разработчики отказались от попыток "добавить еще одну функцию" в QNX, поскольку этот путь ведет в тупик.

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

С точки зрения пользовательского интерфейса и API, эта ОС очень похожа на Unix. Если вы знакомы с Unix на уровне пользователя, то вероятно сможете работать с QNX без проблем - в ней присутствует практически весь набор стандартных утилит и сохраняется большая часть семантики. Конечно, есть и X Window, равно как и TCP/IP. Если вы программист, знающий Unix, то для вас не составит большого труда перенести собственные или GNU/Free-приложения в QNX. Например, Apache и Mosaic хорошо демонстрируют степень совместимости API.

Однако QNX - это не версия Unix. Она была разработана с нуля и построена на совершенно других архитектурных принципах, но с учетом группы стандартов POSIX, которые возникли в результате обобщения существующей практики в различных версиях системы Unix. Разработка ведется канадской фирмой QNX Software Systems Limited (далее - QSSL).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хотя этот список содержит достаточно важные пункты, не все они являются критичными для рынка QNX, поскольку она не проектировалась для конкуренции с Unix. Но, что гораздо более важно, некоторые пункты этого списка, а также другие ограничения QNX, являются серьезными недостатками с точки зрения теории систем реального времени. И это притом, что QNX является лидером этого рынка!

Что же это за недостатки? Чтобы понять, нужно определить требования к ОС, предназначенной для реализации систем реального времени. Именно этот смысл я вкладываю в общеупотребительный термин "ОС реального времени" (Real Time OS). Использование какой-либо ОС еще не гарантирует получения результата. Можно взять любую ОС такого типа и создать на ее базе некую систему, предназначенную для работы в реальном времени (далее - "система реального времени"), но не способную на это фактически. Чем отличается система реального времени? Есть два основных требования.

- Система должна реагировать на события, успевая обработать их за фиксированное время или к фиксированному моменту времени (далее - "временные рамки").

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

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

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

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

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

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

3. Каждая нить управления (thread) должна иметь способ выражения собственной важности. В идеале планировщик должен предоставлять процессор той нити, у которой осталось меньше всего времени до исчерпания своих временных рамок (алгоритм, известный как EDF - Earliest Deadline First). Но учитывая сложность реализации такой схемы, можно ограничиться наличием приоритетов у нитей, при условии поддержки достаточно большого количества уровней приоритетов.

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

5. Поведение самой ОС после системных вызовов и наступления событий должно быть предсказуемо и известно заранее. Это означает, что разработчики ОС должны специфицировать такие временные характеристики, как "задержка обработки прерывания" (interrupt latency), максимальное время маскировки прерываний, а также максимальное время исполнения всех системных вызовов.

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

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

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

Немногие ОС способны выполнить хотя бы часть этих требований, хотя не все из них одинаково важны. Например, Windows NT абсолютно не соответствует критическим требованиям 2 и 4 и весьма слабо - условимя, изложенным в п.п. 3, 5, 6, 7 и 8. В свою очередь заметим, что QNX так же не вполне отвечает всем требованиям. В частности, она имеет следующие серьезные недостатки:

- неадекватная поддержка нитей и отсутствие поддержки симметричных мультипроцессорных архитектур (SMP);

- ограниченное количество уровней прерываний (32);

- отсутствие поддержки "наследования приоритетов" для механизмов синхронизации (семафоров);

- неспособность работать на системах с объемом памяти менее 512 Kбайт, а с графическими возможностями потребности еще больше;

- относительно высокие цены, даже при больших объемах закупок.

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

3. Проект Neutrino

Еще до появления Windows 95, стартовал проект создания совершенно новой ОС, которая не наследуя устаревшую кодовую базу, могла бы воплотить в себе лучшие идеи, разработанные в теории операционных систем. Этот проект получил кодовое название "Neutrino", довольно удачно отражающее его суть - очень маленькая и неуловимо быстрая ОС.

Все проблемы QNX можно коротко выразить тремя пунктами:

- недостаточная согласованность с требованиями POSIX к системам реального времени;

- невозможность применения на встроенных системах с ресурсами 64 Kбайт - 512 Kбайт;

- невозможность применения на системах высшего уровня (SMP-серверах).

Отсюда видно, что глобальная цель проекта Neutrino - создание POSIX-совместимой масштабируемой ОС, пригодной для построения систем реального времени на самом широком спектре оборудования.

При этом была еще одна цель: добиться независимости кода приложений от характера целевой системы. То есть код для "тостера" должен быть бинарно совместим с кодом для SMP-сервера. Такого рода система должна быть гибкой, эффективной и универсальной.

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

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

2. Независимость приложений от используемого процессора и операционной системы. Уже сейчас перенос приложений, например с платформы SPARC/Solaris на x86/QNX, не представляет значительного труда. Neutrino должна сделать этот процесс практически безболезненным.

3. Переносимость средств разработки и наличие достаточного количества квалифицированных разработчиков для POSIX API.

4. Близость POSIX и Unix дает возможность совмещения системы разработки и runtime-системы, что позволяет разрабатывать и тестировать приложения еще до появления прототипа устройства, для которого оно предназначено.

5. Правительственные органы некоторых стран (например CША) считают совместимость с POSIX очень важной. Даже более важной, чем сертификацию по классу С2, поскольку POSIX-сертифицированная система неявно обладает достаточными средствами защиты.

Впрочем, POSIX - это большая группа стандартов, а термин "Neutrino", если говорить конкретно, применяется на данном этапе не ко всей ОС, а лишь к ее микроядру. Это микроядро будет совместимо, в частности, со следующими стандартами POSIX:

- 1003.1, 1003.1a,

- 1003.1b Realtime,

- 1003.1c Threads,

- 1003.1d Realtime Extensions,

- 1003.13 Realtime Profile Support.

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

Архитектура микроядра Neutrino. Указанные цели продекларировать гораздо легче, чем их достичь. Например, идея реализации ОС для систем реального времени с интерфейсом POSIX существует давно, но никому этого пока не удавалось сделать. POSIX-системы имеют репутацию "раздутых", поскольку они ассоциируются в первую очередь с Unix. В некотором смысле, Neutrino является доказательством возможности существования компактной POSIX-системы. операционный windows синхронизация neutrino

Для достижения этих целей недостаточно было просто косметической модернизации микроядра QNX. Neutrino представляет собой значительно более совершенную модель, выполняющую гораздо больше функций, чем микроядро QNX, имея при этом лучшую производительность и временные характеристики. Улучшенное микроядро позволило также вчетверо уменьшить размер менеджера процессов (с 80 до 20 Кбайт), уменьшив таким образом их суммарный размер почти вдвое.

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

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

По этой причине Neutrino остается достаточно маленьким и простым и по-прежнему оправдывает название "микроядра". Например, Neutrino поддерживает понятие нити, работающей в контексте процесса, но не может создавать процессы. В микроядре вообще нет кода, предназначенного для управления виртуальной памятью, необходимой для реализации защиты процессов. Такое решение объясняется тем, что некоторые системы реального времени предъявляют более жесткие требования к размеру и скорости исполнения кода, чем к защите, поскольку имеют контролируемую среду исполнения. Кроме того, некоторые процессоры вообще не поддерживают механизм виртуальной памяти. А на процессорах с архитектурой, отличной от x86, все вообще выглядит иначе. Так что такой подход повышает модульность и эффективность системы, а также упрощает ее перенос на другие платформы.

Все системные вызовы Neutrino могут вытесняться при необходимости, чтобы обработать вызов от нити с более высоким приоритетом, причем даже в процессе передачи сообщений. Это качество микроядра, а также его сравнительная простота и малый размер, позволяют минимизировать невытесняемые последовательности кода в системе. В свою очередь, за счет этого улучшаются временные характеристики системы. Скромные требования к памяти упрощают разработку встроенных систем низшего уровня. Кроме того, это уменьшает количество блокировок в коде (spin-locks), необходимых для поддержки мультипроцессорных архитектур, что упрощает реализацию SMP и повышает эффективность использования дополнительных процессоров. Улучшаются также характеристики ОС, необходимые для построения систем высокого уровня.

По заявлениям QSSL, бета-тестирование SMP Neutrino продемонстрировало близкий к линейному рост производительности при добавлении дополнительных процессоров (до 8), при автоматической балансировке нагрузки. Многое в QNX и Neutrino "недостижимо". Кроме того, реализация SMP Neutrino допускает ручное распределение процессов между процессорами, что позволит добиться еще большей эффективности в контролируемой среде исполнения. Эта система уже вызвала большой интерес со стороны телекоммуникационных компаний, нуждающихся в сверхпроизводительных системах для реализации мощных коммутационных систем.

Микроядро и дополнительные модули. Главное отличие микроядра Neutrino от микроядра QNX - это его соотношение с внешними модулями. В QNX микроядро физически существовало в коде менеджера процессов, что означало необходимость использования последнего даже там, где не нужны его функции. Поскольку Neutrino должна быть применима для систем самого низкого уровня, типа "интеллектуального тостера", это ограничение необходимо было ликвидировать с целью снижения требований к памяти. Микроядро Neutrino может существовать вне менеджера процессов, что позволяет связать его с пользовательским кодом, получив таким образом сущность, называемую "системный процесс" (system process). Такой процесс не требует для работы ни ОС, ни даже BIOS, поскольку в комплект системы входит набор модулей IPL (начальной загрузки), способных заменить BIOS в этом качестве.

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

Если же для системы требуется полноценная ОС, то нужно связать микроядро с менеджером процессов Neutrino (ProcNto), затем сформировать шаблон ядра, и получить из него загружаемый двоичный образ - так, как это делается в QNX.

А что, если для реализации системы ProcNto не подходит? Neutrino предоставляет разработчикам целый спектр решений на этот случай.

Альтернативная реализация дополнительного сервиса. Менеджер процессов ProcNto представляет собой набор нитей, исполняющихся в адресном пространстве микроядра, и отвечает за управление памятью, поддержку пространства имен и создание новых процессов. Не всегда эти функции бывают нужны одновременно. Например, встроенной системе, использующей фиксированный набор процессов, "зашитых" в ядро, вряд ли понадобятся функции создания новых процессов, с поддержкой различных форматов. Поэтому, несмотря на свой малый размер, ProcNto может оказаться нецелесообразно велик. В таких случаях разработчик системы может реализовать самостоятельно альтернативный вариант, в котором вместо ProcNto используется его собственный код, связанный с опреденной библиотекой, содержащей упрощенные заменители для минимально необходимого набора функций. Так, например, можно переопределить реализацию функций open(), read() и write() - если это все, что необходимо для системы.

Расширения ядра и добавление новых системных вызовов. Еще одно новшество микроядра Neutrino заключается в поддержке расширений (еxtensions). Код Neutrino содержит различные таблицы переходов, которые могут быть переопределены в момент исполнения любой нитью, работающей в адресном пространстве микроядра. Эти таблицы могут указывать на адреса функций в любой другой нити. Например, ProcNto использует этот механизм для замены примитивных функций управления памятью, содержащихся в Neutrino, на более сложные, позволяющие выполнять операции с множественными виртуальными адресными пространствами, соответствующими различным процессам. Само микроядро не содержит кода, способного работать с виртуальной памятью, чтобы не обременять системы, которые этот механизм не поддерживают или не используют.

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

Neutrino также содержит специальную точку входа, через которую нити, исполняющиеся в адресном пространстве микроядра, могут передавать ему адреса функций. Затем микроядро вызывает эти функции со своим контекстом. Этот механизм используется менеджерами сети для того, чтобы выполнять манипуляции объектами микроядер на различных узлах от их собственного имени. Это и позволяет добиться полной прозрачности сетевого взаимодействия в QNX/Neutrino, поскольку исчезает разница между локальным и удаленным исполнением программы. Сеть Neutrino превращается в "виртуальный компьютер", позволяя создавать высокопроизводительные кластерные SMP-системы.

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

Управление процессами и памятью. Как уже отмечалось, управление процессами и памятью не является, строго говоря, функцией Neutrino - это функция менеджера процессов ProcNto, который, кроме этого, занимается поддержкой пространства имен ввода/вывода и еще рядом "мелочей". Однако обзор был бы неполным без рассмотрения данного вопроса.

Прежде чем управлять процессами, необходимо иметь возможность загружать их с какого-либо носителя. С этой целью в состав ProcNto также входят "нить заргузчика" и "нить терминатора". Нить загрузчика обеспечивает загрузку исполняемых модулей в формате ELF, QNX4 и shell-скриптов. Формат ELF (известный также как Evil Linkage Format J) является для Neutrino стандартным, поскольку он обеспечивает ряд преимуществ, таких как поддержка динамического связывания, и, что очень важно для встроенных систем, совместим со спецификацией XIP (eXecute-In-Place), предусматривающей исполнение кода прямо из ROM, без загрузки в RAM. Нить терминатора обеспечивает "уборку мусора" после завершения процессов, на тот случай, если они не смогли сделать это сами.

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

И все же самое интересное - это управление памятью. Данный вопрос является достаточно болезненным, поскольку от его решения зависит очень многое. Решение, примененное в QNX, не было достаточно гибким. QNX всегда использует виртуальную память, что не позволяет делать этого на некоторых типах Intel-совместимых процессоров, довольно широко применяемых во встроенных сиcтемах, например производства National Semiconductor или AMD, поскольку они не содержат Paged-MMU (устройство управления виртуальной памятью). Кроме того, зависимость микроядра от специфичной для x86 аппаратуры MMU затрудняет перенос системы на другие платформы.

В результате Neutrino принимает соломоново решение - предоставить выбор модели защиты памяти разработчикам. Код Neutrino не использует MMU или виртуальную память в явном виде. Это достигается за счет выноса функции инициализации MMU во внешний модуль (mmuon) и выноса функций управления виртуальной памятью в расширения микроядра, обеспечиваемые ProcNto. Для поддержки MMU модуль mmuon нужно включить в ядро, после чего менеджер процессов сможет поддерживать виртуальную память. Этот модуль не является "сервером", он выполняет инициализацию процессора и немедленно завершает свою работу. Сам менеджер процессов также существует в нескольких вариантах, соответствующих типу защиты памяти. Таким образом, Neutrino/ProcNto поддерживает 4 варианта управления памятью, от полного отсутствия защиты до предоставления каждому процессу собственного виртуального адресного пространства в 4 Гбайт. В будущем появится также версия ProcNto, поддерживающая своппинг виртуальной памяти на диск, что может оказаться желательным для некоторых систем верхнего уровня.

Вариант 1. Физическая память. Все нити перемещаются при построении системы в адреса, расположенные в адресном пространстве Neutrino. Менеджер процессов обычно отсутствует. Это типичная конфигурация, которую предоставляют различные realtime executive, но отличие Neutrino в том, что она пытается даже в этой модели памяти выполнять (насколько это возможно) функцию mmap(), что позволяет обходиться без изменения исходного кода системы при смене модели памяти.

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

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

Вариант 4. Виртуальная память. В этой модели каждый процесс имеет собственное адресное пространство, начинающееся с адреса 0 и защищенное от остальных процессов. Нити процесса делят с ним одно адресное пространство. Системное адресное пространство Neutrino также защищено от остальных процессов. Защита поддерживается аппаратурой Paged-MMU и реализуется соответствующей версией ProcNto.

Объекты и сервис микроядра. Neutrino поддерживает 48 системных вызовов (QNX - 14), обеспечивающих нити, передачу сообщений, сигналы, системные часы и таймеры, обработку прерываний и механизмы синхронизации нитей.

Процессы и нити: диспетчеризация и синхронизация. Neutrino поддерживает модель нитей POSIX 1003.1с, в соответствии с которой процесс может динамически создавать и уничтожать одну или более нитей. Разработчики могут по своему выбору использовать для работы с нитями либо API Neutrino, либо стандартную библиотеку pthreads.

Этот же стандарт определяет, что нити должны иметь собственные уровни приоритетов. Neutrino к моменту выхода окончательной версии будет поддерживать 256 уровней, причем каждая нить может также иметь собственный алгоритм диспетчеризации, список которых традиционен для QNX (и определен POSIX) - round-robin, FIFO и адаптивный.

Разумеется, поддержка нитей подразумевает также, что они могут делить общие данные. Для обеспечения синхронизации Neutrino поддерживает два механизма: условные переменные (condvars) и блоки взаимного исключения (mutexes). Для этих объектов микроядро поддерживает механизм наследования приоритетов.

Реализация mutexes отличается высокой эффективностью. Получение или освобождение несвязанного объекта типа mutex требует выполнения всего одного кода. Для сравнения, в Windows NT эта операция может занимать время до 700 мс.

Модель событий и средства обмена сообщениями. Модель событий Neutrino представляет собой еще одно значительное достижение этой системы. Учитывая сложность и многообразие форм событий и способов уведомления о них, реализация такой системы в каждой паре "клиент-сервер" может занять значительный объем кода и затруднить разработку надежной модели взаимодействия. Поэтому Neutrino использует другой подход, называемый event steering, при котором сервер может передать микроядру форму уведомления клиента, которую он у него запросил.

Практически нити получают уведомления от одного из трех типов источников: сообщение от другой нити, прерывание или таймер. События существуют в форме синхронных сообщений, асинхронных пульсов, Unix или POSIX-сигналов, прерываний, а также специального особытия ForceReady, вызывающего безусловный переход нити в состояние Ready без доставки какого-либо события. Механизм event steering работает следующим образом:

1. Клиент посылает серверу сообщение, содержащее структуру с описанием желаемого механизма уведомления;

2. Сервер регистрирует эту форму в микроядре и отвечает клиенту, выводя его из блокировки.

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

Сигналы в Neutrino поддерживаются в двух разновидностях: классические сигналы Unix и real-time сигналы POSIX, c которыми можно передавать короткую порцию данных (4 байт). Еще одно различие между ними заключается в том, что сигналы POSIX при поступлении к процессу буферизуются, пока какая-либо из нитей процесса не проявит к ним интерес. Neutrino расширяет семантику POSIX тем, что такое поведение можно заказать выборочно для любого сигнала, в том числе для стандартных сигналов Unix. Кроме того, Neutrino позволяет адресовать сигнал к конкретной нити внутри процесса, а не просто к процессу.

...