2009 overview ИУС РВ (1185197), страница 2
Текст из файла (страница 2)
обеспечение непрерывности выполнения кода системы (т.е. отсутствие переключениязадач во время исполнения кода системы).Основным преимуществом монолитной архитектуры является относительная быстротаработы по сравнению с другими архитектурами.Недостатки монолитной архитектуры:1. Системные вызовы, требующие переключения уровней привилегий должныреализовывать API как прерывания или ловушки .Это сильно увеличивает время их работы.2. Ядро не может быть прервано пользовательской задачей. Это может привести к тому,что высокоприоритетная задача может не получить управление из-за работы низкоприоритетной.3.
Сложность переноса на новый архитектуры процессора из-за значительныхассемблерных вставок.4. Негибкость и сложность развития: изменение части ядра системы требует его полнойперекомпиляции.Модульная архитектура (на основе микроядра) появилась как попытка убрать узкоеместо – API и облегчить модернизацию системы и перенос ее на новые процессоры.API обеспечивает связь прикладных процессов и специального модуля – менеджерапроцессов. Однако, теперь микроядро играет двойную роль:1. управление взаимодействием частей системы (например, менеджеров процессов ифайлов)2.
обеспечение непрерывности выполнения кода системы (т.е. отсутствие переключениязадач во время исполнения микроядра).Недостатки у модульной архитектуры фактически те же, что и у монолитной. Проблемыперешли с уровня API на уровень микроядра. Системный интерфейс по-прежнему не допускаетпереключения задач во время работы микроядра, только сократилось время пребывания в этомсостоянии. API по-прежнему может быть реализован только на ассемблере, проблемы спереносимостью микроядра уменьшились (в связи с сокращением его размера), но остались.Сочетание объекно-ориентированных приложений и процедурных операционных системимеет ряд недостатков: В едином работающем комплексе (приложение + ОСРВ) разные компонентыиспользуют разные подходы к разработке программного обеспечения.
Не используются все возможности объектно-ориентированного подхода. Возникают некоторые потери производительности из-за разного типа интерфейсов вОСРВ и приложении.Естественно, возникает идея строить саму ОСРВ, используя объектно-ориентированныйподход.Объектная архитектура на основе объектов-микроядер. В этой архитектуре APIотсутствует вообще. Взаимодействие между компонентами системы (микроядрами) ипользовательскими процессами осуществляется посредством обычного вызова функций,поскольку и система, и приложения написаны на одном языке (Для ОСРВ SoftKernel этоC++).Это обеспечивает максимальную скорость системных вызовов.Фактическое равноправие всех компонент системы обеспечивает возможностьпереключения задач в любое время, т.е.
система полностью preemptible.Объектно-ориентированный подход обеспечивает модульность, безопасность, легкостьмодернизации и повторного использования кода.Роль API играет компилятор и динамический редактор объектных связей (linker). Пристарте приложения динамический linker загружает нужные ему микроядра (т.е., в отличие отпредыдущих систем, не все компоненты самой операционной системы должны быть загруженыв оперативную память). Если микроядро уже загружено для другого приложения, оно повторноне загружается, а использует код и данные уже имеющегося ядра. Это позволяет уменьшитьобъем требуемой памяти.Поскольку разные приложения разделяют одни микроядра, то они должны работать водном адресном пространстве.
Следовательно, система не может использовать виртуальнуюпамять и тем самым работает быстрее (так как исключаются задержки на трансляциювиртуального адреса в физический).Поскольку все приложения и сами микроядра работают в одном адресном пространстве,то они загружаются в память, начиная с неизвестного на момент компиляции адреса.Следовательно, приложения и микроядра не должны зависеть от начального адреса (как покоду, так и поданным (последнее обеспечить значительно сложнее)). Это свойствоавтоматически обеспечивает возможность записи приложений и модулей в ПЗУ, с ихпоследующим исполнением как в самом ПЗУ, так и оперативной памяти.Микроядра по своим характеристикам напоминают структуры, используемые в другихоперационных системах. Однако есть и свои различия. Микроядра и модули.
Многие ОС поддерживают динамическую загрузку компонентсистемы, называемых модулями. Однако, модули не поддерживают объектно-ориентрованныйподход (напомним, микроядро фактически является представителем некоторого класса). Далее,обмен информацией с модулями происходит посредством системных вызовов, что достаточнодорого. Микроядра и драйверы. Многие ОС поддерживают возможность своего расширенияпосредством драйверов (специальных модулей, обычно служащих для поддержкиоборудования).
Однако, драйверы часто должны быть статически связаны с ядром (т.е.образовывать с ним связанный загрузочный образ еще до загрузки) и должны работать впривилегированном (суперпользовательском) режиме. Далее, как модули они не поддерживаютобъектно-ориентированный подход и доступны приложению только посредством системныхвызовов. Микроядра и DLL. Многие системы оформляют библиотеки, из которых берутсяфункции при динамическом связывании, в виде специальных модулей, называемых DLL(Dynamically Linked Libraries – динамически связываемые библиотеки).
DLL обеспечиваетразделение своего кода и данных для всех работающих приложений, в то время как длямикроядер можно управлять доступом для каждого конкретного приложения. DLL неподдерживает объектно-ориентированный подход, код DLL не является позиционнонезависимым и не может быть записан в ПЗУ.Системы реального времени можно разделить на 4 класса.1-й класс: исполнительные СРВ.Это программы для программируемых микропроцессоров, встраиваемых в различныеустройства, очень небольшие и обычно написаны на языке низкого уровня типа ассемблера илиPLM. Внутрисхемные эмуляторы пригодны для отладки, но высокоуровневые средстваразработки и отладки программ не применимы. Операционная среда обычно недоступна.Признаки систем этого типа - различные платформы для систем разработки и исполнения.Приложение реального времени разрабатывается на host- компьютере (компьютере системыразработки), затем компонуется с ядром и загружается в целевую систему для исполнения.
Какправило, приложение реального времени - это одна задача и параллелизм здесь достигается спомощью нитей (threads).Системы этого типа обладают рядом достоинств, среди которых главное - скорость иреактивность системы. Главная причина высокой реактивности систем этого типа - наличиетолько нитей(потоков) и, следовательно, маленькое время переключения контекста между ними( в отличие от процессов).С этим главным достоинством связан и ряд недостатков: зависание всей системы призависании нити, проблемы с динамической подгрузкой новых приложений2-й класс: минимальное ядро системы реального времени.На более высоком уровне находятся системы реального времени, обеспечивающиеминимальную среду исполнения.
Предусмотрены лишь основные функции, а управлениепамятью и диспетчер часто недоступны. Ядро представляет собой набор программ,выполняющих типичные, необходимые для встроенных систем низкого уровня функции, такие,как операции с плавающей запятой и минимальный сервис ввода/вывода. Прикладнаяпрограмма разрабатывается в инструментальной среде, а выполняется, как правило, навстроенных системах.В этот класс входят системы с монолитным ядром, где и содержится реализация всехмеханизмов реального времени этих операционных систем.Системы этого класса, как правило, модульны, хорошо структурированы, имеют наиболееразвитый набор специфических механизмов реального времени, компактны и предсказуемы.Наиболее популярные системы этого класса: OS9, QNX.Одна из особенностей систем этого класса - высокая степень масштабируемости.
На базеэтих ОС можно построить как компактные системы реального времени, так и большие системысерверного класса.3-й класс: ядро системы реального времени и инструментальная среда. Этот класссистем обладает многими чертами ОС с полным сервисом. Разработка ведется винструментальной среде, а исполнение - на целевых системах.
Этот тип систем обеспечиваетгораздо более высокий уровень сервиса для разработчика прикладной программы. Сюдавключены такие средства, как дистанционный символьный отладчик, протокол ошибок идругие средства CASE. Часто доступно параллельное выполнение программ.4-й класс: ОС с полным сервисом. Такие ОС могут быть применены для любыхприложений реального времени.
Разработка и исполнение прикладных программ ведутся врамках одной и той же системы.Область применения расширений реального времени - большие системы реальноговремени, где требуется визуализация, работа с базами данных, доступ в интернет и пр.Функции ядра ОСРВ. Процессы. Состояния процесса. Жизненный цикл процесса. Потоки.Приоритеты процессов.Ядро может обеспечивать сервис пяти типов:Синхронизация ресурсов. Метод синхронизации требует ограничить доступ к общимресурсам (данным и внешним устройствам). Наиболее распространенный тип примитивнойсинхронизации - двоичный семафор, обеспечивающий избирательный доступ к общимресурсам.
Так, процесс, требующий защищенного семафором ресурса, вынужден ожидать дотех пор, пока семафор не станет доступным, что свидетельствует об освобождении ожидаемогоресурса, и, захватив ресурс, установить семафор. В свою очередь, другие процессы также будутожидать доступа к ресурсу вплоть до того момента, когда семафор возвратит соответствующийресурссистемераспределенияресурсов.Системы,обладающиебольшейошибкоустойчивостью, могут иметь счетный семафор. Этот вид семафора разрешаетодновременный доступ к ресурсу лишь определенному количеству процессов.Межзадачный обмен.
Часто необходимо обеспечить передачу данных междупрограммами внутри одной и той же системы Кроме того, во многих приложениях возникаетнеобходимость взаимодействия с другими системами через сеть. Внутренняя связь может бытьосуществлена через систему передачи сообщений. Внешнюю связь можно организовать либочерез датаграмму (наилучший способ доставки), либо по линиям связи (гарантированнаядоставка). Выбор того или иного способа зависит от протокола связи.Разделение данных. В прикладных программах, работающих в реальном времени,наиболее длительным является сбор данных.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
