Деревянко А.С., Солощук М.Н. Операционные системы. Часть II. Обзор операционных систем

Подождите немного. Документ загружается.

До 1997 г. ОС Linux была популярна почти исключительно в

университетской среде. Однако в 1997 г. ряд фирм объявил о выпуске

собственных версий Linux. Некоторые из этих версий (например, Red Hat)

остались бесплатными, некоторые (например, Caldera) стали

коммерческими. Принципиально важно то, что у Linux появились

"хозяева", которые несли ответственность (в том числе и коммерческую) за

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

Linux пользователей, которые решают задачи промышленной обработки

информации. Такой интерес объясняется, с одной стороны, желанием

иметь "почти настоящую" ОС Unix со значительно меньшими расходами, с

другой, нежеланием попадать в полную зависимость от Microsoft. Фирмы-

лидеры информационных технологий не могли игнорировать настроения

рынка и объявили либо о выпуске собственных версий Linux (например,

Hewlett-Packard), либо о поддержке определенных версий Linux на своих

аппаратных платформах и в своем промежуточном программном

обеспечении (например, IBM). Интересно, что эти фирмы являются

производителем собственных коммерческих версий ОС Unix. В последних

версиях всех коммерческих ОС Unix, рассмотренных выше, в API ОС

внесены системные вызовы, обеспечивающие возможность выполнения в

них приложений, написанных для Linux. Пока, по-видимому, гранды

информационных технологий не видят в Linux серьезного конкурента для

своих ОС в сфере промышленной обработки данных и систем высокой

готовности и предусматривают перенос информационных систем с Linux

на коммерческие Unix при достижении ими определенной степени

зрелости. Не без помощи "грандов" достигнут перенос Linux на большое

число платформ – от встроенных вычислительных устройств до

мейнфреймов и суперкомпьютеров. Возможно, с достижением Linux

промышленного уровня, в этой ОС сможет воплотиться идея, не удавшаяся

в проекте Monterey – единая ОС Unix для всех.

Следует отметить еще одну интересную сферу применения Linux.

Ряд стран (например, Китай, Россия) объявил о принятии в качестве

базовой ОС для информационных системах в своих силовых структурах

ОС, "изготовляемой на основе Linux". Основную роль здесь играет

открытость исходного кода. Доступность исходного кода Linux позволяет

правительственным специалистам этих стран с одной стороны убедиться в

отсутствии в ОС "закладок", занимающихся "электронным шпионажем", а

с другой – провести исчерпывающую верификацию ОС и добиться ее

высокой надежности и безопасности.

В следующем изложении мы ориентируемся прежде всего на

"классическую" ОС Unix, ведущую свою родословную от Bell Labs, и ее

последнюю на сегодняшний день версию – Open Unix 8, но рассматриваем

также и некоторые особенности других коммерческих и некоммерческих

ОС семейства Unix.

6.2. Архитектура Unix

Архитектура ОС Unix [14] представлена на рисунке 6.1.

Рисунок 6.1 Архитектура Unix

Хотя эта архитектура объявлена как иерархическая, в ней

просматриваются всего три уровня иерархии: ядро, системные утилиты,

процессы пользователей. Само ядро Unix, таким образом, является

монолитным, хотя некоторая (не формулируемая декларативно)

структурированность в нем, конечно же, имеется. Так, в Unix различаются

две принципиально различные группы системных вызовов: внутренние,

которые доступны для пользовательских процессов и составляют

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

Весьма тщательно выполнено разделение ядра на аппаратно-зависимую и

аппаратно-независимую части.

Модули первой части пишутся на языке Ассемблера целевой

платформы и выполняют:

• загрузку и инициализацию ОС;

• переключение контекста;

• управление реальной памятью;

• первичную (низкоуровневую) обработку прерываний;

• низкоуровневое управление устройствами (аппаратные драйверы).

Модули второй части написаны на языке C и обеспечивают

высокоуровневую обработку, в том числе:

• порождение планирование и прочее управление процессами и (в

поздних реализациях) нитями:

• управление виртуальной памятью;

• средства взаимодействия между процессами;

• поддержку файловой системы;

• логическую обработку прерываний;

• высокоуровневые функции драйверов устройств;

• поддержку API.

Обращения процессов к системе имеют вид программных

прерываний, но из прикладной программы обращение к ОС имеет вид

