Монолитная архитектура операционной системы

Предыстория

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

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

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

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

[править]Эра мейнфреймов

Первой в мире операционной системой считается GM OS (General Motors Operating System).

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

[править]Системы для оборудования IBM

Такое состояние дел продолжалось до 1960-х, когда IBM, лидирующий поставщик оборудования на тот момент, прекратила разработку существующих систем и направила усилия на создание серии машин System/360, все представители которой должны были использовать одинаковые инструкции и архитектуру ввода/вывода. IBM начала разрабатывать единую операционную систему для этих машин, OS/360. Проблемы, возникшие при создании OS/360, стали легендарными и были описаны в книге Мифический человеко-месяц Фредерика Брукса. Из-за различий в производительности и задержек при разработке программного обеспечения, вместо единой OS/360 было представлено семейство операционных систем под таким же названием.

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

§ OS/MFT для систем среднего класса. Она имела одного преемника, систему OS/VSI, развитие которой продолжалось до 1980-х.

§ OS/MVT для крупных машин. Она была сходна с OS/MFT (программы могли переноситься между ними без перекомпилирования), но имела более продвинутое управление памятью и систему разделения времени, TSO. MVT имела несколько наследников, включая z/OS.

§ DOS/360 для низших моделей System/360 имела несколько преемников, включая z/VSE, используемую до настоящего времени. Она значительно отличалась от OS/MFT и OS/MVT.

IBM поддерживает полную совместимость, поэтому разработанные в шестидесятых программы всё ещё можно запускать под z/VSE (если они создавались для DOS/360) или z/OS (если создавались для OS/MFT или OS/MVT) без изменений.

IBM разрабатывала, но официально не выпустила TSS/360, операционную сиcтему с разделением времени для S/360 Model 67.

Несколько операционных систем для архитектур IBM S/360 и S/370 были разработаны третьими фирмами, включая Michigan Terminal System (MTS) и MUSIC/SP.

[править]Другие операционные системы для мейнфреймов

Control Data Corporation разработала операционную систему SCOPE в 1960-х для обработки пакетных заданий. В сотрудничестве с Университетом Миннесота были созданы операционные системы KRONOS и NOS в 1970-х, которые поддерживали одновременный запуск заданий и разделение времени.

В конце 1970-х Control Data и Университет Иллинойс разработали машину PLATO, привнесшей множество инноваций для своего времени. Система использовала язык программирования TUTOR, что позволило создавать такие программы, как чат в реальном времени и многопользовательские графические игры.

UNIVAC, первый производитель коммерческих компьютеров, создала серию операционных систем EXEC. Как большинство ранних операционных систем для мейнфреймов, это были операционные системы, ориентированные на обработку пакетных заданий. В 1970-х UNIVAC выпустила систему Real-Time Basic.

Burroughs Corporation представила машину B5000 в 1961 с операционной системой MCP (Master Control Program). B5000 поддерживала исключительно языки высокого уровня и не поддерживала машинные языки или ассемблер; таким образом, MCP стала первой операционной системой, написанной только на высокоуровневом языке (ESPOL, диалект Алгола). MCP также представила несколько инноваций, включая первую коммерческую реализацию виртуальной памяти. MCP по сей день используется на компьютерах Unisys ClearPath/MCP.

Project MAC разработал Multics и General Electric Comprehensive Operating Supervisor (GECOS), в которых была введена концепция уровней привилегий.

Digital Equipment Corporation разработала множество операционных систем для своих различных линеек компьютеров, включая системы TOPS-10 и TOPS-20 с разделением времени для 36-битных машин PDP-10. До широкого рапространения UNIX, TOPS-10 пользовалась большой популярностью в университетах и раннем сообществе ARPANET.

[править]Миникомпьютеры и развитие UNIX

Начальные версии операционной системы UNIX были разработаны в AT&T Bell Laboratories в конце 1960-х. Будучи абсолютно бесплатной в первых версиях и легко модифицируемой, эта система завоевала большую популярность. Так как UNIX была написана на языке высокого уровня Си, её можно легко было перенести на новую аппаратную архитектуру. Эта переносимость позволила ей стать основной системой для второго поколения миникомпьютеров и первого поколения рабочих станций.

