Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
осрв.doc
Скачиваний:
20
Добавлен:
25.04.2019
Размер:
269.82 Кб
Скачать

Вопрос 3. Типы архитектур осрв. Объектная архитектура на основе объектов-микроядер. Сравнение микроядер и модулей, драйверов, dll.

Микроядра по своим характеристикам напоминают структуры, используемые в других операционных системах, однако есть и свои различия.

1) Микроядра и модули. Многие ОС поддерживают динамическую загрузку компонент системы, называемых модулями. Однако, модули не поддерживают объектно-ориентированный подход (напомним, микроядро является фактически представителем некоторого класса). Далее, обмен информацией с модулями происходит посредством системных вызовов, что достаточно дорого.

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

3) Микроядра и DLL (Dynamically Linked Libraries, динамическисвязываемыебиблиотеки). Многие системы оформляют библиотеки, из которых берутся функции при динамическом связывании, в виде специальных модулей, называемых DLL. DLLобеспечивает разделение своего кода и данных для всех работающих приложений, в то время, как для микроядер можно управлять доступом для каждого конкретного приложения. DLL не поддерживает объектно-ориентированный подход, код DLL не является позиционно-независимым, и потому не может быть записан в ПЗУ.

Вопрос 4. Типы архитектур осрв. Модульная архитектура (на основе микроядер).

Модульная архитектура появилась как попытка убрать узкое место - API и облегчить модернизацию системы и перенос ее на новые процессоры.

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

1. управление взаимодействием частей системы (например, менеджеров процессов и файлов),

2. обеспечение непрерывности выполнения кода системы (т.е. отсутствие переключения задач во время исполнения микроядра).

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

Вопрос 5. Поддержка многозадачности и многопроцессорности специальными инструкциями.

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

Рассмотрим более подробно случай булевского семафора. Задача или процессор, собирающийся взять управление разделяемым ресурсом, начинают с чтения значения семафора. Если он обнулен, то задача или процессор должны ждать, пока ресурс станет доступным. Если семафор установлен в 1, то задача или процессор немедленно его обнуляют, чтобы показать, что контролируют ресурс. В процессе изменения семафора можно выделить три фазы: чтение, изменение, запись. Если на стадии чтения возникнет переключение задач или другой процессор станет главным на шине, то может возникнуть ошибка, так как две задачи или два процессора контролируют один и тот же ресурс. Аналогично, если переключение контекста произойдет между циклом чтения и записи, то два процесса могут взять семафор, что тоже приведет к системной ошибке. Для решения этой проблемы большинство процессоров имеют инструкцию, выполняющую неделимый цикл чтение - изменение - запись. Поскольку это одна инструкция, то переключение задач во время операции с семафором невозможно. Так как она производит неделимый цикл, то процессор, ее выполняющий, остается владельцем шины до окончания операции с семафором.