вызова библиотечных функций, написанных на языке C. Модули

библиотеки системных вызовов аппаратно-зависимые и содержат

обращения к ядру с использованием тех механизмов программного

прерывания, которые доступны на данной аппаратной платформе.

6.3. Процессы

Концепция процесса в том виде, в каком она представлена в нашей

книге, родилась именно в MULTICS и Unix. Процессом является

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

байтов, интерпретируемые процессором как машинные команды, данные и

стековые структуры.

Контекстом процесса в Unix является его состояние, определяемое

содержимым адресного пространства процесса, значениями глобальных

переменных пользователя и информационными структурами, содержимым

машинных регистров, значениями, хранимыми в строке таблицы

процессов, а также содержимым стеков задачи и ядра, данного процесса.

Коды модулей ОС и общие информационные структуры, совместно

использующиеся всеми процессами, не являются составной частью

контекста процесса.

Вся работа системы происходит в контексте какого-либо процесса.

Если процесс выполняет системный вызов, при котором происходит

переход в режим ядра, то меняется режим, но не контекст. Модули ядра,

следовательно, выполняются в контексте процесса и используют ресурсы

того процесса, для которого они выполняются. Прерывания также

выполняются в контексте процесса – того процесса, который был прерван,

даже если прерывание не имеет отношения к этому процессу. Программы

обработки прерываний обычно не работают со статической составляющей

контекста процесса, так как эта часть не связана с прерываниями.

В системе процесс представляется строкой в таблице процессов. В

ранних версиях Unix таблица процессов, как и другие системные

структуры данных в памяти, располагались в статической памяти, имели

фиксированный размер и смежное размещение. Позднее эти структуры

стали располагаться в динамически выделяемой памяти со связным

размещением, что дает возможность изменять их размер. Строка таблицы

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

вне его контекста, такие как: идентификатор процесса, состояние процесса,

его приоритет и т.д., а также указатели на структуры, описывающие

контекст процесса.

Контекст процесса состоит из пользовательской и системной

составляющих.

Пользовательский контекст включает в себя содержимое адресного

пространства процесса (программного кода, данных, стека) и вектор

состояния (содержимое аппаратных регистров).

Системный контекст содержит структуры данных ядра, связанные с

этим процессом. Системный контекст процесса в Unix состоит из

статической и динамических частей. Для каждого процесса имеется одна

статическая часть контекста системного уровня и переменное число

динамических частей.

Статическая часть системного контекста процесса включает в себя:

• строку таблицы процессов;

• часть адресного пространства задачи, выделенную процессу, где

хранится управляющая информация о процессе; эта информация

недоступна самому процессу, но может использоваться ядром

только в контексте процесса;

• структуры данных, описывающие виртуальное адресное

пространство процесса; если два или более процессов используют

разделяемые сегменты памяти (см. ниже), то соответствующие

структуры данных включаются в системный контекст каждого из

этих процессов.

Динамическая часть системного контекста процесса представляет

собой стек ядра.

Стек, входящий в состав пользовательской части контекста процесса

предназначается для размещения в нем локальных переменных и

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

сказали выше, процесс может выполняться как в режиме процесса, так и в

режиме ядра (точнее – модули ядра выполняются в контексте процесса).

Динамическая часть системного процесса предназначена для обеспечения

функционирования в режиме ядра. Выполнение модулей в режиме ядра

может прерываться так же, как и выполнение модулей в режиме процесса.

ОС Unix рассчитана на некоторую иерархию прерываний: каждое

прерывание имеет некоторый уровень приоритета, и обработка

прерывания какого-то уровня может быть прервано только прерыванием с

более высоким уровнем приоритета. Уровни приоритетов прерываний

обычно поддерживаются аппаратной платформой. Типовое распределение

уровней приоритетов (в порядке возрастания) следующее:

• программные прерывания,

• прерывания от терминалов,

• прерывания от сетевого оборудования,

• прерывания от дисков,

• прерывания от таймера,

• исключения (машинные сбои и исключительные ситуации).

Для каждого уровня прерывания создается свой стек ядра (или

выделяется уровень в общем стеке ядра). В стеке i-го уровня сохраняется

вектор состояния прерванного i-1-го уровня (в стеке нижнего уровня –

сохраняется вектор состояния прерванного процесса) и выделяется рабочее

