Файл: Учебнометодическое пособие Томск 2016 2 удк 004. 451(075. 8) Ббк 32. 973. 2018. 2я73 к 754 Рецензенты.pdf

143 бинарным, ни скриптом, явно задающим shell, то будет загружен тот shell, который загружается по умолчанию в данной системе.
Сама загрузка программы в отличие, например, от MS-DOS не сводится к записи ее сегментов в ОП. Эти сегменты копируются из исполняемого файла в область ВП, называемую областью свопинга. Непосредственно в ОП записы- вается лишь самая начальная часть сегмента кода программы, с которой начнется выполнение программы в результате передачи управления или из ядра
(при завершении системного вызова ЗАГРУЗИТЬ_ПРОГРАММУ),или из дина- мического редактора связей (при использовании в программе DLL). Далее за- грузка требуемых фрагментов программы из области свопинга будет произво- диться динамически, то есть во время выполнения программы. В том случае, если программа процесса является реентерабельной, ее сегмент кода вообще не нуждается в записи в какую-либо память при условии, что эта программа уже выполняется каким-либо процессом.
Основная операция, выполняемая при загрузке программы, заключается в подготовке структур отображения памяти. Наличие данных структур, во- первых, позволяет использовать в программе логическую адресацию команд и данных, не зависящую от фактического размещения этих элементов в памяти.
Во-вторых, эти структуры выполняют важную роль при защите информации в ОП. Подробно структуры отображения памяти рассматриваются в гл. 6.
5.3 Обработка сигналов
Вне зависимости от того, кто является источником сигнала (обработчик прерываний или процесс), его выдача сводится к установке одного бита в поле
«сигналы» структуры proc. (Вспомним, что наряду с user это одна из двух основных управляющих структур процесса.) Длина этого поля в битах совпада- ет с числом типов сигналов, существующих в системе. Так как одному типу сигнала соответствует всего один бит, то до начала обработки сигнала и, следо- вательно, до сброса бита в поле «сигналы» все последующие сигналы данного типа будут процессом игнорироваться.
Наличие сигнала означает, что он должен быть обработан процессом.
В общем случае существуют три варианта обработки сигнала:
1) обработка по умолчанию. Она выполняется одной из подпрограмм яд- ра и для большинства типов сигналов сводится к прекращению суще- ствования процесса;
2) игнорирование сигнала;

144 3) обработка сигнала собственной подпрограммой процесса.
В любой момент времени для каждого типа сигналов, поступающих в процесс, задан один (и только один) вариант обработки. Для этого использу- ется строка диспозиция сигналов в управляющей структуре user. Каждое поле данной строки соответствует одному типу сигналов и содержит вариант его об- работки. При этом, если для обработки сигнала используется собственная
(пользовательская) подпрограмма, указанное поле содержит ее адрес в ОП.
Сразу же после создания процесса с помощью соответствующего систем- ного вызова диспозиция сигналов нового процесса точно такая же, как и у про- цесса-отца (наследование диспозиции). Но если далее процесс выдаст систем- ный вызов ЗАГРУЗИТЬ_ПРОГРАММУ, то для всех сигналов устанавливается диспозиция «по умолчанию». Это объясняется тем, что все прежние обработчи- ки сигналов уничтожены (как и все другие прикладные подпрограммы) в ре- зультате загрузки. Если такая начальная диспозиция не устраивает, то для ее изменения процесс выполняет системный вызов:
УСТАНОВИТЬ_ОБРАБОТКУ_СИГНАЛА (I
S
, i, A
a
||),
(на Си – sigaction), где I
S
– имя сигнала (номер или символьное имя); i–вариант обработки сигнала (по умолчанию, игнорирование, свой обра- ботчик сигнала);
A
a
– стартовый адрес своего обработчика сигнала.
Воспользовавшись этим системным вызовом, программа процесса может сама задать вариант обработки любого своего входного сигнала, за исключени- ем сигналовSIGKILLиSIGSTOP,для каждого из которых допустима только обработка по умолчанию (уничтожение процесса).
Установка в единицу бита в поле «сигналы» структурыprocне означает, что соответствующий сигнал начнет немедленно обрабатываться. Такая обра- ботка может быть начата ядром в один из следующих моментов:
1) непосредственно перед переходом процесса из состояния «Готов» в состояние «Задача»;
2) непосредственно перед переходом процесса из состояния «Ядро» в состояние «Задача»;
3) непосредственно перед переходом процесса в состояние «Сон»;
4) непосредственно перед переходом процесса из состояния «Сон» в со- стояние «Готов».

