Настраиваемость операционных систем

 

В последнее время одной из главных тем исследовательских работ в области операционных систем стало исследование настраиваемости (customizability) или адаптируемости операционной системы. Настраиваемой или адаптируемой операционной системой называется операционная система, допускающая гибкую модификацию основных механизмов, стратегий и политик системы. В зависимости от контекста, настраиваемость системы может преследовать различные цели. В операционных системах общего назначения, как правило, такой целью является производительность системы в целом. Для встроенных систем настраиваемость служит целям энергосбережения и/или сокращения объема программного обеспечения. Детальный систематический обзор исследовательских операционных систем с точки зрения их настраиваемости дается в работе Дениса и др. [105].

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

ХАРАКТЕРИСТИКИ НАИБОЛЕЕ РАСПРОСТРАНЕННЫХ ОПЕРАЦИОННЫХ СИСТЕМ РЕАЛЬНОГО ВРЕМЕНИ

 

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

 

QNX

 

Операционная система QNX является разработкой канадской компании QNX Software System LTD (1981) [100].

Операционная система QNX представляет собой гибрид 16/32 – битовой операционной системы, которую пользователь может конфигурировать по своему усмотрению. Наиболее часто она применяется для создания систем, работающих в реальном масштабе времени. Время, необходимое для полной инсталляции системы, включая сетевые средства, составляет всего 10-15 минут, после чего можно начинать работу. Нетребовательность системы к ресурсам проявляется уже в том, что система с необходимой и достаточной средой разработки в виде компилятора Watcom C/C++ (основной компилятор для QNX) умещается в 10 Mb.

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

Эти идеи позволили добиться нескольких важнейших преимуществ:

• предсказуемость, означающую ее применимость к задачам жесткого реального времени; Ни одна версия UNIX не может достичь подобного качества, поскольку код ядра слишком велик. Любой системный вызов из обработчика прерывания в UNIX может привести к непредсказуемой задержке (как и Windows NT);

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

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

Система построена по технологии FLEET [Fault-tolerance (отказоустойчивая), Load-balancing (регулирующая нагрузку), Efficient (эффективная), Extensible (расширяемая), Transparent (прозрачная)], которая выражается в следующем. QNX является ОСРВ на основе микроядра (размером около 10 Кб). В качестве основного средства взаимодействия между процессами система использует передачу сообщений. Благодаря этому в 32-битовой среде возможно взаимодействие процессов с 32- и 16-битовыми кодами, причем сообщения передаются между любыми процессами, независимо от того, находятся ли процессы на одном компьютере или на разных узлах сети.

Пользователь, работая на одном из узлов сети, может иметь доступ к любым ресурсам остальных узлов, включая порты, файловую систему и задачи. Пользователю нет необходимости вникать в сетевой протокол, который, кстати, не является тайной, вплоть до его структуры. Он содержит пакеты, которые применяются и для передачи сообщений. Сетевой администратор распознает эти пакеты и переправляет микроядру, которое, в свою очередь, переправляет их в шину локальных сообщений. QNX распознает не только пакеты сообщений QNX-процессов. Можно также легко обращаться к сетевому администратору для передачи таких пакетных протоколов, как TCP/IP, 8MB и др. Возможно обращение к различным сетевым администраторам через один кабель.

Операционная система QNX объединяет всю сеть ПК в единый набор ресурсов с абсолютной прозрачностью доступа к ним. Узлы могут добавляться и исключаться из сети, не влияя на целостность системы. Сетевая обработка данных в QNX является настолько гибкой, что можно объединить в одну сеть любой разнородный набор Intel совместимых компьютеров, соединенных через Arcnet, Ethernet, Token Ring или через последовательный порт, к которому также может быть подключен модем. Кроме того, возможно участие компьютера одновременно в нескольких сетях, и если одна из них окажется перегруженной или выйдет из строя, то QNX автоматически будет использовать другие доступные сети без потери информации.

QNX имеет некоторые ограничения, связанные с ориентацией системы на рынок встроенных систем реального времени:

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

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

• неэффективная и нестандартная поддержка нитей;

• неполноценная реализация отображения файлов в память;

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

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

Несмотря на присущие минусы, для QNX разработано множество пользовательских программ (например, базы данных, которые по производительности часто превосходят аналоги под управлением других операционных систем).

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

 

VxWorks/Tornado

