Операционные системы

2. Последовательный процесс есть работа, производимая последовательным процессором при выполнении программы с ее данными. Процесс не эквивалентен программе и это не процессор, а пара (процессор и программа) при выполнении.

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

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

Лекция 4. Концептуальные основы ОС. Ресурс. Дисциплины распределения ресурсов, используемые в ОС. Концепция прерывания

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

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

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

само понятие ресурса;

роль стратегии управления ресурсами;

отношение между управляемыми ресурсами и программами, которыми они распределяются.

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

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

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

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

среднее время выполнения заданий;

число запаздывающих ответов;

максимально допустимое время ответа;

степень загрузки оборудования;

загрузку оборудования, при условии, что время ответа не превышает некоторого установленного значения;

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

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

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

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

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

Стратегии управления ресурсами могут меняться в зависимости от размеров программ.

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

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

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

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

Концепция прерываний

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

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

Прерывания делятся на три категории:

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

внутренние аппаратные, вырабатываемые самим процессором;

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

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

ошибка процессора (деление на 0, несовпадение четности и т.д.);

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

прерывания от каналов ввода-вывода.

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

Можно организовать различные схемы структур прерываний.

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

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

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

И наконец, можно рассматривать большее число классов прерываний.

Основным механизмом функционирования MS DOS является система прерываний.

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

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

В IBM-совместимом компьютере имеется 256 различных прерываний с номерами от 0 до OFFH (номера представлены в виде шестнадцатеричных цифр). В самом начале адресного пространства памяти машины расположена таблица адресов прерываний. Каждый из этих адресов указывает на процедуру в памяти, которая будет исполнена в результате возникновения прерывания. Адреса программ прерываний чаще называют векторами. Каждый вектор прерывания имеет длину 4 байта. Таким образом, вектора располагаются в памяти компьютера с адреса 0 до 3FFH. При возникновении любого прерывания, значения регистра флагов процессора и текущее значение счетчика команд CS:IP автоматически сохраняются в стеке, прерывания временно запрещаются и выполняется переход по вектору прерывания.

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

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

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

Ядро Операционной Системы

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

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

Эти функции имеют следующие свойства:

они являются резидентными, т.е. постоянно находятся в оперативной памяти, хотя не все резидентные программы входят в ядро;

чаще всего они выполняются в режиме управления, не допуская прерываний, т.е. являются примитивами;

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

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

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

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

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

Выводы

1. Ресурс - это некоторая абстрактная структура с целым рядом атрибутов, характеризующих способы доступа к этим структурам и её физическое представление в системе.

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

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



Лекция 5. Средства, механизмы, подсистемы ОС. Подсистема управления вводом-выводом. Подсистема управления данными

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

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

механизм мультипрограммирования;

механизм управления;

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

механизмы защиты и привилегированных команд;

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

Перечисленные механизмы, в зависимости от стратегии их реализации, могут быть как причислены к ОС, так и нет.

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

Подсистемы

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

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

Рассмотрим различия системных служб и подсистем.

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

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

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

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

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

Но любое распределение функций порождает проблемы.

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

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

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

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

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

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

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

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

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

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

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

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

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

Теперь рассмотрим различные специализированные подсистемы.

Подсистемы управления базами данных

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

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

Существуют две точки зрения на этот вопрос:

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

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

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

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

Подсистема поддержки ввода-вывода

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

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

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

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

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

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

адрес внешнего устройства;

функции обмена;

адрес данных на внешнем устройстве.

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

Выводы

1.Система - это совокупность объектов и отношений между ними.

2. Среда выполнения - совокупность памяти, команд процесса и прикладных программ, где программа становится активной.

3. Подсистема - это набор функций, работающих как одно целое.

Лекция 6. Механизмы управления процессами. Средства взаимодействия параллельных процессов. Задачи синхронизации. Семафорная техника синхронизации и упорядочения процессов

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

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

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

Рассмотрим способы связи программ при первом способе синхронизации ресурсов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если программа-распределитель, обслуживающая запрос программы А, первой обращается к таблице, то она меняет сигнал семафора на 0, перекрывая, тем самым, доступ к данной информации другим программам. Затем программа-распределитель, обслуживающая запрос программы В, также пытается обратиться к таблице, для чего обращается к семафору с командой P. Однако семафор закрыт. Но, получив отказ, предположим, что программа снова и снова будет пытаться выполнить P-операцию, до тех пор, пока программа, захватившая таблицу, не выполнит V-операцию, и новая программа получит доступ к таблице.

Заметим, что в многопроцессорной системе желательно иметь универсальный механизм выполнения P и V- операций, т.к. может возникнуть неприятная ситуация: процессор 1 обращается к семафору и пытается записать в сигнальный разряд 0, но до изменения сигнала к семафору обращается процессор 2, и, найдя семафор открытым, естественно, пытается захватить ресурс. Для обработки подобных ситуаций существуют специальные программно реализованные алгоритмы, но все же в большинстве мультипроцессорных систем обращение к семафору и изменение его состояний осуществляются с помощью единого механизма, реализуемого одной непрерывной командой.

