Мультипрограммирование, многопользовательский режим работы и режим разделения времени
 Скачать 0.67 Mb.
|
|
§2.3. Мультипрограммирование, многопользовательский режим работы и режим разделения времени Суть мультипрограммного режима работы заключается в том, что пока одна программа (один вычислительный процесс) ожидает завершения очередной операции ввода-вывода, другая программа (а точнее, другая задача) может быть поставлена на решение (рис.1). Это позволяет более полно использовать имеющиеся ресурсы (например, центральный процессор начинает меньше простаивать, как это видно из рисунка) и уменьшить общее (суммарное) время, необходимое для решения некоторого множества задач. Рис.1. Пример выполнения двух программ (задач А и В) в мультипрограммном режиме На рисунке в качестве примера изображена такая гипотетическая ситуация, при которой благодаря совмещению во времени двух вычислительных процессов общее время их выполнения получается меньше, чем если бы их выполняли по очереди (запуск одного начинался бы только после полного завершения другого). Из этого же рисунка видно, что время выполнения каждого процесса в общем случае больше, чем если бы мы выполняли каждый из них как единственный. Мультипрограммирование, многопользовательский режим работы и режим разделения времени . При мультипрограммировании повышается пропускная способность системы, но отдельный процесс никогда не может быть выполнен быстрее, чем если бы он выполнялся в однопрограммном режиме (всякое разделение ресурсов замедляет работу одного из участников за счет дополнительных затрат времени на ожидание освобождения ресурса). Историческая справка: Мультипрограммирование стало применяться все чаще и шире в 60-х годах XX века, когда крупные компании получили, наконец, возможность приобретать в собственность вычислительную технику и использовать ее для решения своих задач. До этого времени вычислительная техника была доступна, прежде всего, для военных целей и решения отдельных задач общегосударственного масштаба. А поскольку стоимость компьютеров в то время была чрезвычайно большой, то компании, вложив свои капиталы в вычислительную технику, захотели за счет продажи машинного времени не только покрыть те расходы, которые сопутствовали ее приобретению и использованию, но и зарабатывать дополнительные деньги, то есть получать прибыль. Машинное время стали активно продавать, сдавая в аренду имеющиеся компьютеры, и потенциальная возможность решать в единицу времени большее количество задач, возможно от разных клиентов, стала выступать основным стимулом в развитии способов организации вычислений и операционных систем. Задачи пользователей ставились в очередь на решение, и распределение времени центрального процессора и других ресурсов компьютера между несколькими выполняющимися вычислительными процессами позволяло организовать параллельное выполнение сразу нескольких задач. Эти задачи могли относиться и к одному пользователю, и к нескольким. Однако ставил их на решение оператор вычислительной системы. Приблизительно в то же время стали активно развиваться всевозможные устройства ввода и вывода данных. Не стояло на месте и системное программное обеспечение. Появилась возможность пользователю самому вводить исходные данные и тут же получать результаты вычислений, причем в удобном для него виде. Упрощение пользовательского интерфейса и развитие интерфейсных функций операционных систем позволило реализовать диалоговый режим работы. Диалоговый режим предполагает, что пользователь может сам, без посредника, взаимодействовать с компьютером — готовить и запускать свои программы, вводить исходные данные, получать результаты, приостанавливать вычисления и вновь их возобновлять и т. д Мультипрограммирование, многопользовательский режим работы и режим разделения времени . Диалоговый режим работы может быть реализован и без мультипрограммирования. Наглядное тому доказательство — многочисленные дисковые операционные системы, начиная от СР-М и кончая PC-DOS 7.0, которые долгие годы устанавливались на персональные компьютеры и обеспечивали только однопрограммный режим. Однако эти однопрограммные диалоговые системы появились гораздо позже мультипрограммных. Как это ни кажется странным, им предшествовали многочисленные и разнообразные операционные системы, позволяющие одновременно работать с компьютером большому количеству пользователей и параллельно решать множество задач. Основная причина тому — стоимость компьютера. Только с удешевлением компьютеров появилась возможность иметь свой персональный компьютер, и первое время считалось, что однопрограммного режима работы вполне достаточно. Главным для персональных компьютеров до сих пор считается удобство работы, причем именно в диалоговом режиме, простота интерфейса и его интуитивная понятность. Совмещение диалогового режима работы с компьютером и режима мультипрограммирования привело к появлению мультитерминальных, или многопользовательских, систем. Организовать параллельное выполнение нескольких задач можно разными способами. Если на каждую задачу поочередно выделяется некий квант времени, после чего процессор передается другой задаче, готовой к продолжению вычислений, то такой режим принято называть режимом разделения времени (time sharing). Системы разделения времени активно развивались в 60-70 годы, и сам термин означал именно мультитерминальную и мультипрограммную систему. Итак, операционная система может поддерживать мультипрограммирование (многопроцессорность). В этом случае она должна стараться эффективно использовать имеющиеся ресурсы путем организации к ним очередей запросов, составляемых тем или иным способом. Это требование достигается поддерживанием в памяти более одного вычислительного процесса, ожидающего процессор, и более одного процесса, готового использовать другие ресурсы, как только последние станут доступными. Мультипрограммирование, многопользовательский режим работы и режим разделения времени . Рассмотрим общую схему выделения ресурсов: 1). При необходимости использовать какой-либо ресурс (оперативную память, устройство ввода-вывода, массив данных и т. п.) вычислительный процесс (задача) путем обращения к супервизору (supervisor) операционной системы посредством специальных вызовов (команд, директив) сообщает о своем требовании. При этом указывается вид ресурса и, если надо, его объем. Например, при запросе оперативной памяти указывается количество адресуемых ячеек, необходимое для дальнейшей работы. Супервизор — центральный (главный) управляющий модуль операционной системы. Может состоять из нескольких модулей, например супервизора ввода-вывода, супервизора прерываний, супервизора программ, диспетчера задач и т. д. В последние годы термин «супервизор» применяется все реже и реже. 2). Команда обращения к операционной системе передает ей управление, переводя процессор в привилегированный режим работы (если такой существует). Как нам уже известно, большинство компьютеров имеют два (и более) режима работы: привилегированный (режим супервизора) и пользовательский. Кроме того, могут быть режимы для эмуляции какой-нибудь другой ЭВМ или для организации виртуальной машины, защищенной от остальных вычислений, осуществляемых на этом же компьютере, и т. д. Ресурс может быть выделен вычислительному процессу (задаче), обратившемуся к операционной системе с соответствующим запросом, если: • ресурс свободен и в системе нет запросов от задач более высокого приоритета к этому же ресурсу; • текущий запрос и ранее выданные запросы допускают совместное использование ресурсов; • ресурс используется задачей низшего приоритета и может быть временно отобран (разделяемый ресурс). 3). Получив запрос, операционная система либо удовлетворяет его и возвращает управление задаче, выдавшей данный запрос, либо, если ресурс занят, ставит задачу в очередь к ресурсу, переводя ее в состояние ожидания (блокируя). Очередь к ресурсу может быть организована несколькими способами, но чаще всего она реализуется с помощью списковой структуры. Мультипрограммирование, многопользовательский режим работы и режим разделения времени . 4). После окончания работы с ресурсом задача опять с помощью специального вызова супервизора (посредством соответствующей команды) сообщает операционной системе об отказе от ресурса, либо операционная система забирает ресурс сама, если управление возвращается супервизору после выполнения какой-либо системной функции. 5). Супервизор операционной системы, получив управление по этому обращению, освобождает ресурс и проверяет, имеется ли очередь к освободившемуся ресурсу. Если очередь есть, то в зависимости от принятой дисциплины обслуживания и приоритетов заявок он выводит из состояния ожидания задачу, ждущую ресурс, и переводит ее в состояние готовности к выполнению, после чего либо передает управление ей, либо возвращает управление задаче, только что освободившей ресурс. Термин «дисциплина обслуживания» следует понимать как некое правило обслуживания, в том числе и учет каких-либо приоритетов при обслуживании. Например, дисциплина «последний пришедший обслуживается первым» определяет обслуживание в порядке, обратном очередности поступления соответствующих запросов. При выдаче запроса на ресурс задача может указать, хочет ли она владеть ресурсом монопольно или допускает совместное использование с другими задачами. Например, с файлом можно работать монопольно, а можно и совместно с другими задачами. Если в системе имеется некоторая совокупность ресурсов, то управлять их использованием можно на основе некоторой стратегии. Стратегия подразумевает четкую формулировку целей, следуя которым можно добиться эффективного распределения ресурсов. При организации управления ресурсами всегда требуется принять решение о том, что в данной ситуации выгоднее: 1.быстро обслуживать отдельные наиболее важные запросы, предоставлять всем процессам равные возможности или 2. обслуживать максимально возможное количество процессов и наиболее полно использовать ресурсы. §2.4. Диаграмма состояний процесса Необходимо отличать системные управляющие вычислительные процессы, представляющие работу супервизора операционной системы и занимающиеся распределением и управлением ресурсов, от всех других процессов: задач пользователей и системных обрабатывающих процессов. Последние, хоть и относятся к операционной системе, но не входят в ядро операционной системы и требуют общих ресурсов для своей работы, которые получают от супервизора. Для системных управляющих процессов, в отличие от обрабатывающих, в большинстве операционных систем ресурсы распределяются изначально и однозначно. Эти вычислительные процессы сами управляют ресурсами системы, в борьбе за которые конкурируют все остальные процессы. Поэтому исполнение системных управляющих программ не принято называть процессами, и термин «задача» следует употреблять только по отношению к процессам пользователей и к системным обрабатывающим процессам. Однако это справедливо не для всех операционных систем. Например, в так называемых «микроядерных» операционных системах (см. главу 9) большинство управляющих программных модулей самой операционной системы и даже драйверы имеют статус высокоприоритетных процессов, для выполнения которых необходимо выделить соответствующие ресурсы. В качестве примера можно привести хорошо известную операционную систему реального времени QNX фирмы Quantum Software Systems. Аналогично и в UNIX-системах, которые хоть и не относятся к микроядерным, выполнение системных программных модулей тоже имеет статус системных процессов, получающих ресурсы для своего исполнения. Диаграмма состояний процесса . Очевидно, что если некий вычислительный процесс (назовем его первым) в данный конкретный момент времени не исполняется, поскольку процессор занят исполнением какого-то другого процесса, то операционная система должна знать, что вычисления в первом процессе приостановлены. Информация об этом заносится в специальную информационную структуру(подробную информацию о ней см.в след.параграфе презентации), сопровождающую каждый вычислительный процесс. Таких приостановленных процессов может быть несколько. Они могут образовывать очередь задач, которые возобновят свои вычисления, как только им будет предоставлен процессор. Некоторые процессы, при своем выполнении требующие ввода или вывода данных, на время выполнения этих запросов могут освобождать процессор. Такие события тоже должны для операционной системы помечаться соответствующим образом. Говорят, что процесс может находиться в одном из нескольких состояний. Информация о состоянии процесса содержится в упомянутой выше информационной структуре, доступной супервизору. Если обобщать и рассматривать не только традиционные системы общего назначения и привычные всем нам современные мультизадачные операционные системы для персональных компьютеров, но и операционные системы реального времени, то можно сказать, что процесс может находиться в активном и пассивном (не активном) состоянии. В активном состоянии процесс может конкурировать за ресурсы вычислительной системы, а в пассивном состоянии он известен системе, но за ресурсы не конкурирует (хотя его существование в системе и сопряжено с предоставлением ему оперативной и/или внешней памяти). Диаграмма состояний процесса . Активный процесс может быть в одном из следующих состояний: • выполнения — все затребованные процессом ресурсы выделены (в этом состоянии в каждый момент времени может находиться только один процесс, если речь идет об однопроцессорной вычислительной системе); • готовности к выполнению — ресурсы могут быть предоставлены, тогда процесс перейдет в состояние выполнения; • блокирования, или ожидания, — затребованные ресурсы не могут быть предоставлены, или не завершена операция ввода-вывода. В большинстве операционных систем последнее состояние, в свою очередь, подразделяется на множество состояний ожидания, соответствующих определенному виду ресурса, из-за отсутствия которого процесс переходит в заблокированное состояние. В обычных операционных системах, как правило, процесс появляется при запуске какой-нибудь программы. Операционная система организует (порождает, или выделяет) для нового процесса уже упомянутую выше информационную структуру — так называемый дескриптор процесса, и процесс (задача) начинает выполняться. Поэтому пассивного состояния в большинстве систем не существует. В операционных системах реального времени (ОСРВ) ситуация иная. Обычно при проектировании системы реального времени состав выполняемых ею программ (задач) известен заранее. Известны и многие их параметры, которые необходимо учитывать при распределении ресурсов (например, объем памяти, приоритет, средняя длительность выполнения, открываемые файлы, используемые устройства и проч.). Поэтому для них заранее заводят дескрипторы задач с тем, чтобы впоследствии не тратить драгоценное время на организацию дескриптора и поиски для него необходимых ресурсов. Диаграмма состояний процесса . Рис. 2. Граф состояний процесса Рассмотрим эти переходы из одного состояния в другое более подробно. Процесс из состояния бездействия может перейти в состояние готовности в следующих случаях. • По команде оператора (пользователя). Имеет место в тех диалоговых операционных системах, где программа может иметь статус задачи, даже оставаясь пассивной, а не просто быть исполняемым файлом и получать статус задачи только на время исполнения (как это имеет место в большинстве современных операционных систем, в том числе и для персональных компьютеров). • При выборе из очереди планировщиком (характерно для операционных систем, работающих в пакетном режиме). • При вызове из другой задачи (посредством обращения к супервизору один процесс может создать, инициировать, приостановить, остановить, уничтожить другой процесс). Таким образом, в ОСРВ многие процессы (задачи) могут находиться в состоянии бездействия (см. рис.2- состояние бездействие отделено от остальных состояний пунктиром). За время своего существования процесс может неоднократно совершать переходы из одного состояния в другое, обусловленные обращениями к операционной системе с запросами ресурсов и выполнения системных функций, которые предоставляет операционная система, взаимодействием с другими процессами, появлением сигналов прерывания от таймера, каналов и устройств ввода-вывода, других устройств. Возможные переходы процесса из одного состояния в другое отображены на рисунке 2 в виде графа состояний. Диаграмма состояний процесса . • По прерыванию от внешнего инициативного устройства (сигнал о свершении некоторого события может запускать соответствующую задачу). Устройство называется инициативным, если по сигналу запроса на прерывание от него должна запускаться некоторая задача. • При наступлении запланированного времени запуска программы. Последние два способа запуска задачи, при которых процесс из состояния бездействия переходит в состояние готовности, наиболее характерны для операционных систем реального времени. Процесс, который может исполняться, как только ему будет предоставлен процессор (а для диск-резидентных задач в некоторых системах и оперативная память), находится в состоянии готовности. Считается, что такому процессу уже выделены все необходимые ресурсы за исключением процессора. Из состояния выполнения процесс может выйти по одной из следующих причин. • Процесс завершается, при этом он посредством обращения к супервизору передает управление операционной системе и сообщает о своем завершении. В результате этих действий супервизор либо переводит его в список бездействующих процессов (процесс переходит в пассивное состояние), либо уничтожает. Уничтожается, естественно, не сама программа, а именно задача, которая соответствовала исполнению этой программы. В состояние бездействия процесс может быть переведен принудительно: по команде оператора или путем обращения к супервизору операционной системы из другой задачи с требованием остановить данный процесс. Само собой, что действие по команде оператора реализуется системным процессом, который «транслирует» эту команду в запрос к супервизору с требованием перевести указанный процесс в состояние бездействия. Диаграмма состояний процесса . Из состояния выполнения процесс может выйти по одной из следующих причин (продолжение). • Процесс переводится супервизором операционной системы в состояние готовности к исполнению в связи с появлением более приоритетной задачи или в связи с окончанием выделенного ему кванта времени. • Процесс блокируется (переводится в состояние ожидания) либо вследствие запроса операции ввода-вывода (которая должна быть выполнена прежде, чем он сможет продолжить исполнение), либо в силу невозможности предоставить ему ресурс, запрошенный в настоящий момент (причиной перевода в состояние ожидания может быть отсутствие сегмента или страницы в случае организации механизмов виртуальной памяти), либо по команде оператора на приостанов задачи, либо по требованию через супервизор от другой задачи. При наступлении соответствующего события (завершилась операция ввода-вывода, освободился затребованный ресурс, в оперативную память загружена необходимая страница виртуальной памяти и т. д.) процесс деблокируется и переводится в состояние готовности к исполнению. Таким образом, движущей силой, меняющей состояния процессов, являются события. Одним из основных видов событий являются прерывания. §2.5. Реализация понятия последовательного процесса в ОС Для того чтобы операционная система могла управлять процессами, она должна располагать всей необходимой для этого информацией. С этой целью на каждый процесс заводится специальная информационная структура, называемая дескриптором процесса (описателем задачи, блоком управления задачей). В общем случае дескриптор процесса содержит следующую информацию: • идентификатор процесса (Process Identifier, PID); • тип (или класс) процесса, который определяет для супервизора некоторые правила предоставления ресурсов; • приоритет процесса, в соответствии с которым супервизор предоставляет ресурсы (в рамках одного класса процессов в первую очередь обслуживаются более приоритетные процессы); • переменную состояния, которая определяет, в каком состоянии находится процесс (готов к работе, выполняется, ожидает устройства ввода-вывода и т. д.); • контекст задачи, то есть защищенную область памяти (или адрес такой области), в которой хранятся текущие значения регистров процессора, когда процесс прерывается, не закончив работы; • информацию о ресурсах, которыми процесс владеет и/или имеет право пользоваться (указатели на открытые файлы, информация о незавершенных операциях ввода-вывода и др.); • место (или его адрес) для организации общения с другими процессами; • параметры времени запуска (момент времени, когда процесс должен активизироваться, и периодичность этой процедуры); • в случае отсутствия системы управления файлами адрес задачи на диске в ее исходном состоянии и адрес на диске, куда она выгружается из оперативной памяти, если ее вытесняет другая задача (последнее справедливо для диск-резидентных задач, которые постоянно находятся во внешней памяти на системном магнитном диске и загружаются в оперативную память только на время выполнения). Реализация понятия последовательного процесса в операционных системах . Описатели(дескрипторы) задач, как правило, постоянно располагаются в оперативной памяти с целью ускорить работу супервизора. В свою очередь супервизор организует их в списки (очереди) и отображает изменение состояния процесса перемещением соответствующего описателя из одного списка в другой. Для каждого состояния (за исключением состояния выполнения для однопроцессорной системы) операционная система ведет соответствующий список задач, находящихся в этом состоянии. Однако для состояния ожидания обычно имеется не один список, а столько, сколько различных видов ресурсов могут вызывать состояние ожидания. Например, состояний ожидания завершения операции ввода-вывода может быть столько, сколько устройств ввода-вывода имеется в системе. В разных ОС количество описателей регламентируется по-разному:
Рассмотрим несколько примеров: В данной ОС максимально возможное количество описателей задач указывается в конфигурационном файле CONFIG.SYS. Cтрока THREADS=1024 в файле CONFIG.SYS означает, что всего в системе может параллельно существовать и выполняться до 1024 задач, включая вычислительные процессы и их потоки. . Реализация понятия последовательного процесса в операционных системах В операционных системах реального времени чаще всего количество процессов фиксируется, и, следовательно, целесообразно заранее определять (на этапе генерации или конфигурирования ОС) количество дескрипторов. Для использования таких операционных систем в качестве систем общего назначения (что нынче уже нехарактерно) обычно количество дескрипторов бралось с некоторым запасом и появление новой задачи связывалось с заполнением этой информационной структуры. В недалеком прошлом достаточно часто в качестве вычислительных систем общего назначения приобретались мини-ЭВМ и устанавливали на них ОС реального времени. Поскольку дескрипторы процессов постоянно располагаются в оперативной памяти (с целью ускорить работу диспетчера), то их количество не должно быть очень большим. 2. Windows NT/2000/XP/../7. В ныне широко распространенных системах Windows NT/2000/XP/../7 количество описателей нигде в явном виде не задается. Это переменная величина, и она определяется самой операционной системой. Однако посмотреть на текущее количество таких описателей можно. Если, работая в Windows NT/2000/XP/../7, нажать одновременно комбинацию клавиш Ctrl+Shift+Esc, появится окно Диспетчера задач. На вкладке Быстродействие этой программы содержится информацию о соответствующем числе задействованных дескрипторов (рис.3). Также на этой вкладке указывается количество дескрипторов для управления потоками (задачами) и число полноценных вычислительных процессов. Рис.3. Вкладка Быстродействие окна Диспетчера задач в Windows 7. . Для более эффективной обработки данных в системах реального времени целесообразно иметь постоянные задачи, полностью или частично всегда существующие в системе независимо от того, поступило на них требование или нет. Каждая постоянная задача обладает некоторой собственной областью оперативной памяти (ОЗУ-резидентная задача, или просто резидентная задача) независимо от того, выполняется задача в данный момент или нет. Эта область, в частности, может использоваться для хранения данных, полученных задачей ранее. Данные могут храниться в ней и тогда, когда задача находится в состоянии ожидания или даже в состоянии бездействия. Для аппаратной поддержки работы операционных систем с этими информационными структурами (дескрипторами задач) в процессорах могут быть реализованы соответствующие механизмы. Так, например, в микропроцессорах Intel 80x86 имеется специальный регистр TR (Task Register), указывающий местонахождение специальной информационной структуры — сегмента состояния задачи (Task State Segment, TSS), в котором при переключении с задачи на задачу автоматически сохраняется содержимое регистров процессора. Реализация понятия последовательного процесса в операционных системах |