Процессы и примитивы ОС

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

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

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

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

Правила захватов ресурсов процессами в различных ОС не совпадают!

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

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

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

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

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

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

В ОС IBM и др. фирм принят несколько иной порядок работы, и информация о завершении процессов помещается в специально выделенный блок управления событиями (ECB - Event Control Block). В некоторых системах вызывающая программа может проверить окончание процесса с помощью макрокоманды, обычно называемой CHECK. В любой момент времени после выдачи, например, запроса на вывод эта команда позволяет определить, завершился ли процесс, запущенный по команде WRITE. Если процесс вывода еще не завершен, то программа может заняться другой работой, либо, при ее отсутствии, продолжать посылать команду CHECK, пока буфер не освободится.

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

Нетрудно видеть, что понятие POST-операции и БУС (ECB) фактически представляют собой реализацию P- и V-механизмов, упорядочивающих доступ к ресурсам. Но в отличие от P- и V-аппарата, данный аппарат синхронизации допускает прерывания в процессе работы и относится к одному из высоких уровней иерархической структуры ОС.

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

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

В реальных ОС процессы синхронизации содержат более сложные механизмы.