В windows реализован следующий алгоритм планирования потоков

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

Лекция № 7. Алгоритмы планирования потоков.

1. Вытесняющие алгоритмы планирования.

2. Планирование в системах реального времени.

Алгоритмы планирования, основанные на квантовании

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

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

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

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

Поток, который исчерпал свой квант, переводится в состояние готовности и ожи­дает, когда ему будет предоставлен новый квант процессорного времени, а на вы­полнение в соответствии с определенным правилом выбирается новый поток из очереди готовых. Граф состояний потока, изображенный на рис. 4.6, соответству­ет алгоритму планирования, основанному на квантовании.

Рис. 4.6. Граф состояний потока в системе с квантованием

Кванты, выделяемые потокам, могут быть одинаковыми для всех потоков или различными. Рассмотрим, например, случай, когда всем потокам предоставляют­ся кванты одинаковой длины q (рис. 4.7). Если в системе имеется п потоков, то время, которое поток проводит в ожидании следующего кванта, можно грубо оце­нить как q(n-l). Чем больше потоков в системе, тем больше время ожидания, тем меньше возможности вести одновременную интерактивную работу нескольким пользователям. Но если величина кванта выбрана очень небольшой, то значение произведения q(n-l) все равно будет достаточно мало для того, чтобы пользова­тель не ощущал дискомфорта от присутствия в системе других пользователей. Типичное значение кванта в системах разделения времени составляет десятки миллисекунд.

Рис. 4.7. Иллюстрация расчета времени ожидания в очереди

Если квант короткий, то суммарное время, которое проводит поток в ожидании процессора, прямо пропорционально времени, требуемому для его выполнения (то есть времени, которое потребовалось бы для выполнения этого потока при монопольном использовании вычислительной системы). Действительно, поскольку время ожидания между двумя циклами выполнения равно q(n-l), а количество циклов B/q, где В — требуемое время выполнения, то W=B(n-l). За­метим, что эти соотношения представляют собой весьма грубые оценки, осно­ванные на предположении, что В значительно превышает q. При этом не учиты­вается, что потоки могут использовать кванты не полностью, что часть времени они могут тратить на ввод-вывод, что количество потоков в системе может ди­намически меняться и т. д.

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

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

Потоки получают для выполнения квант времени, но некоторые из них ис­пользуют его не полностью, например из-за необходимости выполнить ввод или вывод данных. В результате возникает ситуация, когда потоки с интен­сивными обращениями к вводу-выводу используют только небольшую часть выделенного им процессорного времени. Алгоритм планирования может ис­править эту «несправедливость». В качестве компенсации за неиспользован­ные полностью кванты потоки получают привилегии при последующем об­служивании. Для этого планировщик создает две очереди готовых потоков (рис. 4.8). Очередь 1 образована потоками, которые пришли в состояние го­товности в результате исчерпания кванта времени, а очередь 2 — потоками, у которых завершилась операция ввода-вывода. При выборе потока для выпол­нения прежде всего просматривается вторая очередь, и только если она пуста, квант выделяется потоку из первой очереди.

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

Рис. 4.8. Квантование с предпочтением потоков, интенсивно обращающихся к вводу-выводу

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

Алгоритмы планирования, основанные на приоритетах

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

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

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

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

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

В качестве примера рассмотрим схему назначения приоритетов потокам, приня­тую в операционной системе Windows NT (рис. 4.9). В системе определено 32 уровня приоритетов и два класса потоков — потоки реального времени и по­токи с переменными приоритетами. Диапазон от 1 до 15 включительно отведен для потоков с переменными приоритетами, а от 16 до 31 — для более критичных ко времени потоков реального времени (приоритет 0 зарезервирован для систем­ных целей).

Рис. 4.9. Схема назначения приоритетов в Windows NT

