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

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

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

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

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

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

Алгоритмы реального времени могут быть статическими или динамическими.

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

Условия выполнения статического Алгоритма RMS:

1.Каждый периодичесий процесс должен быть завершен за время его периода.

2. Ни один процесс не должен зависеть от любого другого процесса.

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

4. у непериодических процессов нет жестких сроков.

5. прерывание процесса происходит мгновенно, без накладных расходов

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

54.Политика и мезанизм.

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

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

Важным инструментом любой комплексной системы является отделение политики от механизма.(впервые осуществлено в mach и MINIX).

Рассмотрим пример(mach):

Здесь управление памятью делится на 3 части:

1.низкоуровневый драйвер диспечера памяти

2.обработчик страничных прерываний(часть ядра)

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

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

Эта реализация оставляет вопрос о размещении алгоритма замещения страниц. Возможно покажется более удачным расположить его во внешнем обработчике страниц, но тогда возникают некоторые проблемы. Из них принципиально то, что внешний обработчик страниц не имеет доступа к битам R и M для всех страниц. Таким образом необходим какой-то механизм для передачи содержимого битов внешнему обработчику страниц, или же алгоритм замещения страниц должен находиться в ядре. Во втором случае обработчик прерываний сообщает внешнему обработчику, какую страницу он выбрал для удаления, и предоставляет данные или путем отображения их в адресное пространство внешнего обработчика страниц, или включая их в сообщение. В любом варианте внешний обработчик страниц пишет данные на доск.

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