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

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

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

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

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

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

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

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

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

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

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

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