При создании процесса он в зависимости от класса получает по умолчанию ба­зовый приоритет в верхней или нижней части диапазона. Базовый приоритет процесса в дальнейшем может быть повышен или понижен операционной систе­мой. Первоначально поток получает значение базового приоритета из диапазона базового приоритета процесса, в котором он был создан. Пусть, например, значе­ние базового приоритета некоторого процесса равно К. Тогда все потоки данного процесса получат базовые приоритеты из диапазона [К-2, К+2]. Отсюда видно, что, изменяя базовый приоритет процесса, ОС может влиять на базовые приори­теты его потоков.

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

Существуют две разновидности приоритетного планирования: обслуживание с относительными приоритетами и обслуживание с абсолютными приоритетами.

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

В системах с абсолютными приоритетами выполнение активного потока преры­вается кроме указанных выше причин, еще при одном условии: если в очереди готовых потоков появился поток, приоритет которого выше приоритета активно­го потока. В этом случае прерванный поток переходит в состояние готовности (рис. 4.10, б).

В системах, в которых планирование осуществляется на основе относительных приоритетов, минимизируются затраты на переключения процессора с одной ра­боты на другую. С другой стороны, здесь могут возникать ситуации, когда одна задача занимает процессор долгое время. Ясно, что для систем разделения вре­мени и реального времени такая дисциплина обслуживания не подходит: интер­активное приложение может ждать своей очереди часами, пока вычислительной задаче не потребуется ввод-вывод. А вот в системах пакетной обработки (в том числе известной ОС OS/360) относительные приоритеты используются широко.

Рис. 4.10. Графы состояний потоков в системах с относительными и абсолютными приоритетами

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

Смешанные алгоритмы планирования

Во многих операционных системах алгоритмы планирования построены с ис­пользованием как концепции квантования, так и приоритетов. Например, в ос­нове планирования лежит квантование, но величина кванта и/или порядок вы­бора потока из очереди готовых определяется приоритетами потоков. Именно так реализовано планирование в системе Windows NT, в которой квантование сочетается с динамическими абсолютными приоритетами. На выполнение выби­рается готовый поток с наивысшим приоритетом. Ему выделяется квант време­ни. Если во время выполнения в очереди готовых появляется поток с более вы­соким приоритетом, то он вытесняет выполняемый поток. Вытесненный поток возвращается в очередь готовых, причем он становится впереди всех остальных потоков имеющих такой же приоритет.

Рассмотрим более подробно алгоритм планирования в операционной системе UNIX System V Release 4. В этой ОС понятие «поток» отсутствует, и планирова­ние осуществляется на уровне процессов. В системе UNIX System V Release 4 реализована вытесняющая многозадачность, основанная на использовании при­оритетов и квантования.

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

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

Процессы разделения времени были до появления UNIX System V Release 4 един­ственным классом процессов, и по умолчанию UNIX System V Release 4 назнача­ет новому процессу именно этот класс. Состав класса процессов разделения вре­мени наиболее неопределенный и часто меняющийся в отличие от системных процессов и процессов реального времени. Для справедливого распределения времени процессора между процессами в этом классе используется стратегия ди­намических приоритетов. Величина приоритета, назначаемого процессам разде­ления времени, вычисляется пропорционально значениям двух составляющих: пользовательской части и системной части. Пользовательская часть приоритета может быть изменена администратором и владельцем процесса, но в последнем случае только в сторону его снижения.

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

Другой пример относится к операционной системе OS/2. Планирование здесь основано на использовании квантования и абсолютных динамических приори­тетов. На множестве потоков определены приоритетные классы — критический (time critical), серверный (server), стандартный (regular) и остаточный (idle), в каждом из которых имеется 32 приоритетных уровня. Потоки критического класса имеют наивысший приоритет. В этот класс могут быть отнесены, напри­мер, системные потоки, выполняющие задачи управления сетью. Следующий по приоритетности класс предназначен, как это следует из его названия, для потоков, обслуживающих серверные приложения. К стандартному классу могут быть отнесены потоки обычных приложений. Потоки, входящие в остаточный класс, имеют самый низкий приоритет. К этому классу относится, например, по­ток, выводящий на экран заставку, когда в системе не выполняется никакой ра­боты.

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

