Способы построения операционных систем

 

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

 

Иерархическая структура

 

Многие реально существующие операционные системы разработаны и реализованы на основе иерархической структуры. Примеры подобно_ структуры приведены на рис. 6.35. В этом случае основным принципом, как видно из рис. 6.35а, является обобщение идеи расширенной машины, приведенной нарис.6.1. Каждый слой, или уровень, в структуре может использовать функции, предоставляемые ему более низким уровнем, как если бы они являлись частью реальной машины. Так, Уровень О, часто называемый ядром (kernel) операционной системы, имеет дело непосредственно с аппаратурой; Уровень 1 имеет дело с интерфейсом, предоставляемым уровнем О, и т. д. Программы пользователя имеют дело с интерфейсом самого высокого уровня (в данном случае Уровня 3), который представляет собой интерфейс пользователя, рассмотренный в разд. 6.1.

 

 

Интерфейс пользователя

Уровень 3

 

Уровень 2

 

 

Уровень 1

 

Уровень 0

(ядро)

 

 

а

 

Уровень	Функции
	Управление файлами Управление памятью Управление вводом-выводом Диспетчеризация, управление ресурсами

 

б

Рис. 6.35. Пример системы с иерархической структурой.

 

На рис. 6.356 показаны функции, соответствующие уровням рассматриваемой структуры. Их расположение определяется взаимоотношениями между выполняемыми ими операциями. В общем случае функции каждого уровня могут обращаться лишь к функциям того же или более низкого уровня; таким образом, не должно быть внешних вызовов. В нашем примере программы управления файлами (УровеньЗ) для распределения буферов должны использовать менеджер памяти (Уровень 2), а для чтения и записи блоков - супервизор ввода-вывода. Если управление памятью производится при помощи размещения страниц но запросу, то менеджер памяти для передачи страниц между реальной памятью и вспомогательной тоже должен вызывать супервизор ввода-вывода. Все уровни системы используют предоставляемые Уровнем О функции планирования процессов и управления ресурсами.

 

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

На рис. 6.356 показано типичное расположение функций, однако различные системы существенно отличаются друг от друга. Рассмотрим, например, программы обработки прерывания. Во многих системах обработчики прерываний первого уровня (FLIH - First-Level Interrupt Handlers) размещены в ядре (Уровень О). После начальной обработки прерываний FLIH может передать управление программе более высокого уровня; это исключение из правил, согласно которым внешние вызовы недопустимы. Так, например, FLIH в случае прерывания и отсутствию страницы может сохранить информацию о состоянии, разрешить другие прерывания, а затем передать управление программе Уровня 2 (см. рис. 6.25в).

В некоторых операционных системах иерархическое распределение функций в особых случаях сделано более сложным. Информацию об этом и о других примерах иерархических структур можно найти в Лорин [1981] и Питерсон [1983].

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

Дальнейшее обсуждение иерархических структур операционных систем можно найти в Питерсон [1983], Лорин [1981] и Мэдник [1974].

 

Виртуальные машины

 

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

Рассмотрим, например, рис. 6.36. Операционная система ОС1 - мультипрограммная, поддерживающая одновременную работу трех пользователей; операционная система ОС2 - однопрограммная; ОСЗ - операционная система, которая в этот момент тестируется. Есть также программа пользователя (Пользователь5), предназначенная для работы в режиме супервизора в качестве автономной программы, не находящейся под управлением операционной системы.

 

	Монитор виртуальной машины (МВМ)
	Реальная машина

 

 

Рис. 6.36. Операционная система с виртуальными машинами и многими пользователями.

 

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

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

 

 

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

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

 

Интерфейс

пользователя

 

 

Виртуальная

машина.

 

 

Рис.6.37. Виртуальная машина как расширение понятия иерархической структуры.

 

Каждый непосредственный пользователь виртуальной, например ОС1 или Пользователь5 на рис. 6.36, факт работает не в режиме супервизора, а в пользовательском режиме. Когда такой пользователь пытается выполнить привилегированную команду, такую как 510, STI или LPS, программное прерывание. По нему управление передается монитору виртуальной машины. MВM имитирует (с учетом реальности машины) выполнение требуемой команды, а возвращает управление пользователю. Монитор виртуальной машины активизируется и по прерыванию на реальной машине. Он определяет, какая из виртуальных машин должна быть задействована, и производит соответствующие изменения ее состояния.

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

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

Дальнейшее обсуждение операционных систем виртуальных машин можно найти в Дейтел [1984] и Питерсон [1983].

 

Мультипроцессорные системы

 

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

 

 

		Память

 

 

Рис. 6.38. Мультипроцессорные системы со слабо связанными процессорами.

 

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

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

 

 

 

а б

Рис. 6.39. Мультипроцессорные системы с сильно связанными процессорами с обработкой: а - типа главный-подчиненный и б - симметричной.

 

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

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

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

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

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

Дальнейшую информацию по операционным системам для мультипроцессоров можно найти в Дейтел [1984], Лорин [1981] и Мэдник [1974].

 

Примеры реализаций

 

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

Первые два примера - операционные системы, не привязанные к какой-нибудь одной машине. В разд. 6.5.1 рассматривается небольшая переносимая однопользовательская система UCSD Pascal, функционирующая на мини-ЭВМ. В разд. 6.5.2 описывается UNIX, более сложная операционная система, которая также может быть реализована и на разных ЭВМ.

