Системное программное обеспечение

Рис. 3.1. Монолитная структура ОС

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

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

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

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

3.3. Микроядерные ОС

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

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

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

3.4. Модель клиент – сервер

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

11

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

Рис. 3.2. Структура ОС клиент-сервер

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

3.5. Объектно-ориентированный подход

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

12

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

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

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

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

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

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

3.6. Множественные прикладные среды

Наличие нескольких прикладных сред дает возможность в рамках одной ОС од­ новременно выполнять приложения, разработанные для нескольких ОС. Многие совре­ менные операционные системы поддерживают одновременно прикладные среды MSDOS, Windows, UNIX (POSIX), OS/2 или хотя бы некоторого подмножества из этого попу­ лярного набора. Концепция множественных прикладных сред наиболее просто реализует­

13

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

3.7. Распределённые ОС

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

4. ОСНОВНЫЕ СТАНДАРТЫ ИНТЕРФЕЙСОВ ПРИКЛАДНОГО ПРОГРАМ­ МИРОВАНИЯ СОВРЕМЕННЫХ ОС

Интерфейс прикладного программирования (application program interface, API) представляет собой набор функций, предоставляемых системой программирования разра­ ботчику прикладной программы и ориентированных на организацию взаимодействия ре­ зультирующей прикладной программы с целевой вычислительной системой. Целевая вы­ числительная система представляет собой совокупность программных и аппаратных средств, в окружении которых выполняется прикладная программа.

API предназначен для использования прикладными программами системных ресур­ сов ОС.

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

Существует несколько вариантов реализации программного интерфейса:

реализация на уровне ОС;

реализация на уровне системы программирования;

реализация на уровне внешней библиотеки процедур и функций.

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

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

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

14

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

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

4.1. ANSI C

В 1989 г. Американским национальным институтом стандартов (American National Standarts Institute, ANSI) был утвержден стандарт Х3.159-1989 языка программирования С. Целью появления этого стандарта являлось улучшение переносимости программ написан­ ных на языке С в различные ОС. Стандарт определяет не только синтаксис и семантику языка, но и содержимое стандартной библиотеки.

4.2. POSI X

Чтобы решить проблему переносимости приложений между различными ОС, Институт инженеров по электротехнике и радиоэлектронике (IEEE) в 80-х годах сфор­ мировал специальную рабочую группу под названием POSIX (Portable Operating System Interface –интерфейс переносимых операционных систем), перед которой была поставлена задача создания комплекта стандартов, предназначенных для согласования между собой различных реализаций операционных систем. В POSIX имеется несколько подгрупп, в частности, POSIX.1, POSIX.1b, POSIX.1c, которые занимаются разработкой этого комплекта стандартов для системных программистов.

В частности, комплект POSIX.1 предлагает стандарт на базовый интерфейс при­ кладного программирования ОС, в котором определяются функции для манипулирования файлами и процессами. Официально он известен как IEEE 1003.1-1990 и принят также ISO как международный стандарт ISO/IEE 9945:1:1990. Комитет POSIX.1b предлагает на­ бор стандартных функций прикладного программирования для интерфейса операционных систем реального времени (IEEE 1003.4-1993). Наконец, стандарт POSIX.1c определяет интерфейс многопоточного программирования.

Хотя в основе своей работа комитетов POSIX строится на использовании ОС UNIX, предлагаемые ими стандарты предназначены для некой обобщенной ОС, которая вовсе не обязательно должна быть системой UNIX.

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

4.3. Стандарты X/Open

Организация X/Open была создана группой европейских компаний с целью разра­ ботки общего интерфейса операционных систем для производимых ими компьютеров. В 1989 году организация издала выпуск №3 руководства по разработке переносимого про­ граммного обеспечения X/Open Portabilty Guid (XPG3), а в 1994 году – выпуск №4. В этих

15

документах определяется набор общих средств и функций интерфейсов прикладного про­ граммирования языка С, которые должны присутствовать во всех «открытых системах» на базе UNIX. Руководства XPG3 и XPG4 основаны на стандартах ANSI С, POSIX.1, POSIX.2 и содержат дополнительные конструкции, разработанные организацией X/Open.

5. ПРИНЦИПЫ УПРАВЛЕНИЯ ПРОЦЕССАМИ

5.1. Термины и определения

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

Дескриптор процесса – по сравнению с контекстом содержит более оперативную инфор­ мацию, которая должна быть легко доступна подсистеме планирования процессов: иден­ тификатор процесса, состояние процесса, данные о степени привилегированности процес­ са и т.п.

Приоритет – это число, характеризующее степень привилегированности процесса при использовании ресурсов вычислительной машины, в частности, процессорного време­ ни: чем выше приоритет, тем выше привилегии.

Интерфейс системных вызовов – представляет собой набор услуг ядра и определя­ ет формат запросов на его услуги. Процесс запрашивает услугу посредством системного вызова определённой процедуры ядра, внешне похожего на обычный вызов библиотечной функции. Ядро от имени процесса выполняет запрос и возвращает процессу необходимые данные.

5.2. Понятие процесса

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

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

16

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

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

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

стояний:

выполнение – активное состояние процесса, во время которого процесс обладает всеми необходимыми ресурсами и непосредственно выполняется процессором;

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

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

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

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

Рис. 5.1. Граф состояний процесса в многозадачной среде

5.4. Режимы выполнения процессов

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

17

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

5.5. Алгоритмы планирования процессов

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

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

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

3.переключение контекстов "старого" и "нового" процессов.

Первые две задачи решаются программными средствами, а последняя в значитель­ ной степени аппаратно.

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

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

∙процесс завершился и покинул систему,

∙произошла ошибка,

∙процесс перешел в состояние ожидания,

∙исчерпан квант процессорного времени, отведенный данному процессу.

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

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

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

18

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

Существует две разновидности приоритетных алгоритмов: алгоритмы, использую­ щие относительные приоритеты, и алгоритмы, использующие абсолютные приоритеты.

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

(а)

(б)

Рис. 5.2. Графы состояний процессов в системах: (а) с относительными приоритетами; (б) с абсолютными приоритетами

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

19

6. СРЕДСТВА СИНХРОНИЗАЦИИ И ВЗАИМОДЕЙСТВИЯ ПРОЦЕССОВ

6.1. Проблема синхронизации процессов

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

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

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

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

Необходимо упорядочить доступ нескольких задач к разделяемому ресур­ су.

6.2.Сигналы

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

1.Ядро отправляет процессу (или группе процессов) сигнал при нажатии пользова­ телем определенных клавиш или их комбинаций. Например, нажатие клавиш <Del> (или <Ctrl> + <C>) приведет к отправке сигнала SIGINT, что используется для завершения процессов, вышедших из-под контроля.

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

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

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

Каждому типу сигналов присвоено мнемоническое имя (например, SIGINT), кото­ рое указывает, для чего обычно используется сигнал. Имена сигналов определены в стан­ дартном заголовочном файле <signal.h> при помощи директивы препроцессора #define.

20