145
В любой из этих моментов времени подпрограмма ядра issig проверяет наличие поступивших сигналов, читая соответствующее поле в структуре proc
. Если сигнал обнаружен, и если он не должен быть проигнорирован, то инициируется или системный обработчик сигнала, или собственная подпро- грамма процесса. В последнем случае запуску подпрограммы процесса предше- ствует его перевод в состояние «Задача».
Если в момент появления сигнала процесс находился в состоянии «Ядро», то никакого воздействия на процесс сигнал не окажет до выхода из этого состо- яния. С другой стороны, сигнал не может появиться в то время, когда процесс находится в состоянии «Задача», так как источником сигнала в это время может быть только один из обработчиков прерываний. А любой из таких обработчи- ков прерываний может выполняться только в состоянии «Ядро».
Если запущенный обработчик сигнала не выполняет завершения процес- са, то после выполнения этого обработчика выполнение процесса продолжится с той точки, в которой оно было прервано для обработки сигнала.
5.4 Диспетчеризация процессов
Наряду с ОП время ЦП является важнейшим ресурсом системы, подле- жащим распределению между процессами, существующими в данный момент времени в системе и находящимися в состоянии «Готов». Система UNIX явля- ется системой с разделением времени, так как она предоставляет время ЦП про- цессам по очереди небольшими порциями (квантами). Что касается частоты предоставления квантов процессу и их фактической величины, то это зависит от типа процесса, предыдущей истории его обслуживания на ЦП, а также от типа других процессов, существующих в системе.
В зависимости от требуемой дисциплины диспетчеризации все суще- ствующие в UNIXпроцессы можно разбить на три группы:
1) интерактивные процессы. Они выполняются в оперативном режиме
(имеют доступ к терминалу), выполняя диалог с пользователем. При- меры: командные интерпретаторы (shell), текстовые редакторы.
Так как пользователь постоянно находится за терминалом, то основ- ным требованием интерактивного процесса к диспетчеризации явля- ется минимизация среднего времени реакции системы. Время реак-
ции – время ожидания пользователем сообщения системы в ответ на завершение им ввода с клавиатуры. Для того чтобы пользователю не

146 надоел диалог с системой, среднее время реакции не должно превы- шать 2–3 секунды;
2) фоновые процессы. Они не имеют непосредственного доступа к тер- миналу и не ведут диалог с пользователем. Примером являются про- цессы, выполняющие трудоемкие вычисления. Процессы такого типа предъявляют требования к общему объему времени ЦП, а не к дина- мике его назначения;
3) процессы реального времени (РВ). В отличие от интерактивных и фо- новых процессов такие процессы обслуживают не лю- дей-пользователей, а технологические процессы, выполняя автомати- ческий съем информации и (или) автоматическую выдачу управляющих воздействий. Для каждого процесса РВ задается пре- дельное время выполнения. Следствием этого являются жесткие тре- бования к диспетчеризации таких процессов.
Структура данных ядра, которая находится в ведении диспетчера, назы- вается списком готовности (СГ).СГ– приоритетная очередь, в которую поме- щаются процессы при их переходе в состояние «Готов». Приоритетная оче-
редь может рассматриваться как последовательное соединение обычных очередей, каждая из которых предназначена для размещения процессов с оди- наковым приоритетом. Выборка элемента (процесса) из приоритетной очереди производится как и из обыкновенной очереди – из начала списка. А размещение нового процесса в очереди производится в конце той подочереди, которая соот- ветствует приоритету диспетчеризации процесса. Данный приоритет исполь- зуется диспетчером при выборке процесса для исполнения на ЦП (не путать с аппаратными приоритетами, используемыми для защиты информации в ОП).
Приоритет диспетчеризации представляет собой целое неотрицательное число. В разных UNIX-системах это число выбирается по-разному. В некото- рых из них чем число-приоритет выше, тем оно «лучше», а в других, наоборот,
«хуже». Для определенности далее рассматривается второй случай. Заметим, что реальные процедуры диспетчеризации достаточно громоздки. Поэтому да- лее приводится упрощенная такая процедура.
В любой UNIX-системе процессу соответствует не один, а три различных приоритета:
1) пользовательский приоритет;
2) текущий прикладной приоритет;
3) текущий системный приоритет.