пространство стека для поддержки выполнения i-го уровня (например, для

размещения его локальных переменных). Число стеков ядра (число

динамических составляющих системного контекста) определяется

количеством уровней прерываний, зависящим от платформы.

6.4. Нити

Нити появились в Unix довольно поздно, но они вошли в требования

стандартов POSIX и Single Unix Specifications. Во всех современных

клонах ОС Unix имеется механизм нитей, семантика (но не обязательно

синтаксис) которого соответствует требованиям стандарта POSIX. В Open

Unix 8 реализация нитей выполнена на уровне системной библиотеки

нитей, однако потребовала и серьезной перестройки ядра. На уровне ядра

работа с нитями поддерживается системными сущностями, называемыми

легковесными процессами (light weight process). Нить представляет собой

отдельный поток управления с точки зрения программы. Легковесный

процесс – отдельный поток управления с точки зрения ОС. Легковесный

процесс предоставляет нити собственную среду выполнения, прежде всего

– динамическую составляющую системного процесса, то есть стек ядра.

Легковесные процессы могут интерпретироваться как виртуальные

процессоры, как показано на рисунке 6.2. В каждый момент времени

легковесный процесс может выполнять только одну нить, но нити могут

сменять друг друга в легковесном процессе.

Рисунок 6.2 Нити и легковесные процессы (ЛВП)

Легковесные процессы подчиняются следующим правилам:

• с одним процессом может быть связано много легковесных

процессов;

• каждый легковесный процесс разделяет адресное пространство

"своего" процесса с другими легковесными процессами в том же

процессе;

• каждый легковесный процесс разделяет легковесными процессами

в том же процессе все ресурсы процесса (файлы, программные

каналы и т.п.) и пользуется правами и привилегиями доступа

своего процесса;

• каждый легковесный процесс является единицей планирования в

ОС (ниже при описании дисциплины планирования мы везде под

"процессом" имеем в виду "легковесный процесс");

• в мультипроцессорной системе несколько легковесных процессов

одного процесса могут выполняться на разных процессорах

одновременно (реальный параллелизм);

Нити могут быть мультиплексируемыми и связанными.

Системная библиотека нитей обеспечивает мультиплексирование

нитей в пуле легковесных процессов каждого процесса по следующим

правилам:

• легковесный процесс может выбирать и выполнять только одну

нить за раз;

• по прошествии некоторого времени легковесный процесс

оставляет текущую нить и выбирает другую;

• позже оставленная нить может быть выбрана вновь, не

обязательно тем же легковесным процессом;

• в многопроцессорной системе имеется вероятность выполнения

нитей с реальным параллелизмом.

Размер пула легковесных процессов называется реальным уровнем

параллелизма. Уровень параллелизма устанавливается в

конфигурационных параметрах, но может устанавливаться для процесса и

программно при помощи соответствующего системного вызова. Кроме

того, он может изменяться динамически "вокруг" установленного уровня.

Динамическое изменение уровня параллелизма выполняется библиотекой

нитей для каждого процесса отдельно. При запуске каждого процесса для

него создается только один легковесный процесс. Размер пула

увеличивается, если создается новая нить с соответствующим параметром

системного вызова thr_create. Если все легковесные процессы данного

процесса оказываются в заблокированном состоянии, ядро посылает

процессу специальный сигнал. По этому сигналу создается новый

легковесный процесс. Как правило, количество легковесных процессов не

превосходит количество нитей. Если легковесный процесс остается без

работы в течение некоторого предустановленного интервала времени, он

прекращается.

Связанные нити имеют собственный легковесный процесс для

выполнения. Этот процесс создается одновременно с созданием нити (это

определяется специальным параметром системного вызова thr_create)

и уничтожается с уничтожением нити. Связанные нити не учитываются

при определении реального уровня параллелизма. Связанная нить

постоянно присоединена к своему легковесному процессу, когда такая

нить переходит в ожидание, ее легковесный процесс также ожидает.

Мультиплексируемые же нити планируются на легковесные

процессы – подобно тому, как процессы планируются на процессоры.

Дисциплины планирования мультиплексируемых нитей реализуются

библиотекой нитей, он "не видны" для ОС. Смена нитей на легковесном

процессе происходит по событиям. Событиями, распознаваемыми

библиотекой нитей, являются:

• освобождение легковесного процесса вследствие завершения

выполнявшейся на нем нити, перехода нити в состояние ожидания