Дескрипторы в диспетчере задач это

В этой статье мы поговорим на такие темы, как процессы и потоки, дискрипторы процесса, поговорим о синзронизации потоков и затронем всеми любимый диспетчер задач windows.

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

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

Дескриптор – специальная информационная структура, которая заводится на каждый процесс (описатель задачи, блок управления задачей).

В общем случае дескриптор содержит следующую информацию:

1. Идентификатор процесса.
2. Тип (или класс) процесса, который определяет для супервизора некоторые правила предоставления ресурсов.
3. Приоритет процесса.
4. Переменную состояния, которая определяет, в каком состоянии находится процесс (готов к работе, в состоянии выполнения, ожидание устройства ввода-вывода и т.д.)
5. Защищенную область памяти (или адрес такой зоны), в которой хранятся текущие значения регистров процессора, если процесс прерывается, не закончив работы. Эта информация называется контекстом задачи.
6. Информацию о ресурсах, которыми процесс владеет и/или имеет право пользоваться (указатели на открытые файлы, информация о незавершенных операциях ввода/вывода и т.п.).
7. Место (или его адрес) для организации общения с другими процессами.
8. Параметры времени запуска (момент времени, когда процесс должен активизироваться, и периодичность этой процедуры).
9. В случае отсутствия системы управления файлами – адрес задачи на диске в ее исходном состоянии и адрес на диске, куда она выгружается из оперативной памяти, если ее вытесняет другая.

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

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

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

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

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

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

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

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

Для повышения быстродействия процессов есть возможность задействовать внутренний параллелизм в самих процессах.

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

Можно выделить следующие отличия потоков от процессов:

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

Главное, что обеспечивает многопоточность, — это возможность параллельно выполнять несколько видов операций в одной прикладной программе. За счет чего реализуется эффективное использование ресурсов ЦП, а суммарное время выполнения задач становится меньше.

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

Диспетчер задач WINDOWS

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

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

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

На вкладке Процессы отображаются сведения о выполняющихся на компьютере процессах: сведения об использовании ЦП и памяти, счетчике процессов и некоторые другие параметры:

На вкладке Быстродействие, отображаются сведения о счетчике дескрипторов и потоках, параметры памяти:

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

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

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

Пример. Задача ведения базы данных клиентов некоторого предприятия.

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

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

Оба эти потока совместно работают над общим файлом базы данных, используя однотипные алгоритмы:

1. Считать из файла БД в буфер запись и клиенте с заданным идентификатором.
2. Ввести новое значение в поле Заказ (для потока А) или оплата (для потока В).
3. Вернуть модифицированную запись в файл БД.

Обозначим шаги 1-3 для потока А как А1-А3, а для потока В как В1-В3. Предположим, что в некоторый момент поток А обновляет поле Заказ записи о клиенте N. Для этого он считывает эту запись в свой буфер (шаг А1), модифицирует значение поля Заказ (шаг А2), но внести запись в базу данных не успевает, так как его выполнение прерывается, например, вследствие истечение кванта времени.

Предположим, что потоку В также потребовалось внести сведения об оплате относительно того же клиента N. Когда подходит очередь потока В, он успевает считать запись в свой буфер (шаг В1) и выполнить обновление поля Оплата (шаг В2), а затем прерывается. Заметим, что в буфере у потока В находится запись о клиенте N, в которой поле Заказ имеет прежнее, не измененное значение.

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

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

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

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

Реализация критических секций с использованием блокирующих переменных имеет существенный недостаток: в течение времени, когда один процесс находится в критической секции, другой процесс, которому требуется тот же ресурс, будет выполнять рутинные действия по опросу блокирующей переменной, бесполезно тратя процессорное время. Для устранения таких ситуаций может быть использован так называемый аппарат событий. С помощью этого средства могут решаться не только проблемы взаимного исключения, но и более общие задачи синхронизации процессов. В разных операционных системах аппарат событий реализуется по-своему, но в любом случае используются системные функции аналогичного назначения, которые условно называются 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.

