№ 17

Подсистема управления вводом-выводом

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

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

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

одно конкретное физическое устройство. Например, как устройство трактуется
физическая память, чтобы позволить процессу обращаться к ней извне, пусть даже память
не является периферийным устройством. Команда ps обращается к информационным
структурам ядра в физической памяти, чтобы сообщить статистику процессов. Еще один
пример: драйверы могут вести трассировку записей в удобном для отладки виде, а
драйвер трассировки дает возможность пользователям читать эти записи. Наконец,
профиль ядра выполнен как драйвер: процесс записывает адреса программ ядра,
обнаруженных в таблице идентификаторов ядра, и читает результаты профилирования.
Процессы в операционной системе UNIX.

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

процессов, которая обсуждалась на лекции. Контекст процесса складывается из
пользовательского контекста и контекста ядра, как изображено на рисунке.

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

адресном пространстве процесса. Все данные подразделяются на:

 инициализируемые неизменяемые данные (например, константы);

 инициализируемые изменяемые данные (все переменные, начальные значения которых
присваиваются на этапе компиляции);

 неинициализируемые изменяемые данные (все статические переменные, которым не

присвоены начальные значения на этапе компиляции);

 стек пользователя;

 данные, расположенные в динамически выделяемой памяти (например, с помощью

стандартных библиотечных C функций malloc(), calloc(), realloc()).

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

программы, который исполняется в контексте процесса. Пользовательский стек
применяется при работе процесса в пользовательском режиме (user-mode).

Под понятием "контекст ядра" объединяются системный контекст и регистровый

контекст, рассмотренные на лекции. Мы будем выделять в контексте ядра стек ядра,
который используется при работе процесса в режиме ядра (kernel mode), и данные ядра,
хранящиеся в структурах, являющихся аналогом блока управления процессом — PCB.
Состав данных ядра будет уточняться на последующих семинарах. На этом занятии нам
достаточно знать, что в данные ядра входят: идентификатор пользователя — UID,
групповой идентификатор пользователя — GID, идентификатор процесса — PID,
идентификатор родительского процесса — PPID.
№ 16

Система смешанного типа со свопингом и подкачкой по запросу

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

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

Ядро в версии V манипулирует алгоритмами подкачки процессов и замещения страниц

так, что проблемы соперничества перестают быть неизбежными. Когда ядро не может
выделить процессу страницы памяти, оно возобновляет работу процесса подкачки и
переводит пользовательский процесс в состояние, эквивалентное состоянию "готовности к
запуску, будучи зарезервированным". В этом состоянии одновременно могут находиться
несколько процессов. Процесс подкачки выгружает один за другим целые процессы, пока
объем доступной памяти в системе не превысит верхнюю отметку. На каждый
выгруженный процесс приходится один процесс, загруженный в память из состояния
"готовности к выполнению, будучи зарезервированным". Ядро загружает эти процессы не
с помощью обычного алгоритма подкачки, а путем обработки отказов при обращении к
соответствующим страницам. На последующих итерациях процесса подкачки при условии
наличия в системе достаточного объема свободной памяти будут обработаны отказы,
полученные другими пользовательскими процессами. Применение такого метода ведет к
снижению частоты возникновения системных отказов и устранению соперничества: по
идеологии он близок к методам, используемым в операционной системе VAX/VMS
Взаимодействие драйверов с программной и аппаратной средой

В системе UNIX имеется два типа устройств - устройства ввода/вывода блоками и

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

Пользователь взаимодействует с устройствами через посредничество файловой системы.

Каждое устройство имеет имя, похожее на имя файла, и пользователь обращается к нему
как к файлу. Специальный файл устройства имеет индекс и занимает место в иерархии
каталогов файловой системы. Файл устройства отличается от других файлов типом файла,
хранящимся в его индексе, либо "блочный", либо "символьный специальный", в
зависимости от устройства, которое этот файл представляет. Если устройство имеет как
блочный, так и символьный интерфейс, его представляют два файла: специальный файл
устройства ввода-вывода блоками и специальный файл устройства посимвольного ввода-
вывода. Системные функции для обычных файлов, такие как open, close, read и write,
имеют то же значение и для устройств, в чем мы убедимся позже. Системная функция
ioctl предоставляет процессам возможность управлять устройствами посимвольного
ввода-вывода, но не применима в отношении к файлам обычного типа. Тем не менее,
драйверам устройств нет необходимости поддерживать полный набор системных
функций. Например, вышеупомянутый драйвер трассировки дает процессам возможность
читать записи, созданные другими драйверами, но не позволяет создавать их.
№ 15

