Лекции / 9_обзор современных ОС и операционных оболочек
.doc9. Обзор современных ОС и операционных оболочек
9.1. Обзор операционных систем семейств UNIX, Windows (Лекция 19)
9.1.1. Организация ОС W2K
9.1.1.1. Архитектура
История: PC-DOS->DOS->Windows 3.x->Windows NT, Windows 9x/
Архитектура:
Рис.1
HAL формирует отображение между общими командами, а также ответными сигналами от аппаратуры и таковыми для конкретной платформы. Это есть попытка виртуализации аппаратуры. К этому уровню относятся средства поддержки системной шины, DMA, котроллер прерываний, память, средства мультипроцессорности, системные таймеры.
Микроядро состоит наиболее используемые компоненты ОС: распределение ресурсов, переключение и синхронизация потоков и процессов. Код микроядра не разделен на потоки и не может быть выгружен на диск.
Исполнительная система, ее структура выполнена в соответствие с моделью клиент-сервер, т.е. общепринятой моделью распределенной вычислений.
Преимущества модели Клиент-Сервер:
-
Модульность по отношению к интерфейсам.
В систему легко добавлять новые API, т.к. для этого требуется:
-
публикация свойств интерфейса
-
объект-сервер, реализующий интерфейс.
-
Надежность.
Каждый сервер имеет отдельный поток или процесс.
Сервер может быть реализован по двум схемам:
-
простой вызов подпрограммы,
-
в виде асинхронного процесса, обменивающегося сообщениями с процессами клиента. При этом реализация функции сервера осуществляется в системном процессе сервера и соответственно в отдельном адресном пространстве, что исключает ошибочное или преднамеренное вмешательство в процесс клиента.
Недостатки:
-
необходимость использования объектов синхронизации
-
сложность схемы-вызова сервиса.
Алгоритм работы сервера заключается в следующем:
-
создать именованный объект синхронизации, свидетельствующий о том, свободен ли процесс сервера или завершено выполнение функции.
-
ждать, пока в системе не перейдет в активное состояние объект синхронизации, «запрос» клиента.
-
Выполнить функцию, выставить в активное состояние объект «выполнение функции завершено».
-
Перейти к 2).
Алгоритм работы клиент:
-
ждать активного состояния объекта «сервер свободен».
-
выставить активное состояние клиента «сервер свободен».
ждать активного состояния объекта «выполнение завершено»
Для передачи параметров в такой схеме используется разделяемая область памяти, в которой размещаются параметры функции в формате, известном и клиенту, и серверу.
-
Локальные и удаленные вызовы процедур выглядят одинаково для клиента.
Рис.2
9.1.1.2. Поддержка потоков и симметричной мультипроцессорности
-
Серверные процессы могут использовать несколько потоков для одновременной обработки запросов от разных клиентов.
-
Потоки могут одновременно выполняться на разных процессорах. Следовательно, при аппаратной поддержке гарантируется повышение эффективности обработки клиентских запросов.
Архитектура WIN2000 объектно-ориентированная. Для управления объектами любого типа W2k использует общий набор функций API. Объектами являются файлы, процессы, потоки, семафоры, таймеры, окна и т.п.
Объектам всех типов присущи общие атрибуты (имена, параметры безопасности, счетчики использования). Каждый отдельный класс имеет свои специфические элементы (например, приоритет процесса).
Когда создается объект для использования приложения, система возвращает дескриптор (описатель), который фактически является указателем на объект.
Объекты в W2k могут быть именованными и неименованными. Обращение к неименованным объектам – через дескриптор, именованным – по имени.
Именованные объекты – почти единственный способ разделения ресурсов между процессами, потому что дескриптор (указатель) не имеет смысла в адресном пространстве другого процесса. Например, именованные события используются для синхронизации процессов. Но внутри процесса для его потоков достаточно дескрипторов.
W2k не является полностью объектно-ориентированным. Достаточно взглянуть на функции API – у каждой чуть не по десятку параметров. Хотя есть и такие функции, которые принимают заполненные объектные структуры.
9.1.1.3. Области API
Атомы
Ввод с клавиатуры, мыши
Вывод на печать
DLL
Коммуникации
Консоли
Буфер обмена
Окна
Службы
Реестр
Графические примитивы
Конвейеры (pipes)
Мультимедиа
Процессы и потоки
Ресурсы
Сети
Управление памятью
Файлы
В W2k реализована объектно-ориентированная технология COM (Component Object Model). В основе СОМ лежит понятие двоичного компонента – объекта, содержащего исполняемый код, доступ к которому осуществляется через интерфейс. СОМ-объекты могут быть как системными, так и пользовательскими.
Исполнительная система предоставляет API.
Модули исполнительной системы:
- диспетчер в/в. Реализует APIв/в. Поддерживает доступность устройств в/в для приложений. Отвечает за координацию драйверов. С помощью диспетчера объектов следит за безопасностью и именованием устройств и ФС.
- диспетчер объектов. Создает и удаляет объекты и абстрактные типы данных исполнительной системы. Среди объектов: потоки, процессы, объекты синхронизации. Создает дескрипторы объектов, в которых содержится информация о правах доступа.
- монитор безопасности обращений.
Обеспечивает выполнение правил доступа.
ОО Модель позволяет формировать единообразный взгляд на безопасность. Для авторизации доступа и аудита всех защищенных объектов используются одни и те же служебные программы. (Остальные диспетчеры более или менее понятны).
W2k поддерживает 5 типов приложений пользователя.
Win32, POSIX, OS/2, Windows 3.1 и MS-DOS.
Все это поддерживается с помощью единой и компактной исполнительной системы. Вызовы преобразуются в вызовы W2k. Каждая из подсистем является отдельным системным процессом.
9.1.2. UNIX
9.1.2.1. Обзор ОС семейства UNIX
История BellLabs (1970), PDP-7, затем перенесена на PDP-11.
Рис.1
1974 – Unix описана в техническом журнале->волна интереса.
1976 – 6-я версия (1-я широко распространенная за пределами BellLabs).
1978 – 7-я версия – прототип современных систем.
1982 – AT&T компонует все свои варианты в Unix System III -> Unix System V.
Структура системы.
Рис.2
Ядро Unix монолитное, имеет сложное и объёмное устройство, не разделяется на модули. Основной недостаток монолитного ядра – слабая возможность повторного изменения кода, ядро не является наращиваемым.
Рис.3
Основной недостаток монолитного и немодульного ядра – слабые возможности повторного использования кода. Ядро не является наращиваемым.
Современные системы Unix имеют модульное ядро.
Рис.4
System V Release 4 (SVR4).
Разработана совместно компаниями AT&T и Sun, сочетает в себе SVR3, 4.3BSD, SunOS.
1) поддержка обработки данных в реальном времени
2) классы планирования процессов
3) динамическое распределение структурных данных управления виртуальной памятью
4) виртуальная файловая система
5) ядро с вытеснением.
Solaris (Sun, на основе SVR4)
Особенности: многопоточное ядро, полная вытесняемость, поддержка SMP, объектно-ориентированный интерфейс файловых систем.
4BSD(Berkley, Калифорнийский университет)
Linux
1991 – первая версия
Разрабатывается под эгидой GNU.
Особенности Linux
- Модульная архитектура
Linux организована в виде относительно независимых модулей, называемых загружаемыми.
- динамическое связывание – любой модуль может быть загружен в память и подсоединен к ядру, когда оно уже загружено и выполняется. Отсоединение и удаление из памяти аналогично. (Чем не DLL?)
- стековая организация модулей.
1) однотипный код помещается в один модуль.
2) ядро проверяет зависимости модулей, загружая вместе все связанные.
Каждый модуль задается двумя таблицами: таблицей модулей и таблицей символов.
Таблица модулей состоит из следующих полей:
next – указатель на следующий модуль (связный список); начинается список псевдомодулем.
ref – список модулей, используемых данным модулем.
symtab – указатель на таблицу символов модуля.
name – имя модуля.
size – размер (в страницах).
addr – указатель на начальный адрес.
State – текущее состояние.
*cleanup() – указатель на программу, которая запускается при выгрузке модуля.
Таблица символов определяет символы, контролируемые данным модулем:
size – полный размер таблицы.
n_symbols – количество символов.
n_refs – количество ссылок.
symbols – символы.
references – модули, зависящие от данного.
QNX – микроядерная ОС, предназначенная для управления процессами реального времени, имеет ядро – 8 Кб, 16 систем вызовов.
Менеджер процессов добивается к микроядру для управления программами и памятью.
Из-за спецификации ОС PB о встроенных, часто бездисковых системах, применение полного объема модулей нецелесообразно, но при необходимости файловая система и менеджер устройств добираются к микроядру.
Механизм передачи сообщений между модулями QNX оптимизируется, т.к. подобная архитектура может иметь серьезное ограничение производительности.