147
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Пользовательский приоритет (NICE) – приоритет, заяв-
ленный пользователем при создании процесса.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Этот приоритет используется диспетчером для определения начальных значений текущих приоритетов процесса. UNIX предоставляет своим пользова- телям команды, позволяющие изменять NICE у требуемого процесса. При этом следует отметить, что обычный пользователь может только ухудшать NICE у своих процессов. А администратор системы может не только ухудшать, но и улучшать NICE для любого процесса системы.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Текущий прикладной приоритет – динамически изменяю-
щийся приоритет процесса в состоянии «Задача».
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Диспетчер корректирует этот приоритет и использует его при размеще- нии процесса в СГ. Для расчета текущего прикладного приоритета i-го процес- са используется формула:
,
,
PRI
B
NICE
M ,
i t
i
i
i t



где
,
PRI
i t
– текущий прикладной приоритет i-го процесса на t-й секунде време- ни;
B
i
–базовый прикладной приоритет. Для рассматриваемой системы
40;
B
i

,
M
i t
– мера использования ЦП i-м процессом на t-м интервале времени.
,
M
i t
корректируется следующим образом. Если процесс выполняется на
ЦП (в состоянии «Задача»), то через каждый тик (10 мс) его
,
M
i t
увеличивается на небольшую фиксированную величину. И наоборот, если процесс находится в СГ (находится в состоянии «Готов»), то через каждую секунду его
,
M
i t
кор- ректируется в сторону уменьшения по формуле:

 

,
, 1 1
1
M : M
2
/ 2 1 ,
i t
i t
t
t
n
n






где
1
t
n

– среднее число процессов, находившихся в СГ в течение последней се- кунды. Нетрудно заметить, что чем n больше, тем меньше улучшение приори- тета каждого процесса в СГ.

148
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Текущий системный приоритет – приоритет процесса
в состоянии «Ядро».
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Диапазон системных приоритетов никогда не перекрывается с диапазо- ном прикладных приоритетов. Поэтому самый худший системный приоритет лучше самого лучшего прикладного приоритета. Допустим далее, что диапазон системных приоритетов от 0 до 40. Что касается конкретной величины текуще- го системного приоритета, то он корректируется динамически так же, как и прикладной приоритет.
Интересно отметить, что системный приоритет присущ процессу не толь- ко в состоянии «Ядро», но и в состоянии «Сон». В этом состоянии процесс ожидает получения от системы какого-то ресурса и чем дефицитнее для систе- мы этот ресурс, тем системный приоритет сна лучше (для избежания «простаи- вания» этого ресурса). Как только процесс переходит из состояния «Сон» в со- стояние «Готов», его приоритет сна сразу же становится текущим системным приоритетом.
В п. 3.2 мы применяли команду shell – ps для получения краткой ин- формации о процессах. Применение этой командыс флагом -l позволяет вы- вести на экран полную информацию о процессах, в том числе и их приоритеты.
· · · · · · · · · · · · · · · · · · · · · · · · ·
Пример
· · · · · · · · · · · · · · · · · · · · · · · · ·
$ ps -l
F S UID PID PPID CPU PRI NICE ADDR SZ WCHAN TTY TIME CMD
1 S vlad
145 1 0
60 10 362 21 4356 2 0:01 s
1 Z vlad
313 145 4 56 10 127 19 2125 2 0:03 e
1 S vlad
431 145 5 70 20 245 11 12454 2 0:01 ps
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
В выдаче команды появились новые столбцы:
1) F – комбинация битов (записанная в восьмеричной системе), опреде- ляющая тип процесса (1 – программа процесса находится в ОП; 2 – системный процесс; 4 – программа процесса занимает фиксированное место в ОП (используется в процессах-драйверах); 10 – программа процесса выгружена из ОП; 20 – процесс трассируется другим про-

149 цессом). Например, если F = 3, то это означает, что процесс систем- ный и его программа находится в ОП;
2) S – состояние процесса (O – выполняется на ЦП; S – находится в со- стоянии «Сон»; R – «Готов»; I – создается; Z – «Зомби»);
3) UID– имя пользователя – владельца процесса;
4) PPID– номер процесса-родителя;
5) CPU – текущий системный приоритет процесса;
6) PRI– текущий прикладной приоритет процесса;
7) NICE – пользовательский приоритет процесса;
8) ADDR – адрес программы процесса (в ОП – для резидентных процес- сов; на диске (в области свопинга) – для остальных процессов);
9) SZ – размер программы процесса в блоках (по 512 байт);
10) WCHAN– номер события, которого ожидает процесс в состоянии сна.
Рассмотрим динамику выполнения процессов на ЦП. Допустим, что наш процесс находится в СГ и готов выполняться в состоянии «Задача». Так как со временем его текущий приоритет улучшается, а другие процессы не могут дол- го находиться в состоянии «Ядро», то процесс неизбежно окажется в начале СГ и в случае освобождения процессора будет загружен в него диспетчером путем загрузки в регистры ЦП аппаратного контекста процесса.
Выполнение процесса в состоянии «Задача» может завершиться в резуль- тате одного из следующих событий:
1) закончился квант времени ЦП;
2) переход в состояние «Ядро»;
3) появление в системе более приоритетного процесса.
Квант – небольшая порция времени ЦП, выделяемая очередному процес- су. По истечении ее процесс снимается с ЦП, если имеется процесс с таким же
(или почти таким же) текущим прикладным приоритетом. Появление более приоритетного процесса приводит к досрочному завершению кванта. Переход процесса в состояние «Ядро» является или результатом системного вызова, или результатом исключения, или результатом внешнего аппаратного прерывания.
В результате процесс не снимается с ЦП, а переходит в другое состояние вы- полнения.
Особую опасность для целостности данных ядра имеет обработка внеш- них аппаратных прерываний во время нахождения процесса в состоянии «Яд- ро». В отличие от исключений, происходящих вследствие выполнения про-

