Лорин Г., Дейтел Х.М. Операционные системы. Главы 1-3
Подождите немного. Документ загружается.
Рис. 2.3. иллюстрирует развитие идеи, лежащей в основе структуры,
приведенной на рис. 2.2. Если существует несколько типов объектов, то в принципе
любой управляющий модуль можно ориентировать на выполнение всех операций
над объектами данного типа. Сходство структур, изображенных на рис. 2.2 и 2.3,
состоит в том, что информация о местонахождении процедур или устройств
41
заключена внутри соответствующих программ-обработчиков. Однако система,
показанная на рис. 2.3, нуждается в большем количестве управляющей информации,
поскольку для всех объектов каждого данного типа должно быть указано их
расположение на конкретных устройствах.
Структура, приведенная на рис. 2.4, реализует понятие расслоения. Здесь
представлены отдельные модули для создания (СREATE), уничтожения
(DESTROY), чтения-записи (READ-WRIТЕ) и управления устройствами.
Программа, выполняющаяся под управлением операционной системы, может
независимо обращаться к существующим модулям (вводится функциональная
иерархия), а модули более высокого уровня могут обращаться друг к другу.
Расслоение подводит к вопросу о составе операционной системы. Если функции
СRЕАТЕ, DЕSТRОY и РRОТЕСТ достаточно просты, они могут быть естественным
образом реализованы в виде модулей операционной системы. Если же они сложны,
как, например, в случае управления базами данных, то их естественно реализовать в
виде составной части управления базой данных. При этом все программы,
относящиеся к комплексу управления базой данных, подобно обычным программам
могут работать под контролем операционной системы, а функции CREATE и
DESTROY, применяемые к объектам данных, не будут функциями операционной
системы.
На рис. 2.5 показано принципиально иное соответствие между объектами и
функциями. Здесь каждой функции сопоставляется отдельный модуль,
обслуживающий все типы объектов. Модуль READ должен представлять собой
универсальную реализацию операции чтения, хотя, конечно, чтение набора данных
и чтение процедуры — операции совершенно разные Структура, изображенная на
рис. 2.5, во многих деталях существенно отличается от предыдущих.
Например, каждый объект должен быть доступен функциональному модулю.
Поэтому необходимо наличие единой и внешней по отношению ко всем функциям
42
таблицы, в которой хранилась бы информация о физическом расположении
объектов системы.
Однако расслоение может принимать и иные формы. Так, одни операции
чтения могут реализовываться модулями операционной системы, а другие —
модулями, входящими в пакет программ управления базой данных. Например,
считывание с некоторого устройства логической записи, совпадающей с како-то
физической записью, возможно с помощью функции READ операционной системы.
Если же требуется выбрать логическую запись, формируемую из нескольких
физических, то данная функция реализуется одним из модулей системы управления
базой данных.
Система, изображенная на рис. 2.5, и своей схемой, и качественно отличается
от систем, изображенных на рис. 2.2—2.4. В одном случае мы имеем дело с
модулями (называемыми обработчиками), относящимися к отдельным объектам, в
другом модули служат для чтения, записи и т. д. Любая реальная операционная
система, вероятно, должна включать и те и другие модули. Зачастую изучение
атрибутов объектов системы позволяет определить, следует ли рассматривать
относящиеся к этим объектам функции как функции операционной системы или нет.
Иногда в разбиения конкретных операционных систем на модули двух указанных
выше типов лежат сложившиеся традиции. В подобных ситуациях сами системы
носят отпечаток структурной нечеткости и концептуальной непоследовательности.
Основная структура системы и определяющиеся ею эффективность и
гибкость существенно зависят от распределения функций между отдельными
системными элементами. Полезно, однако, попытаться представить себе функцию,
никак не связанную со структурной организацией программного обеспечения.
Любой список функций предполагает некоторую структуру, но не следует думать,
что те четыре функции, о которых скоро пойдет речь, влекут за собой обязательное
разбиение операционной системы на четыре основных компонента. Предлагаемая
классификация имеет свой целью дать общее представление о назначении
операционной системы.
В самом общем виде операционная система выполняет две функции:
• создает комплекс логических ресурсов, более удобных в управлении по
сравнению с физическими ресурсами аппаратуры;
• обеспечивает механизмы доступа, управления очередями и защиты в
условиях конкуренции объектов системы за предоставление этих ресурсов.
Тем не менее известно такое количество способов реализации этих двух
функций, что конкретные средства обеспечения логических ресурсов и механизмов
доступа для разных систем могут оказаться существенно различными. Это в свою
очередь приводит к неоднозначной трактовке задач операционной системы на более
низком уровне.
Особенностью рассматриваемого в настоящей главе списка функций
является их крупномасштабность. Эти функции служат для следующих целей:
• определения среды, в которой создаются и выполняются программы;
• создания методов доступа к средствам вычислительной системы;
43
• построения операционных интерфейсов;
• управления ресурсами системы в соответствии с планами администрации
вычислительного центра.
Последний пункт включает все пять функций, соответствующих
«ограничительному» подходу к операционной системе, изложенному в начале
главы. Согласно этому подходу система рассматривается как совокупность средств
управления ресурсами. Однако и он допускает неоднозначное решение вопроса о
том, в какой степени на систему должна быть возложена реализация стратегий
использования соответствующих средств.
2.2. СРЕДА ДЛЯ СОЗДАНИЯ
И ВЫПОЛНЕНИЯ ПРОГРАММ
В этом разделе мы постараемся связать иерархическую структуру
рассмотренную в гл. 1, с процессом создания программ.
Программист всегда заинтересован в 1) записи программы решения
требуемой задачи на подходящем языке, 2) получении необходимой поддержки на
этапах отладки и тестирования, 3) разделении своей работы на части и 4)
объединении этих частей в удобном для себя порядке. Все перечисленные
возможности предоставляются компиляторами, различными средствами
тестирования и отладки, редакторами связей и интерфейсами операционной
системы, формирующими расширенную архитектуру.
В процессе подготовки программы к выполнению ее элементы сл|ужат
данными для некоторых компонентов поддержки. Эти компоненты — компилятор и
редактор связей. Компиляторы обычно не включаются в состав операционной
системы, редакторы же почти всегда оформляются как ее составная часть. В задачу
редактора связей входит сборка программ, написанных в различное время и,
возможно, различными людьми, в единую структурную единицу. После обработки
редактором связей программа загружается в память с помощью загрузчика.
Необходимые для выполнения ресурсы обеспечиваются программой-
распределителем курсов.
Программа становится активной после того, как попадает в так называемую
среду выполнения. Пример среды выполнения в проекции операционной системы
показан на рис. 2.6.
44
Здесь предполагается, что с точки зрения активной программы система
представлена командами процессора и множеством ячеек памяти, имеющих адреса
от 0 до X. Однако в процессе ее работы могут также использоваться некоторые
операции (в нашем случае OPEN, GET, PUT и WRIТЕ), не являющиеся машинными
командами. Все подобные операции реализуются соответствующими модулями
операционной системы, в результате чего функции GET, PUT и т. д. можно
применять наряду с машинными командами.
Привилегированные команды и защищенные области памяти доступны
выполняющейся программе не непосредственно, а через механизмы поддержки
функций расширенного набора.
Расширенная машина дает возможность упростить этап компиляции путем
обеспечения интерфейсов более высокого уровня, в терминах которых оформляется
объектная программа, а также снизить трудоемкость процесса программирования на
машинном языке.
Описанные функции высокого уровня естественно считать функциями
операционной системы. Эти функции считаются внешними по отношению к
прикладным программам. Однако в принципе создание подобных интерфейсов не
обязательно связывать с операционной системой. В частности, программа GЕТ,
позволяющая получить очередную запись файла, может быть включена в
библиотеку ассемблера или компилятора. При этом она будет включаться в
основную программу всякий раз, когда в последней встретится обращение к
соответствующей функции. Широко применяется реализация такого способа с
помощью макроассемблера. Столь же обычным способом ввода записи
ассемблируемой или компилируемой программой, причем даже в условиях
поддержки расширенной среды выполнения, представляется помещение
соответствующих кодов непосредственно в объектный модуль.
Необходимо отметить, что наличие режима управления, прерываний и
привилегированных команд приводит к тому, что программа из библиотеки
компилятора или ассемблера, включаемая в основную программу для реализации
выборки очередной записи файла, не может обеспечить функцию GЕТ во всей ее
полноте. Команды ввода-вывода — привилегированные, и их разрешено выполнять
только в режиме управления. Поэтому в процессе работы программа неизбежно
обратится к операционной системе с запросом на выполнение тех функций, которые
не могут быть вставлены компилятором непосредственно в программу. Все
манипуляции с указателем очередной записи в буфере ввода-вывода можно
осуществить в основной программе. Однако, если буфер пуст, требуется произвести
фактический обмен. Для этого необходимо перевести процессор в режим
управления, вызвав программу супервизор (команда SVС — Supervisor Саll).
Выполнение команды SVС приводит к прерыванию. В результате включается
режим управления и начинает работать обработчик прерываний,
интерпретирующий команду SVС как запрос на реализацию ввода-вывода.
До сих пор мы относили функции типа GЕТ и РUT к расширенному набору,
однако правильнее было бы считать их псевдокомандами, включенными в
45
соответствующий язык. Эти псевдокоманды позволяют обращаться к функциям
расширенной архитектуры путем вызовов программ супервизора (SVС-программ).
Компиляторы заменяют псевдокоманды подпрограммами, включающими
соответствующие команды SVС. Программисты, пишущие на языке Ассемблера,
при желании могут непосредственно пользоваться командами SVС.
Поскольку операции ввода-вывода выполняются либо асинхронно по
отношению к основной программе, либо вызывают ее приостановку, в расширенной
машине должен быть предусмотрен механизм синхронизации выполнения
программы и операций ввода-вывода или средства, позволяющие сообщить
основной программе о завершении обменов.
Последовательность событий, включающая перевод процессора из режима задачи в
режим управления, при появлении запроса на выполнение операций ввода-вывода (а
также при завершении процесса ввода-вывода) служит для поддержки
мультипрограммной работы, при которой несколько программ одновременно
используют ЦП и подсистему ввода-вывода. Идея ввести режим управления
возникла в связи с необходимостью каким-то образом координироватъ выполнение
независимых программ. Этот режим должен предусматривать меры для сохранения
целостности и логики параллельно выполняемых программ. Таким образом, понятие
среды выполнения наряду с расширенным интерфейсом включает в себя также
средства синхронизации и управления. Именно поэтому компиляторы не в
состоянии обеспечить непосредственную реализацию всех функций,
запрашиваемых программой для выполнения в мультипрограммном окружении.
Различные программы зачастую обращаются к одним и тем же функциям. Поэтому,
разрешив программе иметь общие участки кодов, можно добиться определенной
экономии памяти. И следовательно, можно исключить ненужное дублирование
функций ценой создания обобщенного механизма координации. Решение о том,
какие функции следует помещать непосредственно в скомпилированную
программу, а какие реализовывать в виде части расширенной машины, принимается
на этапе проектирования и отражает представление разработчиков об операциях,
наиболее часто встречающихся в программах. Этот вопрос часто служит предметом
дискуссии между разработчиками компиляторов и разработчиками операционных
систем.
2.3. ОПРЕДЕЛЕНИЕ СРЕДЫ ДОСТУПА
Одной из основных функций операционной системы считается поддержка
интерфейсов, служащих для доступа к ресурсам вычислительной системы. Легкость
и простота доступа в значительной мере определяют общую эффективность
использования вычислительных машин. Сторонники предоставления средств
вычислительной системы широкому кругу пользователей для решения различных
задач стремятся создать менее удобные, чем в специализированных системах,
интерфейсы, не забывая при этом о гибкости и мощности создаваемой крупной
системы.
46
Например, машина IВМ 5100 и подобные ей позволяют применять язык
АПЛ. Однако программировать на языке АПЛ можно и в развитых
мультипрограммных системах. В таких случаях роль разработчиков операционных
систем — обеспечить настолько же эффективную работу с АПЛ, как и на
специализированной АПЛ - машине.
Здесь уместно вспомнить иерархию проекций, рассмотренную гл. 1.
Проекция конечного пользователя представляет собой проекцию соответствующей
проблемной области. Пользователю необходимы определенная информация и набор
процедур для ее получения. Эти процедуры хотелось бы максимально упростить при
сохранении минимальной зависимости порядка их использования от структуры
операционной системы и мнений ее разработчиков. Аналогично от программистов-
пользователей, применяющих для записи алгоритмов решения прикладных задач
языки высокого уровня, нельзя требовать, чтобы они были детально знакомы с
элементами вычислительной системы, не имеющими непосредственного отношения
к решаемой задаче.
Профессиональные программисты также нуждаются в подходящих
интерфейсах, позволяющих осуществлять программную поддержку решения
прикладных задач, выполнять тестирование и эффективно объединять различные
компоненты программного обеспечения. В данном случае важно не только удобство
написания программ, но и удобство манипулирования ими.
При проектировании необходимо определить способ доступа к
вычислительным ресурсам. В настоящей главе основное внимание уделяется
взаимоотношению процессов программирования и подготовки программ к
непосредственному выполнению на вычислительной машине. В частности, здесь
рассматривается связь языка управления, предназначенного для описания процесса
выполнения, и языка программирования, предназначенного для записи алгоритмов
решения задач, причем этот вопрос обсуждается с точек зрения системного
программиста и пользователя.
В большинстве систем пакетной обработки процесс создания программы
никак не связан с процессом ее выполнения. В таких системах предусмотрены
специальные языки управления с синтаксисом, заметно отличающимся от
синтаксиса языков программирования. Языки управления возникли как расширение
языков, на которых операторы общались с вычислительной системой. Однако по
синтаксису операторский язык представляет собой еще один, отличный от двух
упомянутых, системный интерфейс.
С учетом функциональных различий языковых интерфейсов можно сказать,
что языки программирования дают возможность описывать процедуры и
определять структуры данных, с которыми эти процедуры работают. Языки
управления позволяют ставить в соответствие наборам данных устройства
ввода-вывода, а также составлять описание ресурсов, необходимых программе при
ее выполнении. Операторские языки служат для изменения конфигурации системы
и ее состояния.
Одна из проблем, возникающих в связи с разработкой операционных систем,
47
— распределение функций между операторами, программистами-пользователями и
системными программистами. При решении этой проблемы необходимо четко
представлять себе, каков должен быть порядок их общения. В некоторых системах
все терминалы рассматриваются как консоли оператора, так что с них можно
выполнять и операторские функции, и функции управления. Существуют системы,
где обязанности операторов, программистов-пользователей и системных
программистов вообще не разделены. Известны также системы, создатели которых,
очевидно, полагали, что программист в состоянии без труда овладеть языком
управления. И наконец, в ряде систем операторский, управляющий и командный
языки объединены. В последнем случае для определения полномочий программиста
служат специальные команды.
Принимая во внимание работу в интерактивном режиме, когда средства
программирования и средства выдачи запросов системе почти не
дифференцируются, следует отметить, что грани между языками управления и
программирования постепенно стираются. Во многих системах команды типа ЕDIТ
(ОТРЕДАКТИРОВАТЬ), RUN (выполнить), COPY (СКОПИРОВАТЬ), SAVE
(СОХРАНИТЬ) имеют вид расширений языка программирования.
Приведем некоторые соображения, касающиеся структуры языков. В
принципе возможно создать систему, в которой любой язык программирования
являлся бы подмножеством управляющего языка. Запросы на выполнение,
использование наборов данных и редактирование в этом случае оказались бы
одинаковыми для всех языков. Примером тому может служить компонент ТSO в
системе МVS фирмы IВМ. Программирование здесь осуществляется в контексте
единого рабочего места программиста. Так же широко распространена организация
систем, предусматривающая для каждого языка программирования свой командный
контекст. В качестве примера можно назвать подсистему ВАSIС в операционной
системе МULTIСS. Известно и множество других способов построения систем,
предусматривающих свои командные и управляющие контексты, а также
компиляторы для работы в диалоговом и пакетном режимах.
2.3.1. Происхождение языков управления
В прошлом запуск задания на ЭВМ (установка соответствующих магнитных
лент и загрузка программы) осуществлялся оператором либо непосредственно под
руководством программиста, либо в соответствие с бланком задания, содержащим
всю необходимую информацию но подготовке данной программы к работе. Таким
образом, программисту приходилось записывать распределение магнитных лент по
конкретным устройствам примерно в следующем виде:
• установить ленту с меткой «управляющая» на устройство с номером 3;
• установить ленту с меткой «изменения» на устройство с номером 4;
• установить чистые ленты на устройства с номерами 5, 6 и 7;
• установить ленту с меткой «программа» на устройство с номером 1;
• установить ленту с меткой «наложение» на устройство с номером 2.
48
После указаний по установке он должен был дать указания по процедуре
запуска:
1. «Считать первые два блока с ленты 1 в ячейки памяти с адресами 0840 —
0960» и, возможно, команды, содержащие директивы о необходимых действиях уже
в период выполнения, как, например..»
2. «При выдаче печатающим устройством диагностики END FIRST MASTER
поставить вторую управляющую ленту на устройство с номером З». Для ранних
машин фирмы IВМ (IВМ 650, IВМ 704) характерно отсутствие операторской
пишущей машинки или телетайпа. В этих машинах устройства считывания с карт
часто представляли собой основной источник ввода программной информации.
В первых операционных системах языки управления неизбежно были
привязаны к формату перфокарт. Кроме того, эти системы обладали недостаточной
гибкостью в установлении соответствия между конкретными устройствами и
функциями, поэтому команды типа «ВЫДЕЛИТЬ (АТТАСН) данное устройство для
выполнения некоторой функции» применялись довольно редко. На каждое
устройство возлагались свои задачи, и никто не чувствовал особой нужды в
динамическом переопределении программистом системной среды. Таким образом,
SYSLIB (системный файл), SYSOUT (файл, содержащий системные выдачи) и
SYSUT (рабочие файлы) стандартно распределялись между устройствами.
Перераспределение файлов рассматривалось как функция оператора в
предположении, что конкретное распределение безразлично программистам.
Программисты, предпочитавшие Фортран, использовали либо обычный
компилятор, либо компилятор системы FMS (Fortran Monitor System), либо средства
операционной системы IBSYS (операционная система для машины 7040). Они не
располагали практически никакими возможностями, помимо предоставленных
непосредственно в рамках указанного языка. Понятие управляющего потока
поначалу было связано только с организацией работы системы и по существу не
касалось прикладных программистов. Каждая Фортран-программа в обязательном
порядке снабжалась картами JOB и DАТЕ. Довольно часто эти дополнительные
карты имели стандартный вид и набивались самими операторами. Карты JOB
позволяли объединять все задания в единую колоду для упрощения процесса ввода
информации в машину и при этом разделяли программы различных пользователей.
Таким образом, система получала возможность непрерывно обрабатывать входной
поток, и программа контролировала потребление ресурсами отдельными заданиями.
Оформление программных единиц для выполнения в системе в виде заданий
навело на мысль о том, что в рамках одного задания в принципе могло бы быть
объединено несколько запросов на компиляцию, компиляцию и выполнение и
просто выполнение уже скомпилированных программ. Для обеспечения
автоматического вызова компилятора была введена специальная карта, в которой
указывалось имя компилятора, а также определенные опции, например
«скомпилировать» или «скомпилировать, загрузить и выполнить».
Поскольку каждое устройство ввода-вывода выполняло свои конкретные
функции, считалось, что каждому заданию предоставляется в полное распоряжение
49
вычислительная система со всеми ее ресурсами. Последовательность обслуживания
заданий устанавливалась в зависимости от их расположения в колоде перфокарт,
представлявшей поток заданий. В связи с этим программисты не испытывали
потребности в тех средствах языков управления, которые появились позднее в более
гибких системах.
Подход к управлению ресурсами как к одной из функций оператора привел к
тому, что в системах с пакетным режимом язык управления синтаксически стал
резко отличаться от языков программирования. С расширением выразительных
возможностей языков управления, отражающих концепции независимости от
устройств и совместного пользования машинными ресурсами, увеличивалась и
сложность этих языков. Сегодня они превратились в важные инструменты
программирования. Составление управляющих предложений оказалось значительно
менее тривиальной задачей. Все эти проблемы мы обсудим после краткого
знакомства с языком управления заданиями для пакетного режима (JCL) системы
OS/360 фирмы IВМ.
2.3.2. Управление в пакетном режиме
Здесь не приводится исчерпывающее описание JCL. Нас пока интересует
только назначение этого языка и его характерные особенности.
JCL представляет собой горизонтальный язык, дающий пользователю
возможность 1) указывать программы, подлежащие выполнению, 2) определять
среду, в которой эти программы следует выполнять, т. е. задавать необходимые
размеры памяти и перечислять используемые устройства, 3) присваивать
программам соответствующие приоритеты, 4) связывать определенные наборы
(данных с конкретными системными функциями.
Мы назвали JCL «горизонтальным» языком в связи с тем, что он обладает
небольшим набором основных команд, но зато имеет богатую операндную
структуру. В нем отсутствуют ставшие привычными многие процедурные
конструкции языков программирования, например условные предложения, передача
параметров, возможности вложения операторов и т. д.
Язык допускает предложения трех основных типов: JOB, ЕХЕС и DD. С
помощью JOB-предложения определяется структура задания, в ЕХЕС-
предложениях перечисляются программы, которые необходимо выполнить, и
указываются параметры выполнения, в DD-предложениях описываются наборы
данных, требующиеся программам, указанным в соответствующих ЕХЕС-
предложениях. Программы, поименованные в ЕХЕС-предложениях, называются
шагами задания.
Задание может включать совершенно не связанные между собой шаги,
объединенные исключительно для удобства учета.
Однако оно может состоять и из упорядоченных шагов, как, например,
компиляция, редактирование связей и выполнение получившейся программы.
Язык JCL должен предоставлять программисту максимальные возможности
50