В то же время Digital Equipment Corporation создала простую операционную систему RT-11 для серии 16 битных машин PDP-11, и систему VMS для 32-битных компьютеров VAX.

Другой разработкой этого времени стала операционная система Pick от Microdata Corporation.

 

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

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

 

4

 

 

Каркас приложения Windows

Теперь; когда мы обсудили все необходимые основные понятия, можно начать разработку простейшего приложения Windows. Как уже отмечалось, все Windows-программы имеют определенные общие черты. Таким образом, в этом разделе мы разрабатываем программу, которая может быть каркасом или шаблоном для любого другого приложения. Технология написания программ для Windows предполагает широкое использование таких каркасов, поскольку, в отличие от DOS, простейшая программа для которой занимает около 5 строк, простейшая программа для Windows содержит примерно 50 строк.

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

1. Определение класса окна.

2. Регистрация класса окна.

3. Создание окна данного класса.

4. Отображение окна.

5. Запуск цикла обработки сообщений.

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

 

Требования к архитектуре операционной системы

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

Многоуровневая архитектура

7

1. Средства аппаратной поддержки ОС. Значительная часть функций ОС может выполняться аппаратными средствами [10]. Чисто программные ОС сейчас не существуют. Как правило, в современных системах всегда есть средства аппаратной поддержки ОС, которые прямо участвуют в организации вычислительных процессов. К ним относятся: система прерываний, средства поддержки привилегированного режима, средства поддержки виртуальной памяти, системный таймер, средства переключения контекстов процессов (информация о состоянии процесса в момент его приостановки), средства защиты памяти и др.

2. Машинно-зависимые модули ОС. Этот слой образует модули, в которых отражается специфика аппаратной платформы компьютера. Назначение этого слоя – "экранирование" вышележащих слоев ОС от особенностей аппаратуры (например, Windows 2000 – это слой HAL (Hardware Abstraction Layer), уровень аппаратных абстракций).

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

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

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

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

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

Рис. 3.10. Перенос основного объема функций ядра в пользовательское пространство

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

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

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

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

Рис. 3.11. Реализация системного вызова в микроядерной архитектуре

 

Управление процессами

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

Состояние процессов

В многозадачной (многопроцессной) системе процесс может находиться в одном из трех основных состояний:

ВЫПОЛНЕНИЕ - активное состояние процесса, во время которого процесс обладает всеми необходимыми ресурсами и непосредственно выполняется процессором;

ОЖИДАНИЕ - пассивное состояние процесса, процесс заблокирован, он не может выполняться по своим внутренним причинам, он ждет осуществления некоторого события, например, завершения операции ввода-вывода, получения сообщения от другого процесса, освобождения какого-либо необходимого ему ресурса;

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

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

В состоянии ВЫПОЛНЕНИЕ в однопроцессорной системе может находиться только один процесс, а в каждом из состояний ОЖИДАНИЕ и ГОТОВНОСТЬ - несколько процессов, эти процессы образуют очереди соответственно ожидающих и готовых процессов. Жизненный цикл процесса начинается с состояния ГОТОВНОСТЬ, когда процесс готов к выполнению и ждет своей очереди. При активизации процесс переходит в состояние ВЫПОЛНЕНИЕ и находится в нем до тех пор, пока либо он сам освободит процессор, перейдя в состояние ОЖИДАНИЯ какого-нибудь события, либо будет насильно "вытеснен" из процессора, например, вследствие исчерпания отведенного данному процессу кванта процессорного времени. В последнем случае процесс возвращается в состояние ГОТОВНОСТЬ. В это же состояние процесс переходит из состояния ОЖИДАНИЕ, после того, как ожидаемое событие произойдет.

Процесс (задача) - программа, находящаяся в режиме выполнения.

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

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

 

Создание процесса

Три основных события, приводящие к созданию процессов (вызов fork или CreateProcess):

· Загрузка системы