Взаимоблокировка процессов

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

При параллельном исполнении процессов могут возникать ситуации, при которых два или более процесса все время находятся в заблокированном состоянии. Самый простой случай – когда каждый из двух процессов ожидает ресурс, занятый другим процессом. Из-за такого ожидания ни один из процессов не может продолжить исполнение и освободить в конечном итоге ресурс, необходимый другому процессу. Эта тупиковая ситуация называется дедлоком (dead lock), тупиком, клинчем или взаимоблокировкой.

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

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

Проблема тупиков включает в себя следующие задачи:

1. предотвращение тупиков.
2. распознавание тупиков.
3. восстановление системы после тупиков.

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

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

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

3. Для чего каждая задача получает свой дескриптор. Какие поля, как правило, содержатся в дескрипторе процесса (задачи). Что такое контекст задачи.

1. Дескриптор ОС реального времени

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

Аппаратная поддержка дескрипторов задач. Для аппаратной поддержки работы ОС с дескрипторами задач в процессорах реального времени реализованы соответствующие механизмы. Начиная с Intel 80286 в котором реализован регистр наз: TR task Register, указывающий местонахождение сегмента состояния задачи, в котором при переключении с задачи на задачу автоматически сохраняется содержание регистров процессора. В современных ОС регистр задачи включает в себя сегмент состояния задачи TSS task state segment Дескриптор задачи больше по размерам чем TSS и включает в себя такие общие поля, как идентификатор задачи, имя, приоритет, тип, и т. д.

1. Активный и пассивный процессы.

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

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

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

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

1 Состояние выполнения: все затребованные процессом ресурсы выделены. В этом состоянии может находится только один процесс.

2 готовности к выполнению: ресурсы могут быть предоставлены этому процессу, тогда он перейдет в состояние выполнения.

3 Блокированное или ожидание: затребованные ресурсы не могут быть предоставлены или не завершена операция ввода/вывода.

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

2. Привилегированные и непривилегированные программные модули.

3. Объяснить понятие ресурса. Назвать виды и типы ресурсов.

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

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

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

Основные виды ресурсов.

1) Процессорное время

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

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

3) Программные модули. Системные программные ресурсы. Могут быть разделены между выполняющимися процессами. Программные модули могут быть однократно исполняемыми (исполняются правильно только один раз, и являются неделимыми ресурсами, более того их вообще можно не рассматривать как ресурс системы. Такие модули используются, как правило, при загрузке системы.) и многократно исполняемыми. Многократно исполняемые программные модули могут быть непривилегированные, привилегированные и реентерабельные.

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

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

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

Это может быть реализовано двумя способами с помощью статических методов определения памяти и динамических методов. Основной, часто используемый метод – метод динамической памяти. (рисунок нарисуй) 1) Привилегированный модуль, который заказывает в системной области памяти блок ячеек для хранения текущих промежуточных данных. 2) Основное тело реентерабельного программного модуля, которое может быть прервано работает в непривилегированном режиме. 3) Привилегированный модуль освобождающий в системной области памяти блок памяти, используемой для хранения промежуточных данных. Системная область памяти используется динамическим образом для буферизованного ввода/вывода и реентерабельной обработки.

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

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

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

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

1. Интерфейсные оболочки.

2. Понятие многопоточности.

3. Сколько и каких типов дескрипторов задач может быть в системе? От чего должно зависеть это число?

1. Вычислительный ресурс.

2. Обслуживание прерываний.

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

1. Системы программирования. Кросс-системы.

2. Понятие ресурса. Виды унд типы оных.

3. Процесс. Задача.

1. Дескриптор процесса.

