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

Интересно, что во всех нововведениях PCI-X остается сов­местимость с устройствами и шинами PCI: каждая шина будет работать в режиме, доступном самому слабому участнику — от PCI с частотой 33 МГц до PCI-X533. Мосты позволяют разным сегментам системы (шинам PCI) работать в разных режимах, так что можно выбрать эффективную конфигурацию, в которой новые устройства, критичные к пропускной способности, бу­дут нормально уживаться со старыми.

Третье поколение организации ввода-вывода — это PCI Express, Hyper Transport. Для третьего поколения характерен переход от шин к двухточечным соединениям с последователь­ным интерфейсом. По сути, третье поколение ввода-вывода при­ближается к совсем локальным (в пределах системной платы) сетям. Здесь между узлами сети передаются пакеты, в которых содержится как управляющая информация (команды), так и собственно передаваемые данные. Каждый интерфейс состоит из пары встречных однонаправленных связей (link), работаю­щих независимо друг от друга (никакого квитирования при пе­редаче не предусматривается). Пропускная способность связей одного интерфейса в разных направлениях может различаться — она выбирается с учетом потребностей данного применения. В архитектуре ввода-вывода появились новые возможности: уп­равление качеством сервиса (QoS), потреблением и бюджетом связей. Топология соединения узлов и свойства связей различ­ны, но и HyperTransport, и PCI Express, как и шины прежних поколений, не допускают петель в топологии.

PCI Express, она же 3GIO (3-Generation Input-Output, ввод- вывод 3-го поколения), — это двухточечное подключение пери­ферийных компонентов как в пределах системной платы, так и карт расширения. Интерфейс с разрядностью 1, 2, 4, 8, 12, 16 или 32 бит обеспечивает скорость передачи до 8 Гбайт/с. Здесь сохраняются программные черты шины РС1 (конфигурирова­ние, типы транзакций), что обеспечивает плавность миграции от PCI к PCI Express.

HyperTransport — это высокоскоростное двухточечное соеди­нение между микросхемами в пределах платы (разъемы и карты расширения не предусмотрены). Основной вариант топологии — цепочка устройств-туннелей, имеющих по два интерфейса, и транслирующих все пакеты насквозь. Возможно применение мостов и коммутаторов, осуществляющих маршрутизацию па­кетов. Разрядность связей может быть 2, 4, 8, 16 или 32 бита; тактовая частота от 200 до 800 МГц при двойной синхрониза­ции обеспечивает пиковую скорость передачи данных до 6,4 Гбайт/с (32-битная связь). Поскольку пакеты могут переда­ваться одновременно в обоих направлениях, можно говорить о пропускной способности интерфейса 12,8 Гбайт/с. Общая идея конфигурирования и поддерживаемые типы транзакций обес­печивают удобную интеграцию с PCI/PCI-X посредством мостов.

InfiniBand — это новая архитектура соединений для серве­ров, основанная на построении централизованной "фабрики ввода-вы вода" (I/O fabric). Узлы InfiniBand объединяются с по­мощью "коммутационной фабрики" — структуры коммутато­ров, допускающей избыточные связи. Избыточность связей при­ветствуется, так как позволяет повысить суммарную пропускную способность. Избыточность обеспечивается как внутренними связями элементов коммутационной фабрики, так и наличием нескольких интерфейсов у устройств, позволяющих подклю­чаться к нескольким точкам коммутационной фабрики.

В InfiniBand представлены три уровня пропускной способности связей: 0,25, 1 и 3 Гбайт/с. Каждая связь (IB Link) состоит из 1, 4 или 12 пар встречных однонаправленных линий, работающих в полнодуплексном режиме со скоростью передачи в каждой линии 2,5 Гбит/с. Соединения обеспечиваются как межплатны­ми разъемами, так и кабельными соединениями: медными до 17 м и оптическими до 10 км; в медном соединении каждая линия — это пара проводов с дифференциальными сигнала­ми, в оптическом — одно волокно. Архитектура позволяет объе­динять до десятков тысяч узлов в единую подсеть. В зависимос­ти от назначения, узлы снабжаются канальными адаптерами InfiniBand двух типов: НСА (Host Channel Adapter) для про­цессорных узлов, являющихся инициаторами транзакций, и ТСА (Terminal Channel Adapter) для узлов ввода-вывода (кон ­троллеров интерфейсов устройств хранения и сетей, графичес­ких контроллеров, шасси ввода-вывода с традиционными ши­нами расширения и т. п.).