Операционная система реального времени VxWorks и инструментальная среда Tornado фирмы Wind River Systems предназначены для разработки ПО встроенных компьютеров, работающих в системах жесткого реального времени. Операционная система VxWorks является системой с кросс-средствами разработки прикладного программного обеспечения, разработка ведется на инструментальном компьютере (host) в среде Tornado для последующего исполнения на целевой машине (target) под управлением VxWorks.

VxWorks поддерживает целевые архитектуры (targets):

• Motorola 680x0 и CPU32, PowerPC;

• Intel 386/486/Pentium, Intel 960;

• Spare, Mips R3 000/4000;

• AMD 29K, Motorola 88110;

• HP PA-RISC;

• Hitachi SH7600;

• DEC Alpha.

Инструментальные платформы, поддерживаемые для Tornado (hosts):

• Sun SPARCstation (SunOS и Solaris);

• HP 9000/400,700 (HP-UX);

• IBM RS6000 (AIX);

• Silicon Graphics (IRIX);

• DEC Alpha (OSF/1);

• PC (Windows).

Поддерживаемые интерфейсы host-target:

• host-target Ethernet;

• RS232;

• внутрисхемный эмулятор ICE (In-Circuit Emulator);

• кросс-шина (backplane).

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

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

Все аппаратно-зависимые части VxWorks вынесены в отдельные модули для того, чтобы разработчик встроенной компьютерной системы мог сам портировать VxWorks на свою нестандартную целевую машину. Этот комплект конфигурационных и инициализационных модулей называется (Board Support Package, BSP) и поставляется для стандартных компьютеров (VME-процессор, PC или Sparcstation) в исходных текстах. Разработчик нестандартной машины может взять за образец BSP наиболее близкий по архитектуре стандартный компьютер и перенести VxWorks на свою машину путем разработки собственного BSP с помощью BSP Porting Kit.

Базовые сетевые средства VxWorks: UNIX-networking, SNMP и STREAMS.

VxWorks была первой операционной системой реального времени, в которой реализован протокол TCP/IP с учетом требований реального времени. С тех пор VxWorks поддерживает все сетевые средства, стандартные для UNIX: TCP/UDP/ICMP/IP/ARP, Sockets, SLIP/CSLIP/PPP, telnet/rlogin/rpc/rsh, ftp/tftp/bootp, NFS (клиент и сервер).

Реализация SNMP-агента с поддержкой как MIB-I, так и MIB-II предназначена для применения VxWorks в интеллектуальном сетевом оборудовании (хабы, мосты, маршрутизаторы, повторители) и других устройствах, работающих в сети.

STREAMS – стандартный интерфейс для подключения переносимых сетевых протоколов к операционным системам, реализован в VxWorks как в версии SVR3, так и SVR4. Таким образом, в VxWorks можно инсталлировать любой протокол, имеющий STREAMS-реализацию, как стандартный (Novell IPX/SPX, DECNET, Apple-Talk и пр.), так и специализированный. Wind River Systems анонсировала (1994) программу WindNet, по которой ведущие фирмы-производители программных средств в области коммуникаций интегрировали свои программные продукты с VxWorks.

На сегодняшний день – это сетевые протоколы Х.25, ISDN, ATM, SS7, Frame Relay и OSI; CASE-средства разработки распределенных систем на базе стандартов ROOM (Real-Time Object Oriented Modelling) и CORBA (Common Object Request Broker Architecture); менеджмент сетей по технологиям MBD (Management By Delegation) и CMIP/GDMO (Common Management Information Protocol/Guidelines for Definition of Managed Objects).

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

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

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

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

Специально для систем с сильно ограниченным объемом памяти компания Wind River Systems разработала редуцированное ядро Wind Stream, которое требует для работы не более 8 Кб ПЗУ и 2 Кб ОЗУ. При этом для Wind Stream применим весь спектр инструментальных средств VxWorks, включая Wind View.

В качестве интерфейса между инструментальной и встроенной целевой машинами можно использовать внутрисхемные эмуляторы ICE (In-Circuit Emulators), например, НР64700, которые включаются в гнездо микропроцессора целевой системы, не имеющей Ethernet, или RS232 для связи с инструментальной машиной.