Для того чтобы ОС могла управлять процессами она должна располагать всей необходимой для этого информацией. С этой целью на каждый процесс заводится опр. информационная структура, наз. дескриптором процесса или описатель задач или блок управления задачами. В общем случае структура дескриптора процесса: 1) Индентификатор процесса PI process identification; 2) тип или класс процесса, который определяет для супервизора некоторые правила предоставления ресурсов; 3) приоритет процесса, в соответствии с которым супервизор предоставляет ресурсы; 4) опред. в каком состоянии находится процесс. ; 5) защищенная область памяти или адрес такой зоны, в которой хранятся текущие значения регистров процессора. Если процесс прерывается, не закончив работы, эта информация называется контекстом задачи; 6) информацию о ресурсах, которыми процесс владеет или имеет право пользоваться (указатели на открытые файлы, информация о незавершенных процессах ввода/вывода); 7) место или его адрес для организации общения с другими процессами; 8) параметры времени запуска.

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

2. Внешние и внутренние прерывания.

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

1. Мультипрограммный и однопрограммный режимы работы вычислительной системы.

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

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

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

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

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

Не все ОС имеют 2 режима работы. Режимы работы бывают привилегированными (режим супервизора), пользовательскими, режим эмуляции.

Ресурс может быть выдан задаче по ее запросу если:

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

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

3 Ресурс используется задачей более низкого приоритета и может быть временно отобран.

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

2. Программные прерывания. Распределение прерываний по уровням приоритета.

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

1. Основные ф-ции ОС.

1. Операционные среды. Эмуляторы. Виртуальные машины.

2. Утилиты. Системные программные модули.

3. Для чего каждая задача имеет свой дескриптор.

1. Ресурсы вычислительной системы. Схема выделения ресурсов.

2. Обработка прерываний при участии супервизоров ОС.

1. Мультипрограммные ОС и ОС реального времени.

2. Работа реентерабельного программного модуля.

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

Процессы могут также получать дескрипторы объектов путем наследования дескрипторов во время создания процесса (когда создатель устанавливает флаг наследования дескрипторов при вызове функции CreateProcess, и дескриптор помечен как наследуемый либо в процессе своего создания, либо после создания путем использования Windows-функции SetHandleInformation) или путем получения продублированного дескриптора от другого процесса (см. Windows-функцию DuplicateHandle).

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

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

ПРИМЕЧАНИЕ. Компоненты исполняющей системы и драйверы устройств могут обращаться к объектам непосредственно, поскольку они запущены в режиме ядра и поэтому имеют доступ к структурам объекта в системной памяти. Но они должны объявить о своем использовании объекта, увеличив значение счетчика ссылок, чтобы объект не мог быть удален из памяти, пока он все еще используется.

Однако для успешного использования объекта драйверы устройств должны знать определение внутренней структуры объекта, а для многих объектов она не предоставляется. Взамен драйверам устройств рекомендуется использовать соответствующие API-функции ядра для изменения или чтения информации из объекта. Например, хотя драйверы устройств могут получить указатель на объект типа «процесс» (EPROCESS), его структура им не известна, и должны быть использованы API-функции вида Ps*.

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

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

Просмотр открытых дескрипторов.

Запустите Process Explorer и убедитесь, что нижняя панель включена и настроена на показ открытых дескрипторов. (View (Вид) — Lower Pane View (Просмотр нижней панели) — Handles (Дескрипторы)). После этого откройте окно командной строки и просмотрите таблицу дескрипторов для нового процесса Cmd.exe. Вы должны увидеть дескриптор открытого файла для текущего каталога. Например, предположим, что текущим является каталог C:UsersAdministrator, тогда Process Explorer покажет следующее.

Теперь поставьте Process Explorer на паузу, нажав клавишу Пробел или щелкнув на пунктах View (Вид) — Update Speed (Изменить скорость) — Pause (Пауза).

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

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

Монитор ресурсов также показывает открытые (именованные) дескрипторы для процессов, выбранных путем установки флажков напротив их имен. Вот как выглядят дескрипторы открытого окна командной строки.

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

Посмотрите, к примеру, на следующий, частично показанный вывод, полученный с помощью средства Handle при изучении дескрипторов файловых объектов, находящихся в таблице дескрипторов для процесса Cmd.exe до и после изменения каталога. По умолчанию Handle отфильтровывает нефайловые дескрипторы, пока не будет использован ключ –a, который приводит к выводу всех дескрипторов в процессе, аналогично Process Explorer.