Карты PCMCIA и PC Card — это 68-контактный разъем. На­значение контактов (тип интерфейса), которое "заказывается" картой при установке ее в слот, следующее:

Интерфейс памяти, 8/16-битные обращения, Vmax=10/20 Мбайт/с.

Интерфейс ввода-вывода, 8/16-битные обращения, Vmax=3,92/7,84 Мбайт/с.

Интерфейс CardBus: чуть упрощенная PCI 33 МГцх х32 бит = 132 Мбайт/с; дополнительно — цифровая передача аудиосигнала, ИКМ или ШИМ (PWM).

Интерфейс АТА, предназначенный для дисков.

Существует 4 типа PC Card. У них у всех размер в плане 54x 85,5 мм, но разная толщина (меньшие адаптеры встают в большие гнезда):

PC Card Type I — 3,3 мм — карты памяти;

PC Card Type II — 5 мм — карты устройств ввода-вывода, модемы, адаптеры локальных сетей;

PC Card Type III — 10,5 мм — дисковые устройства хранения;

PC Card Type IV- 16 мм.Small PC Card размером 45 x 42,8 мм — это тот же коннек­тор и те же типы по толщине.

ZV Port (Zoomed Video) — это двухточечный интерфейс для доставки видеоданных с карты в экранный буфер VGA, 4 аудио- канала.

"Мелкие" интегрированные контроллеры ПУ (порты СОМ, LPT, GAME, контроллер клавиатуры, мыши PS/2, НГМД, аудио), по традициям совместимости как устройства PCI не оформляют. Для них есть "маленькие" шины:

X-Bus (на старых системных платах) — конструктивно не оформленная (слотами) шина ISA со всеми атрибутами (IRQ, DMA). Асинхронная (как ISA), неудобна в стыковке с синхрон­ным окружением.

LPC (Low Pin Count) — синхронная (33 МГц) 4-битная муль­типлексированная шина, адрес памяти 32-битный; прерывания, DMA, BusMaster, пропускная способность на уровне ISA/X -Bus. В современных платах подключается через мост к PCI. Автокон­фигурирование не предусмотрено (все абоненты априорно из­вестны BIOS).

Рассмотрим периферию.

Основной поток информации от PC — зрительный, через активные (монитор) и пассивные (принтер, плоттер) средства вывода.

Графическая подсистема содержит монитор, подключенный через графический адаптер. При этом изображение формируется программно.

Видеосистема обеспечивает ввод/вывод "живого" видео.

Видеокарта (в современном понимании) обеспечивает гра­фику, возможно и видео.

Устройство графического адаптера — это видеопамять, кон­троллер атрибутов (RAMDAC), контроллер ЭЛТ (развертки), интерфейс монитора, интерфейс к хосту, акселератор, VideoBIOS.

Интерфейсы мониторов могут быть дискретные, аналого­вые и цифровые. Наиболее известные интерфейсы следующие:

Дискретный RGB TTL: DB-9, синхронизация HSync, +/—VSync; Video + Intens, RGB + Intens, RrGgBb.

Аналоговый RGB (VGA): DB-15; синхронизация раздель­ная/общая, RGB - 75 Ом/О,7 В.

Цифровые интерфейсы: P&D, DVI, DFP.

Интерфейс Panel-Link (VESA) —- основа; кодек последователь ­ного интерфейса, протокол T M.D.S. (Transition Minimazed Difleretial Signaling), 4 канала (3 data + 1 clock). Каждый канал данных (8 бит) образован кодером, расположенным на видеокарте, лини­ей связи и декодером, расположенным в дисплее; передает либо видео, либо синхронизацию и дополнительные сигналы.

Аналоговый интерфейс Composite Video: полный видеосиг­нал 1,5 В, коаксиал (75 Ом), разъемы RCA "колокольчики" (в бытовых видеомагнитофонах, аналоговых телекамерах, теле­визорах).

Аналоговый интерфейс S-Video (Separate Video, S-VHS и Y/C): Y — это яркость и синхронизации (luminance+sync, обыч­ный черно-белый видеосигнал, 1В) и С — это цветность (под- несущая, модулированная цветоразностными сигналами, 0,3 В). Коаксиал 75 Ом. Разъем mini-DIN (4 конт. или 7).