Приоритеты могут изменяться планировщиком в следующих случаях:

* Если поток находится в ожидании процессорного времени дольше, чем это задано системной переменной MAXWAIT, то его уровень приоритета будет авто­матически увеличен операционной системой. При этом результирующее зна­чение приоритета не должно превышать нижней границы диапазона приори­тетов критического класса.

* Если поток ушел на выполнение операции ввода-вывода, то после ее заверше­ния он получит наивысшее значение приоритета своего класса.

* Приоритет потока автоматически повышается, когда он поступает на выпол­нение.

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

Благодаря такому алгоритму планирования в OS/2 ни один поток не будет «за­быт» системой и получит достаточно процессорного времени.

2. Планирование в системах реального времени

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

При разработке алгоритмов планирования для систем реального времени необ­ходимо учитывать, какие последствия в этих системах возникают при несоблю­дении временных ограничений. Если эти последствия катастрофичны, как, на­пример, для системы управления полетами или атомной электростанцией, то операционная система реального времени, на основе которой строится управле­ние объектом, называется жесткой (hard). Если же последствия нарушения вре­менных ограничений не столь серьезны, то есть сравнимы с той пользой, кото­рую приносит система управления объектом, то система является мягкой (soft) системой реального времени. Примером мягкой системы реального времени яв­ляется система резервирования билетов. Если из-за временных нарушений опе­ратору не удается зарезервировать билет, это не очень страшно — можно просто послать запрос на резервирование заново.

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

В мягких системах реального времени предполагается, что заданные временные ограничения могут иногда нарушаться, поэтому здесь обычно применяются ме­нее затратные способы планирования.

При рассмотрении в качестве примеров подсистем планирования потоков/процессов в операционных системах Windows NT, OS/2 и UNIX System V Release 4 было отмечено, что во всех этих системах имеется приоритетный класс реального времени. Для пото­ков/процессов, относящихся к этому классу, каждая из вышеназванных систем не гаран­тирует выполнение заданных временных ограничений, а лишь обеспечивает предпочтение в скорости обслуживания. Следовательно, эти ОС могут быть основой для построения мягких систем реального времени, но непригодны для жестких систем реального времени.

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

Предположим, что имеется периодический набор задач <Тi>с периодами рi, пре­дельными сроками di и требованиями ко времени выполнения ci. Для проверки возможности существования расписания достаточно проанализировать расписа­ние на периоде времени, равном по крайней мере наименьшему общему множи­телю периодов этих задач. Необходимым критерием существования расписания для набора периодических задач является следующее достаточно очевидное ут­верждение: сумма коэффициентов использования mi = ci/pi, должна быть меньше или равна k, где k — количество доступных процессоров, то есть:

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

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

* Разделение проблемы планирования на две части, чтобы одна часть выполня­лась заранее, перед запуском системы, а вторая, более простая часть — во вре­мя работы системы. Предварительный анализ набора задач с взаимными исключениями может состоять, например, в выявлении так называемых за­прещенных областей времени, в течение которых нельзя назначать выполне­ние задач, содержащих критические секции.

* Введение ограничивающих предположений о поведении набора задач.

При таком подходе планирование приближается к статическому.

Возвращаясь к планированию независимых задач, рассмотрим классический ал­горитм для жестких систем реального времени с одним процессором, разрабо­танный в 1973 году Лью (Liu) и Лейландом (Layland). Алгоритм является дина­мическим, то есть он использует вытесняющую многозадачность и основан на относительных статических (неизменяемых в течение жизни задачи) приори­тетах.

Алгоритм основан на следующих предположениях:

* Запросы на выполнение всех задач набора, имеющих жесткие ограничения на время реакции, являются периодическими.

