Теоретические сведения. Учебная программа обсуждена на заседании кафедры искусствознания

Учебная программа обсуждена на заседании кафедры искусствознания.

Протокол № ___ от _______________

Зав. Кафедрой, профессор Казин А.Л.

Учебная программа одобрена Советом факультета экранных искусств

Протокол № ____ от _______________

Декан факультета, профессор Ершов К.Г.

Лабораторная работа

Тема: «Управление процессами в операционной системе»

Цель работы: ознакомиться с организацией, взаимодействием, планированием процессов и потоков в Windows 200/XP

Теоретические сведения

Процессы и потоки в Windows 2000

В операционной системе Windows 2000 есть множество концепций для управления центральным процессором и объединения ресурсов.

Основные понятия

В операционной системе Windows 2000 поддерживаются традиционные процессы, способные общаться и синхронизироваться друг с другом. Каждый процесс содержит по крайней мере один поток, содержащий, в свою очередь, как минимум одно волокно (облегченный поток). Более того, для управления определенными ресурсами процессы могут объединяться в задания. Все вместе — задания, процессы, потоки и волокна — образует общий набор инструментов для управления ресурсами и реализации параллелизма как на однопроцессорных, так и на многопроцессорных машинах. Краткое описание этих четырех понятий приведено в таблице 1.

Таблица 1

Основные понятия, используемые для управления центральным процессором и ресурсами

Название	Описание
Задание	Набор процессов с общими квотами и лимитами
Процесс	Контейнер для ресурсов
Поток	Сущность, планируемая ядром
Волокно	Облегченный поток, управляемый полностью в пространстве пользователя

Задание в Windows 2000 представляет собой набор, состоящий из одного или нескольких процессов, управляемых как единое целое. С каждым заданием ассоциированы квоты и лимиты ресурсов, хранящиеся в соответствующем объекте задания. Квоты включают такие пункты, как максимальное количество процессов (не позволяющее процессам задания создавать бесконтрольное количество дочерних процессов), суммарное время центрального процессора, доступное для каждого процесса в отдельности и для всех процессов вместе, а также максимальное количество используемой памяти для процесса и для всего задания. Задания также могут ограничивать свои процессы в вопросах безопасности, например, запрещать им получать права администратора (суперпользователя) даже при наличии правильного пароля.

Процессы являются более важными, чем задания. Процессы представляют собой контейнеры для ресурсов. У каждого процесса есть 4-гигабайтное адресное пространство, в котором пользователь занимает нижние 2 Гбайт (в версиях Windows 2000 Advanced Server и Datacenter Server этот размер может быть по желанию увеличен до 3 Гбайт), а операционная система занимает остальную его часть. Таким образом, операционная система присутствует в адресном пространстве каждого процесса, хотя она и защищена от изменений с помощью аппаратного блока управления памятью MMU. У процесса есть идентификатор процесса, один или несколько потоков, список дескрипторов (управляемых в режиме ядра) и маркер доступа, хранящий информацию защиты. Процессы создаются с помощью вызова Win32, который принимает на входе имя исполняемого файла, определяющего начальное содержимое адресного пространства, и создает первый поток.

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

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

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

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

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

Операционная система не знает о смене волокон, так как все тот же поток продолжает работу. Так как операционная система ничего не знает о волокнах, то с ними, в отличие от заданий, процессов и потоков, не связаны объекты исполняющей системы. Для управления волокнами нет и настоящих системных вызовов. Однако для этого есть вызовы Win32 API. Они относятся к тем вызовам Win32 API, которые не обращаются к системным вызовам. Взаимосвязь между заданиями, процессами и потоками показана на рис. 1. (Несколько волокон могут объединяться в одном потоке, что не показано на рисунке.)

Рис. 1. Взаимосвязь между заданиями, процессами и потоками

Вызовы API для управления заданиями, процессами, потоками и волокнами

Новые процессы создаются при помощи функции Win32 API CreateProcess. У этой функции 10 параметров, каждый из которых может задаваться в различных вариантах. У вызова CreateProcess следующие 10 параметров:

1. Указатель на имя исполняемого файла.

2. Сама командная строка (непроанализированная).

3. Указатель на описатель защиты процесса.

4. Указатель на описатель защиты для начального потока.