Рассмотрим другую важную часть обеспечения функциони­рования УВМ.

Работа УВМ в реальном масштабе времени обеспечивается операционной системой реального времени (ОС РВ), являющейся фундаментом базового программного обеспечения любой ЭВМ. ОС РВ должна обеспечивать полный цикл жизни программного обеспечения: создание текста программы, ее компиляцию, по­строение, отладку, исполнение и сопровождение. Требования, которым должны удовлетворять любые ОС РВ, изложены в стан­дарте POSIX 1003.4 (Real Time Extensions for Portable Operating Systems) рабочего комитета IEEE, утвержденном ISO/IEC как международный стандарт 9945. Этот стандарт определяет опера­ционную систему как систему реального времени (ОС РВ), если она обеспечивает требуемый уровень сервиса за вполне опреде­ленное, ограниченное время. Сказанное можно сформулировать таким образом, что ОС РВ должна быть предсказуема. Правиль­ная, но запоздалая реакция системы на внешнее событие зачас­тую может быть просто гибельной, например, в системе без­опасности атомной станции, системах управления воздушным транспортом и т. п. При этом важно не абсолютное время реак­ции системы, а то, что оно определено заранее. В системе управ­ления прокатным станом время реакции системы должно быть в пределах нескольких миллисекунд, а в системе контроля за окружающей средой — несколько минут. Однако оба эти при- ■ мера из области задач реального времени.

Попробуем с учетом изложенных особенностей режима ре­ального времени ответить на вопрос: а можно ли задачу реаль­ного времени решать с помощью операционных систем общего назначения (MS-DOS, UNIX и др.)? j Прежде чем ответить на него, вспомним, что все операционные системы делятся на системы реального времени и разделе­ния времени (общего назначения). Главное требование, предъяв­ляемое к системам общего назначения, заключается в обеспечении оптимального разделения всех ресурсов между всеми процессами,, Соответственно, не должно быть высокоприоритетных задач, которые использовали бы какой-либо ресурс системы только по мере необходимости. Поэтому разработчики операционных сис ­тем так или иначе стремятся достичь компромисса между меха- j низмом приоритетности и упомянутым требованием.

Самыми популярными операционными системами до на~ стоящего времени остаются UNIX — подобные системы. Более j того, UNIX стал de facto стандартом для последующих операци­онных систем. Он реализован и на микро- и на суперкомпьюте­рах. Многие программные международные стандарты и согла ­шения основаны на UNIX, например: POSIX (Portable Operating System Interfase Standard), SV1D, BSD 4.3 UNIX Socket и др. Однако UNIX разрабатывалась как система общего назначения, не имеет эффективного механизма приоритетности задач ^! и поэтому мало пригодна в задачах реального времени. В то же время, как будет показано позже, очень многие ОС РВ можно отнести к UNIX-подобным.

MS-DOS в принципе можно использовать в задачах реаль­ного времени. Однако надо учесть, что существует еще целый ряд требований к системам реального времени, чисто практи­ческого свойства, которым MS-DOS не удовлетворяет, а имен- j но: многозадачность (MS-DOS — однозадачная система), лег­кость написания и включения в систему драйверов внешних устройств и хорошо развитый механизм синхронизации процес­сов и межзадачных обменов.

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

Начнем с классификации ОС РВ. Обычно выделяют 4 класса ОС РВ:

1.0С РВ с программированием на уровне микропроцессо­ров.

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

2. ОС РВ с минимальным ядром системы реального времени.

s9to более высокий уровень системы реального времени, обеспечивающий минимальную среду исполнения. Предусмот­рены основные функции, но управление памятью и диспетчер недоступны. Ядро представляет собой набор программ, выпол­няющих типичные, необходимые для встроенных систем низко­го уровня функции типа арифметические операции с плаваю­щей запятой и функции минимального сервиса ввода-вывода. Прикладные программы разрабатываются в инструментальной среде и выполняются на различных объектных устройствах с помощью встраиваемых микропроцессоров.

З.ОС РВ с ядром системы реального времени и инструмен­тальной средой.

Этот класс систем обладает многими чертами полноцен­ной операционной системы с полным сервисом. Разработка ведется в инструментальной среде, а исполнение -— на целевых системах. Обеспечивается гораздо более высокий уровень сер­виса для разработчиков прикладных программ. Например, сюда включены такие средства, как дистанционный символьный отладчик, анализаторы эффективности, протокол ошибок и другие средства CASE (Computer Aided Software Engineering tools — средства разработки вспомогательного программного обеспечения для работы на компьютере). Кроме того, часто доступно параллельное программирование как часть среды исполнения.