* Все задачи независимы. Между любой парой задач не существует никаких ог­раничений на предшествование или на взаимное исключение.

* Срок выполнения каждой задачи равен ее периоду pi.

* Максимальное время выполнения каждой задачи ci известно и постоянно.

* Время переключения контекста можно игнорировать.

* Максимальный суммарный коэффициент загрузки процессора , при су­ществовании n задач не превосходит n(21/n — 1). Эта величина при стремле­нии n к бесконечности приблизительно равна ln2, то есть 0,7.

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

Если же периоды повторения задач кратны периоду выполнения самой короткой задачи, то требование к максимальному коэффициенту загрузки процессора смяг­чается — он может доходить до 1.

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

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

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

* Активная задача выполнила системный вызов, связанный с запросом на ввод-вывод или на доступ к ресурсу, который в настоящий момент занят (напри­мер, файл данных). Планировщик переводит задачу в состояние ожидания и выполняет перепланирование.

* Активная задача выполнила системный вызов, связанный с освобождением ресурса. Планировщик проверяет, не ожидает ли этот ресурс какая-либо зада­ча. Если да, то эта задача переводится из состояния ожидания в состояние го­товности. При этом, возможно, что задача, которая получила ресурс, имеет более высокий приоритет, чем текущая активная задача. После перепланиро­вания более приоритетная задача получает доступ к процессору, вытесняя те­кущую задачу.

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

* Внутреннее прерывание сигнализирует об ошибке, которая произошла в ре­зультате выполнения активной задачи. Планировщик снимает задачу и вы­полняет перепланирование.

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

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

Первые четыре цикла работы планировщика, приведенные на рисунке, были ини­циированы прерываниями от таймера по истечении квантов времени (эти собы­тия обозначены на рисунке как Т).

Следующая передача управления планировщику была осуществлена в результате выполнения потоком 3 системного запроса на ввод-вывод (событие I/O). Плани­ровщик перевел этот поток в состояние ожидания, а затем переключил процес­сор на поток 2. Поток 2 полностью использовал свой квант, произошло прерыва­ние от таймера, и планировщик активизировал поток 1.

При выполнении потока 1 произошло событие R — системный вызов, в резуль­тате которого освободился некоторый ресурс (например, был закрыт файл). Это событие вызвало перепланировку потоков. Планировщик просмотрел очередь ожидающих потоков и обнаружил, что поток 4 ждет освобождения данного ре­сурса. Этот поток был переведен в состояние готовности, но поскольку приори­тет выполняющегося в данный момент потока 1 выше приоритета потока 4, пла­нировщик вернул процессор потоку 1.

Рис. 4.11. Моменты перепланировки потоков

В следующем цикле работы планировщик активизировал поток 4, а затем, после истечения кванта и сигнала от таймера, управление получил поток 2. Этот поток не успел использовать свой квант, так как был снят с выполнения в результате возникшей ошибки (событие ER).

Далее планировщик предоставлял процессорное время потокам 1, 4 и снова 1. Во время выполнения потока 1 произошло прерывание S от внешнего устройства, сиг­нализирующее о том, что операция передачи данных завершена. Это событие ак­тивизировало работу планировщика, в результате которой поток 3, ожидавший завершения ввода-вывода, вытеснил поток 1, так как имел в этот момент более высокий приоритет.

Последний показанный на диаграмме период выполнения потока 1 прерывался несколько раз. Вначале это было прерывание от внешнего устройства (S), затем программное прерывание (R), вызвавшее освобождение ресурса, и, наконец, пре­рывание от таймера (Т). Каждое из этих трех прерываний вызвало перепланиров­ку потоков. В двух первых случаях планировщик оставил выполняться поток 1, так как в очереди не оказалось более приоритетных потоков, а квант времени, выделенный потоку 1, еще не был исчерпан. Переключение потоков было выпол­нено только по прерыванию от таймера.

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

Источник