C:>handle -p cmd.exe

Copyright (C) 1997-2011 Mark Russinovich

cmd.exe pid: 5124 Alex-LaptopAlex Ionescu

3C: File (R-D) C:WindowsSystem32en-USKernelBase.dll.mui

C:Windows>handle -p cmd.exe

Copyright (C) 1997-2011 Mark Russinovich

cmd.exe pid: 5124 Alex-LaptopAlex Ionescu

3C: File (R-D) C:WindowsSystem32en-USKernelBase.dll.mui

40: File (RW-) C:Windows

Дескриптор объекта является индексом в таблице дескрипторов, относящейся к конкретному процессу. Этот индекс указывается исполнительным блоком процесса (EPROCESS). Первый индекс дескриптора имеет значение 4, второй — 8 и т. д. Таблица дескрипторов процесса содержит указатели на все объекты, которые процесс открыл для своей работы.

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

ПРИМЕЧАНИЕ. В древовидной схеме таблиц таблица верхнего уровня может содержать страницу, заполненную указателями на таблицы среднего уровня, что позволяет иметь более половины миллиарда дескрипторов. Но чтобы поддержать совместимость со схемой дескрипторов, имевшейся в Windows 2000, и унаследовать ограничение в 16 777 216 дескрипторов, таблица верхнего уровня содержит не более 32 указателей на таблицы среднего уровня, устанавливая для более новых версий Windows тот же предел.

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

Например, для систем x86 страница составляет 4096 байт и поделена на записи таблицы дескрипторов размером 8 байт, которых получается 512 минус 1, то есть всего 511 записей в таблице дескрипторов самого низкого уровня. Таблица дескрипторов среднего уровня содержит полную страницу указателей на таблицы нижнего уровня, поэтому количество таблиц дескрипторов нижнего уровня зависит от размера страницы и размера указателя для платформы. Схема таблицы дескрипторов в системе Windows показана на следующем рисунке.

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

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

Чтобы увидеть, сколько дескрипторов можно создать на вашей системе, выполните следующие действия:

1. Загрузите с адреса http://live.sysinternals.com/WindowsInternals исполняемый файл Testlimit, необходимой вам версии для 32- или 64-разрядной версии Windows.
2. Запустите программу Process Explorer, щелкните на пункте View (Вид) — System Information (Информация о системе) — Memory (Память). Обратите внимание на текущий и максимальный размер выгружаемого пула.

Чтобы показать максимальный размер пула, Process Explorer должен быть правильно настроен на доступ к символам образа ядра, Ntoskrnl.exe. Оставьте это отображение системной информации работающим, чтобы можно было следить за использованием пула при запуске программы Testlimit.

1. Откройте окно командной строки.
2. Запустите программу Testlimit с ключом –h (путем ввода команды testlimit –h). Когда программа Testlimit не сможет открыть новый дескриптор, она покажет общее количество тех дескрипторов, которые ей удалось создать. Если количество будет меньше, чем примерно 16 миллионов, значит, вы, наверное, вышли за пределы выгружаемого пула памяти еще до достижения теоретического лимита дескрипторов на один процесс.
3. Закройте окно командной строки, благодаря чему будет прекращено выполнение процесса Testlimit и будут закрыты все открытые им дескрипторы.

Как показано на следующем рисунке, на системах x86 каждая запись дескриптора состоит из структуры с двумя 32-разрядными элементами: указателем на объект (с флагами) и маской предоставленных прав доступа. На 64-разрядных системах запись таблицы дескрипторов имеет длину 12 байт: 64-разрядный указатель на заголовок объекта и 32-разрядная маска доступа.

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

В команде !handle отладчика ядра используются три аргумента: !handle

Индекс дескриптора идентифицирует запись дескриптора в таблице дескрипторов. (Нуль означает «показать все дескрипторы».) Индекс первого дексритора имеет значение 4, второго — 8 и так далее. Например, после ввода команды !handle 4 будет показан первый дескриптор для текущего процесса.

