Текст лекции. Лекция № 2. Архитектура операционных систем

Ключевые вопросы

Лекция № 2. Архитектура операционных систем. Часть 2

Продолжительность: 2 часа (90 мин.)

· Цель и задачи курса.

· Информация и данные.

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

· Основные понятия и определения: многоуровневые ОС;виртуальные машины.

· Экзоядро.

· История развития систем обработки данных.

· Назначение и основные компоненты СБД.

· Модель клиент-сервер.

5.2.1 Многоуровневые ОС — до 15 мин.

Для понимания обобщенной структуры многоуровневой операционной системы рассмотрим пример, приведенный в [2].

- Уровень 1. В него входят электронные схемы – регистры, ячейки памяти, логика. Над элементами этого уровня выполняются такие действия, как очистка содержимого, считывание содержимого и т.д.

- Уровень 2. Набор команд процессора. На этом уровне выполняются такие операции, как сложение, вычитание, пересылки и т. д.

- Уровень 3. Содержит концепцию процедуры (подпрограммы), а также операции вызова и возврата.

- Уровень 4. Уровень прерываний. Здесь организуется выполнение процессором процедуры обработки прерывания с сохранением текущего контекста.

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

- Уровень 5. Уровень процесса, под которым понимается работающая программа. Фундаментальное требование к многозадачной операционной системе – способность приостанавливать процессы и возобновлять их выполнение.

- Уровень 6. Здесь осуществляется работа на физическом уровне со вспомогательными устройствами памяти компьютера.

- Уровень 7. Создает логическое адресное пространство процессов. Этот уровень организует виртуальное адресное пространство в виде блоков, которые могут перемещаться между основной памятью и вспомогательной. В качестве блоков могут использоваться страницы постоянного размера, сегменты переменного размера или комбинация тех и других. Если нужный блок отсутствует в основной памяти, формируется запрос уровню 6 о передаче этого блока.

- Уровень 8. Отвечает за обмен информацией и сообщениями между процессами. Одним из инструментов этого уровня является канал, передающий выход одного процесса на вход другого. На этом уровне может осуществляться связь с процессами внешних устройств или с файловыми процессами.

- Уровень 9. Обеспечивает долгосрочное хранение файлов. Здесь используется логический уровень хранения (название файла, длина) в отличие от физического уровня хранения (дорожка, сектор, головка) уровня 6.

- Уровень 10. Предоставляет доступ к внешним устройствам с помощью стандартных интерфейсов.

- Уровень 11. Поддерживает связь между внешними и внутренними идентификаторами системных ресурсов и объектов (имя файла и его дескриптор). Эта связь поддерживается с помощью каталога, который содержит взаимное отображение внешних и внутренних идентификаторов и права доступа.

- Уровень 12. Предоставляет полнофункциональные средства поддержки процессов. В отличие от уровня 5, на котором реализована поддержка регистров процессора и логика диспетчеризации, на этом уровне поддерживается виртуальное адресное пространство, список объектов и процессов взаимодействия, правила и ограничения этого взаимодействия.

- Уровень 13. Обеспечивает взаимодействие операционной системы с пользователем. Этот уровень обычно называется оболочкой (shell). Оболочка принимает команды пользователя, интерпретирует их, создает необходимые процессы и управляет ими. На этом уровне создаются графические оболочки.

Представим иерархическую модель операционной системы в виде таблицы 5.1.

Таблица 5.1 – Иерархическая модель операционной системы

Уровень	Название	Объекты	Операции
	Оболочка	Среда программирования пользователя	Инструкции командного языка оболочки
	Процессы пользователя	Процессы пользователя	Завершение, приостановка, возобновление процесса
	Каталоги	Каталоги	Создание, удаление, подключение, поиск
	Устройства	Внешние устройства (принтер, монитор, мышь)	Открытие, закрытие, чтение, запись
	Файловая система	Файлы	Создание, удаление, открытие, закрытие, чтение, запись
	Коммуникации	Конвейеры	Создание, удаление, открытие, закрытие, чтение, запись
	Виртуальная память	Сегменты, страницы	Чтение, запись, выборка
	Локальная вторичная память	Блоки данных, каналы, устройства	Чтение, запись, распределение, выборка
	Примитивные процессы	Примитивные процессы, семафоры, список процессов	Приостановка, возобновление выполнения, ожидание, передача сигнала
	Прерывания	Процедуры обработки прерываний	Вызов, маскирование, повтор
	Процедуры	Процедуры, стеки вызова	Вызов, возврат
	Набор команд	Стек вычислений, интерпретатор команд, данные	Пересылка, сложение, вычитание, ветвление
	Электронные схемы	Регистры, шлюзы, шины и т. д.	Очистка, пересылка, активация

Первой системой, построенной таким образом, была система THE, созданная в Technische Hogeschool Eindhoven в Нидерландах Э. Дейкстрой и его студентами в 1968 году. Это была простая пакетная система для компьютера Electrologica X8, память которой состояла из 32 К 27-разрядных слов. Система состояла из шести уровней, как показано в таблице 5.1. Уровень 0 занимался распределением времени процессора, переключая процессы при возникновении прерываний или при срабатывании таймера. То есть, уровень 0 обеспечивал базовую многозадачность процессора.