Экономичной альтернативой внутрисхемным эмуляторам являются так называемые ROM-эмуляторы, включаемые в гнездо ПЗУ микропроцессора целевой системы, например NetROM фирмы XLNT Designs. К Ethernet-разъему эмулятора NetROM подключается инструментальная машина, стандартный Ethernet-драйвер VxWorks заменяется драйвером NetROM, и таким образом на целевой машине появляется виртуальный Ethernet.

Инструментальная среда Tornado имеет открытую архитектуру, что позволяет другим фирмам-производителям инструментальных средств разработки ПО реального времени интегрировать свои программные продукты с Tornado. Пользователь может подключать к Tornado свои собственные специализированные средства разработки, а также расширять возможности инструментальных средств фирмы Wind River Systems.

В стандартную конфигурацию Tornado входят ядро VxWorks и системные библиотеки, GNU C/C⁺⁺ Toolkit, дистанционный отладчик уровня исходного языка Cross Wind, оболочка WindSh, конфигуратор BSP WindConfig и др.

Существует множество программных продуктов, интегрированных с Tornado производства других фирм.

 

Linux

 

Linux – современная POSIX-совместимая и Unix-подобная операционная система для ПК и рабочих станций, т. е. многопользовательская сетевая операционная система.

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

Характерные особенности Linux как ОС:

• многозадачность (является обязательным условием);

• многопользовательский режим;

• защищенный режим процессора (386 protected mode);

• защита памяти процесса; сбой программы не может вызвать зависания системы;

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

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

• виртуальная память со страничной организацией (т. е. на диск из памяти вытесняется не весь неактивный процесс, а только требуемая страница); виртуальная память в самостоятельных разделах диска и/или файлах файловой системы; объем виртуальной памяти до 2 Гб; изменение размера виртуальной памяти во время выполнения программ;

• общая память программ и дискового кэша: вся свободная память используется для буферизации обмена с диском;

• динамические загружаемые разделяемые библиотеки;

• дамп программы для пост-мортем анализа: позволяет анализировать отладчиком не только выполняющуюся, но и завершившуюся аварийно программу;

• сертификация по стандарту POSIX.1, совместимость со стандартами System V и BSD на уровне исходных текстов;

• через iВS2-согласованный эмулятор совместимость с SCO, SVR3, SVR4 по загружаемым программам;

• наличие исходного текста всех программ, включая тексты ядра, драйверов, средств разработки и приложений. Эти тексты свободно распространяются. В настоящее время некоторыми фирмами для Linux поставляется ряд коммерческих программ без исходных текстов, но все, что было свободным, так и остается свободным;

• управление заданиями в стандарте POSIX;

• эмуляция сопроцессора в ядре, поэтому приложение может не заботиться об эмуляции сопроцессора. Конечно, если сопроцессор в наличии, то он и используется;

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

• поддержка ряда распространенных файловых систем (MTNIX, Xenix, файловые системы System V); наличие собственной передовой файловой системы объемом до 4 Тб и с именами файлов до 255 знаков;

• прозрачный доступ к разделам DOS (или OS/2 FAT): раздел DOS выглядит как часть файловой системы Linux; поддержка VFAT (WNT, Windows 95);

• доступ (только чтение) к файловой системе HPFS-2 OS/2 2.1;

• поддержка всех стандартных форматов CD ROM;

• поддержка сети TCP/IP, включая ftp, telnet, NFS и т. д.

Бурный рост популярности Linux побуждает разработчиков внимательнее присмотреться к этой операционной системе. В данный момент эта ОС готова к стабильной работе, а открытость ее исходных текстов и архитектуры наряду с растущей популярностью заставляет программистов переносить свои наработки на многие аппаратные платформы: SGI, IBM, Intel, Motorola и т. д.

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

 

RT-Linux

 

RT-Linux – это операционная система, в которой небольшое ядро реального времени сосуществует с Posix-like ядром Linux. Основная цель – сделать доступными сложные службы и оптимизированное поведение системы в стандартных ситуациях для системы с разделением времени и в то же время выполнять задачи реального времени. В прошлом операционные системы реального времени примитивны – простые программы, которые предлагали пользователю чуть больше, чем просто библиотеку основных функций. Но в наше время пользователи требуют доступ к TCP/IP, графическому дисплею и системе окон, базам данных и другим службам, которые не являются ни примитивными, ни простыми. Одно из решений – добавить non-real-time службы к базовому ядру реального времени, что и было проделано в VxWorks и немного по-другому в микроядре QNX. Вторая возможность модифицировать стандартное ядро и сделать его полностью прерываемым.

