ГЛАВА 8
ÄÈÑÏÅÒ×ÅÐÈÇÀÖÈß ÏÐÎÖÅÑÑÎÂ È ÅÅ ÂÐÅÌÅÍÍÛÅ ÕÀÐÀÊÒÅÐÈÑÒÈÊÈ
В системе разделения времени ядро предоставляет процессу ресурсы центрального процессора (ЦП) на интервал времени, называемый квантом, по истечении которого выгружает этот процесс и запускает другой, периодически переупорядочивая очередь процессов. Алгоритм планирования процессов в системе UNIX использует время выполнения в качестве параметра. Каждый активный процесс имеет приоритет планирования; ядро переключает контекст на процесс с наивысшим приоритетом. При переходе выполняющегося процесса из режима ядра в режим задачи ядро пересчитывает его приоритет, периодически и в режиме задачи переустанавливая приоритет каждого процесса, готового к выполнению.
Информация о времени, связанном с выполнением, нужна также и некоторым из пользовательских процессов: используемая ими, например, команда time позволяет узнать, сколько времени занимает выполнение другой команды, команда date выводит текущую дату и время суток. С помощью различных системных функций процессы могут устанавливать или получать временные характеристики выполнения в режиме ядра, а также степень загруженности центрального процессора. Время в системе поддерживается с помощью аппаратных часов, которые посылают ЦП
прерывания с фиксированной, аппаратно-зависимой частотой, обычно 50-100 раз в секунду. Каждое поступление прерывания по таймеру (часам) именуется таймерным тиком. В настоящей главе рассматриваются особенности реализации процессов во времени, включая планирование процессов в системе UNIX, описание связанных со временем системных функций, а также функций, выполняемых программой обработки прерываний по таймеру.8.1 ПЛАНИРОВАНИЕ ВЫПОЛНЕНИЯ ПРОЦЕССОВ
Планировщик процессов в системе UNIX принадлежит к общему классу планировщиков, работающих по принципу "карусели с многоуровневой обратной связью". В соответствии с этим принципом ядро предоставляет процессу ресурсы ЦП на квант времени, по истечении которого выгружает этот процесс и возвращает его
в одну из нескольких очередей, регулируемых приоритетами. Прежде чем процесс завершится, ему может потребоваться множество раз пройти через цикл с обратной связью. Когда ядро выполняет переключение контекста и восстанавливает контекст процесса, процесс возобновляет выполнение с точки приостанова.8.1.1 Алгоритм
Сразу после переключения контекста ядро запускает алгоритм планирования выполнения процессов (Рисунок 8.1), выбирая на выполнение процесс с наивысшим приоритетом среди процессов, находящихся в состояниях "резервирования" и "готовности к выполнению, будучи загруженным в память". Рассматривать процессы, не загруженные в память, не имеет смысла, поскольку не будучи загружен, процесс не может выполняться. Если наивысший приоритет имеют сразу несколько процессов, ядро, используя принцип кольцевого списка (карусели), выбирает среди них тот процесс, который находится в состоянии "готовности к выполнению" дольше остальных. Если ни один из процессов не может быть выбран для выполнения, ЦП простаивает до момента получения следующего прерывания, которое произойдет не позже чем через один таймерный тик; после обработки этого прерывания ядро снова запустит алгоритм планирования.
-------------------------------------------------------------¬
¦
алгоритм schedule_process ¦¦ входная информация: отсутствует ¦
¦ выходная информация: отсутствует ¦
¦ { ¦
¦ выполнять пока (для запуска не будет выбран один из про-¦
¦ цессов) ¦
¦ { ¦
¦ для (каждого процесса в очереди готовых к выполнению)¦
¦
выбрать процесс с наивысшим приоритетом из загру-¦¦ женных в память; ¦
¦ если (ни один из процессов не может быть избран для ¦
¦ выполнения) ¦
¦ приостановить машину; ¦
¦ /* машина выходит из состояния простоя по преры- ¦
¦ /* ванию ¦
¦ */ ¦
¦ } ¦
¦ удалить выбранный процесс из очереди готовых к выполне- ¦
¦ нию; ¦
¦ переключиться на контекст выбранного процесса, возобно- ¦
¦ вить его выполнение; ¦
¦ } ¦
L------------------------------------------------------------
Рисунок 8.1. Алгоритм планирования выполнения процессов
8.1.2 Параметры диспетчеризации
В каждой записи таблицы процессов есть поле приоритета, используемое планировщиком процессов. Приоритет процесса в режиме задачи зависит от того, как этот процесс перед этим использовал ресурсы ЦП. Можно выделить два класса приоритетов процесса (Рисунок
8.2): приоритеты выполнения в режиме ядра и приоритеты выполнения в режиме задачи. Каждый класс включает в себя ряд значений, с каждым значением логически ассоциирована некоторая очередь процессов. Приоритеты выполнения в режиме задачи оцениваются для процессов, выгруженных по возвращении из режима ядра в режим задачи, приоритеты выполнения в режиме ядра имеют смысл только в контексте алгоритма sleep. Приоритеты выполнения в режиме задачи имеют верхнее пороговое значение, приоритеты выполнения в режиме ядра имеют нижнее пороговое значение. Среди приоритетов выполнения в режиме ядра далее можно выделить высокие и низкие приоритеты: процессы с низким приоритетом возобновляются по получении сигнала, а процессы с высоким приоритетом продолжают оставаться в состоянии приостанова (см. раздел 7.2.1).Пороговое значение между приоритетами выполнения в режимах ядра и задачи на Рисунке 8.2 отмечено двойной линией, проходящей между приоритетом ожидания завершения потомка (в режиме ядра) и нулевым приоритетом выполнения в режиме задачи. Приоритеты процесса подкачки, ожидания ввода-вывода, связанного с диском, ожидания буфера и индекса являются высокими, не допускающими прерывания системными приоритетами, с каждым из которых связана очередь из 1, 3, 2 и
1 процесса, соответственно, в то время как приоритеты ожидания ввода с терминала, вывода на терминал и завершения потомка являются низкими, допускающими прерывания системными приоритетами, с каждым из которых связана очередь из 4, 0 и 2 процессов, соответственно. На рисунке представлены также уровни приоритетов выполнения в режиме задачи .Приоритеты выполнения Уровни приоритетов Процессы
в режиме ядра
¦ -----------------------¬
¦ ¦ Процесс
¦ ---¬¦ ¦ подкачки ¦-+ ¦
¦ Не допускающие +----------------------+ L---
¦ ¦Ожидание ввода-вывода,¦ ---¬ ---¬ ---¬
¦ прерывания ¦ связанного с диском ¦-+ +-+ +-+ ¦
¦ +----------------------+ L--- L--- L---
¦ ¦ Ожидание ¦ ---¬ ---¬
¦ ¦ буфера ¦-+ +-+ ¦
¦ +----------------------+ L--- L---
¦ ¦ Ожидание ¦ ---¬
¦ ¦ индекса ¦-+ ¦
¦ +----------------------+ L---
¦ +----------------------+
¦ ¦ Ожидание ввода с тер-¦ ---¬ ---¬ ---¬ ---¬
¦
¦ минала ¦-+ +-+ +-+ +-+ ¦¦ Допускающие +----------------------+ L--- L--- L--- L---
¦ ¦ Ожидание вывода на ¦
¦ прерывания ¦ терминал ¦
¦ +----------------------+
¦ ¦ Ожидание завершения ¦ ---¬ ---¬
¦ ¦ потомка ¦-+ +-+ ¦
v +----------------------+ L--- L---
Пороговый приоритет +----------------------+
^
¦ Уровень задачи 0 ¦¦ +----------------------+ ---¬ ---¬ ---¬ ---¬
¦ ¦ Уровень задачи 1 ¦-+ +-+ +-+ +-+ ¦
¦ +----------------------+ L--- L--- L--- L---
¦ ¦ • ¦
¦ ¦ • ¦
¦ +----------------------+ ---¬
Приоритеты выполнения ¦ Уровень задачи n ¦-+ ¦
в режиме задачи L----------------------- L---
Рисунок 8.2. Диапазон приоритетов процесса
Ядро вычисляет приоритет процесса в следующих случаях:
В течение кванта времени таймер может послать процессу несколько прерываний; при каждом прерывании программа обработки прерываний по таймеру увеличивает значение, хранящееся в поле таблицы процессов, которое описывает продолжительность использования ресурсов центрального процессора (ИЦП). В версии V каждую секунду программа обработки прерываний переустанавливает значение этого поля, используя функцию полураспада (decay):
decay(ИЦП) = ИЦП/2;
После этого программа пересчитывает приоритет каждого процесса, находящегося в состоянии "зарезервирован, но готов к выполнению", по формуле
приоритет = (ИЦП/2) + (базовый уровень приоритета задачи)
где под "базовым уровнем приоритета задачи" понимается пороговое значение, расположенное между приоритетами выполнения в режимах ядра и задачи. Высокому приоритету планирования соответствует количественно низкое значение. Анализ функций пересчета продолжительности использования ресурсов ЦП и приоритета процесса показывает: чем ниже скорость полураспада значения ИЦП, тем медленнее приоритет процесса достигает значение базового уровня; поэтому процессы в состоянии "готовности к выполнению" имеют тенденцию занимать большое число уровней приоритетов.
Результатом ежесекундного пересчета приоритетов является перемещение процессов, находящихся в режиме задачи, от одной очереди к другой, как показано на Рисунке 8.3. По сравнению с Рисунком 8.2 один процесс перешел из очереди, соответствующей уровню 1, в очередь, соответствующую нулевому уровню. В реальной системе все
процессы, имеющие приоритеты выполнения в режиме задачи, поменяли бы свое местоположение в очередях. При этом следует указать на невозможность изменения приоритета процесса в режиме ядра, а также на невозможность пересечения пороговой черты процессами, выполняющимися в режиме задачи, до тех пор, пока они не обратятся к операционной системе и не перейдут в состояние приостанова.Ядро стремится производить пересчет приоритетов всех активных процессов ежесекундно, однако интервал между моментами пересчета может слегка варьироваться. Если прерывание по таймеру поступило тогда, когда ядро исполняло критический отрезок программы (другими словами, в то время, когда приоритет работы ЦП был повышен, но, очевидно, не настолько, чтобы воспрепятствовать прерыванию данного типа), ядро не пересчитывает приоритеты, иначе ему пришлось бы надолго задержаться на критическом отрезке. Вместо этого ядро запоминает то, что ему следует произвести пересчет приоритетов, и делает это при первом же прерывании по таймеру, поступающем после снижения приоритета работы ЦП. Периодический пересчет приоритета процессов гарантирует проведение стратегии планирования, основанной на использовании кольцевого списка процессов, выполняющихся в режиме задачи. При этом конечно же ядро
откликается на интерактивные запросы таких программ, как текстовые редакторы или программы форматного ввода: процессы, их реализующие, имеют высокий коэффициент простоя (отношение времени простоя к продолжительности использования ЦП) и поэтому естественно было бы повышать их приоритет, когда они готовы для выполнения (см. [Thompson 78], стр.1937). В других механизмах планирования квант времени, выделяемый процессу на работу с ресурсами ЦП, динамически изменяется в интервале между 0 и 1 сек. в зависимости от степени загрузки системы. При этом время реакции на запросы процессов может Приоритеты выполнения
Приоритеты выполнения Уровни приоритетов Процессы
в режиме ядра
¦ -----------------------¬
¦
¦ Процесс ¦ ---¬¦ ¦ подкачки ¦-+ ¦
¦ Не допускающие +----------------------+ L---
¦ ¦Ожидание ввода-вывода,¦ ---¬ ---¬ ---¬
¦ прерывания ¦ связанного с диском ¦-+
+-+ +-+ ¦¦ +----------------------+ L--- L--- L---
¦ ¦ Ожидание ¦ ---¬ ---¬
¦ ¦ буфера ¦-+ +-+ ¦
¦ +----------------------+ L--- L---
¦ ¦ Ожидание ¦ ---¬
¦ ¦ индекса ¦-+ ¦
¦ +----------------------+ L---
¦ +----------------------+
¦ ¦ Ожидание ввода с тер-¦ ---¬ -
--¬ ---¬ ---¬¦ ¦ минала ¦-+ +-+ +-+ +-+ ¦
¦ Допускающие +----------------------+ L--- L--- L--- L---
¦ ¦ Ожидание вывода на ¦
¦ прерывания ¦ терминал ¦
¦ +----------------------+
¦ ¦ Ожидание завершения ¦ ---¬ ---¬
¦ ¦ потомка ¦-+ +-+ ¦
v +----------------------+ L--- L---
Пороговый приоритет +--------------------
--+ ---¬^ ¦ Уровень задачи 0 ¦-+ ¦<- - - - - -¬
¦ +----------------------+ L--- •
¦ ¦ ¦ ---¬ ---¬ ---¬ -+-¬
¦ ¦ Уровень задачи 1 ¦-+ +-+ +-+ + + ¦
¦ +----------------------+ L--- L--- L--- L---
¦ ¦ • ¦
¦ ¦ • ¦
¦ +----------------------+ ---¬
Приоритеты выполнения ¦ Уровень задачи n ¦-+ ¦
в режиме задачи L----------------------- L---
Рисунок 8.2. Переход процесса из одной очереди в другую
сократиться за счет того, что на ожидание момента запуска процессам уже не нужно отводить по целой секунде; однако, с другой стороны, ядру приходится чаще прибегать к переключению контекстов.
8.1.3 Примеры диспетчеризации процессов
На Рисунке 8.4 показана динамика изменений приоритетов процессов A, B и C в версии V при следующих допущениях: все эти процессы были созданы с первоначальным приоритетом 60, который является наивысшим приоритетом выполнения в режиме задачи, прерывания по таймеру поступают 60 раз в секунду, процессы не используют вызов системных функций, в системе нет других процессов, готовых к выполнению. Ядро вычисляет полураспад показателя ИЦП по формуле:
Время Процесс A Процесс B Процесс C
¦ Приоритет ИЦП • Приоритет ИЦП • Приоритет ИЦП
0 --+-- • •
¦ 60 0 • 60 0 • 60 0
¦ 1 • •
¦ 2 • •
¦ · • •
¦ · • •
1 --+-- 60 • •
¦ 75 30 • 60 0 • 60 0
¦ • 1 •
¦ • 2 •
¦ • · •
¦ • · •
2 --+-- • 60 •
¦ 67 15 • 75 30 • 60 0
¦ • • 1
¦ • • 2
¦ • • ·
¦ • • ·
3 --+-- • • 60
¦ 63 7 • 67 15 • 75 30
¦ 8 • •
¦ 9 • •
¦ · • •
¦ · • •
4 --+-- 67 • •
¦ 76 33 • 63 7 • 67 15
¦ • 8 •
¦ • 9 •
¦ • · •
¦ • · •
5 --+-- • 67 •
¦ 68 16 • 76 33 • 63 7
¦ • •
¦ • •
Рисунок 8.4. Пример диспетчеризации процессов
ИЦП = decay(ИЦП) = ИЦП/2;
а приоритет процесса по формуле:
приоритет = (ИЦП/2) + 60;
Если предположить, что первым запускается процесс A и ему выделяется квант времени, он выполняется в течение 1 секунды: за это время таймер посылает системе 60 прерываний и столько же раз программа обработки прерываний увеличивает для процесса A значение поля, содержащего показатель ИЦП (с 0 до 60).
По прошествии секунды ядро переключает контекст и, произведя пересчет приоритетов для всех процессов, выбирает для выполнения процесс B. В течение следующей секунды программа обработки прерываний по таймеру 60 раз повышает значение поля ИЦП для процесса B, после чего ядро пересчитывает параметры диспетчеризации для всех процессов и вновь переключает контекст. Процедура повторяется многократно, сопровождаясь поочередным запуском процессов на выполнение.
Теперь рассмотрим процессы с приоритетами, приведенными на Рисунке 8.5, и предположим, что в системе имеются и другие процессы. Ядро может выгрузить процесс A, оставив его в состоянии "готовности к выполнению", после того, как он получит подряд несколько квантов времени для работы с ЦП и снизит таким образом свой приоритет выполнения в режиме задачи (Рисунок 8.5а). Через некоторое время после запуска процесса A в состояние "готовности к выполнению" может перейти процесс B, приоритет которого в тот момент окажется выше приоритета процесса A (Рисунок 8.5б). Если ядро за это время не запланировало к выполнению любой другой процесс (из тех, что не показаны на рисунке), оба процесса (A и B) при известных обстоятельствах могут на некоторое время оказаться на одном уровне приоритетности, хотя процесс B попадет на этот уровень первым из-за того, что его первоначальный приоритет был ближе (Рисунок 8.5в и 8.5г). Тем не менее, ядро запустит процесс A впереди процесса B, поскольку процесс A находился в состоянии "готовности к выполнению" более длительное время (Рисунок 8.5д) - это решающее условие, если выбор производится из процессов с одинаковыми приоритетами.
В разделе 6.4.3 уже говорилось о том, что ядро запускает процесс на выполнение после переключения контекста: прежде чем перейти в состояние приостанова или завершить свое выполнение процесс должен переключить контекст, кроме того он имеет возможность переключать контекст в момент перехода из режима ядра в режим задачи. Ядро выгружает процесс, который собирается перейти в режим задачи, если имеется готовый к выполнению процесс с более высоким приоритетом. Такая ситуация возникает, если ядро вывело из состояния приостанова процесс с приоритетом, превышающим приоритет текущего процесса, или если в результате обработки прерывания по таймеру изменились приоритеты всех готовых к выполнению процессов. В первом случае текущий процесс не может выполняться в режиме задачи, поскольку имеется процесс с более высоким приоритетом выполнения в режиме ядра. Во втором случае программа обработки прерываний по таймеру решает, что процесс использовал выделенный ему квант времени, и поскольку множество процессов при этом меняют свои приоритеты, ядро выполняет переключение контекста.
8.1.4 Управление приоритетами
Процессы могут управлять своими приоритетами с помощью системной функции nice:
nice(value);
где value - значение, в процессе пересчета прибавляемое к приоритету процесса:
приоритет = (ИЦП/константа) + (базовый приоритет) + (значение nice)
Системная функция nice увеличивает или уменьшает значение поля nice в таблице процессов на величину параметра функции, при этом только суперпользователю дозволено указывать значения, увеличивающие приоритет процесса. Кроме того, только суперпользователь может указывать значения, лежащие ниже определенного порога. Пользователи, вызывающие системную функцию nice для того, чтобы понизить приоритет во время выполнения интенсивных вычислительных работ, "удобны, приятны" (nice) для остальных пользователей сис
----------¬ ----------¬ ----------¬
^ 60 +---------+ +---------+ +----B----+
¦ +---------+ +---------+ +---------+
¦ +---------+ +----B----+ +----A----+
Более +---------+ +---------+ +---------+
высокий +---------+ +----A----+ +---------+
приори- +---------+ +---------+ +---------+
тет +----A----+ +---------+ +---------+
¦ L---------- L---------- L----------
¦ (а) (б) (в)
-----B----¬ --A-----B-¬ -----B----¬
60 +----A----+ +---------+ +---------+(процесс
+---------+ +---------+ +---------+
+---------+ +---------+ +---------+
+---------+ +---------+ +---------+
+---------+ +---------+ +---------+
+---------+ +---------+ +---------+
+---------+ +---------+ +---------+
L---------- L---------- L----------
(г) (д) (е)
Рисунок 8.5. Планирование на основе кольцевого списка и приоритеты процессов
темы, отсюда название функции. Процессы наследуют значение nice у своего родителя при выполнении системной функции fork. Функция nice действует только для выполняющихся процессов; процесс не может сбросить значение nice у другого процесса. С практической точки зрения это означает, что если администратору системы понадобилось понизить приоритеты различных процессов, требующих для своего выполнения слишком много времени, у него не будет другого способа сделать это быстро, кроме как вызвать функцию удаления (kill) для всех них сразу.
8.1.5 Планирование на основе справедливого раздела
Вышеописанный алгоритм планирования не видит никакой разницы между пользователями различных классов (категорий). Другими словами, невозможно выделить определенной совокупности процессов, например, половину сеанса работы с ЦП. Тем не менее, такая возможность имеет важное значение для организации работы в условиях вычислительного центра, где группа пользователей может пожелать купить только половину машинного времени на гарантированной основе и с гарантированным уровнем реакции. Здесь мы рассмотрим схему, именуемую "Планированием на основе справедливого раздела" (Fair Share Scheduler) и реализованную на вычислительном центре Indian Hill фирмы AT&T Bell Laboratories [Henry 84].
Принцип "планирования на основе справедливого раздела" состоит в делении совокупности пользователей на группы, являющиеся объектами ограничений, накладываемых обычным планировщиком на обработку процессов из каждой группы. При этом система выделяет время ЦП пропорционально числу групп, вне зависимости от того, сколько процессов выполняется в группе. Пусть, например, в системе имеются четыре планируемые группы, каждая из которых загружает ЦП на 25% и содержит, соответственно, 1, 2, 3 и 4 процесса, реализующих счетные задачи, которые никогда по своей воле не уступят ЦП. При условии, что в системе больше нет никаких других процессов, каждый процесс при использовании традиционного алгоритма планирования получил бы 10% времени ЦП (поскольку всего процессов 10 и между ними не делается никаких различий). При использовании алгоритма планирования на основе справедливого раздела процесс из первой группы получит в два раза больше времени ЦП по сравнению с каждым процессом из второй группы, в 3 раза больше по сравнению с каждым процессом из третьей группы и в 4 раза больше по сравнению с каждым процессом из четвертой. В этом примере всем процессам в группе выделяется равное время, поскольку продолжительность цикла, реализуемого каждым процессом, заранее не установлена.
Реализация этой схемы довольно проста, что и делает ее привлекательной. В формуле расчета приоритета процесса появляется еще один термин - "приоритет группы справедливого раздела". В пространстве процесса также появляется новое поле, описывающее продолжительность ИЦП на основе справедливого раздела, общую для всех процессов
из группы. Программа обработки прерываний по таймеру увеличивает значение этого поля для текущего процесса и ежесекундно пересчитывает значения соответствующих полей для всех процессов в системе. Новая компонента формулы вычисления приоритета процесса представляет собой нормализованное значение ИЦП для каждой группы. Чем больше процессорного времени выделяется процессам группы, тем выше значение этого показателя и ниже приоритет.В качестве примера рассмотрим две группы процессов (Рисунок 8.6), в одной из которых один процесс (A), в другой - два (B и C). Предположим, что ядро первым запустило на выполнение процесс A, в течение секунды увеличивая соответствующие этому процессу значения полей, описывающих индивидуальное и групповое ИЦП. В
результате пересчета приоритетов по истечении секунды процессы B и C будут иметь наивысшие приоритеты. Допустим, что ядро выбирает на выполнение процесс B. В течение следующей секунды значение поля ИЦП для процесса B поднимается до 60, точно такое же значение принимает поле группового ИЦП для процессов B и C. Таким образом, по истечении второй секунды процесс C получит приоритет, равный 75 (сравните с Рисунком 8.4), и ядро запустит на выполнение процесс A с приоритетом 74. Дальнейшие действия можно проследить на рисунке: ядро по очереди запускает процессы A, B, A, C, A, B и т.д.8.1.6 Работа в режиме реального времени
Режим реального времени подразумевает возможность обеспечения достаточной скорости реакции на внешние прерывания и выполнения отдельных процессов в темпе, соизмеримом с частотой возникновения вызывающих прерывания событий. Примером системы, работающей в режиме реального времени, может служить система управления жизнеобеспечением пациентов больниц, мгновенно реагирующая на изменение состояния пациента. Процессы, подобные текстовым редакторам, не считаются процессами реального времени: в них быстрая реакция на действия пользователя является желательной, но не необходимой (ничего страшного не произойдет, если пользователь, выполняющий редактирование текста, подождет ответа несколько лишних секунд, хотя у пользователя на этот счет могут быть и свои соображения). Вышеописанные алгоритмы планирования выполнения процессов предназначены специально для использования в системах разделения
времени и не годятся для условий работы в режиме реального времени, поскольку не гарантируют запуск ядром каждого процесса в течение фиксированного интервала времени, позволяющего говорить о взаимодействии вычислительной системы с процессами в темпе, соизмеримом со скоростью протекания этих процессов. Другой помехой в поддержке работы в режиме реального времени является невыгружаемость ядра; ядро не может планировать выполнение процесса реального времени в режиме задачи, если оно уже исполняет другой процесс в режиме ядра, без внесения в работу существенных изменений. В настоящее время системным программистам приходится переводить процессы реального времени в режим ядра, чтобы обеспечить достаточную скорость реакции. Правильное решение этой проблемы - дать таким процессам возможность динамического протекания (другими словами, они не должны быть встроены в ядро) с предоставлением соответствуюВремя Процесс A Процесс B Процесс C
¦ Прио- Ин- Груп-• Прио- Ин- Груп-• Прио- Ин- Груп-
¦ ритет диви- по- • ритет диви- по- • ритет диви- по-
¦ дуал. вое • дуал. вое • дуал. вое
¦ ИЦП ИЦП • ИЦП ИЦП • ИЦП ИЦП
0 --+-- • •
¦ 60 0 0 • 60 0 0 • 60 0 0
¦ 1 1 • •
¦ 2 2 • •
¦ · · • •
¦ · · • •
1 --+-- 60 60 • •
¦ 90 30 30 • 60 0 0 • 60 0 0
¦ • 1 1 • 1
¦ • 2 2 • 2
¦ • · · • ·
¦ • · · • ·
2 --+-- • 60 60 • 60
¦ 74 15 15 • 90 30 30 • 75 0 30
¦ 16 16 • •
¦ 17 17 • •
¦ · · • •
¦ · · • •
3 --+-- 75 75 • •
¦ 96 37 37 • 74 15 15 • 67 0 15
¦ • 16 • 1 16
¦ • 17 • 2 17
¦ • · • · ·
¦ • · • · ·
4 --+-- • 75 • 60 75
¦ 78 18 18 • 81 7 37 • 93 30 37
¦ 19 19 • •
¦ 20 20 • •
¦ · · • •
¦ · · • •
5 --+-- 78 78 • •
¦ 98 39 39 • 70 3 18 • 76 15 18
¦ • •
¦ • •
Рисунок 8.6. Пример планирования на основе справедливого раздела, в котором используются две группы с тремя процессами щего механизма, с помощью которого они могли бы сообщать ядру о своих нуждах, вытекающих из особенностей работы в режиме реального
времени. На сегодняшний день в стандартной системе UNIX такая возможность отсутствует.8.2 СИСТЕМНЫЕ ОПЕРАЦИИ, СВЯЗАННЫЕ СО ВРЕМЕНЕМ
Существует несколько системных функций, имеющих отношение к времени протекания процесса: stime, time, times и alarm. Первые две имеют дело с глобальным системным временем, последние две - с временем выполнения отдельных процессов.
Функция stime дает суперпользователю возможность заносить в глобальную ние глобальной переменной. Выбирается время из этой переменной с помощью функции time:
time(tloc);
где tloc - указатель на переменную, принадлежащую процессу, в которую заносится возвращаемое функцией значение. Функция возвращает это значение и из самой себя, например, команде date, которая вызывает эту функцию, чтобы определить текущее время.
Функция times возвращает суммарное время выполнения процесса и всех его потомков, прекративших существование, в режимах ядра и задачи.
-------------------------------------------------------------¬
¦ #include <sys/types.h> ¦
¦ #include <sys/times.h> ¦
¦ extern long times(); ¦
¦ ¦
¦ main() ¦
¦ { ¦
¦ int i; ¦
¦ /* tms - имя структуры данных, состоящей из 4 элемен- ¦
¦ тов */ ¦
¦ struct tms pb1,pb2; ¦
¦ long pt1,pt2; ¦
¦ ¦
¦ pt1 = times(&pb1); ¦
¦ for (i = 0; i < 10; i++) ¦
¦ if (fork() == 0) ¦
¦ child(i); ¦
¦ ¦
¦ for (i = 0; i < 10; i++) ¦
¦ wait((int*) 0); ¦
¦ pt2 = times(&pb2); ¦
¦ printf("процесс-родитель: реальное время %u ¦
¦ в режиме задачи %u в режиме ядра %u ¦
¦ потомки: в режиме задачи %u в режиме ядра %u\n",¦
¦ pt2 - pt1,pb2.tms_utime - pb1.tms_utime, ¦
¦ pb2.tms_stime - pb1.tms_stime, ¦
¦ pb2.tms_cutime - pb1.tms_cutime, ¦
¦ pb2.tms_cstime - pb1.tms_cstime); ¦
¦ } ¦
¦ ¦
¦ child(n); ¦
¦ int n; ¦
¦ { ¦
¦ int i; ¦
¦ struct tms cb1,cb2; ¦
¦ long t1,t2; ¦
¦ ¦
¦ t1 = times(&cb1); ¦
¦ for (i = 0; i < 10000; i++) ¦
¦ ; ¦
¦ t2 = times(&cb2); ¦
¦ printf("потомок %d: реальное время %u в режиме задачи %u¦
¦ в режиме ядра %u\n",n,t2 - t1, ¦
¦ cb2.tms_utime - cb1.tms_utime, ¦
¦ cb2.tms_stime - cb1.tms_stime); ¦
¦ exit(); ¦
¦ } ¦
L------------------------------------------------------------
Рисунок 8.7. Пример программы, использующей функцию times
Синтаксис вызова функции:
times(tbuffer)
struct tms *tbuffer; где tms - имя структуры, в которую помещаются возвращаемые значения и которая описывается следующим образом:
struct tms {
/* time_t - имя структуры данных, в которой хранится время */
time_t tms_utime; /* время выполнения процесса в режиме задачи */
time_t tms_stime; /* время выполнения процесса в режиме ядра */
time_t tms_cutime; /* время выполнения потомков в режиме задачи */
time_t tms_cstime; /*
время выполнения потомков в режиме ядра */};
Функция times возвращает время, прошедшее "с некоторого произвольного момента в прошлом", как правило, с момента загрузки системы.
На Рисунке 8.7 приведена программа, в которой процесс-родитель создает 10 потомков, каждый из которых 10000 раз выполняет пустой цикл. Процесс-родитель обращается к функции times перед созданием потомков и после их завершения, в свою очередь потомки вызывают эту функцию перед началом цикла и после его завершения. Кто-то по наивности может подумать, что время выполнения потомков процесса в режимах задачи и ядра равно сумме соответствующих слагаемых каждого потомка, а реальное время процесса-родителя является суммой реального времени его потомков. Однако, время выполнения потомков не включает в себя время, затраченное на исполнение системных функций fork и exit, кроме того оно может быть искажено за счет обработки прерываний и переключений контекста.
С помощью системной функции alarm пользовательские процессы могут инициировать посылку сигналов тревоги ("будильника") через кратные промежутки времени. Например, программа на Рисунке 8.8 каждую минуту проверяет время доступа к файлу и, если к файлу было произведено обращение, выводит соответствующее сообщение. Для этого в цикле, с помощью функции stat, устанавливается момент последнего обращения к файлу и, если оно имело место в течение последней минуты, выводится сообщение. Затем процесс с помощью функции signal делает распоряжение принимать сигналы тревоги, с помощью функции alarm задает интервал между сигналами в 60 секунд и с помощью функции pause приостанавливает свое выполнение до момента получения сигнала. Через 60 секунд сигнал поступает, ядро подготавливает стек задачи к вызову функции обработки сигнала wakeup, функция возвращает управление на оператор, следующий за вызовом функции pause, и процесс исполняет цикл вновь.
Все перечисленные функции работы с временем протекания процесса объединяет то, что они опираются на показания системных часов (таймера). Обрабатывая прерывания по таймеру, ядро обращается к различным таймерным счетчикам и инициирует соответствующее действие.
8.3 ТАЙМЕР
В функции программы обработки прерываний по таймеру входит:
Некоторые из функций реализуются при каждом прерывании по таймеру, другие - по прошествии нескольких таймерных тиков. Программа обработки прерываний по таймеру запускается с высоким приоритетом обращения к процессору, не допуская во время работы возникновения других внешних событий (таких как прерывания от периферийных устройств). Поэтому программа обработки прерываний по таймеру работает очень быстро, за максимально-короткое время пробегая свои критические отрезки, которые должны выполняться без прерываний со стороны других процессов. Алгоритм обработки прерываний по таймеру приведен на Рисунке 8.9.
-------------------------------------------------------------¬
¦ #include <sys/types.h> ¦
¦ #include <sys/stat.h> ¦
¦ #include <sys/signal.h> ¦
¦ ¦
¦ main(argc,argv) ¦
¦ int argc; ¦
¦ char *argv[]; ¦
¦ { ¦
¦ extern unsigned alarm(); ¦
¦ extern wakeup(); ¦
¦ struct stat statbuf; ¦
¦ time_t axtime; ¦
¦ ¦
¦ if (argc != 2) ¦
¦ { ¦
¦ printf("только 1 аргумент\n"); ¦
¦ exit(); ¦
¦ } ¦
¦ ¦
¦ axtime = (time_t) 0; ¦
¦ for (;;) ¦
¦ { ¦
¦ /* получение значения времени доступа к файлу */ ¦
¦ if (stat(argv[1],&statbuf) == -1) ¦
¦ { ¦
¦ printf("файла с именем %s нет\n",argv[1]); ¦
¦ exit(); ¦
¦ } ¦
¦ if (axtime != statbuf.st_atime) ¦
¦ { ¦
¦ printf("к файлу %s было обращение\n",argv[1]); ¦
¦ axtime = statbuf.st_atime; ¦
¦ } ¦
¦ signal(SIGALRM,wakeup); /* подготовка к приему ¦
¦ сигнала */ ¦
¦ alarm(60); ¦
¦ pause(); /* приостанов до получения сигнала */¦
¦ } ¦
¦ } ¦
¦ ¦
¦ wakeup() ¦
¦ { ¦
¦ } ¦
L------------------------------------------------------------
Рисунок 8.8. Программа, использующая системную функцию alarm
-------------------------------------------------------------¬
¦ алгоритм clock ¦
¦ входная информация: отсутствует ¦
¦ выходная информация: отсутствует ¦
¦ { ¦
¦ перезапустить часы; /* чтобы они снова посылали преры-¦
¦ вания */ ¦
¦ если (таблица ответных сигналов не пуста) ¦
¦ { ¦
¦ установить время для ответных сигналов; ¦
¦ запустить функцию callout, если время истекло; ¦
¦ } ¦
¦ если (профилируется выполнение в режиме ядра) ¦
¦ запомнить значение счетчика команд в момент прерыва-¦
¦ ния; ¦
¦ если (профилируется выполнение в режиме задачи) ¦
¦ запомнить значение счетчика команд в момент прерыва-¦
¦ ния; ¦
¦ собрать статистику о самой системе; ¦
¦ собрать статистику о протекающих в системе процессах; ¦
¦ выверить значение продолжительности ИЦП процессом; ¦
¦ если (прошла 1 секунда или более и исполняется отрезок,¦
¦ не являющийся критическим) ¦
¦ { ¦
¦ для (всех процессов в системе) ¦
¦ { ¦
¦ установить "будильник", если он активен; ¦
¦ выверить значение продолжительности ИЦП; ¦
¦ если (процесс будет исполняться в режиме задачи)¦
¦ выверить приоритет процесса; ¦
¦ } ¦
¦ возобновить в случае необходимости выполнение про- ¦
¦ цесса подкачки; ¦
¦ } ¦
¦ } ¦
L------------------------------------------------------------
Рисунок 8.9. Алгоритм обработки прерываний по таймеру
8.3.1 Перезапуск часов
В большинстве машин после получения прерывания по таймеру требуется программными средствами произвести перезапуск часов, чтобы они по прошествии интервала времени могли вновь прерывать работу процессора. Такие средства являются машинно-зависимыми и мы их рассматривать не будем.
8.3.2 Внутренние системные тайм-ауты
Некоторым из процедур ядра, в частности драйверам устройств и сетевым протоколам, требуется вызов функций ядра в режиме реального времени. Например, процесс может перевести терминал в режим ввода без обработки символов, при котором ядро выполняет запросы пользователя на чтение с терминала через фиксированные промежутки времени, не дожидаясь, когда пользователь нажмет клавишу "возврата каретки" (см. раздел 10.3.3). Ядро хранит всю необходимую информацию в таблице ответных сигналов (Рисунок 8.9), в том числе имя функции, запускаемой по истечении интервала времени, параметр, передаваемый этой функции, а также продолжительность интервала (в таймерных тиках) до момента запуска функции.
Пользователь не имеет возможности напрямую контролировать записи в таблице ответных сигналов; для работы с ними существуют различные системные алгоритмы. Ядро сортирует записи в этой таблице в соответствии с величиной интервала до момента запуска функций. В связи с этим для каждой записи таблицы запоминается не общая продолжительность интервала, а только промежуток времени между моментами запуска данной и предыдущей функций. Общая продолжительность интервала до момента запуска функции складывается из промежутков времени между моментами запуска всех функций, начиная с первой и вплоть до текущей.
Функция Время до запуска Функция Время до запуска
-----------------------------¬ -----------------------------¬
¦ a() -2 ¦ ¦ a() -2 ¦
+----------------------------+ +----------------------------+
¦ b() 3 ¦ ¦ b() 3 ¦
+----------------------------+ +----------------------------+
¦ c() 10 ¦ ¦ f() 2 ¦
L----------------------------- +----------------------------+
¦ c() 8 ¦
L-----------------------------
До После
Рисунок 8.10. Включение новой записи в таблицу ответных сигналов
На Рисунке 8.10 приведен пример добавления новой записи в таблицу ответных сигналов. (К отрицательному значению поля "время до запуска" для функции a мы вернемся несколько позже). Создавая новую запись, ядро отводит для нее надлежащее место и соответствующим образом переустанавливает значение поля "время до запуска" в записи, следующей за добавляемой. Судя по рисунку, ядро собирается
запустить функцию f через 5 таймерных тиков: оно отводит место для нее в таблице сразу после функции b и заносит в поле "время до запуска" значение, равное 2 (тогда сумма значений этих полей для функций b и f составит 5), и меняет "время до запуска" функции c на 8 (при этом функция c все равно запускается через 13 таймерных тиков). В одних версиях ядро пользуется связным списком указателей на записи таблицы ответных сигналов, в других меняет положение записей при корректировке таблицы. Последний способ требует значительно меньших издержек при условии, что ядро не будет слишком часто обращаться к таблице.При каждом поступлении прерывания по таймеру программа обработки прерывания проверяет наличие записей в таблице ответных сигналов и в случае их обнаружения уменьшает значение поля "время до запуска" в первой записи. Способ хранения продолжительности интервалов до момента запуска каждой функции, выбранный ядром, позволяет, уменьшив значение поля "время до запуска" в одной только первой записи, соответственно уменьшить продолжительность интервала до момента запуска функций, описанных во всех записях таблицы. Если в указанном поле первой записи хранится отрицательное или нулевое значение, соответствующую функцию следует запустить. Программа обработки прерываний по таймеру не запускает функцию немедленно, таким образом она не блокирует возникновение последующих прерываний данного типа. Текущий приоритет работы процессора вроде бы не позволяет таким прерываниям вмешиваться в выполнение процесса, однако ядро не имеет представления о том, сколько времени потребуется на исполнение функции. Казалось бы, если функция выполняется дольше одного таймерного тика, все последующие прерывания должны быть заблокированы. Вместо этого, программа обработки прерываний в типичной ситуации оформляет вызов функции как "программное прерывание", порождаемое выполнением отдельной машинной команды. Поскольку среди всех прерываний программные прерывания имеют самый низкий приоритет, они блокируются, пока ядро не закончит обработку всех остальных прерываний. С момента завершения подготовки к запуску функции и до момента возникновения вызываемого запуском функции программного прерывания может произойти множество прерываний, в том числе и программных, в таком
случае в поле "время до запуска", принадлежащее первой записи таблицы, будет занесено отрицательное значение. Когда же наконец программное прерывание происходит, программа обработки прерываний убирает из таблицы все записи с истекшими значениями полей "время до запуска" и вызывает соответствующую функцию.Поскольку в указанном поле в начальных записях таблицы может храниться отрицательное или нулевое значение, программа обработки прерываний должна найти в таблице первую запись с положительным значением поля и уменьшить его. Пусть, например, функции a соответствует "время до запуска", равное -2 (Рисунок 8.10), то есть перед тем, как функция a была выбрана на выполнение, система получила 2 прерывания по таймеру. При условии, что функция b 2 тика
назад уже была в таблице, ядро пропускает запись, соответствующую функции a, и уменьшает значение поля "время до запуска" для функции b.8.3.3 Построение профиля
Построение профиля ядра включает в себя измерение продолжительности выполнения системы в режиме задачи против режима ядра, а также продолжительности выполнения отдельных процедур ядра. Драйвер параметров ядра следит за относительной эффективностью работы модулей ядра, замеряя параметры работы системы в момент прерывания по таймеру. Драйвер
параметров имеет список адресов ядра (главным образом, функций ядра); эти адреса ранее были загружены процессом путем обращения к драйверу параметров. Если построение профиля ядра возможно, программа обработки прерывания по таймеру запускает подпрограмму обработки прерываний, принадлежащую драйверу параметров, которая определяет, в каком из режимов - ядра или задачи - работал процессор в момент прерывания. Если процессор работал в режиме задачи, система построения профиля увеличивает значение параметра, описывающего продолжительность выполнения в режиме задачи, если же процессор работал в режиме ядра, система увеличивает значение внутреннего счетчика, соответствующего счетчику команд. Пользовательские процессы могут обращаться к драйверу параметров, чтобы получить значения параметров ядра и различную статистическую информацию.---------------------------------¬
¦ Алгоритм Адрес Счетчик ¦
¦ ¦
¦ bread 100 5 ¦
¦ breada 150 0 ¦
¦ bwrite 200 0 ¦
¦ brelse 300 2 ¦
¦ getblk 400 1 ¦
¦ user - 2 ¦
L--------------------------------
Рисунок 8.11. Адреса некоторых алгоритмов ядра
На Рисунке 8.11 приведены гипотетические адреса некоторых процедур ядра. Пусть в результате 10 измерений, проведенных в моменты поступления прерываний по таймеру, были получены следующие значения счетчика команд: 110, 330, 145, адрес в пространстве задачи, 125, 440, 130, 320, адрес в пространстве задачи и 104. Ядро сохранит при этом те значения, которые показаны на рисунке. Анализ этих значений показывает, что система провела 20% своего времени в режиме задачи (user) и 50% времени потратила на выполнение алгоритма bread в режиме ядра.
Если измерение параметров ядра выполняется в течение длительного периода времени, результаты измерений приближаются к истинной картине использования системных ресурсов. Тем не менее, описываемый механизм не учитывает время, потраченное на обработку прерываний по таймеру и выполнение процедур, блокирующих поступление прерываний данного типа, поскольку таймер не может прерывать выполнение критических отрезков программ и, таким образом, не может в это время обращаться к подпрограмме обработки прерываний драйвера параметров. В этом недостаток описываемого механизма, ибо критические отрезки программ ядра чаще всего наиболее важны для измерений. Следовательно, результаты измерения параметров ядра содержат определенную долю приблизительности. Уайнбергер [Weinberger 84] описал механизм включения счетчиков в главных блоках программы, таких как "if-then" и "else", с целью повышения точности измерения частоты их выполнения. Однако, данный механизм увеличивает время счета программ на 50-200%, поэтому его использование в качестве постоянного механизма измерения параметров ядра нельзя признать рациональным.
На пользовательском уровне для измерения параметров выполнения процессов можно использовать системную функцию profil:
profil(buff,bufsize,offset,scale);
где buff - адрес массива в пространстве задачи, bufsize - размер массива, offset - виртуальный адрес подпрограммы пользователя (обычно, первой по счету), scale - способ отображения виртуальных адресов задачи на адрес массива. Ядро трактует аргумент "scale" как двоичную дробь с фиксированной точкой слева. Так, например, значение аргумента в шестнадцатиричной системе счисления, равное Oxffff, соответствует однозначному отображению счетчика команд на адреса массива, значение, равное Ox7fff, соответствует размещению в одном слове массива buff двух адресов программы, Ox3fff - четырех адресов программы и т.д. Ядро хранит параметры, передаваемые при вызове системной функции, в пространстве процесса. Если таймер прерывает выполнение процесса тогда, когда он находится в режиме задачи, программа обработки прерываний проверяет значение счетчика команд в момент прерывания, сравнивает его со значением аргумента offset и увеличивает содержимое ячейки памяти, адрес которой является функцией от bufsize и scale.
Рассмотрим в качестве примера программу, приведенную на Рисунке 8.12, измеряющую продолжительность выполнения функций f и g. Сначала процесс, используя системную функцию signal, делает указание при получении сигнала о прерывании вызывать функцию theend, затем он вычисляет диапазон адресов программы, в пределах которых будет производиться измерение продолжительности (начиная с адреса функции main и кончая адресом функции theend), и, наконец, запускает функцию profil, сообщая ядру о том, что он собирается начать измерение. В результате выполнения программы в течение 10 секунд на несильно загруженной машине AT&T 3B20 были получены данные, представленные на Рисунке 8.13. Адрес функции f превышает адрес начала профилирования на 204 байта; поскольку текст функции f имеет размер 12 байт, а размер целого числа в машине AT&T 3B20 равен 4 байтам, адреса функции f отображаются на элементы массива buf с номерами 51, 52 и
53. По такому же принципу адреса функции g отображаются на элементы buf c номерами 54, 55 и 56. Элементы buf с номерами 46, 48 и 49 предназначены для адресов, принадлежащих циклу функции main. В обычном случае диапазон адресов, в пределах которого выполняется измерение параметров, определяется в результате обращения к таблице идентификаторов для данной программы, где указываются адреса программных секций. Пользователи сторонятся функции profil из-за того, что она кажется им слишком сложной; вместо нее они используют при компиляции программ на языке Си параметр, сообщающий компилятору о необходимости сгенерировать код, следящий за ходом выполнения процессов.-------------------------------------------------------------¬
¦ #include <signal.h> ¦
¦ int buffer[4096]; ¦
¦ main() ¦
¦ { ¦
¦ int offset,endof,scale,eff,gee,text; ¦
¦ extern theend(),f(),g(); ¦
¦ signal(SIGINT,theend); ¦
¦ endof = (int) theend; ¦
¦ offset = (int) main; ¦
¦ /* вычисляется количество слов в тексте программы */ ¦
¦ text = (endof - offset + sizeof(int) - 1)/sizeof(int); ¦
¦ scale = Oxffff; ¦
¦ printf ¦
¦ ("смещение до начала %d до конца %d длина текста %d\n",¦
¦ offset,endof,text); ¦
¦ eff = (int) f; ¦
¦ gee = (int) g; ¦
¦ printf("f %d g %d fdiff %d gdiff %d\n",eff,gee, ¦
¦ eff-offset,gee-offset); ¦
¦ profil(buffer,sizeof(int)*text,offset,scale); ¦
¦ for (;;) ¦
¦ { ¦
¦ f(); ¦
¦ g(); ¦
¦ } ¦
¦ } ¦
¦ f() ¦
¦ { ¦
¦ } ¦
¦ g() ¦
¦ { ¦
¦ } ¦
¦ theend() ¦
¦ { ¦
¦ int i; ¦
¦ for (i = 0; i < 4096; i++) ¦
¦ if (buffer[i]) ¦
¦ printf("buf[%d] = %d\n",i,buffer[i]); ¦
¦ exit(); ¦
¦ } ¦
L------------------------------------------------------------
Рисунок 8.12. Программа, использующая системную функцию profil
-------------------------------------------------------¬
¦ смещение до начала 212 до конца 440 длина текста 57 ¦
¦ f 416 g 428 fdiff 204 gdiff 216 ¦
¦ buf[46] = 50 ¦
¦ buf[48] = 8585216 ¦
¦ buf[49] = 151 ¦
¦ buf[51] = 12189799 ¦
¦ buf[53] = 65 ¦
¦ buf[54] = 10682455 ¦
¦ buf[56] = 67 ¦
L------------------------------------------------------
Рисунок 8.13. Пример результатов выполнения программы, использующей системную функцию profil
8.3.4 Учет и статистика
В момент поступления прерывания по таймеру система может выполняться в режиме ядра или задачи, а также находиться в состоянии простоя (бездействия). Состояние простоя означает, что все процессы приостановлены в ожидании наступления события. Для каждого состояния процессора ядро имеет внутренние счетчики, устанавливаемые при каждом прерывании по таймеру. Позже пользовательские процессы могут проанализировать накопленную ядром статистическую информацию.
В пространстве каждого процесса имеются два поля для записи продолжительности времени, проведенного процессом в режиме ядра и задачи. В ходе обработки прерываний по таймеру ядро корректирует значение поля, соответствующего текущему режиму выполнения процесса. Процессы-родители собирают статистику о своих потомках при выполнении функции wait, беря за основу информацию, поступающую от завершающих свое выполнение потомков.
В пространстве каждого процесса имеется также одно поле для ведения учета использования памяти. В ходе обработки прерывания по таймеру ядро вычисляет общий объем памяти, занимаемый текущим процессом, исходя из размера частных областей процесса и его долевого участия в использовании разделяемых областей памяти. Если, например, процесс использует области данных и стека размером 25 и 40 Кбайт, соответственно, и разделяет с четырьмя другими процессами одну область команд размером 50 Кбайт, ядро назначает процессу 75 Кбайт памяти (50К/5 + 25К + 40К). В системе с замещением страниц ядро вычисляет объем используемой памяти путем подсчета числа используемых в каждой области страниц. Таким образом, если прерываемый процесс имеет две частные области и еще одну область разделяет с другим процессом, ядро назначает ему столько страниц памяти, сколько содержится в этих частных областях, плюс половину страниц, принадлежащих разделяемой области. Вся указанная информация отражается в учетной записи при завершении процесса и может быть использована для расчетов с заказчиками машинного времени.
8.3.5 Поддержание времени в системе
Ядро увеличивает показание системных часов при каждом прерывании по таймеру, измеряя время в таймерных тиках от момента загрузки системы. Это значение возвращается процессу через системную функцию time и дает возможность определять общее время выполнения процесса. Время первоначального запуска процесса сохраняется ядром в адресном пространстве процесса при исполнении системной функции for
k, в момент завершения процесса это значение вычитается из текущего времени, результат вычитания и составляет реальное время выполнения процесса. В другой переменной таймера, устанавливаемой с помощью системной функции stime и корректируемой раз в секунду, хранится календарное время.8.4 ВЫВОДЫ
В настоящей главе был описан основной алгоритм диспетчеризации процессов в системе UNIX. С каждым процессом в системе связывается приоритет планирования, значение которого появляется в момент перехода процесса в состояние приостанова и периодически корректируется программой обработки прерываний по таймеру. Приоритет, присваиваемый процессу в момент перехода в состояние приостанова, имеет значение, зависящее от того, какой из алгоритмов ядра исполнялся процессом в этот момент. Значение приоритета, присваиваемое процессу во время выполнения программой обработки прерываний по таймеру (или в тот момент, когда процесс возвращается из режима ядра в режим задачи), зависит от того, сколько времени процесс занимал ЦП: процесс получает низкий приоритет, если он обращался к ЦП, и высокий - в противном случае. Системная функ ция nice дает процессу возможность влиять на собственный приоритет путем добавления параметра, участвующего в пересчете приоритета.
В главе были также рассмотрены системные функции, связанные с временем выполнения системы и протекающих в ней процессов: с установкой и получением системного времени, получением времени выполнения процессов и установкой сигналов "будильника". Кроме того, описаны функции программы обработки прерываний по таймеру, которая следит за временем в системе, управляет таблицей ответных сигналов, собирает статистику, а также подготавливает запуск планировщика процессов, программы подкачки и "сборщика" страниц. Программа подкачки и "сборщик" страниц являются объектами рассмотрения в следующей главе.
8.5 УПРАЖНЕНИЯ
1
. При переводе процессов в состояние приостанова ядро назначает процессу, ожидающему снятия блокировки с индекса, более высокий приоритет по сравнению с процессом, ожидающим освобождения буфера. Точно так же, процессы, ожидающие ввода с терминала, получают более высокий приоритет по сравнению с процессами, ожидающими возможности производить вывод на терминал. Объясните причины такого поведения ядра.*2
. В алгоритме обработки прерываний по таймеру предусмотрен пересчет приоритетов и перезапуск процессов на выполнение с интервалом в 1 секунду. Придумайте алгоритм, в котором интервал перезапуска динамически меняется в зависимости от степени загрузки системы. Перевесит ли выигрыш усилия по усложнению алгоритма ?3
. В шестой редакции системы UNIX для расчета продолжительности ИЦП текущим процессом используется следующая формула:decay(ИЦП) = max (пороговый приоритет, ИЦП-10);
а в седьмой редакции:
decay(ИЦП) = .8 * ИЦП;
Приоритет процесса в обеих редакциях вычисляется по формуле:
приоритет = ИЦП/16 + (базовый уровень приоритета);
Повторите пример на Рисунке 8.4, используя приведенные формулы.
4
. Проделайте еще раз пример на Рисунке 8.4 с семью процессами вместо трех, а затем измените частоту прерываний по таймеру с 60 на 100 прерываний в секунду. Прокомментируйте результат.5
. Разработайте схему, в которой система накладывает ограничение на продолжительность выполнения процесса, при превышении которого процесс завершается. Каким образом пользователь должен отличать такой процесс от процессов, для которых не должны существовать подобные ограничения ? Каким образом должна работать схема, если единственным условием является ее запуск из shell'а ?6
. Когда процесс выполняет системную функцию wait и обнаруживает прекратившего существование потомка, ядро приплюсовывает к его ИЦП значение поля ИЦП потомка. Чем объясняется такое "наказание" процесса-родителя ?7
. Команда nice запускает последующую команду с передачей ей указанного значения, например:nice 6 nroff -mm big_memo > output
Напишите на языке Си программу, реализующую команду nice.
8
. Проследите на примере Рисунка 8.4, каким образом будет осуществляться диспетчеризация процессов в том случае, если значение, передаваемое функцией nice для процесса A, равно 5 или -5.9
. Проведите эксперимент с системной функцией renice x y, где x - код идентификации процесса (активного), а y - новое значение nice для указанного процесса.10
. Вернемся к примеру, приведенному на Рисунке 8.6. Предположим, что группе, в которую входит процесс A, выделяется 33% процессорного времени, а группе, в которую входит процесс B, - 66% процессорного времени. В какой последовательности будут исполняться процессы ? Обобщите алгоритм вычисления приоритетов таким образом, чтобы значение группового ИЦП усреднялось.11
. Выполните команду date. Команда без аргументов выводит текущую дату: указав аргумент, например:date mmddhhmmyy
(супер)пользователь может установить текущую дату в системе (соответственно, месяц, число, часы, минуты и год). Так,
date 0911205084
устанавливает в качестве текущего времени 11 сентября 1984 года 8:50 пополудни.
12
. В программах можно использовать функцию пользовательского уровня sleep:sleep(seconds);
с помощью которой выполнение программы приостанавливается на указанное число секунд. Разработайте ее алгоритм, в котором используйте системные функции alarm и pause. Что произойдет, если процесс вызовет функцию alarm раньше функции sleep ? Рассмотрите две возможности:
1) действие ранее вызванной функции alarm истекает в то время, когда процесс находится в состоянии приостанова,
2) действие ранее вызванной функции alarm истекает после завершения функции sleep.
*13
. Обратимся еще раз к последней проблеме. Ядро может выполнить переключение контекста во время исполнения функции sleep между вызовами alarm и pause. Тогда есть опасность, что процесс получит сигнал alarm до того, как вызовет функцию pause. Что произойдет в этом случае ? Как вовремя распознать эту ситуацию ?