5. Бит, управляющий наследованием дескрипторов.

6. Разнообразные флаги (например, режим ошибки, приоритет, отладка, консоли).

7. Указатель на строки окружения.

8. Указатель на имя текущего рабочего каталога нового процесса.

9. Указатель на структуру, описывающую начальное окно на экране.

10. Указатель на структуру, возвращающую вызывающему процессу 18 значений.

В операционной системе Windows 2000 не поддерживается какой-либо иерархии процессов, например «родительский-дочерний». Все созданные процессы равны. Поскольку один из 18 параметров, возвращаемых вызывающему процессу, представляет собой дескриптор нового процесса (что предоставляет контроль над новым процессом), существует негласная иерархия, заключающаяся в том, кто чьим дескриптором владеет. Хотя эти дескрипторы не могут напрямую передаваться другим процессам, у процесса есть способ создать дубликат дескриптора. Дубликат дескриптора может быть передан другому процессу и использоваться им, поэтому неявная иерархия процессов может просуществовать недолго.

Каждый процесс в Windows 2000 создается с одним потоком, но процесс может позднее создать дополнительные потоки. Создание потока проще создания процесса — у вызова CreateThread всего шесть параметров вместо десяти:

1. Описатель защиты (необязательный).

2. Начальный размер стека.

3. Адрес запуска.

4. Параметр, задаваемый пользователем.

5. Начальное состояние потока (готовый или блокированный).

6. Идентификатор потока.

Созданием потоков занимается ядро, поэтому оно имеет полное представление о потоках (потоки не реализуются полностью в пространстве пользователя, как это делается в некоторых других системах).

Межпроцессное взаимодействие

Для общения друг с другом потоки могут использовать широкий спектр возможностей, включая каналы, именованные каналы, почтовые ящики, вызов удаленной процедуры и совместно используемые файлы. Каналы могут работать в одном из двух режимов, выбираемом при создании канала: байтовом и режиме сообщений. Байтовые каналы работают так же, как и в системе UNIX. Каналы сообщений в чем-то похожи на байтовые каналы, но сохраняют границы между сообщениями, так что четыре записи по 128 байт будут читаться с другой стороны канала как четыре сообщения по 128 байт, а не как одно 512-байтовое сообщение, как это может слу­читься с байтовыми каналами. Также имеются именованные каналы, для которых существуют те же два режима. Именованные каналы, в отличие от обычных каналов, могут использоваться по сети.

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

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

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

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

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

Семафор создается при помощи API-функции CreateSemaphore, которая может задать для него начальное значение, а также установить максимальное значение. Семафоры представляют собой объекты в ядре и, таким образом, обладают дескрипторами или дескрипторами защиты. Копия дескриптора может быть получена с помощью функции DuplicateHandl e и передана другому процессу, в результате чего несколько процессов могут синхронизироваться, используя один семафор. Существуют вызовы для выполнения на семафоре операций up и down, они имеют несколько странные имена: ReleaseSemaphore (up) и WaitForSingleObject (down). Функции WaitForSingleObject также можно задать интервал времени, по истечении которого ждущий изменения состояния семафора поток будет отпущен, даже если семафор останется равным 0 (хотя использование таймеров приводит к конфликтам).

Мьютексы также представляют собой объекты ядра, используемые для синхронизации, но они проще семафоров, так как не содержат счетчиков. По существу, они являются блокировками, для работы с которыми используются функции API WaitForSingleObject и ReleaseMutex. Как и дескрипторы семафоров, дескрипторы мьютексов можно скопировать и передать другому процессу, так что потоки различных процессов смогут иметь доступ к одному и тому же мьютексу.

Третий механизм синхронизации основан на критических секциях (которые назывались критическими областями в других главах этой книги). Критические секции подобны мьютексам, но отличаются тем, что они связаны с адресным пространством создавшего их потока. Поскольку критические секции не являются объектами ядра, у них нет дескрипторов или дескрипторов защиты и они не могут передаваться от одного процесса другому. Блокирование и разблокирование выполняется функциями EnterCriticalSection и LeaveCri ticalSection соответственно. Поскольку эти функции API в основном выполняются в пространстве пользователя и обращаются к системным вызовам в ядро, только когда требуется блокирование потока, они работают быстрее, чем мьютексы.