4. ОС РВ с полным сервисом.

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

Системы второго и третьего классов принято называть сис­темами "жесткого" реального времени из-за жестких требова- | ний к времени реакции и необходимому объему памяти, а сис­темы четвертого класса — "мягкого" реального времени из-за более мягких требований. Быстродействие ОС РВ полностью за­висит от приложений, но всем ОС РВ присуща предсказуемость, т. е. способность системы откликнуться на событие в течение определенного ограниченного времени. При выборе той или иной ОС РВ все более важным моментом становится среда разработки прикладных программ.

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

1. Встроенные промышленные системы.

2. Промышленные системы с дисковой поддержкой.

3. Промышленные системы с сетевой поддержкой.

4. Однопользовательские системы разработки.

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

6. Небольшие многопользовательские системы.

7. Большие многопользовательские системы.

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

В настоящее время наиболее распространенными ОС РВ яв­ляются VRTX, Сехес, pSOS+, OS-9, VxWorks, iRMX, pDOS, QNX, HP RT. Рассматривая их основные характеристики, надо отметить, что при своих отличиях все они обладают основным набором возможностей к которым относятся:

-многозадачность с управлением задачами,

-управление памятью,

-синхронизация

-процессов,

-межзадачный обмен,

-ввод-вывод.

Операционная система VRTX разработана фирмой Ready Systems (США) и нашла применение в области автоматизации производства, коммуникации, управления роботами и аэрокос­мических исследований. Крупнейшими пользователями систе­мы являются фирмы AT&T, NASA, Motorola, IBM и другие. Распространяется в двух вариантах: VRTX — ядро реального вре­мени и VTRXvelocity — ядро реального времени плюс средства разработки.

Это UNIX-подобная система "жесткого" реального време­ни, которая может быть любой из рассмотренных возможных конфигураций. VRTXvelocity реализована на следующих систе­мах (кросс-среда): SUN 3, SUN 4, DECstation, VAX/VMS, HP 9000/400, PC/AT 80386. Система поддерживает стандарты TCP/ IP, NFS и сети Ethernet. Используется на процессорах Motorola 680x0, 68302, 68332; Intel 8086, 80186, 80286, 80386; Philips 68070, 93Cxxx; SUN SPARK; MIPS R3000; INMOS Transputer T4, T8.

Операционная система Cexec разработана фирмой JMI Software Consultants (США) и нашла применение в области уп­равления радарами, кардиографическими установками, лазер­ными принтерами, лабораторными системами регистрации дан­ных и других. Крупнейшими пользователями системы являются: IBM, Boeing, Lockheed, Xerox, DEC и другие. Система не требу­ет специальной кросс-среды. Задача кросс — компилируется, а затем строится с переносимой библиотекой (Cexecutive).

Cexec фактически является ядром реального времени, от­носится к системам "жесткого" реального времени и может быть первой и второй из рассмотренных конфигураций. Кросс-средой может служить любая система, поддерживающая стандартные С-компиляторы. Используется на процессорах: Motorola 680x0, 68332, 68008, 68009; Intel 8080, 8085, 8086, 8088, 80286, 80386, i860, i960; Zilog Z80; Hitachi 64180; Texas Instruments TMS 34010; DEC LSI-11, National Semiconductor Series 32000; MIPS R2000, R3000; AMD 29000; SUN SPARC.

Операционная система pSOS+ разработана фирмой Software Component Group (США) и нашла применение в области аэро-космических исследований, телекоммуникации, военной элек­троники, автоматизации производства и других.

Это UNIX-подобная система "жесткого" реального време­ни и может быть любой из рассмотренных конфигураций. Кросс- среда реализована на PC/AT, SUN 3, SUN 4, VAX, HP 9000, Apollo Workstation. Есть пакет CASE-средств для SUN 3, SUN 4 и отладчик языков высокого уровня для PC/AT, SUN 3, SUN 4, VAX/VMS, HP 9000, Apollo Workstation. Используется на про­цессорах: Motorola 680x0; Intel 80x86, i960; AMD 29000. Поддер­живает стандарты TCP/IP, NFS, X Windows, ANSI С-компиля- тор BSD 4.3 UNIX socket и сети Ethernet.

