Понятие процесса и потока

Понятие процесса и потока

Концепция процесса. Диаграмма состояний процесса. Операции над процессами. Создание и завершение процесса. Иерархия процессов. Структуры управления процессами. Процессы-зомби. Системные вызовы для управления процессами. Процессы в Windows и UNIX. Процессы и потоки. Понятия мультизадачности и многопоточности. Потоки в пространстве пользова- теля. Потоки в ядре. Облегченные потоки. Потоки в Windows и UNIX. Всплывающие потоки. Понятие о прерываниях. Па- раллельные процессы. Независимые и взаимодействующие процессы. Сигналы UNIX. Сообщения Windows

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

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

Процесс – это выполняемая программа, включая текущие значения счетчика команд, регистров и переменных. С этой точки зрения, у каждого процесса есть собственный виртуальный процессор. При необходимости использования ресурса, процесс обращается с запросом на ресурс к супервизору ОС (центральному управляющему модулю), который может состоять из не- скольких, например, супервизор в/в, супервизор прерываний и т.д. При этом указывается вид ресурса и при необходимости, параметры (объем памяти, например, или необходимость в монопольном использовании ресурса). Управление передается ОС, переводя процессор в привилегированный режим работы. Ресурс может быть выделен процессу, если:

-          он свободен и в системе нет запросов на этот ресурс от задач с более высоким приоритетом

-          текущий запрос и ранее выданные запросы допускают совместное использование ресурсов

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

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

-          выполнение – все затребованные процессом ресурсы выделены. В этом состоянии в однопроцессорной системе в каждый момент времени может находиться только один процесс - готовность – ресурсы могут быть предоставлены, тогда процесс перейдет в состояние выполнения

-          ожидание – ресурсы не могут быть предоставлены, либо не завершена операция ввода-вывода.

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

За время существования процесс может неоднократно переходить из одного состояния в другое. Из состояния пассивности в состояние готовности процесс может перейти в следующих случаях:

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

-          при выборе из очереди планировщиком (характерно для пакетного режима)

-          по вызову из другой задачи (с помощью обращения к супервизору один процесс может создать, инициировать, остановить, уничтожить другой процесс)

-          по прерыванию от внешнего устройства

-          при наступлении запланированного времени запуска задачи.

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

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

-          переводится супервизором в состояние готовности в связи с появлением более приоритетной задачи или по окончанию выделенного кванта времени

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

Понятие последовательного процесса в ОС.

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

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

На каждый процесс выделяется специальная информационная структура – дескриптор процесса. В общем случае он со- держит:

-          идентификатор процесса PID – process identificator

-          тип/класс процесса, который определяет для супервизора некоторые правила предоставления ресурсов

-          приоритет процесса. В рамках класса в первую очередь обслуживаются процессы с более высоким приоритетом

-          переменная состояния, определяющую, в каком состоянии находится процесс

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

-          Информацию о ресурсах, которыми владеет процесс или имеет право пользоваться (указатели на файлы, информация о незавершенных операциях в/в)

-          Область памяти (адрес) для организации взаимодействия с другими процессами

-          Параметры времени запуска (момент активации и периодичность этого)

-          При отсутствии системы управления файлами – адрес задачи на диске в ее исходном состоянии и адрес, куда она вы-

гружается, если ее вытесняет другая.

Дескрипторы, как правило, постоянно находятся в оперативной памяти с целью ускорения работы супервизора. Для каждого состояния ОС ведет соответствующий список процессов, находящихся в этом состоянии. При изменении состояния процес- са, супервизор перемещает дескриптор из одного списка в другой. Для состояния ожидания может быть не один список, а несколько – по количеству соответствующих видов ресурсов. Часто в ОС заранее определяется максимальное количество дескрипторов задач. Существует и аппаратная поддержка дескрипторов задач. Так в процессорах i80x86 начиная с 80286 имеется регистр TR (task register), указывающий местонахождение сегмента состояния задачи TSS, где при переключении задач сохраняется содержание регистров.

В UNIX используются 2 структуры: u и proc. Ядро имеет массив структур proc, который называется таблицей процессов. Поскольку таблица находится в системном пространстве, она всегда доступна ядру. Область u является часть пространства процесса, т.е. видна только в момент выполнения процесса, и содержит данные, необходимые только в период выполнения процесса.

В UNIX существует только один системный запрос для создания процесса: fork. Этот запрос создает дубликат существую- щего, т.е. дочерний процесс полностью повторяет родительский процесс. Адресное пространство полностью повторяет ад- ресное пространство родительского процесса, аналогичны и строки окружения, эти процессы имеют одни и те же открытые файлы. Все переменные имеют одинаковые величины во время вызова fork как у родительского, так и у дочернего процесса, но как только данные скопированы для дочернего процесса, дальнейшие изменения в одном из них уже не влияют на дру- гой. Чтобы можно было отличить родительский процесс от дочернего, fork возвращает 0 для дочернего процесса и PID до- чернего процесса для родительского, –1 в случае ошибки. Вызов fork выполняет следующие действия:

-          резервирует пространство своппинга для данных и стека процесса-потомка

-          назначает новый идентификатор PID и структуру proc потомка

-          инициализирует структуру proc потомка. Часть полей копируются от родителя, часть устанавливается в 0, часть ус- танавливается в специфические для потомка значения

-          размещает карты трансляции адресов для потомка

-          выделяет область u потомка и копирует в нее содержимое области u родителя

-          изменяет ссылки области u на новые карты адресации и своппигна

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

-          Постранично дублирует области данных и стека родителя и модифицирует карты адресации потомка в соответствии с этими новыми страницами

-          Получает ссылки на разделяемые ресурсы, наследуемые потомком, такие как открытые файлы и рабочий каталог

-          Инициализирует аппаратный контекст потомка копируя текущие состояния регистров родителя

-          Процесс потомок становится выполняемым и помещается в очередь планировщика

-          Для потомка установить возвращаемое значение в 0 - Для родителя возвращается PID потомка

Очевидно, что если после fork сразу использовать exec, то в копировании образа памяти родительского процесса нет необ- ходимости. Один из подходов – метод копирования при записи. Страницы данных и стека родителя временно получают ат- рибут только для чтения и помечаются как копируемые при записи. Потомок получает собственную копию карт трансляции адресов, но использует те же самые страницы, что и родитель. Если любой из этих двух процессов попытается изменить страницу, произойдет исключительная ситуация, ядро запустит соответствующий обработчик, который, увидев пометку ко- пирования при записи, создаст копию страницы, которую уже можно изменять. Таким образом создаются копии только тех страниц памяти, которые изменяются в одном из процессов. Второй подход – использование системного вызова vfork, кото- рый не копирует страницы памяти. Процесс родитель предоставляет свое адресное пространство потомку и блокируется до тех пор, пока потомок не выполнит exec или exit, после чего ядро вернет родителю его адресное пространство и переведет его из состояния ожидания.

Для изменения образа памяти и запуска новой программы дочерний процесс выполняет системный вызов execve. Вызов заменяет весь образ памяти процесса файлом, имя которого указано в первом параметре. Как правило, у вызова имеется еще два параметра: указатель на массив аргументов и указатель на массив переменных окружения. Например, при выполнении команды cp file1 file2 произойдет следующее: оболочка с помощью fork создаст дочерний процесс, далее с помощью exec будет помещен в память файл cp (код программы копирования), а вторым аргументом вызова будет указатель на массив па- раметров, содержащих имена файлов. Вызов выполняет следующие действия:

-          Разбирает путь к исполняемому файлу и осуществляет доступ к нему

-          Проверяет, есть у процесса полномочия на выполнение файла

-          Читает заголовок, чтобы убедиться что файл исполняемый

-          Идентификаторы пользователя и группы UID и GID изменяются на соответствующие владельцу файла

-          Копируются передаваемые аргументы и переменные среды в пространство ядра, подготавливая текущее пользова- тельское пространство к уничтожению

-          Выделяется пространство своппинга для областей данных и стека

-          Освобождается старое адресное пространство и связанное с ним пространство своппинга

-          Выделяются карты трансляции адресов для нового текста, данных и стека

-          Устанавливается новое адресное пространство

-          Аргументы и переменные среды копируются обратно в новый стек приложения

-          Все обработчики сигналов сбрасываются в действия по умолчанию

-          Инициализируется аппаратный контекст

Родительский процесс может ожидать окончания дочернего с помощью системного вызова waitpid. В качестве первого па- раметра выступает pid дочернего процесса, либо –1, если достаточно дождаться завершения любого из них. Вторым пара- метром передается указатель, который будет установлен на статус завершения дочернего процесса. Вызов wait тоже позво- ляет ожидать завершения работы потомка, однако без указания какого именно. Wait возвращает PID завершившегося про- цесса, освобождает его структуру proc, сохраняет его статус выхода в соответствующей переменной. Если работу завершили несколько дочерних процессов, то обработан будет только один из них. Пример кода создания дочернего процесса: if (fork()!=0)

{waitpid(-1,&status,0); }     // код родительского процесса else execve (command, parameters,0);                // а это дочерний процесс

Вызов exit завершает процесс. При этом выполняется:

-          Отключаются все сигналы

-          Закрываются открытые файлы

-          Освобождается файл программы и другие ресурсы

-          Делается запись в журнал

-          Сохраняются данные об использованных ресурсах и статус выхода в структуре proc

