DAY11 (Старые версии Машбука или нечто подобное)

4

Лекция №11

На прошлой лекции мы ввели понятие процесса. Мы установили, что процесс - это нечто, что зарегистрировано в таблице процессов. Каждый процесс имеет уникальное имя - номер записи в таблице процессов. С процессом ассоциированы две сущности: тело и контекст. В некоторых операционных системах тело процесса делится на два сегмента: кода и данных. В свою очередь встречаются реализации, когда сегмент кода бывает закрыт на запись - в этом случае отпадает необходимость запуска n копий одного и того же процесса. Мы говорили о контексте - важной сущности процесса. Контекст описывает атрибуты актуального состояния процесса в каждый момент времени. Причем содержимое контекста можно разделить на две группы: статические характеристики и динамические характеристики. Статические характеристики меняются во времени редко или вообще не меняются - это, например, общие права доступа процесса, открытые файлы и т. п. Динамические характеристики отображают состояние процесса на текущий момент времени. Доступ к динамическим характеристикам мы можем получить через контекст, когда процесс приостановлен (например, после прихода сигнала). Далее мы говорили о схеме порождения процесса в ОС UNIX. Мы сказали, что эта схема единая для всей системы. Процессы порождаются средствами использования базовых функций fork() и exec(...). Мы подчеркнули тот факт, что при обращении к функции fork() система поддерживает родственные связи процессов. Функция exec(...) обеспечивает замену тела процесса, тем самым для создания процесса с некоторым именем нужно создать копию, а затем в эту копию «запихнуть» другое тело процесса. К функциям fork() и exec(...) можно обращаться независимо друг от друга. Нами была рассмотрена последовательность действий при загрузке системы, т. е. некий скелет системы - последовательность действий начиная от включения и кончая завершением сеанса работы.

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

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

Планирование процессов

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

С каждым процессом связан приоритет процесса, который мы назовем P_PRI. Чем больше значение P_PRI, тем ниже реальный приоритет. В вычислении приоритета процесса P_PRI участвуют несколько приоритетных компонент и, в частности, две составляющие P_NICE и P_CPU. P_PRI представляет собой некую функцию от нескольких аргументов:

P_PRI=F(..., P_NICE, P_CPU)

P_NICE - это некоторая пользовательская составляющая приоритета в том смысле, что мы сами устанавливаем ее значение из некоторого отрезка [C1, C2] с помощью соответствующей команды, но вот отрезок изменения - параметры C1 и C2 выбираются системой. Пользовательская составляющая P_NICE наследуется сыновними процессами. Кроме того существует такое правило: значение переменной P_NICE, заданное в процессе отце, не может быть уменьшено в процессе-сыне.

Что касается другого параметра - P_CPU, то это так называемая системная составляющая. Ее суть такова. Через каждый фиксированный промежуток времени непрерывного использования процессора значение P_CPU увеличивается на единицу.

В вычислении приоритета процесса также используется константа P_USER. И обычно функция вычисления приоритета процесса P_PRI выглядит в виде суммы составляющих P_NICE, P_CPU и P_USER:

P_PRI=P_NICE+P_CPU+P_USER

Заметим, что при расчете приоритета системных процессов константа P_USER не используется. Появляется некоторый порок, который выводит системные процессы на более приоритетный уровень.

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

Планирование подкачки

В некотором месте внешнего устройства располагается т. н. область сохранения. Мы будем считать, что область сохранения располагается за блоками файлов. В области сохранения располагаются копии процессов, запускные файлы которых, помеченными t-битами. Также область сохранения используется для подкачки. В каждый момент времени процесс находится либо в RAM, либо откачен в область сохранения. Заметим, что мы рассматриваем некий модельный вариант свопинга, когда процесс откачивается целиком. Понятно, что это довольно неэффективно. Итак, процесс может быть либо активным - использовать CPU, либо пассивным - находиться в состоянии приостановки, ожидания освобождения CPU. Упрощенная схема планирования подкачки основывается на использовании приоритета P_TIME, находящегося в контексте процесса. В этом параметре аккумулируется время пребывания процесса на конкретном запоминающем устройстве.

Значение P_TIME при каждом перемещении процесса из одного запоминающего устройства в другое обнуляется. P_TIME - приоритет для свопинга. Для загрузки процесса в RAM из области свопинга выбирается процесс с максимальным значением P_TIME. Если для загрузки этого процесса нет места в RAM, то система, а именно диспетчер процессов - компонент ОС, отвечающий за подкачку, ищет среди процессов, находящихся в оперативной памяти, процесс, ожидающий ввода/вывода и занимающий наибольший объем памяти. Этот процесс откачивается, осуществляется проверка: достаточно ли теперь в оперативной памяти места для загрузки процесса. И если места нет, то снова ищется процесс наибольшего размера, ожидающий ввода/вывода. Может так случиться, что все ожидают откачки, но места не хватает. Тогда выбирается процесс, у которого самое большое значение P_TIME. Откачка идет пока не освободится необходимый объем памяти.

Как я уже сказал, эта схема во многом неэффективна. Происходит свопинг всего процесса целиком. Также наблюдаются притеснения прав процессов при свопинге. Это не есть хорошо. Современные UNIX системы имеют более гибкие алгоритмы планирования свопинга и, в частности, свопируют части процессов.

Продолжим рассмотрение темы «Взаимодействие процессов». Итак само взаимодействие включает в себя три компоненты:

• порождение процесса (FORK()/EXEC(...));

• базовые средства взаимодействия;

• разделение ресурсов и распределенная обработка.

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

Сигналы

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

Сигналы появились уже в ранних версиях UNIX, но их реализация не была достаточно надежной (что не характерно для UNIX). Сигнал мог быть «потерян», возникали также определенные сложности с отключением (блокировкой) сигналов на время выполнения критических участков кода. В последующие версии, например, в BSD UNIX, были внесены изменения, позволившие реализовать надежные (reliable) сигналы.

В системе имеется перечень этих воздействий. В сегодняшних UNIX-ах их около 30, а первые версии насчитывали чуть более двенадцати сигналов. Каждый сигнал имеет уникальное символьное имя и соответствующий ему номер, а также определенное правило интерпретации, например, SIG_KILL, сигнал №9 - завершение процесса.

Возникновение сигнала может происходить (как и прерывание) по 4 причинам:

• Событие, связанное с приходом некоторой информации от устройства. Например, ядро отправляет процессу (или группе процессов) сигнал SIG_TRAP, при нажатии пользователем комбинации клавиш <Ctrl>+<C> (или <Del>) , что вызовет «мягкое завершение» работы процесса.

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

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

• Передача сигнала от одного процесса к другому.

Система предоставляет ряд функций по работе с сигналами.

Прототип функции установки обработки сигнала выглядит так:

void (* signal (sig, fun)) ()

int sig;

void (* fun) ();

При обращении к signal мы передаем:

sig - имя сигнала;

fun - указатель на функцию, которая будет обрабатывать событие, связанное с возникновением этого сигнала. Функция signal возвращает указатель на предыдущую функцию обработки данного сигнала.

Событие, связанное с возникновением сигнала, может быть обработано в системе тремя способами:

1. SIG_DEF - стандартная реакция на сигнал, которая предусмотрена системой;

2. SIG_IGN - игнорирование сигнала (следует отметить, что далеко не все сигналы можно игнорировать, например, SIG_KILL);

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

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