RT-Linux организован третьим способом, в котором простое ядро реального времени запускает обычное ядро как одну из задач реального времени с самым низким приоритетом, используя виртуальную машину для того, чтобы сделать стандартное ядро полностью прерываемым.

В RT-Linux все прерывания обслуживаются ядром реального времени, а затем передаются стандартному ядру, но только в том случае, если нет необходимости запускать одну из задач реального времени. Для того чтобы минимизировать количество изменений в стандартном ядре, этот механизм реализован при помощи эмулирования ICH (Interrupt Control Hardware). Ядро реального времени и пользовательские задачи Linux могут обмениваться данными через неблокируемые очереди и сегменты разделяемой памяти.

С точки зрения программиста очереди выглядят как стандартные последовательные устройства UNIX, доступ к которым возможен при помощи системных вызовов POSIX read/write/open/ioctl. Разделяемая память доступна через системный вызов mmap.

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

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

На практике оказалось, что идея RT-Linux очень удачна. В самом худшем случае запаздывание прерываний на 486/33MHz PC оказалось менее 30 мкс, что близко к аппаратному пределу. Для прикладных задач симбиоз систем реального времени и оптимизированной для «общего случая» оказался очень удачным. Наиболее часто используемая конфигурация RT-Linux – примитивные задачи реального времени со статически распределяемой памятью без ее защиты, простым планировщиком с фиксированными приоритетами без защиты от нереализуемых планов, аппаратным запрещением прерываний; разделяемая память – единственный механизм синхронизации задач реального времени, ограниченный набором операций над FIFO-очередями, подсоединенными к обычным процессам Linux.

Ядро Linux позволяет в динамике загружать и выгружать модули ядра, сделав отдельные части ядра реального времени в виде модулей, легко изменять ядро реального времени. Уже написаны альтернативные планировщики и модуль семафоров. Во время работы системы можно загрузить модуль с задачами реального времени, затем выгрузить стандартный планировщик и загрузить, например, EDF планировщик. Можно пробовать разные комбинации модулей, пока не будет найдена оптимальная.

Этот вариант Linux позволяет выполнять задачи в реальном времени. Это достигается путем вставки ядра реального времени между стандартным ядром Linux и аппаратными прерываниями и позволяет избавиться от главной причины непригодности Linux для задач реального времени – большого запаздывания прерываний.

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

Простые очереди FIFO реализованы для обмена данными между процессами реального времени и процессами Linux. Типичное приложение состоит из двух частей – задачи реального времени, непосредственно работающей с аппаратурой, и обыкновенной задачи Linux, которая выполняет остальные операции, такие как сохранение данных на диск, пересылка их по сети, работа с пользователем (GUI) и т. д.

Самый короткий период для периодически вызываемых задач реального времени в RT-Linux на Pentium 120 – менее 150 мкс. Задачи, вызываемые по прерыванию, могут иметь намного меньший период.

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

Необходимо отметить, что компания LynuxWorks начала поставки (17.05.2002) встраиваемой ОС BlueCat Linux для комплекта разработчика ПО Intel Internet Exchange Architecture Software Developers Kit (Intel IXA SDK) 2.0, предназначенного для семейства сетевых процессоров Intel IXP1200. ОС BlueCat Linux распространяется бесплатно совместно с Intel IXA SDK 2.0.

Vx Works давно стала де-факто стандартом для подавляющего большинства систем, использующих встроенные ОС. Флэш-память вычислительной системы IXP1200 содержит загрузчик ядра VxWorks. Для разработчиков это упрощает задачу написания новых программ. Кроме того, уже реализована возможность работы сетевого процессора под управлением ОС Linux (с расширениями реального времени). Осуществляется программная поддержка некоторыми производителями ОС Linux (HanpHMep, LynuxWorks и т. д.).

 

RTEMS

 

RTEMS (Real-Time Executive for Multiprocessor Systems) – это некоммерческая операционная система реального времени для глубоко встраиваемых систем [101]. Разработчик системы – компания OAR (On-Line Applications Research Corporation, США). Система была создана по заказу министерства обороны США для использования в системах управления ракетными комплексами. Система разрабатывается для многопроцессорных систем на основе открытого исходного кода в противовес аналогичным системам с закрытым кодом. Система рассчитана на платформы MS-Windows и Unix (GNU/Linux, FreeBSD, Solaris, MacOS X).