150 граммы самого процесса, внешние аппаратные прерывания никак не связаны с выполняемым на ЦП процессом.
Для того чтобы обработчик внешнего прерывания не нарушил данные яд- ра, он снабжается своим приоритетом диспетчеризации, который сравнивается с приоритетом выполняемого на ЦП процесса. Уровень этого приоритета до- статочен, чтобы прервать выполнение любого процесса в состоянии «Задача».
Что касается состояния «Ядро», то приоритет процесса может быть как лучше, так и хуже приоритета обработчика. Это определяется тем, занимается ли в данный момент процесс обработкой данных ядра или нет. Если да, то процесс выполняет свою критическую секцию (см. пп. 3.4.3) и его прерывать нежела- тельно. Во время выполнения критической секции приоритет процесса улучша- ется настолько, чтобы он был лучше приоритетов опасных обработчиков пре- рываний. Затем восстанавливается прежнее значение приоритета.
Изложенная схема диспетчеризации учитывает интересы как интерактив- ных, так и вычислительных процессов. Интерактивные процессы большую часть своего времени находятся в состоянии «Сон» в ожидании завершения пользовательского ввода. Выходя из этого состояния, они имеют достаточно хороший системный приоритет и поэтому достаточно быстро начинают выпол- няться на ЦП. Что касается вычислительных процессов, то с нахождением по- долгу в СГ их приоритет улучшается, и они гарантированно получают доступ к ЦП.
Если система рассчитана на выполнение не только интерактивных и вы- числительных процессов, но и процессов реального времени, то пространство текущих приоритетов разделяют не на две, а на три части. Лучшая часть прио- ритетов отводится для процессов РВ, худшая – для остальных процессов в со- стоянии «Ядро», самая худшая – в состоянии «Задача». Приоритет процесса РВ фиксирован. Он не меняется ОС и одинаков для состояний процесса «Ядро» и «Задача». Поэтому на продолжительность выполнения процесса РВ никак не влияют не только интерактивные и вычислительные процессы, но и менее приоритетные процессы РВ.
Диспетчер инициируется одной из подпрограмм ядра, выполняющей одно из действий:
1) обработку системных вызовов, например создание процесса. Перед тем как возвращать управление в прикладную программу процесса, обработка любого системного вызова предполагает вызов диспетчера;