Операционная система GS-9/9000 разработана фирмой Microware System Corporation (США) и нашла применение в области систем связи, управления роботами, бортовых сис­тем, приборостроения, автоматизации производства, обработ­ки данных, образования, графических систем и других. Круп­нейшими пользователями системы являются: AT&T, NASA, Motorola, IBM, CERN, Boeing, Philips, Hitachi, Samsung, Sharp, Bruker, Thompson, Sony и другие.

Это UNIX-подобная система "мягкого" реального времени и может быть с первой по шестую из рассмотренных конфигу­раций. Кросс-среда реализована на PC/AT, SUN 3, SUN 4, VAX, HP 9000/300, Apollo/Domain, Silicon Graphics. Кроме того, раз­работка программ может вестись в рамках самой системы (Self- hosted-система) Используется на процессорах: Motorola 6809, 680x0, 683хх; Intel 80386, 80486. Поддерживает стандарты TCP/IP, NFS, X Windows, BSD 4.3 UNIX socket, X Motif, Kernighan & Ritchi С-компилятор, RPC и сети Ethernet.

Операционная система VxWorks разработана фирмой Wind River Systems (США) и нашла применение в области аэрокос­мических исследований, в телекоммуникации, управлении про­цессами, научныех исследованиях, медицинском приборост­роении, финансовом сервисе и других. Крупнейшими пользователями системы являются IBM, Boeing, Rockwell, Mitsubishi, British Aerospace, Xerox и другие.Это UNIX-подобная система "жесткого" реального време­ни и может быть любой из рассмотренных конфигураций. Кросс- среда реализована на PC/AT, SUN, HP 9000, DEC, FORCE.

Используется на процессорах: Motorola 680x0; Intel i960; SUN SPARC; MIPS RxOOO. Поддерживает стандарты POSIX, TCP/IP, NFS, X Windows, ANSI C-компилятор, RPC и сети Ethernet.

Операционная система iRMX разработана фирмой Intel Corporation (США) и нашит применение в области авиастроения, телекоммуникации, регистрации и анализа данных, автоматиза ции производства, управления финансами, спутниковой связи и других. Жестко ориентирована на шинные архитектуры MULTIbus 1/11 и стандартные компьютеры семейства IBM PC и PS/2.

Это UNIX-подобная система "мягкого" реального времени и может быть любой из рассмотренных конфигураций. Факти­чески iRMX — это семейство систем iRMX 1/11/111. При этом iRMX 1 — это базовая система для 16-битных процессоров, iRMX 11 — это развитие базовой системы с учетом особеннос­тей процессора 80286, a iRMX 111 — это развитие системы с адаптацией для 32-битных процессоров. Кроме того, в семей­ство входит 32-битное ядро реального времени для процессоров 80386/486. Кросс-среда реализована в MS-DOS и UNIX по сис­теме self-hosted. Используется на процессорах: Intel 8086, 8088, 80188,80x86 (iRMX 1); Intel 80286, 80386,80486 (iRMXll); Intel 80386, 80486 (iRMX 111). Поддерживает стандарт POSIX и сети Ethernet.

Операционная система pDOS разработана фирмой Eyring Corporation (США) и нашла применение в области телеком­муникации, приборостроения, автоматизации производства и друг их.

Это система "мягкого" реального времени и может быть с первой по шестую из рассмотренных конфигураций. Кросс- среда реализована в UNIX, VMS, MS-DOS, SUN OS. Кроме того, разработка прикладных программ может вестись в рамках самой системы (self-hosted). Используется на процессорах: Motorola 68000, 68010, 68020,68030. Поддерживает стандарты TCP/IP, POSIX, ANSI С-компилятор и сети Ethernet. Одна из наиболее популярных версий Vmeprorn — предназначена для VME.

Операционная система QNX разработана фирмой Quantum Software System (Канада) и нашла применение в области управ­ления производством, роботами, процессами контроля окружа­ющей среды и других.

Это система "мягкого" реального времени и может быть со второй по седьмую из рассмотренных конфигураций. Разработка ■ прикладных программ может вестись в рамках самой системы (self-hosted) Используется на процессорах: Intel 80286, 80386,! 80486; PS/2, HP-Vectra. Поддерживает стандарты TCP/IP, POSIX и сети Ethernet.

