Для чего каждая задача получает соответствующий дескриптор

Для чего каждая задача получает соответствующий дескриптор

Глава 4. Управление задачами.

Для того, чтобы переключиться с одной задачи на другую, нужно чтобы процессор уже выполнял задачу, т.е. переключиться на задачу можно только из задачи. Это значит, что, во-первых, просто запустить первую задачу не получится, нужны некоторые хитрости, о которых мы поговорим позже. А во-вторых, из задачи нельзя «вернуться» в обычную процедуру, т.е. однажды запустив мультизадачность, программа остаётся в ней до перехода в режим реальных адресов.
Переключение задач происходит следующим образом. Процессор сначала сохраняет параметры текущей задачи в её TSS, заполняя все поля, начиная с CR3. Потом он ищет в GDT дескриптор указанной новой задачи и после проверки всех параметров дескриптора, начинает загружать регистры значениями из полей нового TSS. При этом процессор контролирует значение каждого системного и сегментного регистра и если обнаруживает ошибку, то генерирует исключение. После загрузки всех значений, процессор записывает в поле Link (смещение 0 в TSS) селектор дескриптора предыдущей задачи и немного корректирует значение EFLAGS. После всего этого процессор передаёт управление по адресу CS:EIP и задача начинает свою работу (или продолжает, если она была прервана).
Как видите, переключение задачи довольно-таки трудоёмкий процесс и требует много времени на различные проверки и обращения к памяти. Кроме того, переключение на задачу не кэшируется буфером ветвлений, представленных в процессорах, начиная с Pentium и при переключении на задачу происходит сброс конвейера команд, что потребует перед выполнением первой команды задачи потерю времени на ожидание, пока заполнится линия кэша из памяти и пока команды пройдут по конвейеру. Дополнительные задержки происходят из-за того, что при чтении новых значений из TSS, происходит загрузка CR3, а это значит, что производится сброс буферов TLB и процессору понадобится обращаться к каталогу и таблицам страниц, даже если он только что с ними работал (загрузка значения в CR3, даже того же самого, что в нём и было, приводит к сбросу буферов TLB).

Если переключение на задачу было произведено командой FAR CALL либо оно произошло в результате прерывания, то процессор после загрузки контекста новой задачи установит флаг NT в регистре EFLAGS. Это обеспечит возврат в старую задачу командой IRET.

Дескриптор TSS содержит в байте прав доступа поле DPL (Descriptor Privilege Level). В данном случае, для дескриптора TSS, это поле содержит уровень привилегий, с которого процессор разрешает переключение на эту задачу. Переключения с меньшего уровня привилегий также разрешены. Другими словами, при передаче управления должно выполняться следующее условие:

Источник

Внешние, внутренние и программные прерывания

2. Внешние, внутренние и программные прерывания.

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

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

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

Распределение прерываний по уровням приоритета:

3. Изобразить диаграмму состояния процесса. Пояснить все возможные переходы из одного состояния в другое.

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

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

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

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

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

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

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

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

Источник

Лекция 3: Физическая и логическая организация адресного пространства

Сегментная организация памяти в защищенном режиме

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

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

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

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

В случае если режим страничной адресации выключен (в регистре CR0 бит PG = 0), полученный линейный адрес равен физическому адресу искомого операнда или команды.

Рассмотрим подробнее процесс получения адреса операнда на примере команды

Формирование физического адреса операнда включает следующие действия (для сегментированного ЛАП):

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

Источник

Процессы и потоки, диспетчер задач windows, синхронизация потоков.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обозначим шаги 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), тупиком, клинчем или взаимоблокировкой.

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

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

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

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

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

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

Источник