Рассмотрим стратегии применения семафора.

Итак, простейший аппарат обеспечения исключительного доступа состоит из P и V примитивных механизмов. Каждая программа может применять этот аппарат, располагая информацией, идентифицирующей объект, к которому осуществляется право доступа, и средствами, позволяющими выполнить команду закрытия семафора и его открытия. Обычно в командах, соответствующих P-,V- операциям, одним из операндов служит имя замка, которое объявляется предварительно с помощью специальной команды описания. Фактически замок защищает не столько сам объект, сколько определенную часть выполняемой программы, так называемую критическую секцию. Все обращения к защищенному объекту непременно находятся внутри этой критической секции. Обычно для работы с замками применяются команды типа TEST AND SET (проверить и установить), сравнивающие содержимое семафорной ячейки с 0. На время выполнения этой команды доступ к этой ячейке в системе полностью закрыт. В этом случае могут возникнуть неприятные ситуации.

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

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

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

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

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

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

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

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

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

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

В некоторых ОС они разделяются стратегиями реализации.

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

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

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

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

Механизмы синхронизации в операционной системе Windows

Рассмотрим конкретную реализацию механизмов синхронизации в операционной системе Windows.

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

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

Анализ состояния осуществляется с помощью двух функций синхронизации -- WaitForSingleObject(HANDLE hObject, DWORD dwTimeout) и WaitForMultipleObject(DWORD cObjects, HANDLE *lphObjects, BOOL fWaitAll, DWORD dwTimeout). В функции WaitForMultipleObject() первый параметр означает число синхронизирующих объектов, второй -- адрес массива дескрипторов объектов, третий -- флаг ожидания (TRUE или FALSE), четвертый -- лимит времени ожидания в миллисекундах. Чтобы функция ожидала событие в течение неограниченного времени, то в качестве последнего параметра следует указать константу INFINITE. Усыпление потока -- это очень эффективная операция. Когда поток спит, он не потребляет системных ресурсов. Можно усыпить поток функцией Sleep(). А теперь преступим к подробному рассмотрению объектов.

Итак, критические секции. Критической секцией называется фрагмент программы, который должен обладать монопольным доступом к некоторым данным любого содержания и объема. Их особенность в том, что в отличие от остальных объектов синхронизации, они годятся только для потоков. Чтобы использовать критические секции в программе, следует определить глобальную переменную типа CRITICAL_SECTION. Эта переменная никак не связана с потоками и общими данными. Она лишь определяет, можно ли в данный момент предоставить доступ к общим данным тому или иному потоку. В первичном потоке следует выполнить инициализацию критической секции, вызвав функцию InitializeCriticalSection(). Фрагменты функций потоков, в которых осуществляется обращение к общим данным, следует защищать функциональными скобками EnterCriticalSection().LeaveCriticalSectoin(). Механизм критических секций очень прост. Например, работают два потока: в первом происходит операция и чтение/запись в общие данные, а второй лишь пытается работать с ними. Как только второй поток вызовет функцию EnterCriticalSection(), он остановится и будет ждать, пока первый не закончит работу с данными, вызвав функцию LeaveCriticalSectoin().

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

Надо отметить, что программа, в которой реализованы мьютексы, работает на порядок медленнее, чем программа с критическими секциями. Это обусловлено тем, что на выполнение функций EnterCriticalSection() и LeaveCriticalSectoin() уходит девять машинных команд, в то время как организация мьютексов и использование функций WaitForSingleObject() и WaitForMultipleObject() требуют 600 команд. Поэтому не стоит использовать мьютексы там, где можно обойтись без них.

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

События могут быть двух видов: со сбросом вручную и с автосбросом. События со сбросом вручную требуют явной установки состояния с помощью функции SetEvent(). События с автосбросом сбрасывают свое состояние, как только в управляемом потоке функция ожидания события обнаружит, что событие установлено, и соответственно разбудит поток. События с автосбросом удобно использовать в циклических фрагментах программы. Создать событие со сбросом вручную можно, задав в качестве значения параметра bInitialState константу TRUE (для события с автосбросом -- FALSE). Существует функция PulseEvent(), которая устанавливает в качестве параметра событие в свободное состояние и, после того как все ожидающие потоки проснулись, тут же снова сбрасывает его, предотвращая повторное выполнение защищенных участков потоков, пока это событие не будет явно установлено в управляющем потоке.

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

Выводы

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

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

3. Существуют два типа механизмов, обеспечивающих временный запрет на доступ к определенному ресурсу, названных соответственно P- и V- семафорами.



Лекция 7. Организация оперативной памяти. Структура, основные понятия и принципы виртуализации памяти. Основы логической организации виртуальной оперативной памяти

Функции ОС по управлению памятью

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

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

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

Функциями ОС по управлению памятью в мультипрограммной системе являются:

отслеживание свободной и занятой памяти;

выделение памяти процессам и освобождение памяти по завершении процессов;

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

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

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

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

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

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

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

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

Рис. 5. Структуры микропрограммной памяти:

а - процессор (Р) и основная память (М);

...