Process Control Block и контекст процесса

Для того чтобы операционная система могла выполнять операции над процессами, каждый процесс представляется в ней некоторой структурой данных. Эта структура (контекст процесса) содержит информацию, специфическую для данного процесса:

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

Ее состав и строение зависят, конечно, от конкретной ОС. Во многих ОС информация, характеризующая процесс, хранится не в одной, а в нескольких связанных структурах данных. Эти структуры могут иметь различные наименования, содержать дополнительную информацию или, наоборот, лишь часть описанной информации. Для любого процесса, находящегося в вычислительной системе, вся информация, необходимая для совершения операций над ним, доступна ОС. Для простоты будем считать, что она хранится в одной структуре данных. Мы будем называть ее PCB (Process Control Block) или блоком управления процессом. Блок управления процессом является моделью процесса для ОС. Любая операция, производимая ОС над процессом, вызывает определенные изменения в PCB. В рамках принятой модели состояний процессов содержимое PCB между операциями остается постоянным.

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

 

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

Порождение процессов в системе Unix происходит в результате выполнения системного вызова «fork». ОС строит образ порожденного процесса, являющийся точной копией образа родительского процесса: т.е. дублируется дескриптор, контекст и образ процесса. После выполнения системного вызова «fork» оба процесса продолжают выполнение с одной и той же точки. Чтобы процесс мог опознать, является ли он родительским или процессом-потомком, системный вызов fork возвращает в родительский процесс идентификатор процесса-потомка, а в процесс-потомок - значение NULL. Типичное разветвление на языке С выглядит так:

if (fork())

{ действие родительского процесса}

else

{действие процесса-потомка}

С помощью системного вызова exec процесс может перейти к выполнению другой программы.

Одноразовые операции

Любая ОС, поддерживающая концепцию процессов, должна обладать средствами для их создания. В очень простых системах (например, в системах, спроектированных для работы только одного конкретного приложения) все процессы могут быть порождены на этапе старта системы. Более сложные ОС создают процессы динамически, по мере необходимости. Инициатором рождения нового процесса после старта ОС может выступить либо процесс пользователя, совершивший специальный системный вызов, либо сама ОС, то есть, в конечном итоге, тоже некоторый процесс. Процесс, инициировавший создание нового процесса, принято называть процессом-родителем (parent process), а вновь созданный процесс – процессом-ребенком (child process). Процессы-дети могут в свою очередь порождать новых детей и т. д., образуя, в общем случае, внутри системы набор генеалогических деревьев процессов – генеалогический лес. Пример генеалогического леса изображен на рисунке 4. Следует отметить, что все пользовательские процессы вместе с некоторыми процессами операционной системы принадлежат одному и тому же дереву леса. В ряде вычислительных систем лес вообще вырождается в одно такое дерево.

Рис. 8. Упрощенный генеалогический лес процессов. Стрелочка означает отношение родитель–ребенок

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

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

После наделения процесса-ребенка ресурсами необходимо занести в его адресное пространство программный код, значения данных, установить программный счетчик. Здесь также возможны два решения. В первом случае процесс-ребенок становится дубликатом процесса-родителя по регистровому и пользовательскому контекстам, при этом должен существовать способ определения, кто для кого из процессов-двойников является родителем. Во втором случае процесс-ребенок загружается новой программой из какого-либо файла. ОС Unix разрешает порождение процесса только первым способом; для запуска новой программы необходимо сначала создать копию процесса-родителя, а затем процесс-ребенок должен заменить свой пользовательский контекст с помощью специального системного вызова. ОС VAX/VMS допускает только второе решение. В Windows NT возможны оба варианта (в различных API).

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

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

После того как процесс завершил свою работу, ОС переводит его в состояние "закончил исполнение" и освобождает все ассоциированные с ним ресурсы, делая соответствующие записи в блоке управления процессом. При этом сам PCB не уничтожается, а остается в системе еще некоторое время. Это связано с тем, что процесс-родитель после завершения процесса-ребенка может запросить ОС о причине "смерти" порожденного им процесса и/или статистическую информацию о его работе. Подобная информация сохраняется в PCB отработавшего процесса до запроса процесса-родителя или до конца его деятельности, после чего все следы завершившегося процесса окончательно исчезают из системы. В Unix процессы, находящиеся в состоянии закончил исполнение, принято называть процессами-зомби.

Многоразовые операции

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

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

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

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

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

Переключение контекста

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

Давайте для примера упрощенно рассмотрим, как в реальности может протекать операция разблокирования процесса, ожидающего ввода-вывода (см. рис. 5). При исполнении процессором некоторого процесса (на рисунке – процесс 1) возникает прерывание от устройства ввода-вывода, сигнализирующее об окончании операций на устройстве. Над выполняющимся процессом производится операция приостановки. Далее ОС разблокирует процесс, инициировавший запрос на ввод-вывод (на рисунке – процесс 2) и осуществляет запуск приостановленного или нового процесса, выбранного при выполнении планирования (на рисунке был выбран разблокированный процесс). Как мы видим, в результате обработки информации об окончании операции ввода-вывода возможна смена процесса, находящегося в состоянии исполнение.

Рис. 9. Выполнение операции разблокирования процесса. Использование термина "код пользователя" не ограничивает общности рисунка только пользовательскими процессами

Для корректного переключения процессора с одного процесса на другой необходимо сохранить контекст исполнявшегося процесса и восстановить контекст процесса, на который будет переключен процессор. Такая процедура сохранения/восстановления работоспособности процессов называется переключением контекста. Время, затраченное на переключение контекста, не используется вычислительной системой для совершения полезной работы и представляет собой накладные расходы, снижающие производительность системы. Оно меняется от машины к машине и обычно колеблется в диапазоне от 1 до 1000 микросекунд. Существенно сократить накладные расходы в современных ОС позволяет расширенная модель процессов, включающая в себя понятие threads of execution (нити исполнения и ли просто нити).

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

Планирование и диспетчеризация потоков.

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

- определение момента времени для смены текущего активного потока;

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

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

Статический тип планирования может использоваться, если весь набор одновременно выполняемых задач определен заранее (в системах реального времени).

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

 

- сохранение контекста текущего потока, который нужно сменить;

- загрузка контекста нового потока, выбранного в результате планирования;

- запуск нового потока на выполнение.

В мультипрограммной системе поток может находиться в одном из 3-х состояний:

 

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

- ожидание – пассивное состояние, находясь в котором поток заблокирован по своим внутренним причинам (ожидает осуществление события), например: завершение ввода/вывода.

- готовность – пассивное состояние, в котором поток заблокирован в связи с внешними по отношению к нему обстоятельствами (он имеет все ресурсы, но процессор занят выполнением другого потока.

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

 

Алгоритмы планирования.

С общих позиций их можно разделить на 2 класса:

 

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

- вытесняющие - при их использовании решение о переключении процессора с потока на поток принимает сама ОС, а не активный поток.

 

Почти во всех современных ОС применяются вытесняющие алгоритмы. В основе таких алгоритмов имеет концепция квантования, в соответствии с которой каждому потоку поочередно предоставляется ограниченный и непрерывный период процессорного времени – квант.

 

Смена активного потока происходит если:

а) поток завершился и покинул систему;

б) произошла ошибка;

в) поток перешел в состояние ожидания;

г) исчерпан квант процессорного времени, отведенного потоку.

 

Кванты могут иметь фиксированную длительность одинаковую для всех потоков. Но длительность кванта может зависеть от текущего состояния потока и всей системы.

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

Во многих ОС есть возможность изменения приоритета в процессе жизни потока. Используются так же смешанные подходы к планированию потоков.