Ядро RTEMS обеспечивает базовую функциональность систем реального времени. В эти возможности входят

· мультизадачная обработка;

· работа в гомогенных и гетерогенных системах;

· планирование, управляемое событиями, на основе приоритетов;

· планирование с монотонной скоростью;

· взаимодействие задач и синхронизация;

· приоритетное наследование;

· управление ответным прерыванием;

· распределение динамической памяти;

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

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

Ядро RTEMS отвечает за управление основной памятью компьютера и виртуальной памятью выполняемых процессов, за управление процессором и планирование распределения процессорных ресурсов между совместно выполняемыми процессами, за управление внешними устройствами и, наконец, за обеспечение базовых средств синхронизации и взаимодействия процессов. При этом ядро использует соответствующие менеджеры. В состав RTEMS входит набор следующих менеджеров: инициализации, задач, прерываний, часов реального времени, таймера, семафоров, сообщений, событий, сигналов, разделов, регионов, двухпортовой памяти, ввода/вывода, неисправимых ошибок, монотонной частоты, расширений пользователя, многопроцессорности. Привязка ОСРВ к аппаратуре производится с помощью специальной библиотеки подпрограмм BSP (board support package) и специализированных подпрограмм для различных архитектур. В состав BSP входят программа инициализации аппаратуры и драйверы устройств. Поддержка в RTEMS мультипроцессорных систем позволяет использовать ее для управления как однородными, так и неоднородными системами. Ядро RTEMS автоматически учитывает различия в архитектуре используемых процессоров, выполняя в случае необходимости перестановку байтов и другие процедуры. Это позволяет осуществлять переход на другое семейство процессоров без значительных изменений системы.

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

В ОСРВ RTEMS реализуются следующие виды межпроцессорного взаимодействия:

· обмен данными между задачами;

· обмен данными между задачами и программами обработки прерываний;

· синхронизация между задачами;

· синхронизация между задачами и программами обработки прерываний.

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

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

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

Менеджер сообщений. Служит для обмена между задачами сообщениями переменной длины. Сообщения передаются через очереди типа FIFO («первым пришёл, первым обслужен»). Имеется возможность посылки срочного сообщения. Для каждой очереди задается максимальная длина сообщения. Сообщения могут использоваться для синхронизации задач. Задача может ожидать прихода определенного сообщения или проверять наличие сообщения в очереди.

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

Менеджер задач. Обеспечивает полный набор функций для создания, удаления и управления задачами. С точки зрения RTEMS, задачей является наименьшая последовательность команд, которая может самостоятельно конкурировать за использование системных ресурсов. Каждой задаче соответствует блок контроля задачи TCB (Task Control Block). Этот блок является структурой, которая содержит всю информацию, относящуюся к выполнению задачи. В процессе инициализации RTEMS выделяет TCB для каждой задачи, имеющейся в системе. Элементы TCB изменяются в соответствии с системными вызовами, которые выполняются приложением в ответ на внешние запросы. Блок TCB – это единственная внутренняя структура данных RTEMS, доступная приложению через дополнительные процедуры пользователя. При переключении задач в TCB сохраняется контекст задачи. При возвращении управления задаче ее контекст восстанавливается. При перезапуске задачи исходный контекст задачи восстанавливается в соответствии со стартовым контекстом, хранящемся в TCB. Задача может находиться в одном из пяти состояний: выполнение; готовность к выполнению (управление может быть передано задаче); остановка (задача заблокирована); спящий режим (созданная, но не запущенная задача); отсутствие задачи (задача не создана или удалена).

Ядро реального времени RTEMS поддерживает 255 уровней приоритетов. Чем больше значение приоритета, тем более привилегированной является задача. Количество задач, имеющих одинаковый приоритет, не ограничено. Каждая задача всегда имеет какой-либо уровень приоритета, начальное значение которого присваивается при создании задачи и в дальнейшем может быть изменено. Режим выполнения задачи определяется следующими параметрами: вытесняемость; обработка асинхронных запросов ASR (Asynchronous Signal Request); квантование времени; уровень прерывания. Эти параметры используются для распределения процессорного времени и изменения контекста задачи. Они задаются пользователем при компиляции системы.

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

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

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

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

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

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

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

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