В последнем механизме синхронизации используются объекты ядра, называемые событиями, которые бывают двух видов: сбрасываемые вручную и сбрасыва­емые автоматически. Каждое событие может находиться в одном из двух состояний: установленном и сброшенном. Поток может ждать какого-либо события с помощью функции WaitForSingleObject. Если другой поток вызывает событие при помощи функции SetEvent, результат зависит от типа события. Если событие является сбрасываемым вручную, то все ждущие его потоки отпускаются, а событие остается в установленном состоянии, пока его кто-либо не сбросит при помощи функции ResetEvent. Вслучае сбрасываемого автоматически события отпускается только один ожидающий его поток, а событие тут же сбрасывается. Кроме функции SetEvent существует также функция PulseEvent, отличающаяся от первой функ­ции тем, что если этого события никто не ждет, событие все равно само сбрасывается и, таким образом, пропадает впустую. При использовании функции SetEvent событие, которого никто не ждет, напротив, остается в установленном состоянии, так что как только какой-либо поток обратится к функции WaitForSingleObject, он будет тут же отпущен, после чего событие сбросится.

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

Интерфейс Win32 API содержит около 100 вызовов, работающих с процессами, потоками и волокнами. Значительное количество этих вызовов в той или иной мере имеет отношение к межпроцессному взаимодействию. Некоторые из обсуждавшихся выше функций, а также некоторые другие важные функции приведены в табл. 2.

Таблица 2.

Некоторые функции Win32 API для управления процессами, потоками и волокнами

Функция Win32 API	Описание
CreateProcess	Создать новый процесс
CreateThread	Создать новый поток в существующем процессе
CreateFiber	Создать новое волокно
ExitProcess	Завершить текущий процесс и все его потоки
ExitThread	Завершить этот поток
ExitFiber	Завершить это волокно
SetPriorityClass	Задать класс приоритета для процесса
SetThreadPriority	Задать приоритет для потока
CreateSemaphore	Создать новый семафор
CreateMutex	Создать новый мьютекс
OpenSemaphore	Открыть существующий семафор
OpenMutex	Открыть существующий мьютекс
WaitForSingleObject	Блокироваться на одном семафоре, мьютексе и т. д.
WaitForMultipleObjects	Блокироваться на множестве объектов, чьи дескрипторы перечисляются
PulseEvent	Перевести событие в сигнализирующее состояние, а затем вернуть в несигнализирующее
ReleaseMutex	Освободить мьютекс, чтобы другой поток мог его захватить
ReleaseSemaphore	Увеличить на единицу счетчик семафора
EnterCriticalSection	Захватить блокировку для критической секции
LeaveCriticalSection	Освободить блокировку для критической секции

Реализация процессов и потоков

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

1. Указанный в качестве параметра исполняемый файл изучается и открывается. Если это корректный исполняемый файл формата POSIX, OS/2, 16-разрядной системы Windows или MS-DOS, то для него устанавливается специальное окружение. Если это корректный .ехе файл 32-разрядного интерфейса Win32, в реестре проверяется, не является ли этот файл особенным в каком-либо смысле (например, должен выполняться под контролем отладчика). Все эти действия выполняются в режиме пользователя внутри kernel32.dll.

2. Выполняется обращение к системному вызову NtCreateProcess, чтобы создать пустой объект процесса и поместить его в пространство менеджера объектов. Создаются объект ядра и объект исполняющей системы. Менеджер процессов создает для объекта управляющий блок процесса и инициализирует его идентификатором процесса, квотами, маркером доступа и различными другими полями. Также создается объект секции, чтобы следить за адресным пространством процесса.

3. Когда динамическая библиотека kernel32.dll снова получает управление, она обращается к системному вызову, NtCreateThread, чтобы создать начальный поток. Для потока создаются стек режима пользователя и стек режима ядра. Размер стека указан в заголовке исполняемого файла.

4. Библиотека kernel32.dll посылает подсистеме окружения Win32 сообщение, в котором содержится информация о новом процессе, и передает ей дескрипторы процесса и потока. Данные о процессе и потоке помещаются в таблицы подсистемы, в результате чего у нее оказывается полный список всех процессов и потоков. Подсистема отображает курсор в виде стрелки с песочными часами, чтобы сообщить пользователю, что что-то происходит, но курсор может использоваться. Когда процесс обращается к своему первому вызову графического интерфейса пользователя, чтобы создать окно, курсор удаляется (если обращения к вызову не поступает, курсор удаляется через 2 с).

