Автор: Пользователь скрыл имя, 24 Марта 2013 в 11:42, курс лекций
Первые шаги по созданию электронных вычислительных машин были предприняты в конце второй мировой войны. В середине 40-х были созданы первые ламповые вычислительные устройства, и появился принцип программы, хранимой в памяти машины (John Von Neumann, июнь 1945г). В то время одна и та же группа людей участвовала и в проектировании, и в эксплуатации, и в программировании вычислительной машины. Это была скорее научно-исследовательская работа в области вычислительной техники, а не регулярное использование компьютеров в качестве инструмента решения каких-либо практических задач из других прикладных областей. Программирование осуществлялось исключительно на машинном языке.
Среди программ ОС можно выделить программы, расширяющие функции аппаратуры, и программы, по своей сути являющиеся обслуживающими. Для того, чтобы отнести конкретную программу к одному из указанных типов, необходимо знать, каким образом ей передается управление.
Примитивы. Иногда в ОС необходимо выполнение нескольких функций строго последовательно. В связи с этим не возникает никакой необходимости в их синхронизации. Подобные отношения последовательного выполнения возможны и между программами пользователей и элементами ОС. Отношения такого типа удобны, когда вызывающей программе для продолжения работы необходимы результаты, получаемые, вызываемой программой. Подобным образом выполняются обычно все функции ОС, относящиеся к нижнему уровню иерархии. В большинстве ОС в набор примитивов входят: программа обработки прерываний, диспетчер, программы синхронизации (для реализации 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-аппарата, данный аппарат синхронизации допускает прерывания в процессе работы и относится к одному из высоких уровней иерархической структуры ОС.
Структура, включающая два элемента
в очереди диспетчера, общий буфер
и механизм обмена сообщениями, может
также применяться для
Во многих ОС
обращения к отдельным
В реальных ОС процессы синхронизации содержат более сложные механизмы.
Диспетчирование и состояние процессов. Планирование выполнения задач является одной из ключевых концепций в многозадачности и многопроцессорности как в операционных системах общего назначения, так и в операционных системах реального времени.
Планирование заключается
в назначении приоритетов процессам в очеред
Диспетчер обычно – фундаментальный элемент ядра ОС, однако в принципе обязанности диспетчера могут выполняться на более высоком уровне ОС, либо самими прикладными программами. Самой важной целью планирования задач является наиболее полная загрузка процессора.
Основные параметры планирования: а) производительность — кол-во процессов, которые завершают выполнение за единицу времени; б) время ожидания — время, которое процесс ожидает в очереди готовности; в) время отклика — время, которое проходит от начала запроса до первого ответа на запрос.
В средах вычислений реального времени, например, на мобильных устройствах, предназначенных для автоматического управления в промышленности (например, робототехника), планировщик задач должен обеспечить отработку процессов в течение заданных временны́х промежутков (время отклика); это критично для поддержания корректной работы системы реального времени.
Диспетчирование (планирование) заключается в постоянном принятии решений о том, какой процесс нужно запускать следующим и в соответствующей установке машинного счетчика команд, содержащего адрес очередной команды, которая подлежит выполнению.
Основные функции диспетчера:
создание процессов для
создание обработчиков событий;
синхронизация процессов и обработчиков для правильного формирования временной диаграммы.
Процесс диспетчирования в основных чертах предусматривает выполнение следующих действий:
Процесс - одна или совокупность программ, выполнение которых планируется отдельно.
Построение диспетчеров. Известны два типа построения диспетчера: с запуском задач по расписанию (Time Triggered) и с запуском задач по событиям (Event Triggered). Запуск задач по расписанию обычно строится на базе часов реального времени, либо по прерываниям от внешнего источника тактирующих импульсов. Так как часы реального времени, как правило, строятся на базе аппаратного таймера, вызывающего прерывания с заданным периодом повторения, можно считать первый тип разновидностью второго.
Состояния процесса. При использовании такой абстракции все, что выполняется в вычислительных системах (не только программы пользователей, но и, возможно, определенные части операционных систем), организовано как набор процессов. Понятно, что реально на однопроцессорной компьютерной системе в каждый момент времени может исполняться только один процесс. Для мультипрограммных вычислительных систем псевдопараллельная обработка нескольких процессов достигается с помощью переключения процессора с одного процесса на другой. Пока один процесс выполняется, остальные ждут своей очереди на получение процессора.
Как видим, каждый процесс может находиться как минимум в двух состояниях: процесс исполняется и процесс не исполняется. Диаграмма состояний процесса в такой модели изображена на рисунке 5.1.
Рис 5.1. Простейшая диаграмма состояний процесса.
Процесс, находящийся в состоянии процесс исполняется, может через некоторое время завершиться или быть приостановлен операционной системой и снова переведен в состояние процесс не исполняется. Приостановка процесса происходит по одной из двух причин: для его дальнейшей работы потребовалось возникновение какого-либо события (например, завершения операции ввода-вывода) или истек временной интервал, отведенный операционной системой для работы этого процесса. После этого операционная система по определенному алгоритму выбирает для исполнения один из процессов, находящихся в состоянии процесс не исполняется, и переводит его в состояние процесс исполняется. Новый процесс, появляющийся в системе, первоначально помещается в состояние процесс не исполняется.
Такая модель является очень грубой. Она не учитывает, в частности то, что процесс, выбранный для исполнения, может все еще ждать события, из-за которого он был приостановлен, и реально к выполнению не готов. Для того чтобы избежать такой ситуации, разобьем состояние «процесс не исполняется» на два новых состояния: «готовность» и «ожидание» (рисунок 5.2).
Рис. 5.2. Более подробная диаграмма состояний процесса.
Всякий новый процесс, появляющийся в системе, попадает в состояние готовность. Операционная система, пользуясь каким-либо алгоритмом планирования, выбирает один из готовых процессов и переводит его в состояние исполнение. В состоянии исполнение происходит непосредственное выполнение программного кода процесса. Покинуть это состояние процесс может по трем причинам:
либо он заканчивает свою деятельность;
либо он не может продолжать свою работу, пока не произойдет некоторое событие, и операционная система переводит его в состояние ожидание;
либо в результате возникновения прерывания в вычислительной системе (например, прерывания от таймера по истечении дозволенного времени выполнения) его возвращают в состояние готовность.
Наша новая модель хорошо описывает поведение процессов во время их жизни, но она не акцентирует внимания на появлении процесса в системе и его исчезновении из системы. Для полноты картины нам необходимо ввести еще два состояния процессов: рождение и закончил исполнение (см. рисунок 5.3).
Рис. 5.3. Диаграмма состояний процесса, принятая в курсе.