· Работающий процесс подает системный вызов на создание процесса

· Запрос пользователя на создание процесса

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

В UNIX каждому процессу присваивается идентификатор процесса (PID - Process IDentifier)

 

Завершение процесса

Четыре события, приводящие к остановке процесса (вызов exit или ExitProcess):

· Плановое завершение (окончание выполнения)

· Плановый выход по известной ошибке (например, отсутствие файла)

· Выход по неисправимой ошибке (ошибка в программе)

· Уничтожение другим процессом

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

 

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

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

1) Определение момента времени для смены определяемого процесса;

2) Вывод процесса на выполнения из очереди готовых процессов;

3) Переключение контекстов в процессы;

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

1) Алгоритмы, основанные на квантование;

2) Алгоритмы, основанные на приоритетах.

В соответствие с алгоритмами основанные на квантование, смена активного процесса происходит если:

1) Исчерпан квант процессорного времени;

2) Процесс завершился и покинул систему;

3) Процесс перешел в состояние ожидания;

4) Произошла ошибка.

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

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

По-разному могут организованными очереди процессов. На пример первый пришел первый обслужился(fee fo).

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

 

13
Количество про­цессорного времени, выделяемое конкретному потоку, определяется многими факторами. Во-первых, каждый процесс обладает собственным базовым уровнем приоритета, который присваивается всем принадлежащим ему потокам. Во-вто­рых, каждый из потоков обладает собственным приоритетом, который добавля­ется к базовому значению.
ОС поддерживает 4 класса приоритетов процессов: idle (простаивающий), normal (нор­мальный), high (высокий) и realtime (реального времени). Программы, запускаемые пользователем, основном относятся к приложениям с классом приоритета normal. Приоритет idle идеален для приложений, занимающихся мониторингом системы или хранителя экрана (screen saver). Класс приоритета high следует использовать только при необ­ходимости. Класс приоритета realtime используют только: 1) в программе, напрямую “общающейся” с оборудованием, и 2) если приложение выполняет быстротечную операцию, которую нельзя прерывать ни в коем случае.
Потоки имеют 5 уровней относительного приоритета. Их описание приведено в таблице 1

Таблица 1 - Уровни приоритета потоков

THREAD_PRIORITY_LOWEST Приоритет потока должен быть на 2 единицы меньше класса приоритета процесса

THREAD_PRIORITY_BELOW_NORMAL Приоритет потока должен быть на 1 единицу меньше класса приоритета процесса

THREAD_PRIORITY_NORMAL Приоритет потока должен соответствовать классу приоритета процесса

THREAD_PRIORITY_ABOVE_NORMAL Приоритет потока должен быть на 1 единицу больше класса приоритета процесса

THREAD_PRIORITY_HIGHEST Приоритет потока должен быть на 2 единицы больше класса приоритета процесса

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

Последовательность действий в ВС при обработке прерываний

Обработка прерываний проходит в два этапа. Первый этап – аппаратный, он выполняется ЦП. Второй этап – программный, он выполняется ОС.

[править]Аппаратный этап обработки прерываний

На аппаратном этапе обработки прерываний процессором производтятся следующие действия:

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

Завершение выполнения текущей команды.

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

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

Программный этап обработки прерываний

На программном этапе сначала определяется тип прерывания.

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

Если прерывание не «короткое», то возможны две ситуации:

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

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

Применение семафоров

Вот некоторые из проблем, которые могут решать семафоры.

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

§ поочерёдный доступ к критическому ресурсу (важному ресурсу, для которого невозможен одновременный доступ).

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

semaphore.init(1);Поток 1:semaphore.enter();cout << "Состояние массива: ";for (int i=0; i<n; i++) cout << a[i] << ' ';cout << '\n';semaphore.leave();Поток 2:semaphore.enter();cout << "Нажато Esc.\n";semaphore.leave();

Этот код поможет предотвратить появление листинга наподобие

Состояние массива: 1 2 3 Нажато Esc.4 5 6

Проблемы семафоров