5. В этот момент поток готов к работе. Он начинается с запуска процедуры системы поддержки исполнения программ для завершения инициализации.

6. Процедура системы поддержки исполнения программ устанавливает приоритет потока, сообщает загруженным библиотекам DLL о появлении нового потока, а также выполняет другую рутинную работу. Наконец, она запускает код основной программы потока.

Создание потока также состоит из нескольких этапов. Сначала работающий процесс обращается к функции CreateThread, которая вызывает процедуру внутри kemel32.dll. Эта процедура выделяет в вызывающем процессе память для стека режима пользователя, а затем обращается к системному вызову NtCreateThread, чтобы создать объект потока для исполняющей системы, проинициализировать его, а также создать и проинициализировать блок управления потоком. В этом случае уведомляется подсистема Win32, а информация о потоке помещается в ее таблицы. Затем поток начинает работу с собственной инициализации.

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

Планирование

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

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

2) Поток сигнализирует каким-либо объектом (например, выполняет операцию up на семафоре). П оток находится в ядре. После сигнализирования объектом он может продолжать работу, так как эта операция никогда не приводит к блокированию. Тем не менее поток должен запустить процедуру планировщика, чтобы посмотреть, нет ли среди готовых к работе потока с более высоким приоритетом. Если такой поток есть, происходит переключение на этот поток, так как операционная система Windows 2000 является системой с приоритетным прерыванием (то есть переключение потока может произойти в любой момент, а не только тогда, когда у текущего потока закончится выделенный ему квант времени).

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

Планировщик вызывается при еще двух условиях:

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

2. Истекает ожидание таймера. Поток выполнил операцию down на семафоре или блокировался на каком-либо другом объекте, но установленное время ожидания истекло. И в этом случае обработчик прерываний должен установить DPC в очередь, чтобы она не была запущена во время работы обработчика прерываний. Если в результате тайм-аута поток оказался готовым к работе, будет запущен планировщик, и если ничего более важного в данный момент нет, будет выполнен отложенный вызов процедуры.

Алгоритм планирования. Интерфейс Win32 API содержит два вызова, предоставляющих процессам возможность влиять на планирование потоками. Алгоритм планирования в большой степени определяется этими вызовами. Во-первых, есть вызов SetPriori tyCl ass, устанавливающий класс приоритета всех потоков вызывающего процесса. К допустимым значениям приоритета относятся: реального времени, высокий, выше нормы, нормальный, ниже нормы и неработающий.

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

Планировщик работает следующим образом. В системе существует 32 уровня приоритета, пронумерованные от 0 до 31. 42 комбинации отображаются на эти 32 приоритета в соответствии с табл. 3. Число в таблице определяет базовый приоритет потока. Кроме того, у каждого потока есть текущий приоритет, который может быть выше (но не ниже) базового приоритета и о котором мы скажем несколько слов.

Чтобы использовать эти приоритеты для планирования, система содержит массив из 32 элементов, соответствующих приоритетам от 0 до 31, полученных из табл. 3. Каждый элемент массива указывает на начало списка готовых потоков с соответствующим приоритетом. Базовый алгоритм планирования состоит из процедуры сканирования массива от приоритета 31 до приоритета 0. Как только найден непустой элемент, выбирается поток в начале очереди и запускается на один квант времени. Когда квант истекает, поток направляется в конец очереди своего приоритета, а следующим выбирается поток в начале очереди. Другими словами, когда есть несколько готовых потоков с наивысшим уровнем приоритета, они запускаются поочередно, получая каждый по одному кванту времени. Если готовых потоков нет, запускается бездействующий поток.

Таблица 3.

Преобразование приоритетов Win32 в приоритеты Windows 2000

Приоритеты потоков Win32	Классы приоритетов процессов в Win32	Ниже нормы	Бездействующий
Реального времени	Высокий	Выше нормы	Нормальный
Самый высокий
Выше нормы
Приоритеты потоков Win 32	Классы приоритетов процессов в ghbjhbntnjd ghjwtccjd d Цшт 32				Ниже нормы	Бездействующий
Реального времени	Высокий	Выше нормы	Нормальный
Критичный ко времени
Самый высокий
Выше нормы
Нормальный
Ниже нормы
Самый низкий
Неработающий

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