Флаги можно указать в виде поразрядной маски, где разряд 0 означает «показать только информацию в записи дескриптора», разряд 1 означает «показать свободные (то есть неиспользуемые) дескрипторы, а разряд 2 означает «показать информацию об объекте, на который ссылается дескриптор». Следующая команда приводит к показу всех подробностей о таблице дескрипторов для процесса с идентификатором 0x62C:

lkd> !handle 0 7 62c

processor number 0, process 000000000000062c

Searching for Process with C >

SessionId: 1 Cid: 062c Peb: 7fffffdb000 ParentCid: 0558

DirBase: 7e401000 ObjectTable: fffff8a00381fc80 HandleCount: 111.

Handle table at fffff8a0038fa000 with 113 Entries in use

0000: free handle, Entry address fffff8a0038fa000, Next Entry 00000000fffffffe

0004: Object: fffff8a005022b70 GrantedAccess: 00000003 Entry: fffff8a0038fa010

Object: fffff8a005022b70 Type: (fffffa8002778f30) Directory

ObjectHeader: fffff8a005022b40fffff8a005022b40 (new version)

HandleCount: 25 PointerCount: 63

Directory Object: fffff8a000004980 Name: KnownDlls

0008: Object: fffffa8005226070 GrantedAccess: 00100020 Entry: fffff8a0038fa020

Object: fffffa8005226070 Type: (fffffa80027b3080) File

ObjectHeader: fffffa8005226040fffffa8005226040 (new version)

HandleCount: 1 PointerCount: 1

Directory Object: 00000000 Name: Program FilesDebugging Tools for Windows (x64)

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

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

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

Дескрипторы в этой таблице доступны только из режима ядра и в контексте любого процесса. Это означает, что функция режима ядра может сослаться на дескриптор в контексте любого процесса, не оказывая отрицательного влияния на производительность системы. Диспетчер объектов распознает ссылки на дескрипторы из таблицы дескрипторов ядра, когда установлен старший бит дескриптора, то есть когда ссылки на дескрипторы из таблицы дескрипторов ядра имеют значение, больше чем 0x80000000.

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

Поиск открытых файлов с помощью отладчика ядра.

Хотя для поиска дескрипторов открытых файлов можно воспользоваться такими средствами, как Process Explorer, Handle и OpenFiles.exe, они недоступны при просмотре аварийного дампа или удаленном анализе системы.

Вместо них для поиска дескрипторов, отрытых для файлов на том или ином томе, можно воспользоваться командой !devhandles.

1. Сначала нужно выбрать букву диска, представляющего интерес, и получить указатель на его объект Device. Для этого, как показано ниже, можно воспользоваться командой !object:

1: kd> !object Global??C:

Object: fffff8a00016ea40 Type: (fffffa8000c38bb0) SymbolicLink

ObjectHeader: fffff8a00016ea10 (new version)

HandleCount: 0 PointerCount: 1

Directory Object: fffff8a000008060 Name: C:

Target String is ‘DeviceHarddiskVolume1’

Drive Letter Index is 3 (C:)

1. Затем нужно воспользоваться командой !object, чтобы получить объект

Device для нужного имени тома:

1: kd> !object DeviceHarddiskVolume1

Object: fffffa8001bd3cd0 Type: (fffffa8000ca0750) Device

1. Теперь можно воспользоваться указателем на объект Device, вставив его в команду !devhandles. Каждый показанный объект указывает на файл:

Checking handle table for process 0xfffffa8000c819e0

Kernel handle table at fffff8a000001830 with 434 entries in use

SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000

DirBase: 00187000 ObjectTable: fffff8a000001830 HandleCount: 434.

0048: Object: fffffa8001d4f2a0 GrantedAccess: 0013008b Entry: fffff8a000003120

Object: fffffa8001d4f2a0 Type: (fffffa8000ca0360) File

ObjectHeader: fffffa8001d4f270 (new version)

HandleCount: 1 PointerCount: 19

Directory Object: 00000000 Name: WindowsSystem32LogFilesWMI