-          Состояние процесса изменяется на SZOMB, его структура proc помещается в список процессов-зомби

-          Все потомки процесса получают в качестве нового родителя системный процесс init

-          Освобождается адресное пространство, область u, карты трансляции адресов и пространство своппинга -   Родителю процесса посылается сигнал SIGCHLD

-          Будится родительский процесс

-          Вызывается swtch для перехода к следующему процессу

После выполнения вызова процесс находится в состоянии зомби. В этом состоянии не освобождена структура proc, данные из которой могут понадобиться родителю. Соответственно родитель и отвечает за ее освобождение. Здесь существует про- блема. Если родительский процесс завершен раньше дочернего, то дочерний усыновляется процессом init. Все в порядке. Если дочерний завершается раньше, а родитель не вызывает wait, который освобождает proc, то процесс-зомби так и оста- нется. Эти процессы видны при вызове ps, однако завершить их невозможно, поскольку они уже завершены. Кроме того, они продолжают занимать структуру proc, число которых в таблице процессов как правило, ограничено.

В Windows и созданием процесса и запуском в нем нужной программы управляет функция CreateProcess. Родительский и дочерний процессы имеют собственные адресные пространства, различные изначально. Процессы в Windows идентифицируются как дескрипторами, так и идентификаторами процессов. GetCurrentProcess и GetCurrentProcessId возвращают дескриптор и идентификатор соответственно. Завершается процесс функцией ExitProcess. Ожидание завершения процесса или группы процессов выполняется функциями WaitForSingleObject и WaitForMultipleObject. Во втором случае происхо- дит ожидание либо одного из указанных объектов либо всех. Выполнение дочернего процесса не зависит от родительского. Функция CreateProcess выполняет следующие действия:

-          открывается исполняемый файл

-          если файл не является Windows-приложением, ищется образ поддержки (программа) для запуска этого приложения

-          создается и инициализируется объект процесса исполнительной системы ОС

-          создается первичный поток – стек, контекст и объект потока исполнительной системы

-          подсистема Windows получает сообщение о создании нового процесса и потока

-          начинается выполнение первичного потока

-          в контексте нового процесса и потока инициализируется адресное пространство и начинается выполнение программы

Процессы и потоки.

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

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

Возможны два основных варианта реализации потоков – на уровне пользователя и на уровне ядра. В первом случае у каждого процесса имеется своя собственная таблица

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

При реализации на уровне ядра, таблица потоков единая для всех процессов. Ядро в общем случае может при блокировании потока выбрать новый, не принадлежащий текущему процессу. В терминологии UNIX такие потоки часто называют “легко- весными процессами”. (LWP, lightweight process). В отличие от пользовательских потоков, при блокировке одного LWP ос- тальные продолжают работать. Поскольку все потоки LWP планируются на выполнение ядром независимо друг от друга, но в отличие от полновесных процессов, разделяют общее адресное пространство, при доступе к переменным, используемым несколькими LWP, требуется применение специальных механизмов синхронизации на уровне ядра. Все запросы, которые могут блокировать поток, реализуются как системные, что увеличивает временные издержки. Чтобы их снизить некоторые системы после завершения потока не уничтожают его структуры, только помечая, как неработающий. При запросе на созда- ние нового потока используются уже готовые структуры. В Windows именно потоки, а не процессы являются объектами диспетчеризации. Т.е. планировщик выбирает из очереди готовый поток, а не процесс.

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

Потоки в Windows создаются функцией CreateThread. Завершить поток можно функцией ExitThread, либо возврат из функции потока с использованием кода завершения в качестве возвращаемого значения. Функции GetCurrentThread и GetCurrentThreadId позволяют получить дескриптор и соответственно идентификатор вызывающего потока, OpenThread позволяет получить дескриптор потока по известному идентификатору. Функции SuspendThread и ResumeThread позво- ляют приостановить поток и возобновить его выполнение. Ожидание завершения потока выполняется функциями Wait- ForSingleObjects и WaitForMultipleObjects. CreateRemoteThread позволяет создать поток в другом процессе.

POSIX описывает стандарт библиотеки pthreads для поддержки потоков. Поддержка включена в ряд реализаций UNIX и Linux. Соответственно создание и завершение потока соответствуют системные вызовы pthread_create и pthread_exit, для организации ожидания завершения потока pthread_join.

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

В архитектуру современных процессоров включена возможность работать с задачами (Task), объединяющими в себе поня- тие потока и процесса. Это при разработке ОС позволяет построить соответствующие дескрипторы как для процесса, так и для потока.

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

-          прием запроса на прерывание и его идентификация

-          запоминание состояния прерванного процесса. Сохраняется счетчик команд, регистры процессора, а также другая ин- формация.

-          Передача управления подпрограмме обработки прерываний. В простейшем случае в счетчик команд заносится началь- ный адрес обработчика, а в регистры – информация из слова состояния.