Операционная система HP-RT (HP-VX9.0) является разви­тием LvnxOS версии 2.1 фирмы Lynx Real-time Systems, Inc. (США) и нашла применение в области научных исследований, телекоммуникации, приборостроения, автоматизации производ­ства и других.

Это UNIX-подобная система "мягкого" реального времени и может быть любой из рассмотренных конфигураций. Кросс- среда реализована в UNI, возможен режим self-hosted. Исполь­зуется на процессорах HP-PA RISC7100. Поддерживает стандар­ты TCP/IP, POSIX, X Windows, NFS, ANSI С-компилятор j и сети Ethernet.

В России есть официальные дистрибуторы фирм-разработ­чиков ОС РВ, например АО "RTSoft" в г. Черноголовка, дистри­бутор фирмы "Microware System Corporation" — разработчика OS- 9, OS-9000, или AVD Systems г. Москва, дистрибутор фирмы Wind River Systems — разработчика VxWorks, и др.

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

В традиционных ОСРВ для межпроцессного взаимодействия (IPC — Inter-Process communication) используется, как прави­ло, модель "разделяемой памяти" (share memory). Большинству разработчиков хорошо известны трудности, связанные с управ­лением межпроцессным взаимодействием такого типа, а также опасность сбоя системы, возникающая в том случае, когда один процесс "приватизирует" доступ к данным или когда один про­цесс повреждает данные, жизненно важные для другого про- I цесса. Проблема обеспечения стабильности работы системы через разделяемую память вполне разрешима, однако в общем случае такая задача требует весьма аккуратного управ­ления разработкой и сопровождения программного обеспече­ния и достаточно длительного периода выявления ошибок. Пе­речисляя недостатки межпроцессного взаимодействия через разделяемую память, следует упомянуть также о том, что дан­ный метод плохо подходит для распределенных систем и не мо­жет похвастаться высокой степенью совместимости с управле­нием памятью. Работоспособность системы с IPC через разделяемую память достижима и в этих случаях, однако есть способы лучше.

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

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

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

В традиционных ОСРВ для динамического распределения памяти используется механизм, подобный вызову функции malloc в языке Си. При выполнении этой команды исследуется весь массив памяти в поисках свободной области достаточно боль­шого размера. У данного метода есть два недостатка. Первый — это то, что "глубина" таких поисков (а следовательно, и затра­чиваемое на распределение памяти время) будет меняться в за­висимости от того, как долго работает система. Второй недоста­ток связан с проблемой возникновения фрагментации: вы можете иметь 50 кбайт свободной памяти, но эти 50 кбайт могут быть в виде непригодных для использования 4-килобайтных кусоч­ков. Многие специалисты решают эту проблему при помощи хит­роумных программ и процедур собственного изготовления, од­нако такие методы могут нелучшим образом сказаться на характеристиках реального времени.

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

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

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

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

Известно, что большинство традиционных ОСРВ разраба­тывались с прицелом на единственный центральный процес­сор, установленный на единственной плате. В наши дни все чаще требуется поддержка многопроцессорных систем, в том числе с поддержкой процессоров цифровой обработки сигналов (DSP- процессоры). В современной операционной системе OSE обра­ботчик связей (link handler) позволяет естественным образом распределять приложение по многочисленным центральным и/или DSP-процессорам. Он действует на манер почтальона, беря сообщение от одного процесса, работающего на одном процес­соре, и вручая его другому процессу, исполняющемуся на дру­гом центральном или DSP-процессоре.

Сейчас ОСРВ все чаще применяются в критичных к без­опасности приложениях и в системах с высоким коэффициентом готовности, и большинство поставщиков операционных систем реального времени ищут способы решения возникающих в этой связи проблем. В случае операционной системы OSE решением являются два особых системных вызова: HUNT и ATTACH. Вы­зов HUNT позволяет ядру вести поиск процесса по имени. Вы­зов ATTACH сообщает процессу, что ядро проявляет к этому процессу "интерес". Это означает, что если с процессом что- нибудь будет "не так", ядро будет обязательно об этом проин­формировано. Используя эти системные вызовы, разработчик может реализовать "горячую" замену и дублирование (резерви­рование) аппаратных средств. При отказе или удалении какого- либо устройства происходит уведомление об этом ядра, после чего ядро может провести поиск (hunt) второго подобного уст­ройства и начать работать (attach) с этим устройством в том случае, если последнее окажется работоспособным.

Дата добавления: 2015-04-29