Во-первых, можно написать программу с «утечкой семафора», вызвав enter() и забыв вызвать leave(). Реже встречаются ошибки, когда дважды вызывается leave().

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

 

Поток 1:semaphore1.enter();semaphore2.enter();...semaphore2.leave();semaphore1.leave();Поток 2:semaphore2.enter();semaphore1.enter();semaphore1.leave();semaphore2.leave();

Таблица 8.2. Сравнительные характеристики объектов синхронизации Windows

	CRITICAL_SECTION	Мьютекс	Семафор	Событие
Именованный защищаемый объект синхронизации	Нет	Да	Да	Да
Доступность из нескольких процессов	Нет	Да	Да	Да
Синхронизация	Вхождение	Ожидание	Ожидание	Ожидание
Освобождение	Выход	Мьютекс может быть освобожден или оставлен без контроля.	Освобождается любым потоком.	Функции SetEvent, PulseEvent.
Права владения	В каждый момент времени иметь права владельца может только один поток. Владеющий поток может осуществлять вхождение несколько раз, не блокируя свое выполнение.	В каждый момент времени иметь права владельца может только один поток. Владеющий поток может выполнять функцию ожидания несколько раз, не блокируя свое выполнение.	Понятие владения неприменимо. Доступ разрешен одновременно нескольким потокам, число которых ограничено максимальным значением счетчика.	Понятие владения неприменимо. Функции SetEvent и PulseEvent могут быть вызваны любым потоком.
Результат освобождения	Разрешается вхождение одного потока из числа ожидающих.	Вслед за последним освобождением права владения разрешается приобрести одному потоку из числа ожидающих.	Продолжать выполнение могут несколько потоков, число которых определяется текущим значением счетчика.	После вызова функций SetEvent или PulseEvent продолжать выполнение будет один или несколько ожидающих потоков.

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

В Windows существует три группы wait-функций:
1) single-object
К этой группе относится функция WaitForSingleObject(), которая приостанавливает поток до освобождения заданного объекта синхронизации.

 

DWORD WaitForSingleObject(
HANDLE hHandle,
DWORD dwMilliseconds
);

Параметр hHandle - это дескриптор объекта синхронизации.
Параметр dwMilliseconds указывает время, по истечении которого функция завершается, даже если объект синхронизации не освободился. В этом случае функция возвращает значение WAIT_TIMEOUT.

2) multiple-object
Функции этой группы позволяют потоку ждать освобождения или нескольких объектов синхронизации, или одного из них. К этой группе относится функция WaitForMultipleObjects().

DWORD WaitForMultipleObjects(
DWORD nCount,
const HANDLE* lpHandles,
BOOL bWaitAll,
DWORD dwMilliseconds
);

Параметр nCount указывает количество дескрипторов объектов, содержащихся в массиве, на который указывает параметр lpHandles. Максимально возможное число дескрипторов объектов равно константе MAXIMUM_WAIT_OBJECTS.
Параметр lpHandles - указатель на массив, в котором содержаться дескрипторы объектов синхронизации.
Параметр bWaitAll - если этот параметр равен TRUE, то функция возвращает управление потоку, когда освобождаются все объекты синхронизации, дескрипторы которых содержатся в массиве. Если параметр равен FALSE, то функция завершается при освобождении любого из объектов.
Параметр dwMilliseconds указывает время, по истечении которого функция завершается, даже если объект синхронизации не освободился. В этом случае функция возвращает значение WAIT_TIMEOUT.

3) сигнализирующие (alertable).

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

 

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

 

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

Структура сообщений

В модуле Windows сообщение описано следующим образом:

• type
• TMsg = packed record
• hWnd: HWND; // Дескриптор окна-получателя
• Message: UINT; // Код сообщения;
• WParam: WPARAM; // Уточняющий параметр
• LParam: LPARAM; // Уточняющий параметр
• Time: DWORD; // Время создания сообщения
• pt: TPoint; // Координаты указателя мыши в этот момент
• end;

 

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

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

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

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

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

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

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

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

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

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

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

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

Алгоритмы распределения памяти

Сл<