Другие примеры - системы, разработанные для определенных семейств ЭВМ. Разд. 6.5.3 посвящен NOS^TW, функционирующей на ЭВМ серии CDC CYBER; это пример мультипроцессорной операционной системы. В разд. 6.5.4 рассматривается система VAX/VMS^TW, в которой используются некоторые интересные методы управления виртуальной памятью. В разд. 6.5.5 рассматривается VM/370 фирмы IBM, операционная система, на базе которой могут быть реализованы многочисленные виртуальные машины.

 

Система UCSD Pascal

 

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

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

Например, когда система загружена впервые, ею выдается строка-подсказка вида

 

Команды: E(dit,R(un,F(ile,C(omp,L(ink,X(ecute,A(ssem,D(ebug.

 

По команде Е пользователь переводится на один уровень ниже и попадает в Редактор (Editor), где выдается новая строка-подсказка. Она может иметь вид

Редактор: A(djst,C(py,D(lete,F(ind,l(nsrt,J(mp,R(eplace,

 

Q(uit,X(chng,Z(ap.

 

(Реальные строки-подсказки в зависимости от версий системы могут немного различаться.) По команде I система запрашивает у пользователя вводимый текст. По команде Q пользователь выходит из Редактора и возвращается к корню дерева (начальной строке-подсказке.)

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

По команде R(un внешнего уровня система начинает выполнение программы из текущего рабочего файла. По X(ecute система запрашивает имя файла и выполняет содержащуюся в нем программу. По D(ebug программа из текущего файла выполняется под управлением системного Отладчика, который вызывается в случае появления ошибки или по достижении контрольной точки, заданной пользователем.

В системе имеется также ряд вспомогательных программ. К ним относится, например, такие, посредством которых производится настройка системы на конкретную аппаратную конфигурацию, создаются самозагружающиеся программы, выполняются операции форматирования диска, не предусмотренные в Фаилере. Вспомогательные программы запускаются на внешнем уровне при помощи команды X(ecute. Операционной системой UCSD Раsсаl программы пользователей обеспечиваются набором лишь основных сервисных функций. В соответствии с нуждами программ, написанных на Паскале, в системе реализовано динамическое распределение памяти; тем самым имеется возможность в случае надобности переназначить содержимое основной памяти. Поддержка параллельности работы минимальна. Большая часть активности системы, включая операции ввода-вывода, синхронизована. Это означает, например, что операция READ приводит к тому, что программе пользователя приходится ждать завершения физической операции ввода-вывода; в это время ни одно другое задание не может быть выполнено. Дальнейшую информацию но системе UCSD Pascal можно найти в SofTech Microsystems [1980 и 1983].

 

UNIX

 

Операционная система UNIX первоначально была разработана в Bell Laboratories для семейства ЭВМ DEC PDP-11. С тех пор она была реализована на многих других машинах, от больших ЭВМ до микропроцессоров. Сейчас существует несколько версий UNIX. Ниже будут рассмотрены некоторые присущие всем им наиболее интересные свойства системы.

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

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

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

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

UNIX поддерживает иерархическую файловую систему. Для файлов пользователя имеются каталоги с древовидной структурой; система тоже имеет несколько каталогов для своих нужд. Один и тот же файл может фигурировать в нескольких различных каталогах, возможно, и под разными именами. Все такие файлы имеют одинаковый статус. Иными словами, файл не принадлежит какому-то одному определенному каталогу. Файлы могут быть и не включены ни в один каталог.

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

Дальнейшую информацию и ссылки, касающиеся системы UNIX, можно найти в Баурн [1983], Дейтел [1984] и Ритчи [1978].

 

NOS

 

NOS - операционная система, предназначенная для использования на ЭВМ серии CDC CYBER и 6000. Это мультипроцессорные машины, имеющие один или два Центральных процессора (ЦП) и до 20 периферийных процессоров (ЦП). ЦП и ПП работают с общей центральной памятью; таким образом, NOS является примером мультипроцессорной системы с сильно связанными процессорами. Однако к каналам и устройствам ввода-вывода ЦП не имеет прямого доступа. Этот доступ обеспечивается периферийными процессорами. Используя специальные аппаратные команды, ПП могут запускать и останавливать ЦП.

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

Все управление машиной возложено на системный монитор, состоящий из программ MTR на ПП и CPUMTR на ЦП. МТ1? непрерывно сканирует запросы на обслуживание заданий пользователей. Подробно об этом будет рассказано ниже. CPUMTI? назначает периферийным процессорам задания, по одному на каждого. Когда задание завершается, ПП оповещает систему. Этого ждет CPUMTR, прежде чем назначить ПП следующее задание.

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

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

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

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

Дополнительную информацию по NOS можно найти в CDC [1981 и 1983]

 

VAX/VMS

 

VAX/VMS - это многоцелевая операционная система, предназначенная для использования на ЭВМ серии VAX. Под ее управлением можно работать в трех режимах: пакетном, разделения времени и реального времени. Неотъемлемой частью VAX является виртуальная память, а управление ею - одним из наиболее интересных свойств операционной системы VAX/VMS.

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

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

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

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

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

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

Функция планирования процессов в VAX/VMS основана на 32 уровневой системе приоритетов. Нижние 16 уровней зарезервированы для обычных процессов; остальные - для процессов реального времени. Каждый процесс в системе определен блоком управления процесса и своим заголовком. Блок управления процесса содержит кластеры флагов событий, которые могут быть использованы процессами для связи и координации их действий.