Уровень 1 управлял памятью. Он выделял процессам пространство в оперативной памяти и на магнитном барабане объемом 512 К слов для тех частей процессов (страниц), которые не помещались в оперативной памяти. Программное обеспечение уровня 1 обеспечивало попадание нужных страниц в оперативную память по мере необходимости.

Таблица 5.2 – Структура операционной системы THE

Уровень	Функция
	Оператор
	Программы пользователя
	Управление вводом-выводом
	Связь оператор-процесс
	Управление памятью и барабаном
	Распределение процессора и многозадачность

Уровень 2 управлял связью между консолью оператора и процессами.

Уровень 3 управлял устройствами ввода-вывода и буферизовал потоки информации к ним или от них.

На уровне 4 работали пользовательские программы, которым не надо было заботиться ни о процессах, ни о памяти, ни о консоли, на об управлении устройствами ввода-вывода.

На уровне 5 размещался процесс системного оператора.

5.2.2 Виртуальные машины — до 15 мин.

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

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

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

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

Таким образом, любая операционная система фактически предоставляет пользователю или программисту некоторую виртуальную машину, которой управлять легче, чем реальной аппаратурой компьютера.

Новое понимание важности формирования виртуальных машин возникло при попытке организовать многозадачную и/или многопользовательскую работу на компьютере. Здесь обычно говорят о системе виртуальных машин.

Система виртуальных машин – это ОС, допускающая одновременную работу нескольких программ, но создающая при этом для каждой программы иллюзию того, что машина находится в ее полном распоряжении. Создание операционной системы, основанной на виртуальных машинах, было обусловлено желанием большого числа пользователей IBM/360 работать в режиме разделения времени. Исходная версия OS/360 предназначалась исключительно для пакетной обработки заданий. Следуя пожеланиям пользователей, в фирме IBM попытались разработать систему разделения времени TSS/360, которая оказалась однако громоздкой и медлительной, и успеха не имела. За разработку требуемой системы взялась группа из научного центра IBM в Кембридже, и разработала систему, которую фирма IBM и приняла в качестве законченного продукта. Эта система до сих пор используется на мейнфреймах.

В оригинале созданная система называлась CP/CMS, затем была переименована в VM/370. Эта система предоставляла многозадачность и расширенную машину с более удобным интерфейсом, чем имеющееся аппаратное обеспечение.

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

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

Так как каждая такая виртуальная машина полностью идентична настоящему оборудованию, на каждой из них может работать любая операционная системе, которая работает на реальной аппаратуре. На разных виртуальных машинах могут одновременно работать различные операционные системы.

Идея таких виртуальных машин используется и в настоящее время. Фирма Intel при моральной поддержке фирмы Microsoft в разработке нового поколения 32-разрядных процессоров (386+) предусмотрела режим виртуального процессора 8086. В этом режиме процессор работает как обычный процессор 8086(8088), включая 16-разрядную адресацию памяти с ограничением адресного пространства в 1 Мбайт.

Этот режим используется системой Windows и другими операционными системами для запуска программ MS-DOS. Программы запускаются в режиме виртуального процессора 8086. Пока они выполняют обычные команды, они работают напрямую с оборудованием. Как только программа обращается операционной системе для выполнения системного вызова, или пытается сама осуществить ввод-вывод данных, генерируется исключение и управление передается монитору виртуальной машины. Затем уже монитор виртуальной машины разбирается с тем, как выполнять соответствующий запрос.

Другое использование виртуальных машин можно продемонстрировать на примере виртуальной Java-машине. Когда фирма Sun разработала язык программирования Java, она разработала и виртуальную Java-машину (JVM – Java Virtual Machine). Компилятор языка Java выдает код для JVM, который затем выполняется интерпретатором JVM.

5.2.3 Экзоядро — до 15 мин.

В системе VM/370 каждый пользователь получает в свое распоряжение точную копию настоящей машины. 386 процессор в режиме виртуальной машины 8086 предоставляет каждому пользователю точную копию другой машины. Развивая эту идею дальше, в Массачусетском технологическом институте разработали систему, которая предоставляет каждому пользователю абсолютную копию реального компьютера, но с подмножеством ресурсов. Например, одна виртуальная машина может получить блоки на диске с номерами от 0 до 1023, другая – от 1024 до 2047 и т. д. На нижнем уровне в режиме ядра работает программа, которая называется экзоядро (exokernel). Она занимается распределением ресурсов для виртуальных машин и проверкой их использования. Каждая виртуальная машина на уровне пользователя может работать с собственной операционной системой (как в системе виртуальных машин), но при этом она ограничена набором ресурсов, которые она запросила, и которые ей были предоставлены.

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

5.2.4 Модель клиент-сервер — до 15 мин.

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

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

Рисунок 5.3 – Модель клиент-сервер

Модель клиент-сервер показан на рисунке 5.3. На рисунке показано, что в задачу ядра входит только управление связью между клиентами и серверами. Такая организация дает системе следующие преимущества:

- Благодаря разделению операционной системы на части, каждая из которых управляет только одним элементом (файловой системой, процессами, терминалом, памятью), все части становятся маленькими и легко управляемыми.

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

- Клиент-серверная архитектура очень просто адаптируется к распределенным системам.

Использование клиент-серверной архитектуры в распределенных системах показано на рисунке 5.4.

Рисунок 5.4 – Модель клиент-сервер в распределенной системе

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

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

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

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