Массив заголовков очередей показан на рис. 2. Из рисунка видно, что в действительности существует четыре категории приоритетов: реального времени, пользовательские, нулевой и бездействующий, равный -1. Приоритеты с 16 по 31 называются приоритетами реального времени, но они таковыми не являются. Выполняющимся с этими приоритетами потокам не дается никаких гарантий и никакие сроки исполнения не учитываются. Это просто более высокие приоритеты, чем приоритеты с 0 по 15. Однако приоритеты с 16 по 31 зарезервированы для самой системы и для потоков, которым такой высокий приоритет явно задаст системный администратор. Обычные пользователи не могут запускать потоки со столь высокими приоритетами, и существует веская причина для этого. Если бы пользовательский процесс мог работать с приоритетом более высоким, чем, скажем, поток клавиатуры или мыши, то длительная работа такого высокоприоритетного потока без операций ввода-вывода (например, в цикле) повесила бы всю систему.

Рис. 2. Windows 2000 поддерживает 32 приоритета для потоков

Пользовательские потоки работают с приоритетами от 1 до 15. Устанавливая приоритеты процесса и потока, пользователь может отдавать преимущество тому или иному потоку. Нулевой поток работает в фоновом режиме и съедает все процессорное время, на которое больше никто не претендует. Его работа заключается в обнулении страниц для менеджера памяти. Его роль в системе будет обсуждаться ниже. Если и у этого потока нет работы, работает пустой поток. Однако он не является полноценным потоком.

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

Приоритет потока увеличивается:

1. Когда завершается операция ввода-вывода и освобождает ожидающий ее поток, приоритет потока увеличивается, чтобы дать шанс этому потоку быстрее запуститься и снова запустить операцию ввода-вывода. Величина, на которую увеличивается приоритет, зависит от устройства ввода-вывода. Как правило, это 1 для диска, 2 для последовательной линии, 6 для клавиатуры и 8 для звуковой карты.

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

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

Есть еще один случай, при котором система изменяет приоритеты потоков. Два потока работают вместе в задаче типа «производитель-потребитель». Работа производителя труднее, поэтому он получает более высокий приоритет, например 12, а потребитель получает приоритет 4. В определенный момент производитель заполняет до отказа общий буфер и блокируется на семафоре, как показано на рис. 3, а.

Рис.3. Пример инверсии приоритета

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

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

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

В системе Windows 2000 Professional длительность кванта по умолчанию равна 20 мс; на однопроцессорных серверах его значение равно 120мс; на многопроцессорных системах используются различные другие варианты в зависимости от частоты процессора. Более короткий квант улучшает работу интерактивных процессов, тогда как более длинный квант снижает количество переключений контекста и тем самым увеличивает производительность. Именно в этом смысл правой колонки табл. 3. Значения по умолчанию при желании могут быть увеличены в 2, 4 или 6 раз.

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

Задание:

1. Изучить работу утилиты PerfMon.exe (Performance monitor - системный монитор), входящий в состав ОС Windows NT/2000/XP.

2. Используя утилиту PerfMon, исследовать загрузку центрального процессора и подсистемы управления памятью (использование оперативной памяти и файла подкачки) при запуске ресурсоёмких приложений. Зарисовать диаграмму загрузки процессор.

3. Изучить назначение и работу диспетчера задач.

4. Используя диспетчер задач, определить какие процессы запущенны и сколько памяти они занимают. Записать протокол загрузки центрального процессора.

5. Используя диспетчер задач, исследовать загрузку центрального процессора и использование оперативной памяти и файла подкачки при запуске ресурсоёмких приложений. Зарисовать диаграмму загрузки процессор.

Содержание отчета:

1. Название практической работы.

2. Цель работы.

3. Задание к работе.

4. Результаты выполнения работы.

Контрольные вопросы:

1. Что такое задание, процесс, поток, волокно?

2. Какие виды механизмов взаимодействия процессов вы знаете?

3. Как реализуются процессы и потоки в Windows?

4. Как планируются процессы в Windows?