Алгоритмы управления памятью

Алгоритм планирования использования процессорного времени, рассмотренный в

предыдущей главе, в сильной степени зависит от выбранной стратегии управления
памятью. Процесс может выполняться, если он хотя бы частично присутствует в основной
памяти; ЦП не может исполнять процесс, полностью выгруженный во внешнюю память.
Тем не менее, основная память - чересчур дефицитный ресурс, который зачастую не
может вместить все активные процессы в системе. Если, например, в системе имеется
основная память объемом 8 Мбайт, то девять процессов размером по 1 Мбайту каждый
уже не смогут в ней одновременно помещаться. Какие процессы в таком случае следует
размещать в памяти (хотя бы частично), а какие нет, решает подсистема управления
памятью, она же управляет участками виртуального адресного пространства процесса, не
резидентными в памяти. Она следит за объемом доступного пространства основной
памяти и имеет право периодически переписывать процессы на устройство внешней
памяти, именуемое устройством выгрузки, освобождая в основной памяти
дополнительное место. Позднее ядро может вновь поместить данные с устройства
выгрузки в основную память.

В ранних версиях системы UNIX процессы переносились между основной памятью и

устройством выгрузки целиком и, за исключением разделяемой области команд,
отдельные независимые части процесса не могли быть объектами перемещения. Такая
стратегия управления памятью называется свопингом (подкачкой). Такую стратегию
имело смысл реализовывать на машине типа PDP-11, где максимальный размер процесса
составлял 64 Кбайта. При использовании этой стратегии размер процесса ограничивается
объемом физической памяти, доступной в системе. Система BSD (версия 4.0) явилась
главным полигоном для применения другой стратегии, стратегии "подкачки по
обращению" (demand paging), в соответствии с которой основная память обменивается с
внешней не процессами, а страницами памяти; эта стратегия поддерживается и в
последних редакциях версии V системы UNIX. Держать в основной памяти весь
выполняемый процесс нет необходимости, и ядро загружает в память только отдельные
страницы по запросу выполняющегося процесса, ссылающегося на них. Преимущество
стратегии подкачки по обращению состоит в том, что благодаря ей отображение
виртуального адресного пространства процесса на физическую память машины
становится более гибким: допускается превышение размером процесса объема доступной
физической памяти и одновременное размещение в основной памяти большего числа
процессов. Преимущество стратегии свопинга состоит в простоте реализации и
облегчении "надстроечной" части системы.
Взаимодействие процессов

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

осуществлять обмен данными и синхронизировать свое выполнение с другими
процессами. Мы уже рассмотрели несколько форм взаимодействия процессов, такие как
канальная связь, использование поименованных каналов и посылка сигналов. Каналы
(непоименованные) имеют недостаток, связанный с тем, что они известны только
потомкам процесса, вызвавшего системную функцию pipe: не имеющие родственных
связей процессы не могут взаимодействовать между собой с помощью непоименованных
каналов. Несмотря на то, что поименованные каналы позволяют взаимодействовать между
собой процессам, не имеющим родственных связей, они не могут использоваться ни в
сети (см. главу 13), ни в организации множественных связей между различными группами
взаимодействующих процессов: поименованный канал не поддается такому
мультиплексированию, при котором у каждой пары взаимодействующих процессов
имелся бы свой выделенный канал. Произвольные процессы могут также связываться
между собой благодаря посылке сигналов с помощью системной функции kill, однако
такое "сообщение" состоит из одного только номера сигнала.

Пакет IPC (interprocess communication) в версии V системы UNIX включает в себя три
механизма. Механизм сообщений дает процессам возможность посылать другим
процессам потоки сформатированных данных, механизм разделения памяти позволяет
процессам совместно использовать отдельные части виртуального адресного
пространства, а семафоры - синхронизировать свое выполнение с выполнением
параллельных процессов. Несмотря на то, что они реализуются в виде отдельных блоков,
им присущи общие свойства.

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

