Управление процессами Управление локальными ресурсами Важнейшей функцией

Управление процессами

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

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

Процессом является выполняемая программа, включая значения счетчика команд, регистров и переменных. Пусть у каждого процесса есть собственный виртуальный ЦП. Схема работы с четырьмя программами: а — четыре программы в многозадачном режиме; б — принципиальная модель четырех независимых логически упорядоченных процессов; в — в каждый момент времени активна только одна программа Скорость, с которой процессор производит вычисления, непостоянна и может отличаться при каждом новом запуске. Если есть критические временные рамки, необходимы спецмеры, чтобы удостовериться в завершении события

Создание процессов В простейших системах все процессы могут присутствовать при загрузке. В универсальных системах необходим способ создания и прерывания процессов по мере необходимости. К созданию процессов приводят следующие 4 события: 1. Инициализация системы 2. Выполнение работающим процессом системного запроса на создание процесса 3. Запрос пользователя на создание процесса 4. Инициирование пакетного задания. При загрузке системы создается несколько процессов: некоторые – обеспечивают взаимодействие с пользователем (приоритетные), остальные – фоновые. Фоновые, связанные с электронной почтой, новостями, web-страницами, выводом на печать называются демонами.

В UNIX новый процесс получает новое окно, в Windows – нет, но он может создать новое окно. В UNIX системный запрос для создания нового процесса fork В Windows – Create. Process интерфейса Win 32 управляет и созданием процесса и запуском нужной программы. У этой функции 10 параметров: программа, атрибуты защиты, приоритеты, параметры командной строки и т. д. Кроме этого в Win 32 есть еще около 100 функций для управления процессами и их синхронизации

Завершение процесса Завершается процесс благодаря одному из следующих процессов: 1. Обычный выход (преднамеренно) 2. Выход по ошибке (преднамеренно) 3. Выход по неисправимой ошибке (непреднамеренно) 4. Уничтожение другим процессом (непреднамеренно) 1. В основном процессы завершаются по мере выполнения работы. После окончания компиляции программы компилятор выполняет системный запрос об окончании работы. В UNIX это exit, в Windows - это Exit. Process; 2. – неустранимая ошибка; 3. – ошибка, вызванная процессом, чаще ошибкой программы (деление на ноль); 4. системный запрос на уничтожение процесса: в UNIX –kill, в Windows – Terminate. Process. В некоторых системах по завершении процесса завершаются все созданные им процессы.

Состояние процессов В многозадачной (многопроцессной) системе процесс может находиться в одном из трех основных состояний: ВЫПОЛНЕНИЕ - активное состояние процесса, во время которого процесс обладает всеми необходимыми ресурсами и непосредственно выполняется процессором; ОЖИДАНИЕ - пассивное состояние процесса, процесс заблокирован, он не может выполняться по своим внутренним причинам, он ждет осуществления некоторого события, например, завершения операции ввода-вывода, получения сообщения от другого процесса, освобождения какого-либо необходимого ему ресурса; ГОТОВНОСТЬ - также пассивное состояние процесса, но в этом случае процесс заблокирован в связи с внешними по отношению к нему обстоятельствами: процесс имеет все требуемые для него ресурсы, он готов выполняться, однако процессор занят выполнением другого процесса.

Рис. 2. 1. Граф состояний процесса в многозадачной среде В состоянии Выполнение в однопроцессорной системе может находиться только один процесс. Жизненный цикл – Г-В-О. Пока процесс существует, он может быть прерван и продолжен, для чего необходимо восстановить состояние его операционной среды (регистров, счетчиков, указателей, кодами ошибок и др. ) – контекстом процесса. Кроме того, ОС для планирования процессов требуется дополнительная информация, называемая в UNIX дескриптором процесса.

Процесс может находиться в рабочем, готовом и заблокированном состоянии. Стрелками показаны возможные переходы между состояниями 1. Процесс блокируется, ожидая входных данных 2. Планировщик выбирает другой процесс 3. Планировщик выбирает этот процесс 4. Доступны входные данные Переходы 2 и 3 вызываются частью операционной системы, называемой планировщиком процессов,

Создать процесс это значит: создать информационные структуры, т. е. дескриптор и контекст, включить дескриптор нового процесса в очередь готовых процессов, загрузить кодовый сегмент процесса в ОЗУ или в область свопинга. Планирование процессов включает в себя решение следующих задач: 1. определение момента времени для смены выполняемого процесса, 2 – выбор процесса на выполнение из очереди готовых процессов, 3. -переключение контекстов «старого» и «нового» процессов (решается аппаратно). Нижний уровень операционной системы отвечает за прерывания и планирование. Выше расположены логически упорядоченные процессы

