ГЛАВА 2
ВВЕДЕНИЕ В АРХИТЕКТУРУ ЯДРА ОПЕРАЦИОННОЙ СИСТЕМЫ
В предыдущей главе был сделан только поверхностный обзор особенностей
операционной среды UNIX. В этой главе основное внимание уделяется ядру опе-
рационной системы, делается обзор его архитектуры и излагаются в общих чер-
тах основные понятия и структуры, существенные для понимания всего последую-
щего материала книги.
2.1 АРХИТЕКТУРА ОПЕРАЦИОННОЙ СИСТЕМЫ UNIX
Как уже ранее было замечено (см. [Christian 83], стр.239), в системе
UNIX создается иллюзия того, что файловая система имеет 'места' и что у про-
цессов есть 'жизнь'. Обе сущности, файлы и процессы, являются центральными
понятиями модели операционной системы UNIX. На Рисунке 2.1 представлена
блок-схема ядра системы, отражающая состав модулей, из которых состоит ядро,
и их взаимосвязи друг с другом. В частности, на ней слева изображена файло-
вая подсистема, а справа подсистема управления процессами, две главные ком-
поненты ядра. Эта схема дает логическое представление о ядре, хотя в дейст-
вительности в структуре ядра имеются отклонения от модели, поскольку отдель-
ные модули испытывают внутреннее воздействие со стороны других модулей.
Схема на Рисунке 2.1 имеет три уровня: уровень пользователя, уровень яд-
ра и уровень аппаратуры. Обращения к операционной системе и библиотеки сос-
тавляют границу между пользовательскими программами и ядром, проведенную на
Рисунке 1.1. Обращения к операционной системе выглядят так же, как обычные
вызовы функций в программах на языке Си, и библиотеки устанавливают соответ-
ствие между этими вызовами функций и элементарными системными операция-
ми, о чем более подробно см. в главе 6. При этом программы на ассемблере мо-
гут обращаться к операционной системе непосредственно, без использования
библиотеки системных вызовов. Программы часто обращаются к другим библиоте-
кам, таким как библиотека стандартных подпрограмм ввода-вывода, достигая тем
самым более полного использования системных услуг. Для этого во время компи-
ляции библиотеки связываются с программами и частично включаются в программу
пользователя. Далее мы проиллюстрируем эти моменты на примере.
На рисунке совокупность обращений к операционной системе разделена на те
обращения, которые взаимодействуют с подсистемой управления файлами, и те,
которые взаимодействуют с подсистемой управления процессами. Файловая под-
система управляет файлами, размещает записи файлов, управляет свободным
пространством, доступом к файлам и поиском данных для пользователей. Процес-
сы взаимодействуют с подсистемой управления файлами, используя при этом со-
вокупность специальных обращений к операционной системе, таких как open
(для того, чтобы открыть файл на чтение или запись),close, read, write, stat
(запросить атрибуты файла), chown (изменить запись с информацией о владельце
файла) и chmod (изменить права доступа к файлу). Эти и другие операции расс-
матриваются в главе 5.
Подсистема управления файлами обращается к данным, которые хранятся в
файле, используя буферный механизм, управляющий потоком данных между ядром и
устройствами внешней памяти. Буферный механизм, взаимодействуя с драйверами
устройств ввода-вывода блоками, инициирует передачу данных к ядру и обратно.
Драйверы устройств являются такими модулями в составе ядра, которые управля-
ют работой периферийных устройств. Устройства ввода-вывода блоками относятся
22
программы пользователя
^
| ------------------------
точка пере- | | библиотеки |
сечения щщщщщщщщщ|щщщщщщщ ------------------------
щ | щ ^
Уровень пользователя щ | щ |
--------------------------|---------------------|-----------------
Уровень ядра v v
-----------------------------------------------------
| ^ обращения к операционной системе ^ |
-------+------------------------------------+--------
| |
------------------+---------------- -----------------+----------
| v | | v |
| | | |
| подсистема управле- | | ............|
| ния файлами | | . взаимо- .|
| <---+-- | . действие .|
| | | | . процессов.|
| ^ ^ | | | подсистема ............|
| | | | | | ............|
--------+--------------+----------- | | . планиров-.|
| v --+> управления . щик .|
| ---------------- | ............|
| | буфер сверх- | | ............|
| | оперативной | | процессами . распреде-.|
| | памяти (кеш) | | . ление .|
| ---------------- | . памяти .|
| ^ | ^ ............|
| | | | |
| v --------+-------------------
--------+----------------------- |
| v . | |
| символ . блок | |
| . | |
|------------------------------| |
| | |
| драйверы устройств | |
| ^ | |
---------------+---------------- |
| |
---------------+------------------------------+-------------------
| v аппаратный контроль v |
------------------------------------------------------------------
Уровень ядра
------------------------------------------------------------------ Уровень
аппаратуры
------------------------------------------------------------------
| технические средства (аппаратура) |
------------------------------------------------------------------
Рисунок 2.1. Блок-схема ядра операционной системы
к типу запоминающих устройств с произвольной выборкой; их драйверы построены
таким образом, что все остальные компоненты системы воспринимают эти устрой-
ства как запоминающие устройства с произвольной выборкой. Например, драйвер
запоминающего устройства на магнитной ленте позволяет ядру системы восприни-
23
мать это устройство как запоминающее устройство с произвольной выборкой.
Подсистема управления файлами также непосредственно взаимодействует с драй-
верами устройств 'неструктурированного' ввода-вывода, без вмешательства бу-
ферного механизма. К устройствам неструктурированного ввода-вывода, иногда
именуемым устройствами посимвольного ввода-вывода (текстовыми), относятся
устройства, отличные от устройств ввода-вывода блоками.
Подсистема управления процессами отвечает за синхронизацию процессов,
взаимодействие процессов, распределение памяти и планирование выполнения
процессов. Подсистема управления файлами и подсистема управления процессами
взаимодействуют между собой, когда файл загружается в память на выполнение
(см. главу 7): подсистема управления процессами читает в память исполняемые
файлы перед тем, как их выполнить.
Примерами обращений к операционной системе, используемых при управлении
процессами, могут служить fork (создание нового процесса), exec (наложение
образа программы на выполняемый процесс), exit (завершение выполнения про-
цесса), wait (синхронизация продолжения выполнения основного процесса с мо-
ментом выхода из порожденного процесса), brk (управление размером памяти,
выделенной процессу) и signal (управление реакцией процесса на возникновение
экстраординарных событий). Глава 7 посвящена рассмотрению этих и других сис-
темных вызовов.
Модуль распределения памяти контролирует выделение памяти процессам. Ес-
ли в какой-то момент система испытывает недостаток в физической памяти для
запуска всех процессов, ядро пересылает процессы между основной и внешней
памятью с тем, чтобы все процессы имели возможность выполняться. В главе 9
описываются два способа управления распределением памяти: выгрузка (подкач-
ка) и замещение страниц. Программу подкачки иногда называют планировщиком,
т.к. она 'планирует' выделение памяти процессам и оказывает влияние на рабо-
ту планировщика центрального процессора. Однако в дальнейшем мы будем ста-
раться ссылаться на нее как на 'программу подкачки', чтобы избежать путаницы
с планировщиком центрального процессора.
Модуль 'планировщик' распределяет между процессами время центрального
процессора. Он планирует очередность выполнения процессов до тех пор, пока
они добровольно не освободят центральный процессор, дождавшись выделения
к.-л. ресурса, или до тех пор, пока ядро системы не выгрузит их после того,
как их время выполнения превысит заранее определенный квант времени. Плани-
ровщик выбирает на выполнение готовый к запуску процесс с наивысшим приори-
тетом; выполнение предыдущего процесса (приостановленного) будет продолжено
тогда, когда его приоритет будет наивысшим среди приоритетов всех готовых к
запуску процессов. Существует несколько форм взаимодействия процессов между
собой, от асинхронного обмена сигналами о событиях до синхронного обмена со-
общениями.
Наконец, аппаратный контроль отвечает за обработку прерываний и за связь
с машиной. Такие устройства, как диски и терминалы, могут прерывать работу
центрального процессора во время выполнения процесса. При этом ядро системы
после обработки прерывания может возобновить выполнение прерванного процес-
са. Прерывания обрабатываются не самими процессами, а специальными функциями
ядра системы, перечисленными в контексте выполняемого процесса.
2.2 ВВЕДЕНИЕ В ОСНОВНЫЕ ПОНЯТИЯ СИСТЕМЫ
В это разделе дается обзор некоторых основных информационных структур,
используемых ядром системы, и более подробно описывается функционирование
модулей ядра, показанных на Рисунке 2.1.
2.2.1 Обзор особенностей подсистемы управления файлами
Внутреннее представление файла описывается в индексе, который содержит
24
описание размещения информации файла на диске и другую информацию, такую как
владелец файла, права доступа к файлу и время доступа. Термин 'индекс'
(inode) широко используется в литературе по системе UNIX. Каждый файл имеет
один индекс, но может быть связан с несколькими именами, которые все отража-
ются в индексе. Каждое имя является указателем. Когда процесс обращается к
файлу по имени, ядро системы анализирует по очереди каждую компоненту имени
файла, проверяя права процесса на просмотр входящих в путь поиска каталогов,
и в конце концов возвращает индекс файла. Например, если процесс обращается
к системе:
open('/fs2/mjb/rje/sourcefile', 1);
ядро системы возвращает индекс для файла '/fs2/mjb/rje/sourcefile'. Если
процесс создает новый файл, ядро присваивает этому файлу неиспользуемый ин-
декс. Индексы хранятся в файловой системе (и это мы еще увидим), однако при
обработке файлов ядро заносит их в таблицу индексов в оперативной памяти.
Ядро поддерживает еще две информационные структуры, таблицу файлов и
пользовательскую таблицу дескрипторов файла. Таблица файлов выступает гло-
бальной структурой ядра, а пользовательская таблица дескрипторов файла выде-
ляется под процесс. Если процесс открывает или создает файл, ядро выделяет в
каждой таблице элемент, корреспондирующий с индексом файла. Элементы в этих
трех структурах - в пользовательской таблице дескрипторов файла, в таблице
файлов и в таблице индексов - хранят информацию о состоянии файла и о досту-
пе пользователей к нему. В таблице файлов хранится смещение в байтах от на-
чала файла до того места, откуда начнет выполняться следующая команда поль-
зователя read или write,
Пользовательская
таблица дескрип- Таблица Таблица торов файла файлов индексов
----------- ------- -------
| - + - - | | | |
|---------| | | | |
| - + - | | | | |
|---------| | | |-----|
| - +-| - - - - ->|-----| - - - - ->| |
|---------| - - - - - ->| - + - - |-----|
| || |-----| | |
| |- - - | | | |
| | | |-----| - - - - ->| |
| | -- - - ->| - + - - |-----|
| | |-----| | |
| | | | | |
----------- ------- -------
Рисунок 2.2. Таблицы файлов, дескрипторов файла и индексов
а также информация о правах доступа к открываемому процессу. Таблица деск-
рипторов файла идентифицирует все открытые для процесса файлы. На Рисунке
2.2 показаны эти таблицы и связи между ними. В системных операциях open (от-
крыть) и creat (создать) ядро возвращает дескриптор файла, которому соответ-
ствует указатель в таблице дескрипторов файла. При выполнении операций read
(читать) и write (писать) ядро использует дескриптор файла для входа в таб-
лицу дескрипторов и, следуя указателям на таблицу файлов и на таблицу индек-
сов, находит информацию в файле. Более подробно эти информационные структуры
рассматриваются в главах 4 и 5. Сейчас достаточно сказать, что использование
этих таблиц обеспечивает различную степень разделения доступа к файлу.
Обычные файлы и каталоги хранятся в системе UNIX на устройствах вво-
да-вывода блоками, таких как магнитные ленты или диски. Поскольку существует
25
некоторое различие во времени доступа к этим устройствам, при установке сис-
темы UNIX на лентах размещают файловые системы. С годами бездисковые автома-
тизированные рабочие места станут общим случаем, и файлы будут располагаться
в удаленной системе, доступ к которой будет осуществляться через сеть (см.
главу 13). Для простоты, тем не менее, в последующем тексте подразумевается
использование дисков. В системе может быть несколько физических дисков, на
каждом из которых может размещаться одна и более файловых систем. Разбивка
диска на несколько файловых систем облегчает администратору управление хра-
нимыми данными. На логическом уровне ядро имеет дело с файловыми системами,
а не с дисками, при этом каждая система трактуется как логическое устройст-
во, идентифицируемое номером. Преобразование адресов логического устройства
(файловой системы) в адреса физического устройства (диска) и обратно выпол-
няется дисковым драйвером. Термин 'устройство' в этой книге используется для
обозначения логического устройства, кроме специально оговоренных случаев.
Файловая система состоит из последовательности логических блоков длиной
512, 1024, 2048 или другого числа байт, кратного 512, в зависимости от реа-
лизации системы. Размер логического блока внутри одной файловой системы пос-
тоянен, но может варьироваться в разных файловых системах в данной конфигу-
рации. Использование логических блоков большого размера увеличивает скорость
передачи данных между диском и памятью, поскольку ядро сможет передать боль-
ше информации за одну дисковую операцию, и сокращает количество продолжи-
тельных операций. Например, чтение 1 Кбайта с диска за одну операцию осущес-
твляется быстрее, чем чтение 512 байт за две. Однако, если размер логическо-
го блока слишком велик, полезный объем памяти может уменьшиться, это будет
показано в главе 5. Для простоты термин 'блок' в этой книге будет использо-
ваться для обозначения логического блока, при этом подразумевается логичес-
кий блок размером 1 Кбайт, кроме специально оговоренных случаев.
----------т---------т-------щщщщ--------т-------щщщщ-------
| | | | |
----------------------------щщщщ----------------щщщщ-------
блок супер- список индексов информационные загрузки блок блоки
Рисунок 2.3. Формат файловой системы
Файловая система имеет следующую структуру (Рисунок 2.3).
* Блок загрузки располагается в начале пространства, отведенного под файло-
вую систему, обычно в первом секторе, и содержит программу начальной заг-
рузки, которая считывается в машину при загрузке или инициализации опера-
ционной системы. Хотя для запуска системы требуется только один блок заг-
рузки, каждая файловая система имеет свой (пусть даже пустой) блок загруз-
ки.
* Суперблок описывает состояние файловой системы - какого она размера,
сколько файлов может в ней храниться, где располагается свободное прост-
ранство, доступное для файловой системы, и другая информация.
* Список индексов в файловой системе располагается вслед за суперблоком. Ад-
министраторы указывают размер списка индексов при генерации файловой сис-
темы. Ядро операционной системы обращается к индексам, используя указатели
в списке индексов. Один из индексов является корневым индексом файловой
системы: это индекс, по которому осуществляется доступ к структуре катало-
гов файловой системы после выполнения системной операции mount (монтиро-
вать) (раздел 5.14).
* Информационные блоки располагаются сразу после списка индексов и содержат
данные файлов и управляющие данные. Отдельно взятый информационный блок
может принадлежать одному и только одному файлу в файловой системе.
26
2.2.2 Процессы
В этом разделе мы рассмотрим более подробно подсистему управления про-
цессами. Даются разъяснения по поводу структуры процесса и некоторых инфор-
мационных структур, используемых при распределении памяти под процессы. За-
тем дается предварительный обзор диаграммы состояния процессов и затрагива-
ются различные вопросы, связанные с переходами из одного состояния в другое.
Процессом называется последовательность операций при выполнении програм-
мы, которые представляют собой наборы байтов, интерпретируемые центральным
процессором как машинные инструкции (т.н. 'текст'), данные и стековые струк-
туры. Создается впечатление, что одновременно выполняется множество процес-
сов, поскольку их выполнение планируется ядром, и, кроме того, несколько
процессов могут быть экземплярами одной программы. Выполнение процесса зак-
лючается в точном следовании набору инструкций, который является замкнутым и
не передает управление набору инструкций другого процесса; он считывает и
записывает информацию в раздел данных и в стек, но ему недоступны данные и
стеки других процессов. Одни процессы взаимодействуют с другими процессами и
с остальным миром посредством обращений к операционной системе.
С практической точки зрения процесс в системе UNIX является объектом,
создаваемым в результате выполнения системной операции fork. Каждый процесс,
за исключением нулевого, порождается в результате запуска другим процессом
операции fork. Процесс, запустивший операцию fork, называется родительским,
а вновь созданный процесс - порожденным. Каждый процесс имеет одного родите-
ля, но может породить много процессов. Ядро системы идентифицирует каждый
процесс по его номеру, который называется идентификатором процесса (PID).
Нулевой процесс является особенным процессом, который создается 'вручную' в
результате загрузки системы; после порождения нового процесса (процесс 1)
нулевой процесс становится процессом подкачки. Процесс 1, известный под име-
нем init, является предком любого другого процесса в системе и связан с каж-
дым процессом особым образом, описываемым в главе 7.
Пользователь, транслируя исходный текст программы, создает исполняемый
файл, который состоит из нескольких частей:
* набора 'заголовков', описывающих атрибуты файла,
* текста программы,
* представления на машинном языке данных, имеющих начальные
значения при запуске программы на выполнение, и указания на то, сколько
пространства памяти ядро системы выделит под неинациализированные данные,
так называемые bss (*) (ядро устанавливает их в 0 в момент запуска),
* других секций, таких как информация символических таблиц.
Для программы, приведенной на Рисунке 1.3, текст исполняемого файла
представляет собой сгенерированный код для функций main и copy, к определен-
ным данным относится переменная version (вставленная в программу для того,
чтобы в последней имелись некоторые определенные данные), а к неопределенным
- массив buffer. Компилятор с языка Си для системы версии V создает отдельно
текстовую секцию по умолчанию, но не исключается возможность включения инст-
рукций программы и в секцию данных, как в предыдущих версиях системы.
Ядро загружает исполняемый файл в память при выполнении системной опера-
ции exec, при этом загруженный процесс состоит по меньшей мере из трех час-
тей, так называемых областей: текста, данных и стека. Области текста и дан-
ных корреспондируют с секциями текста и bss-данных исполняемого файла, а об-
ласть стека создается автоматически и ее размер динамически устанавливается
ядром системы во время выполнения. Стек состоит из логических записей акти-
вации, помещаемых в стек при вызове функции и выталкиваемых из стека при
возврате управления в вызвавшую процедуру; специальный регистр, именуемый
указателем вершины стека, показывает текущую глубину стека. Запись активации
включает параметры передавае-
------------------------------------------------
(*) Сокращение bss имеет происхождение от ассемблерного псевдооператора для
машины IBM 7090 и расшифровывается как 'block started by symbol' ('блок, на-
чинающийся с символа').
27
мые функции, ее локальные переменные, а также данные, необходимые для восс-
тановления предыдущей записи активации, в том числе значения счетчика команд
и указателя вершины стека в момент вызова функции. Текст программы включает
Стек задачи Направление Стек ядра
---------------- увеличения стека --------------------
| Локальные | ^ | |
| переменные | | | ^ |
| (не показаны)| | | . |
|--------------| | | . |
|Адрес записи 2| | | . |
|--------------| | | . |
|Адрес возврата| | | . |
| после вызова | | | . |
| write | | | . |
|--------------| | | . |
|параметры, пе-| | | . |
| редаваемые | | | . |
| write | | | . |
|(new, buffer, | | | v |
| count) | Запись 3 | |
|--------------| call write() Запись 3 |------------------|
| Локальные | | Локальные |
| переменные | | переменные |
| (count) | | |
|--------------| |------------------|
|Адрес записи 1| | Адрес записи 1 |
|--------------| |------------------|
|Адрес возврата| | Адрес возврата |
| после вызова | | после вызова |
| copy | | func2 |
|--------------| |------------------|
|параметры, пе-| | параметры, пере- |
| редаваемые | | даваемые функции |
| copy | | ядра func2 |
| (old, new) | Запись 2 Запись 2 | |
|--------------| call copy() call func2() |------------------|
| Локальные | | Локальные |
| переменные | | переменные |
|(fdold, fdnew)| | |
|--------------| |------------------|
|Адрес записи 0| | Адрес записи 0 |
|--------------| |------------------|
|Адрес возврата| | Адрес возврата |
| после вызова | | после вызова |
| main | | func1 |
|--------------| |------------------|
|параметры, пе-| | параметры, пере- |
| редаваемые | | даваемые функции |
| main | | ядра func1 |
| (argc, argv) | Запись 1 Запись 1 | |
---------------- call main() call func1() --------------------
Запись 0 Запись 0
Старт Интерфейс
обращений к операционной системе
Рисунок 2.4. Стеки задачи и ядра для программы копирования.
28
последовательности команд, управляющие увеличением стека, а ядро системы вы-
деляет, если нужно, место под стек. В программе на Рисунке 1.3 параметры
argc и argv, а также переменные fdold и fdnew, содержащиеся в вызове функции
main, помещаются в стек, как только встретилось обращение к функции main
(один раз в каждой программе, по условию), так же и параметры old и new и
переменная count, содержащиеся в вызове функции copy, помещаются в стек в
момент обращения к указанной функции.
Поскольку процесс в системе UNIX может выполняться в двух режимах, режи-
ме ядра или режиме задачи, он пользуется в каждом из этих режимов отдельным
стеком. Стек задачи содержит аргументы, локальные переменные и другую инфор-
мацию относительно функций, выполняемых в режиме задачи. Слева на Рисунке
2.4 показан стек задачи для процесса, связанного с выполнением системной
операции write в программе copy. Процедура запуска процесса (включенная в
библиотеку) обратилась к функции main с передачей ей двух параметров, помес-
тив в стек задачи запись 1; в записи 1 есть место для двух локальных пере-
менных функции main. Функция main затем вызывает функцию copy с передачей ей
двух параметров, old и new, и помещает в стек задачи запись 2; в записи 2
есть место для локальной переменной count. Наконец, процесс активизирует
системную операцию write, вызвав библиотечную функцию с тем же именем. Каж-
дой системной операции соответствует точка входа в библиотеке системных опе-
раций; библиотека системных операций написана на языке ассемблера и включает
специальные команды прерывания, которые, выполняясь, порождают 'прерывание',
вызывающее переключение аппаратуры в режим ядра. Процесс ищет в библиотеке
точку входа, соответствующую отдельной системной операции, подобно тому, как
он вызывает любую из функций, создавая при этом для библиотечной функции за-
пись активации. Когда процесс выполняет специальную инструкцию, он переклю-
чается в режим ядра, выполняет операции ядра и использует стек ядра.
Стек ядра содержит записи активации для функций, выполняющихся в режиме
ядра. Элементы функций и данных в стеке ядра соответствуют функциям и дан-
ным, относящимся к ядру, но не к программе пользователя, тем не менее, конс-
трукция стека ядра подобна конструкции стека задачи. Стек ядра для процесса
пуст, если процесс выполняется в режиме задачи. Справа на Рисунке 2.4 предс-
тавлен стек ядра для процесса выполнения системной операции write в програм-
промежуточная
таблица облас- таблица
тей процессов областей
----------------------- --------------- --------------
| часть адресного про-| | | | |
| странства задачи, | | | | |
| выделенная процессу | | | | |
----------------------- |-------------| |------------|
^ ---+-> ---+-----+-> |
| | |-------------| |-----+------|
-----------+----------- |--+-> ---+--- | | |
| | | | |-------------| | | | |
| | | | | | | |-----+------|
|----------+----------| | | | ---+-> | |
| v -----+--- | | |-----+---+--|
|---------------------| | | | | | |
| | --------------- ------+---+---
| | | |
----------------------- | |
таблица процессов --------------------------+---+---
| оперативная память v v |
----------------------------------
Рисунок 2.5. Информационные структуры для процессов
29
ме copy. Подробно алгоритмы выполнения системной операции write будут описа-
ны в последующих разделах.
Каждому процессу соответствует точка входа в таблице процессов ядра,
кроме того, каждому процессу выделяется часть оперативной памяти, отведенная
под задачу пользователя. Таблица процессов включает в себя указатели на про-
межуточную таблицу областей процессов, точки входа в которую служат в качес-
тве указателей на собственно таблицу областей. Областью называется непрерыв-
ная зона
адресного пространства, выделяемая процессу для размещения текста, данных и
стека. Точки входа в таблицу областей описывают атрибуты области, как напри-
мер, хранятся ли в области текст программы или данные, закрытая ли эта об-
ласть или же совместно используемая, и где конкретно в памяти размещается
содержимое области. Внешний уровень косвенной адресации (через промежуточную
таблицу областей, используемых процессами, к собственно таблице областей)
позволяет независимым процессам совместно использовать области. Когда про-
цесс запускает системную операцию exec, ядро системы выделяет области под ее
текст, данные и стек, освобождая старые области, которые использовались про-
цессом. Если процесс запускает операцию fork, ядро удваивает размер адресно-
го пространства старого процесса, позволяя процессам совместно использовать
области, когда это возможно, и, с другой стороны, производя физическое копи-
рование. Если процесс запускает операцию exit, ядро освобождает области, ко-
торые использовались процессом. На Рисунке 2.5 изображены информационные
структуры, связанные с запуском процесса. Таблица процессов ссылается на
промежуточную таблицу областей, используемых процессом, в которой содержатся
указатели на записи в собственно таблице областей, соответствующие областям
для текста, данных и стека процесса.
Запись в таблице процессов и часть адресного пространства задачи, выде-
ленная процессу, содержат управляющую информацию и данные о состоянии про-
цесса. Это адресное пространство является расширением соответствующей записи
в таблице процессов, различия между данными объектами будут рассмотрены в
главе 6. В качестве полей в таблице процессов, которые рассматриваются в
последующих разделах, выступают:
* поле состояния,
* идентификаторы, которые характеризуют пользователя, являющегося вла-
дельцем процесса (код пользователя или UID),
* значение дескриптора события, когда процесс приостановлен (находится в
состоянии 'сна').
Адресное пространство задачи, выделенное процессу, содержит описывающую
процесс информацию, доступ к которой должен обеспечиваться только во время
выполнения процесса. Важными полями являются:
* указатель на позицию в таблице процессов, соответствующую текущему
процессу,
* параметры текущей системной операции, возвращаемые значения и коды
ошибок,
* дескрипторы файла для всех открытых файлов,
* внутренние параметры ввода-вывода,
* текущий каталог и текущий корень (см. главу 5),
* границы файлов и процесса.
Ядро системы имеет непосредственный доступ к полям адресного пространст-
ва задачи, выделенного выполняемому процессу, но не имеет доступ к соответс-
твующим полям других процессов. С точки зрения внутреннего алгоритма, при
обращении к адресному пространству задачи, выделенному выполняемому процес-
су, ядро ссылается на структурную переменную u, и, когда запускается на вы-
полнение другой процесс, ядро перенастраивает виртуальные адреса таким обра-
зом, чтобы структурная переменная u указывала бы на адресное пространство
задачи для нового процесса. В системной реализации предусмотрено облегчение
идентификации текущего процесса благодаря наличию указателя на соответствую-
30
щую запись в таблице процессов из адресного пространства задачи.
2.2.2.1 Контекст процесса
Контекстом процесса является его состояние, определяемое текстом, значе-
ниями глобальных переменных пользователя и информационными структурами, зна-
чениями используемых машинных регистров, значениями, хранимыми в позиции
таблицы процессов и в адресном пространстве задачи, а также содержимым сте-
ков задачи и ядра, относящихся к данному процессу. Текст операций системы и
ее глобальные информационные структуры совместно используются всеми процес-
сами, но не являются составной частью контекста процесса.
Говорят, что при запуске процесса система исполняется в контексте про-
цесса. Когда ядро системы решает запустить другой процесс, оно выполняет пе-
реключение контекста с тем, чтобы система исполнялась в контексте другого
процесса. Ядро осуществляет переключение контекста только при определенных
условиях, что мы увидим в дальнейшем. Выполняя переключение контекста, ядро
сохраняет информацию, достаточную для того, чтобы позднее переключиться
вновь на первый процесс и возобновить его выполнение. Аналогичным образом,
при переходе из режима задачи в режим ядра, ядро системы сохраняет информа-
цию, достаточную для того, чтобы позднее вернуться в режим задачи и продол-
жить выполнение с прерванного места. Однако, переход из режима задачи в ре-
жим ядра является сменой режима, но не переключением контекста. Если обра-
титься еще раз к Рисунку 1.5, можно сказать, что ядро выполняет переключение
контекста, когда меняет контекст процесса A на контекст процесса B; оно ме-
няет режим выполнения с режима задачи на режим ядра и наоборот, оставаясь в
контексте одного процесса, например, процесса A.
Ядро обрабатывает прерывания в контексте прерванного процесса, пусть да-
же оно и не вызывало никакого прерывания. Прерванный процесс мог при этом
выполняться как в режиме задачи, так и в режиме ядра. Ядро сохраняет инфор-
мацию, достаточную для того, чтобы можно было позже возобновить выполнение
прерванного процесса, и обрабатывает прерывание в режиме ядра. Ядро не по-
рождает и не планирует порождение какого-то особого процесса по обработке
прерываний.
2.2.2.2 Состояния процесса
Время жизни процесса можно разделить на несколько состояний, каждое из
которых имеет определенные характеристики, описывающие процесс. Все состоя-
ния процесса рассматриваются в главе 6, однако представляется существенным
для понимания перечислить некоторые из состояний уже сейчас:
1. Процесс выполняется в режиме задачи.
2. Процесс выполняется в режиме ядра.
3. Процесс не выполняется, но готов к выполнению и ждет, когда планиров-
щик выберет его. В этом состоянии может находиться много процессов, и алго-
ритм планирования устанавливает, какой из процессов будет выполняться следу-
ющим.
4. Процесс приостановлен ('спит'). Процесс 'впадает в сон', когда он не
может больше продолжать выполнение, например, когда ждет завершения вво-
да-вывода.
Поскольку процессор в каждый момент времени выполняет только один про-
цесс, в состояниях 1 и 2 может находиться самое большее один процесс. Эти
два состояния соответствуют двум режимам выполнения, режиму задачи и режиму
ядра.
31
2.2.2.3 Переходы из состояния в состояние
Состояния процесса, перечисленные выше, дают статическое представление о
процессе, однако процессы непрерывно переходят из состояния в состояние в
соответствии с определенными правилами. Диаграмма переходов представляет со-
бой ориентированный граф, вершины которого представляют собой состояния, в
которые может перейти процесс, а дуги - события, являющиеся причинами пере-
хода процесса из одного состояния в другое. Переход между двумя состояниями
разрешен, если существует дуга из первого состояния во второе. Несколько дуг
может выходить из одного состояния, однако процесс переходит только по одной
из них в зависимости от того, какое событие произошло в системе. На Рисунке
2.6 представлена диаграмма переходов для состояний, перечисленных выше.
Как уже говорилось выше, в режиме разделения времени может выполняться
одновременно несколько процессов, и все они могут одновременно работать в
режиме ядра. Если им разрешить свободно выполняться в режиме ядра, то они
могут испортить глобальные информационные структуры, принадлежащие ядру.
Запрещая произвольное переключение контекстов и управляя возникновением со-
бытий, ядро защищает свою целостность.
Ядро разрешает переключение контекста только тогда, когда процесс пере-
ходит из состояния 'запуск в режиме ядра' в состояние 'сна в памяти'. Про-
цессы, запущенные в режиме ядра, не могут быть выгружены другими процессами;
поэтому иногда говорят, что ядро невыгружаемо, при этом процессы, находящие-
ся в режиме задачи, могут выгружаться системой. Ядро поддерживает целост-
ность своих информационных структур, поскольку оно невыгружаемо, таким обра-
зом решая проблему 'взаимного исключения' - обеспечения того, что критичес-
кие секции программы выполняются в каждый момент времени в рамках самое
большее одного процесса.
В качестве примера рассмотрим программу (Рисунок 2.7) включения информа-
ционной структуры, чей адрес содержится в указателе bp1, в список с исполь-
зованием указателей после структуры, чей адрес содержится в bp. Если система
разрешила переключение контекста при выполнении ядром фрагмента программы,
возможно возникновение следующей ситуации. Предположим, ядро выполняет прог-
рамму
запуск ---------
в режи- | |
ме за- | 1 |
дачи | |
--т------
обращение | ^ возврат
к системе | |
или пре- | |
рывание | |
v |
запуск ---------
в режи- | |<---------- прерывание,
ме яд- | 2 | | возврат из
ра | |<---------- прерывания
--т------
приоста-| ^ процесс пла-
--------- нов | | нирования ---------
ожидание | |<----------- -------------| | готовность
('сон')| 4 |--------------------------->| 3 | к выполнению
--------- пробуждение ---------
переключение
контекста допустимо
Рисунок 2.6. Состояния процесса и переходы между ними
32
до комментариев и затем осуществляет переключение контекста. Список с ис-
пользованием сдвоенных указателей имеет противоречивый вид: структура bp1
только наполовину входит в этот список. Если процесс следует за передними
указателями, он обнаружит bp1 в данном списке, но если он последует за фоно-
выми указателями, то вообще не найдет структуру bp1 (Рисунок 2.8). Если дру-
гие процессы будут обрабатывать указатели в списке до момента повторного за-
пуска первого процесса, структура списка может постоянно разрушаться. Систе-
ма UNIX предупреждает возникновение подобных ситуаций, запрещая переключение
контекстов на время выполнения процесса в режиме ядра. Если процесс перехо-
дит в состояние 'сна', делая допустимым переключение контекста, алгоритмы
ядра обеспечивают защиту целостности информационных структур системы.
Проблемой, которая может привести к нарушению целостности информации яд-
ра, является обработка прерываний, могущая вносить изменения в информацию о
состоянии ядра. Например, если ядро выполняло программу, приведенную на Ри-
сунке 2.7, и получило прерывание по достижении комментариев, программа обра-
ботки прерыва-
-------------------------------------------------------------
| struct queue { |
| |
| |
| |
| } *bp, *bp1; |
| bp1 - > forp = bp - > forp; |
| bp1 - > backp = bp; |
| bp - > forp = bp1; |
| /* здесь рассмотрите возможность переключения контекста */|
| bp1 - > forp - > backp = bp1; |
-------------------------------------------------------------
Рисунок 2.7. Пример программы, создающей список с двунаправленными указате-
лями
---------
| |
| bp1 |
| |
---------
--------- ---------
----->| |------------------------------>| |---->
| bp | | |
<-----| |<------------------------------| |<----
--------- ---------
Включение bp1 в список с двунаправленными указателями
--------- --------- ---------
----->| |---------->| |---------->| |---->
| bp | | bp1 | | |
<-----| |<----------| | ------| |<----
---------<----- --------- | ---------
---------------------
Рисунок 2.8. Список с указателями, некорректный из-за переключения контек-
ста
33
ний может разрушить ссылки, если будет манипулировать указателями, как было
показано ранее. Чтобы решить эту проблему, система могла бы запретить все
прерывания на время работы в режиме ядра, но при этом затянулась бы обработ-
ка прерывания, что в конечном счете нанесло бы ущерб производительности сис-
темы. Вместо этого ядро повышает приоритет прерывания процессора, запрещая
прерывания на время выполнения критических секций программы. Секция програм-
мы является критической, если в процессе ее выполнения запуск программ обра-
ботки произвольного прерывания может привести к возникновению проблем, имею-
щих отношение к нарушению целостности. Например, если программа обработки
прерывания от диска работает с буферными очередями, то часть прерываемой
программы, при выполнении которой ядро обрабатывает буферные очереди, явля-
ется критической секцией по отношению к программе обработки прерывания от
диска. Критические секции невелики по размеру и встречаются нечасто, поэтому
их существование не оказывает практически никакого воздействия на производи-
тельность системы. В других операционных системах данный вопрос решается пу-
тем запрещения любых прерываний при работе в системных режимах или путем
разработки схем блокировки, обеспечивающих целостность. В главе 12 мы еще
вернемся к этому вопросу, когда будем говорить о многопроцессорных системах,
где применения указанных мер для решения проблемы недостаточно.
Чтобы подвести черту, еще раз скажем, что ядро защищает свою целост-
ность, разрешая переключение контекста только тогда, когда процесс переходит
в состояние 'сна', а также препятствуя воздействию одного процесса на другой
с целью изменения состояния последнего. Оно также повышает приоритет преры-
вания процессора на время выполнения критических секций программ, запрещая
таким образом прерывания, которые в противном случае могут вызвать нарушение
целостности. Планировщик процессов периодически выгружает процессы, выполня-
ющиеся в режиме задачи, для того, чтобы процессы не могли монопольно исполь-
зовать центральный процессор.
2.2.2.4 'Сон' и пробуждение
Процесс, выполняющийся в режиме ядра, имеет значительную степень автоно-
мии в решении того, как ему следует реагировать на возникновение системных
событий. Процессы могут общаться между собой и 'предлагать' различные аль-
тернативы, но при этом окончательное решение они принимают самостоятельно.
Мы еще увидим, что существует набор правил, которым подчиняется поведение
процессов в различных обстоятельствах, но каждый процесс в конечном итоге
следует этим правилам по своей собственной инициативе. Например, если про-
цесс должен временно приостановить выполнение ('перейти ко сну'), он это де-
лает по своей доброй воле. Следовательно, программа обработки прерываний не
может приостановить свое выполнение, ибо если это случится, прерванный про-
цесс должен был бы 'перейти ко сну' по умолчанию.
Процессы приостанавливают свое выполнение, потому что они ожидают воз-
никновения некоторого события, например, завершения ввода-вывода на перифе-
рийном устройстве, выхода, выделения системных ресурсов и т.д. Когда гово-
рят, что процесс приостановился по событию, то имеется ввиду, что процесс
находится в состоянии 'сна' до наступления события, после чего он пробудится
и перейдет в состояние 'готовности к выполнению'. Одновременно могут приос-
тановиться по событию много процессов; когда событие наступает, все процес-
сы, приостановленные по событию, пробуждаются, поскольку значение условия,
связанного с событием, больше не является 'истинным'. Когда процесс пробуж-
дается, он переходит из состояния 'сна' в состояние 'готовности к выполне-
нию', находясь в котором он уже может быть выбран планировщиком; следует об-
ратить внимание на то, что он не выполняется немедленно. Приостановленные
процессы не занимают центральный процессор. Ядру системы нет надобности пос-
тоянно проверять то, что процесс все еще приостановлен, т.к. ожидает наступ-
ления события, и затем будить его.
Например, процесс, выполняемый в режиме ядра, должен иногда блокировать
34
структуру данных на случай приостановки в будущем; процессы, пытающиеся об-
ратиться к заблокированной структуре, обязаны проверить наличие блокировки и
приостановить свое выполнение, если структура заблокирована другим процес-
сом. Ядро выполняет блокировки такого рода следующим образом:
while (условие 'истинно')
sleep (событие: условие принимает значение 'ложь');
set condition true;
то есть:
пока (условие 'истинно')
приостановиться (до наступления события, при котором
условие принимает значение 'ложь');
присвоить условию значение 'истина';
Ядро снимает блокировку и 'будит' все процессы, приостанов-
ленные из-за этой блокировки, следующим образом:
set condition false;
wakeup (событие: условие 'ложно');
то есть:
присвоить условию значение 'ложь';
перезапуститься (при наступлении события, при котором условие
принимает значение 'ложь');
На Рисунке 2.9 приведен пример, в котором три процесса, A, B и C оспари-
вают заблокированный буфер. Переход в состояние 'сна' вызывается заблокиро-
ванностью буфера. Процессы, однажды запустившись, обнаруживают, что буфер
заблокирован, и приостанавливают свое выполнение до наступления события, по
которому буфер будет разблокирован. В конце концов блокировка с буфера сни-
мается и все процессы 'пробуждаются', переходя в состояние 'готовности к вы-
полнению'. Ядро наконец выбирает один из процессов, скажем, B, для выполне-
ния. Процесс B, выполняя цикл 'while', обнаруживает, что буфер разблокиро-
ван, блокирует его и продолжает свое выполнение. Если процесс B в дальнейшем
снова приостановится без снятия блокировки с буфера (например, ожидая завер-
шения операции ввода-вывода), ядро сможет приступить к планированию выполне-
ния других процессов. Если будет при этом выбран процесс A, этот процесс,
выполняя цикл 'while', обнаружит, что буфер заблокирован, и снова перейдет в
состояние 'сна'; возможно то же самое произойдет и с процессом C. В конце
концов выполнение процесса B возобновится и блокировка с буфера будет снята,
в результате чего процессы A и C получат доступ к нему. Таким образом, цикл
'while-sleep' обеспечивает такое положение, при котором самое большее один
процесс может иметь доступ к ресурсу.
Алгоритмы перехода в состояние 'сна' и пробуждения более подробно будут
рассмотрены в главе 6. Тем временем они будут считаться 'неделимыми'. Про-
цесс переходит в состояние 'сна' мгновенно и находится в нем до тех пор, по-
ка не будет 'разбужен'. После того, как он приостанавливается, ядро системы
начинает планировать выполнение следующего процесса и переключает контекст
на него.
2.3 СТРУКТУРЫ ДАННЫХ ЯДРА
Большинство информационных структур ядра размещается в таблицах фиксиро-
ванного размера, а не в динамически выделенной памяти. Преимущество такого
подхода состоит в том, что программа ядра проста, но в ней ограничивается
число элементов информационной структуры до значения, предварительно задан-
ного при генерации системы. Если во время функционирования системы число
элементов информационной структуры ядра выйдет за указанное значение, ядро
не сможет динамически выделить место для новых элементов и должно сообщить
35
об ошибке пользователю, сделавшему запрос. Если, с другой стороны, ядро сге-
нерировано таким образом, что выход за границы табличного пространства будет
маловероятен, дополнительное табличное пространство может не понадобиться,
поскольку оно не может быть использовано для других целей. Как бы то ни бы-
ло, простота алгоритмов ядра представляется более важной, чем сжатие послед-
них байтов оперативной памяти. Обычно в алгоритмах для поиска свободных мест
в таблицах используются несложные циклы и этот метод более понятен и иногда
более эффективен по сравнению с более сложными схемами выделения памяти.
2.4 УПРАВЛЕНИЕ СИСТЕМОЙ
К управляющим процессам, грубо говоря, относятся те процессы, которые
выполняют различные функции по обеспечению благополучной работы пользовате-
лей системы. К таким функциям относятся форматирование дисков, создание но-
вых файловых систем, восстановление разрушенных файловых систем, отладка яд-
ра и др. С концептуальной
Время Процесс A Процесс B Процесс C
--------------------------------------------------------------
| Буфер заблокирован
| Приостановлен
| . Буфер заблокирован
| . Приостановлен
| . . Буфер заблокирован
| . . Приостановлен
| ------------------------------------------------------------
| |Буфер разблокирован Пробуждение всех 'спящих' процессов|
| ------------------------------------------------------------
| Готов к Готов к Готов к
| выполнению выполнению выполнению
| . .
| . Запущен .
| . Буфер разблокирован .
| . Блокировка буфера .
| . . .
| . Приостановка по .
| . произвольной причине .
| . . .
| Запущен . .
| Буфер заблокирован . .
| Приостановка . .
| . . Запущен
| . . Буфер заблокирован
| . . Приостановка
| . Пробуждение .
| . Снятие блокировки .
| . буфера .
| Готов к Пробуждение всех Готов к
| выполнению 'спящих' процессов выполнению
|
v Переключение контекста
Запущен
Рисунок 2.9. Многократная приостановка выполнения процессов, вызванная
блокировкой
36
точки зрения, между управляющими и пользовательскими процессами нет разницы.
Они используют один и тот же набор обращений к операционной системе, доступ-
ный для всех. Управляющие процессы отличаются от обычных пользовательских
процессов только правами и привилегиями, которыми они обладают. Например,
режимы разрешения доступа к файлу могут предусматривать предоставление воз-
можности работы с файлами для управляющих процессов и отсутствие такой воз-
можности для обычных пользователей. Внутри системы ядро выделяет особого
пользователя, именуемого суперпользователем, и наделяет его особыми привиле-
гиями, о чем мы еще поговорим ниже. Пользователь может стать суперпользова-
телем, если соответствующим образом зарегистрируется в системе или запустит
специальную программу. Привилегии суперпользователя будут рассмотрены в сле-
дующих главах. Если сказать коротко, ядро системы не выделяет управляющие
процессы в отдельный класс.
2.5 ВЫВОДЫ И ОБЗОР ПОСЛЕДУЮЩИХ ГЛАВ
В этой главе описана архитектура ядра операционной системы; его основны-
ми компонентами выступают подсистема управления файлами и подсистема управ-
ления процессами. Подсистема управления файлами управляет хранением и выбор-
кой данных в пользовательских файлах. Файлы организованы в виде файловых
систем, которые трактуются как логические устройства; физическое устройство,
такое как диск, может содержать несколько логических устройств (файловых
систем). Каждая файловая система имеет суперблок, в котором описывается
структура и содержимое файловой системы, каждый файл в файловой системе опи-
сывается индексом, хранящим атрибуты файла. Системные операции работают с
файлами, используя индексы.
Процессы находятся в различных состояниях и переходят из состояния в
состояние, следуя определенным правилам перехода. В частности, процессы, вы-
полняющиеся в режиме ядра, могут приостановить свое выполнение и перейти в
состояние 'сна', но ни один процесс не может перевести в это состояние дру-
гой процесс. Ядро является невыгружаемым и это означает, что процесс, выпол-
няющийся в режиме ядра, будет продолжать свое выполнение до тех пор, пока не
перейдет в состояние 'сна' или пока не вернется в режим задачи. Ядро обеспе-
чивает целостность своих информационных структур благодаря своей невыгружае-
мости, а также путем блокирования прерываний на время выполнения критических
секций программы.
В остальных частях главы детально описываются подсистемы, изображенные
на Рисунке 2.1, а также взаимодействие между ними, начиная с подсистемы уп-
равления файлами и включая подсистему управления процессами. В следующей
главе рассматривается буфер сверхоперативной памяти (кеш) и описываются ал-
горитмы управления буфером, используемые в главах 4, 5 и 7. В главе 4 расс-
матриваются внутренние алгоритмы файловой системы, включая обработку индек-
сов, структуру файлов, преобразование имени пути в индекс. В главе 5 расс-
матриваются системные операции, которые, используя приведенные в главе 4 ал-
горитмы, обращаются к файловой системе, т.е. такие, как open, close, read и
write. Глава 6 имеет дело с понятием контекста процесса и его адресным прос-
транством, а глава 7 рассматривает системные операции, связанные с управле-
нием процессами и использующие алгоритмы главы 6. Глава 8 касается планиро-
вания выполнения процессов, в главе 9 обсуждаются алгоритмы распределения
памяти. Глава 10 посвящена драйверам устройств, рассмотрение которых до того
откладывалось, чтобы прежде объяснить связь драйвера терминала с управлением
процессами. В главе 11 представлено несколько форм взаимодействия процессов.
Наконец, в последних двух главах рассматриваются вопросы, связанные с углуб-
ленным изучением особенностей системы, в частности, особенности многопроцес-
сорных систем и распределенных систем.
37
2.6 УПРАЖНЕНИЯ
1. Рассмотрим следующий набор команд:
grep main a.c b.c c.c > grepout &
wc -1 < grepout &
rm grepout &
Амперсанд (символ '&') в конце каждой командной строки говорит командному
процессору shell о том, что команду следует выполнить на фоне, при этом
shell может выполнять все командные строки параллельно. Почему это не
равноценно следующей командной строке ?
grep main a.c b.c c.c | wc -1
2. Рассмотрим пример программы, приведенный на Рисунке 2.7. Предположим, что
в тот момент, когда при ее выполнении встретился комментарий, произошло
переключение контекста и другой процесс убрал содержимое буфера из списка
указателей с помощью следующих команд:
remove(gp)
struct queue *gp;
{
gp - > forp - > backp = gp - > backp;
gp - > backp - > forp = gp - > forp;
gp - > forp = gp - > backp = NULL;
}
Рассмотрим три случая:
- Процесс убирает из списка с указателями структуру bp1.
- Процесс убирает из списка с указателями структуру, следующую после
структуры bp1.
- Процесс убирает из списка структуру, которая первоначально следовала за
bp1 до того, как структура bp была наполовину включена в указанный спи-
сок.
В каком состоянии будет список после того, как первый процесс завершит
выполнение части программы, расположенной после комментариев ?
3. Что произошло бы в том случае, если ядро попыталось бы возобновить выпол-
нение всех процессов, приостановленных по событию, но в системе не было
бы к этому моменту ни одного такого процесса ?
38