его детали.
 В каждой записи содержится числовой ключ (key), который представляет
собой идентификатор записи, выбранный пользователем.
 В каждом механизме имеется системная функция типа "get", используемая
для создания новой или поиска существующей записи; параметрами
функции являются идентификатор записи и различные флаги (flag). Ядро
ведет поиск записи по ее идентификатору в соответствующей таблице.
Процессы могут с помощью флага IPC_PRIVATE гарантировать получение
еще неиспользуемой записи. С помощью флага IPC_CREAT они могут
создать новую запись, если записи с указанным идентификатором нет, а
если еще к тому же установить флаг IPC_EXCL, можно получить
уведомление об ошибке в том случае, если запись с таким идентификатором
существует. Функция возвращает некий выбранный ядром дескриптор,
предназначенный для последующего использования в других системных
функциях, таким образом, она работает аналогично системным функциям
creat и open.
 В каждом механизме ядро использует следующую формулу для поиска по
дескриптору указателя на запись в таблице структур данных: указатель =
значение дескриптора по модулю от числа записей в таблице Если, например, таблица
структур сообщений состоит из 100 записей, дескрипторы, связанные с
записью номер 1, имеют значения, равные 1, 101, 201 и т.д. Когда процесс
удаляет запись, ядро увеличивает значение связанного с ней дескриптора на
 число записей в таблице: полученный дескриптор станет новым
дескриптором этой записи, когда к ней вновь будет произведено обращение
при помощи функции типа "get". Процессы, которые будут пытаться
обратиться к записи по ее старому дескриптору, потерпят неудачу.
Обратимся вновь к предыдущему примеру. Если с записью 1 связан
дескриптор, имеющий значение 201, при его удалении ядро назначит записи
новый дескриптор, имеющий значение 301. Процессы, пытающиеся
обратиться к дескриптору 201, получат ошибку, поскольку этого
дескриптора больше нет. В конечном итоге ядро произведет перенумерацию
дескрипторов, но пока это произойдет, может пройти значительный
промежуток времени.
 Каждая запись имеет некую структуру данных, описывающую права
доступа к ней и включающую в себя пользовательский и групповой коды
идентификации, которые имеет процесс, создавший запись, а также
пользовательский и групповой коды идентификации, установленные
системной функцией типа "control" (об этом ниже), и двоичные коды
разрешений чтения-записи-исполнения для владельца, группы и прочих
пользователей, по аналогии с установкой прав доступа к файлам.
 В каждой записи имеется другая информация, описывающая состояние
записи, в частности, идентификатор последнего из процессов, внесших
изменения в запись (посылка сообщения, прием сообщения, подключение
разделяемой памяти и т.д.), и время последнего обращения или
корректировки.
 В каждом механизме имеется системная функция типа "control",
запрашивающая информацию о состоянии записи, изменяющая эту
информацию или удаляющая запись из системы. Когда процесс запрашивает
информацию о состоянии записи, ядро проверяет, имеет ли процесс
разрешение на чтение записи, после чего копирует данные из записи
таблицы по адресу, указанному пользователем. При установке значений
принадлежащих записи параметров ядро проверяет, совпадают ли между
собой пользовательский код идентификации процесса и идентификатор
пользователя (или создателя), указанный в записи, не запущен ли процесс
под управлением суперпользователя; одного разрешения на запись
недостаточно для установки параметров. Ядро копирует сообщенную
пользователем информацию в запись таблицы, устанавливая значения
пользовательского и группового кодов идентификации, режимы доступа и
другие параметры (в зависимости от типа механизма). Ядро не изменяет
значения полей, описывающих пользовательский и групповой коды
идентификации создателя записи, поэтому пользователь, создавший запись,
сохраняет управляющие права на нее. Пользователь может удалить запись,
либо если он является суперпользователем, либо если идентификатор
процесса совпадает с любым из идентификаторов, указанных в структуре
записи. Ядро увеличивает номер дескриптора, чтобы при следующем
назначении записи ей был присвоен новый дескриптор. Следовательно, как
уже ранее говорилось, если процесс попытается обратиться к записи по
старому дескриптору, вызванная им функция получит отказ.