-          Сохранение информации о прерванной программе, не сохраненную ранее аппаратными средствами - Обработка прерывания

-          Восстановление информации прерванного процесса

-          Возврат управления прерванной программе

Первые три шага реализуются аппаратно, остальные – программно.

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

Внешние прерывания вызываются асинхронными событиями, происходящими вне прерываемого процесса, например:

-          прерывание от таймера

-          прерывание от ВУ на ввод-вывод - прерывание по нарушению питания

-          прерывание от оператора

-          прерывание от другого процесса или системы

Внутренние прерывания вызываются событиями, связанными с работой процессора и синхронны относительно его опера- ций:

-          нарушение адресации (используется запрещенный или несуществующий адрес, обращение к отстутствующей странице виртуальной памяти)

-          ошибочный код операции (неизвестная процессору команда)

-          деление на ноль

-          переполнение

-          обнаружение ошибок четности и пр.

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

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

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

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

-          С абсолютными приоритетами. Всегда обслуживается прерывание с наивысшим приоритетом. Для реализации маски- руются все запросы с низшим приоритетом. При этом возможно многоуровневое прерывание.

-          По принципу стека. Любой приходящий запрос прерывает текущее обслуживание. В этом случае маски не накладыва- ются.

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

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

В UNIX для оповещения процесса о возникновении системных событий используются сигналы. Они же могут использо- ваться и как средство синхронизации и обмена данными. Сигналы позволяют вызвать какую-либо процедуру при возникно- вении события из их определенного набора. Процесс состоит из двух этапов – генерирования и доставки. Число поддержи- ваемых сигналов в различных системах различно. POSIX определяет стандартные символические имена для наиболее часто используемых сигналов. Каждый сигнал обладает некоторым действием, которое производится ядром системы, если про- цесс не имеет альтернативного обработчика. Их всего пять:

-          аварийное завершение abort. Завершает процесс, создавая дамп состояния процесса, который может использоваться в дальнейшем при отладке и т.д.

-          выход exit. Завершает процесс без создания дампа

-          игнорирование ignore. Игнорировать сигнал

-          Остановка stop. Приостанавливает процесс

-          Продолжение continue. Возобновляет работу приостановленного процесса

Процесс может переопределить действия по умолчания для любого сигнала, в т.ч. и запуск определенной в приложении фйнкции – обработчика сигнала. Процесс может временно блокировать сигнал. Сигналы SIGKILL и SIGSTOP являются спе- циальными, и процесс не может их блокировать, игнорировать или определять собственные обработчики. Основными ис- точниками сигналов являются: - исключительные состояния,

-          другие процессы

-          прерывания от терминала, например при нажатии определенной комбинации клавиш

-          управление заданиями, это извещение родителя о завершении или приостановке дочернего процесса, управление фоно- выми и текущим процессами;

-          квоты, при превышении процессом временных квот или размера файла - уведомления, например, о готовности устройства в/в - будильники.

Для поддержки механизма сигналов в структуре u содержатся следующие поля: u_signal[] вектор обработчиков для каждого сигнала

u_sigmask[] маски сигналов, ассоциированных с каждым обработчиком u_sigaltstack указатель на альтернативный стек сигнала

u_sigonstack маска сигналов, обрабатываемых с альтернативным стеком u_oldsig набор обработчиков для имитации базового механизма сигналов Структура proc также содержит несколько полей :

p_cursig текущий сигнал, обрабатываемый в данный момент p_sig маска ожидающих сигналов p_hold маска блокируемых сигналов p_ignore маска игнорируемых сигналов

В Windows для оповещения процессов о возникновении каких-либо событий используется концепция сообщений. Сущест- вует около 900 различных типов сообщений. Каждый тип сообщений имеет свой числовой идентификатор. В случаях, когда пользователь выбирает пункт меню, щелкает на кнопке, или выбирает из списка и т.д. формируется сообщения специального типа WM_COMMAND или WM_NOTIFY. Сообщения этих типов принято называть командами. Процесс может передавать сообщения с помощью функции Win32 API PostMessage или

PostThreadMessage, в первом случае указывается, какому окну передается сообщение, во втором – какому потоку. Остальные параметры указывают собственно сообщение, и дополнитель- ную информацию. Сообщение помещается в специальную очередь сообщений, связанную с потоком, которому они посланы. Получить сообщение из этой очереди можно функцией GetMessage. Идентификаторы от 0 до WM_USER – 1 используются для сообщеинй Windows, от WM_USER до

0x7FFF, от 0x8000 до 0xBFFF зарезервированы для последующего использования Windows, от

0xC000 до 0xFFFF строковые сообщения пользователя, от 0xFFFF и выше – зарезервированы Windows.