Алгоритмы планирования процессов Существует множество алгоритмов, наиболее популярны две группы: 1. основанные на квантовании и 2. на приоритетах. 1. Смена активного процесса происходит, если процесс завершил работу и покинул систему, произошла ошибка, процесс перешел в состояние ОЖИДАНИЕ, исчерпан квант процессорного времени, отведенный данному процессу. Кванты могут быть одинаковыми или различными. Другая группа использует приоритет – число, характеризующее степень привилегированности процесса при использовании ресурсов. Он может назначаться администратором, вычисляться ОС по определенным правилам, оставаться фиксированным, либо меняться во времени (динамический приоритет).

Приоритеты могут быть относительными и абсолютными. Отличаются решением о смене активного процесса. В системах с ОП активный процесс выполняется, пока он сам не покинет процессор, перейдя в ОЖИДАНИЕ. В системах с АП прерывается, если появился процесс с приоритетом, выше, чем у активного , прерванный процесс переходит в состояние ГОТОВНОСТИ. Рис. 2. 2. Графы состояний процессов в системах (а) с относительными приоритетами; (б) с абсолютными приоритетами

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

Реализация процессов Для реализации модели процессов операционная система поддерживает таблицу (массив структур), называемую таблицей процессов, с одним элементом для каждого процесса. (Некоторые авторы называют эти элементы блоками управления процессом. ) Элемент таблицы содержит информацию о состоянии процесса, счетчике команд, указателе стека, распределении памяти, состоянии открытых файлов, об использовании и распределении ресурсов, а также всю остальную информацию, которую необходимо сохранять при переключении в состояние готовности или блокировки для последующего запуска, — как если бы процесс останавливался.

Некоторые поля типового элемента таблицы процессов

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

Модель потока Процесс можно рассматривать, как способ объединения родственных ресурсов в одну группу, а с другой – как поток исполняемых команд. Поток имеет счетчик команд, регистры для хранения переменных, стек, содержащий протокол выполнения процесса, где на каждую вызванную процедуру отведен отдельный фрейм. Процессы используются для группировки ресурсов, а потоки являются объектами, исполняющимися на ЦП. Концепция потоков добавляет возможность одновременного выполнения нескольких независимых программ. Потоки обладают некоторыми свойствами процессов, их иногда называют упрощенными процессами, многопоточность используется для описания нескольких потоков в одном процессе. Потоки не так независимы: у всех одно адресное пространство (совместное использование глобальных переменных), невозможно организовать защиту, но это не нужно, т. к. потоки работают совместно, не мешая другу.

Элементы, используемые всеми потоками (слева) и индивидуальные (справа) Элементы процесса Адресное пространство Глобальные переменные Открытые файлы Дочерние процессы Необработанные аварийные сигналы Сигналы и их обработчики Информация об использовании ресурсов Элементы потока Счетчик команд Регистры Стек Состояние

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

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

Реализация критических секций с использованием блокирующих переменных Датский математик Деккер (Т. Dekker) был первым, кто разработал программное решение проблемы взаимного исключения, В 1981 году Петерсон (G. L. Peterson) придумал более простой алгоритм взаимного исключения.

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

Другим способом является использование блокирующих переменных. С каждым разделяемым ресурсом связывается двоичная переменная, которая принимает значение 1, если ресурс свободен (то есть ни один процесс не находится в данный момент в критической секции, связанной с данным процессом), и значение 0, если ресурс занят. На рисунке показан фрагмент алгоритма процесса, использующего для реализации взаимного исключения доступа к разделяемому ресурсу D блокирующую переменную F(D). Перед входом в критическую секцию процесс проверяет, свободен ли ресурс D. Если он занят, то проверка циклически повторяется, если свободен, то значение переменной F(D) устанавливается в 0, и процесс входит в критическую секцию. После того, как процесс выполнит все действия с разделяемым ресурсом D, значение переменной F(D) снова устанавливается равным 1. Если все процессы написаны с использованием вышеописанных соглашений, то взаимное исключение гарантируется. Следует заметить, что операция проверки и установки блокирующей переменной должна быть неделимой

Реализация критических секций с использованием блокирующих переменных имеет существенный недостаток: в течение времени, когда один процесс находится в критической секции, другой процесс, которому требуется тот же ресурс, будет выполнять рутинные действия по опросу блокирующей переменной, бесполезно тратя процессорное время. Для устранения таких ситуаций может быть использован так называемый аппарат событий. С помощью этого средства могут решаться не только проблемы взаимного исключения, но и более общие задачи синхронизации процессов. В разных операционных системах аппарат событий реализуется по своему, но в любом случае используются системные функции аналогичного назначения, которые условно назовем WAIT(x) и POST(x), где x - идентификатор некоторого события. Если ресурс занят, то процесс не выполняет циклический опрос, а вызывает системную функцию WAIT(D), здесь D обозначает событие, заключающееся в освобождении ресурса D. Функция WAIT(D) переводит активный процесс в состояние ОЖИДАНИЕ и делает отметку в его дескрипторе о том, что процесс ожидает события D. Процесс, который в это время использует ресурс D, после выхода из критической секции выполняет системную функцию POST(D), в результате чего операционная система просматривает очередь ожидающих процессов и переводит процесс, ожидающий события D, в состояние ГОТОВНОСТЬ.

