Контрольная работа по "Информатике"

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

 синхронизации  задач 

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

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

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

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

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

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

Требование 5. Поведение  ОС должно быть известно 

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

латентную задержку прерывания (т. е. время от момента  прерывания до момента запуска задачи): она должна быть предсказуема и согласована  с требованиями приложения. Эта величина зависит от числа одновременно “висящих”  прерываний; 

максимальное  время выполнения каждого системного вызова (должно быть предсказуемым  и независимым от числа объектов в системе); 

максимальное  время маскирования прерываний драйверами и ОС. 

системные уровни прерываний; 

уровни прерываний драйверов устройств, их временные  характеристики и т. д. 

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

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

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

QNX 

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

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

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

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

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

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

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

Система построена  по технологии FLEET [Fault-tolerance (отказоустойчивая), Load-bаlаncing (регулирующая нагрузку), Еffiсiеnt (эффективная), Ехtеnsible (расширяемая), Тгаnsparent (прозрачная)], которая выражается в следующем. 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 R3000/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.