Приоритетное планирование

Основные идеи и понятия

Мы приступаем к рассмотрению политик и параметров планирования применительно к использованию процессоров потоками управления ( процессами ), готовыми к выполнению. Эта тема уже затрагивалась в курсе [1] и предыдущих разделах данного курса, посвященных потокам управления.

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

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

Общая идея приоритетного планирования состоит в следующем. У каждого потока управления ( процесса ) в каждый момент времени есть определенный приоритет. Равноприоритетные потоки управления, готовые к выполнению, объединяются в списки, так что поток попадает в список в соответствии со своим текущим приоритетом .

Списки равноприоритетных потоков упорядочены, от первого элемента ( головы ) к последнему ( хвосту ). Цель политики планирования состоит в определении допустимых операций над множеством списков (например, перемещение потоков между списками и внутри них).

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

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

Другие действия (предыдущие и последующие) специфичны для установленной политики планирования. Рассмотрим их.

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

• Если выполняемый поток управления вытесняется с процессора, он помещается в голову списка, соответствующего его приоритету.
• Когда приостановленный (блокированный) поток управления становится готовым к выполнению, он помещается в хвост списка, соответствующего его приоритету.
• Когда выполняемый поток управления вызывает функцию sched_setscheduler(), политика и приоритет планирования процесса, указанного в вызове, изменяются в соответствии со значением аргумента param (см. далее).
• Когда выполняемый поток управления вызывает функцию sched_setparam(), приоритет планирования процесса, указанного в вызове, изменяется в соответствии со значением аргумента param (см. далее).
• Когда выполняемый поток управления вызывает функцию pthread_setschedparam(), политика и приоритет планирования потока, указанного в вызове, изменяются в соответствии со значениями аргументов policy и param.
• Когда выполняемый поток управления вызывает функцию pthread_setschedprio(), приоритет планирования потока, указанного в вызове, изменяется в соответствии со значением аргумента prio.
• Если поток управления, чьи политика и/или приоритет планирования подверглись изменению вызовами, отличными от pthread_setschedprio(), является выполняемым или готовым к выполнению, он помещается в хвост списка, соответствующего его новому приоритету.
• Если поток управления, чей приоритет планирования изменен вызовом pthread_setschedprio(), является выполняемым или готовым к выполнению, воздействие на его позицию в списке определяется направлением изменения, а именно:
  • если приоритет увеличился, поток помещается в хвост соответствующего списка;
  • если приоритет уменьшился, поток помещается в голову соответствующего списка;
  • если приоритет не изменился, не меняется и позиция потока в списке.
• Когда выполняемый поток управления вызывает функцию sched_yield(), он помещается в хвост своего списка.
• Ни при каких других событиях позиция потока управления в списках при данной политике планирования не изменяется.

Допустимый диапазон приоритетов должен включать по крайней мере 32 различных значения и ограничиваться величинами, которые возвращают функции sched_get_priority_min() и sched_get_priority_max() с аргументом SCHED_FIFO.

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

Чтобы сделать планирование более справедливым по отношению к равноприоритетным процессам, можно воспользоваться политикой SCHED_RR ( циклическое планирование ). Она эквивалентна SCHED_FIFO с одним исключением: когда время, в течение которого поток управления занимал процессор, становится больше или равным результату функции sched_rr_get_interval(), он перемещается в хвост соответствующего списка, а для выполнения выбирается головной поток. Таким образом, ни один из равноприоритетных потоков не сможет монополизировать процессор .

Если поток управления вытесняется, а потом возобновляет выполнение, он "дорабатывает" выделенный ему квант процессорного времени.

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

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

Если накладными и непредвиденными расходами процессорного времени пренебречь нельзя, встает вопрос, на кого их списывать. От ответа на этот вопрос зависит, какое из сформулированных выше утверждений станет ложным. Если списывать расходы "на систему" и честно выделять каждому потоку управления Q единиц процессорного времени, поток может возобновить свое выполнение существенно позднее, чем через (N – 1) * Q единиц времени. Обычно для приложений реального времени это неприемлемо (не гарантируется время отклика на события, обслуживаемые потоками), поэтому расходы списывают на потоки, выделяя каждому из них не более Q единиц процессорного времени, что делает ложным первое утверждение, но гарантирует истинность второго. Разумеется, взрывная активность периферийных устройств, "отвлекающих" процессор на обработку прерываний, может практически целиком "съесть" выделяемый потоку квант времени ; если подобная активность окажется периодической с тем же периодом, что и циклическое планирование, некоторые потоки рискуют оказаться на голодном пайке, поэтому стандарт добавляет еще одно требование к реализации политики SCHED_RR: ни один поток управления не должен ожидать доступ к процессору неопределенно долго.

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

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