Обобщающее средство синхронизации процессов предложил Дейкстра, который ввел два новых примитива. В абстрактной форме эти примитивы, обозначаемые P и V, оперируют над целыми неотрицательными переменными, называемыми семафорами. Пусть S такой семафор. Операции определяются следующим образом: V(S) : переменная S увеличивается на 1 одним неделимым действием; выборка, инкремент и запоминание не могут быть прерваны, и к S нет доступа другим процессам во время выполнения этой операции. P(S) : уменьшение S на 1, если это возможно. Если S=0, то невозможно уменьшить S и остаться в области целых неотрицательных значений, в этом случае процесс, вызывающий P-операцию, ждет, пока это уменьшение станет возможным. Успешная проверка и уменьшение также является неделимой операцией.

В частном случае, когда семафор S может принимать только значения 0 и 1, он превращается в блокирующую переменную. Операция P заключает в себе потенциальную возможность перехода процесса, который ее выполняет, в состояние ожидания, в то время как V-операция может при некоторых обстоятельствах активизировать другой процесс, приостановленный операцией P (сравните эти операции с системными функциями WAIT и POST).

Реализация критической секции с использованием системных функций WAIT(D) и POST(D)

Тупики Еще одна проблема синхронизации - взаимные блокировки, называемые также дедлоками (deadlocks), клинчами (clinch) или тупиками. При некотором стечении обстоятельств два процесса могут взаимно заблокировать друга. . Действительно, пусть "писатель" первым войдет в критическую секцию и обнаружит отсутствие свободных буферов; он начнет ждать, когда "читатель" возьмет очередную запись из буфера, но "читатель" не сможет этого сделать, так как для этого необходимо войти в критическую секцию, вход в которую заблокирован процессом "писателем

. (a) фрагменты программ А и В, разделяющих принтер и диск; б) взаимная блокировка (клинч); (в) очередь к разделяемому диску; (г) независимое использование ресурсов

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

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

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

Схема обработки прерывания 1. Аппаратное обеспечение сохраняет в стеке счетчик команд и т. п. 2. Аппаратное обеспечение загружает новый счетчик команд из вектора прерываний. 3. Процедура на ассемблере сохраняет регистры. 4. Процедура на ассемблере устанавливает новый стек. 5. Запускается программа обработки прерываний на С. (Она обычно считывает и буферизует входные данные. ) 6. Планировщик выбирает следующий процесс. 7. Программа на С передает управление процедуре на ассемблере. 8. Процедура на ассемблере запускает новый процесс.

Планирование Циклическое планирование: а — список процессов в состоянии готовности; б — список процессов в состоянии готовности после того, как процесс В исчерпал свой квант времени

Планирование согласно приоритетам Алгоритм планирования с четырьмя классами приоритетов

Планирование с несколькими очередями «Самый короткий процесс — следующий» а — запуск четырех задач в исходном порядке; б — запуск в соответствии с алгоритмом

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

Планируемые системы реального времени Если в систему поступает m периодических событий, событие с номером i поступает с периодом Pi, и на его обработку уходит Сi секунд работы процессора, своевременную обработку всех потоков обеспечивает только выполнение условия

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

Вход и выход из критической области с помощью команды tsl

Семафоры используются три семафора: один для подсчета заполненных сегментов буфера (full), другой для подсчета пустых сегментов (empty), а третий предназначен для исключения одновременного доступа производителя и потребителя (mutex) к буферу.

Мониторы Монитор — набор процедур, переменных и других структур данных, объединенных в особый модуль или пакет. Процессы могут вызывать процедуры монитора, но у процедур, объявленных вне монитора, нет прямого доступа к внутренним структурам данных монитора. monitor example integer i: condition с: procedure producer( ): . . end: procedure consumer( ): end monitor:

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

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

Требования к планированию 1. Равноправие — предоставление каждому процессу справедливой доли процессорного времени. 2. Использование процессора — поддержка постоянной занятости процессора. 3. Время отклика — быстрая реакция на запросы. 4. Оборотное время — минимизация времени, затрачиваемого на ожидание обслуживания и обработку задачи. 5. Пропускная способность — максимальное количество задач в час.