Деревянко А.С., Солощук М.Н. Операционные системы.Часть I. Построение и функционирование операционных систем

Подождите немного. Документ загружается.

361

else {

close(stdout);

dup(fds[1]);

close(ds[1]);

close(fds[0]);

}

exec(pgm1, <параметры>);

}

if ( amp == 0 ) retid = wait(&status);

}

. . .

Наш макет рассчитан на интерпретацию командной строки,

содержащей либо вызов одной программы (pgm1), либо конвейер из двух

программ (pgm1|pgm2). Макет также обрабатывает переадресацию ввода-

вывода и параллельное выполнение.

Тело shell представляет собой цикл (5 - 39), в каждой итерации

которого из файла стандартного ввода вводится (5) строка символов –

командная строка. Далее shell выполняет разбор командной строки,

выделяя и распознавая собственно команду (или команды), параметры и

т.д. Если (7) распознанная команда не является внутренней командой shell

(обработку внутренних команд мы не рассматриваем), а требует

выполнения какой-то программы – безразлично, системной утилиты или

приложения, – то shell проверяет наличие в командной строке признака

параллельности и соответственно устанавливает значение флага amp (8, 9).

Затем shell порождает новый процесс (10) и весь следующий блок (11 - 37)

выполняется только в процессе-потомке. Если shell распознал в команде

362

переадресацию системного вывода (11), то выполняются соответствующие

действия (11 - 16). Они состоят в том, что shell создает файл, в который

будет перенаправлен поток вывода и получает его манипулятор (12). Затем

закрывается файл системного вывода (13). Системный вызов dup (14)

дублирует манипулятор fd в первый свободный манипулятор таблицы

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

вывода, манипулятор которого – 1, дублирование произойдет именно в

него. Теперь два элемента таблицы файлов процесса – элемент с номером 1

и элемент с номером fd – адресуют один и тот же файловый дескриптор –

дескриптор только что созданного файла. Но элемент fd сразу же

освобождается (15), и теперь только манипулятор 1, который

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

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

запрограммировать действия shell при переадресации ввода (17 - 19). (Для

справки: манипулятор системного ввода – 0.)

Если в командной строке задан конвейер (20), то процесс-потомок

прежде всего создает канал (21). Параметром системного вызова pipe

является массив из двух элементов, в который этот вызов помещает

манипуляторы канала: fds[0] – для чтения и fds[1] – для записи. Затем

процесс-потомок порождает еще один процесс (22). Следующий блок (23 -

27) выполняется только во втором процессе-потомке. Этот потомок

переадресует свой стандартный ввод на манипулятор чтения канала (23 -

25). Манипулятор записи канала освобождается за ненадобностью (26).

Затем второй потомок загружается программой, являющейся вторым

компонентом конвейера (27). Следующий блок (28 - 34) выполняется

только в первом потомке: он переадресует свой стандартный вывод на

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

363

Системный вызов exec (36) выполняется в первом потомке (он

является единственным, если конвейер не задан), процесс загружается

программой, являющейся первым компонентом конвейера или

единственным компонентом командной строки. Обратите внимание на то,

что из функции exec нет возврата. При ее вызове выполняется новая

программа, с завершением которой завершается и процесс. Процесс-

родитель, который все время сохраняет контекст интерпретатора shell,

после запуска потомка проверяет (38) флаг параллельного выполнения

amp. Если этот флаг не установлен, то родитель выполняет вызов wait,

блокирующий shell до завершения потомка. (Этот вызов возвращает

идентификатор закончившегося процесса, а в параметре – код завершения,

но в нашем макете эти результаты не обрабатываются). Если флаг

параллельности установлен, то shell начинает следующую свою итерацию,

не дожидаясь завершения потомка.

При разработке командного интерпретатора необходимо следовать

"принципу пользователя", который может быть сформулирован так: те

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

более полного воплощения этого принципа в командный интерпретатор

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

примеры этих возможностей:

• установки по умолчанию – относятся, прежде всего, к параметрам

глобального окружения, обычно эти установки записываются в

отдельный файл – командный файл (cм. следующий раздел)

начальной загрузки типа AUTOEXEC.BAT или в пользовательский

профиль;

• встроенные сокращенные формы команд; в некоторых

интерпретаторах применяется метод автоматического завершения:

пользователь, введя первые символы команды, нажимает

364

определенную клавишу, и интерпретатор выводит в командную

строку остаток команды;

• интеграция команд – введение в состав CL сложных команд,

эквивалентных цепочке простых команд, иногда пользователь

имеет возможность создавать в командном интерпретаторе

собственные интегрированные команды, но чаще такая

возможность реализуется через командные файлы;

• сохранение истории – введенные командные строки запоминаются

в стеке, и по определенной клавише содержимое стека выбирается

в командную строку.

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

имеется возможность запуска вторичного интерпретатора. Эта

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

приложения возникает необходимость выполнить команды ОС, но

завершать приложение из-за этого нежелательно. Приложение является

процессом-потомком командного интерпретатора. Оно порождает новый

процесс (потомок приложения), в котором запускается еще одна копия

интерпретатора, как показано на рисунке 11.1. (Новый процесс-

интерпретатор может разделять сегмент кодов с первичным

интерпретатором). Теперь весь ввод в командную строку обрабатывается

этим вторичным интерпретатором. Вторичный интерпретатор может

запустить другое приложение и т.д. Вторичный интерпретатор запускается

в синхронном режиме и при его завершении (команда exit) продолжает

работать запускавшее его приложение.

365

Рисунок 11.1 Запуск вторичного командного интерпретатора

11.2. Командные файлы и язык процедур

Принцип пользователя диктует необходимость короткого обращения

к часто выполняемым последовательностям команд. Простым и

эффективным решением этой задачи является запись такой

последовательности в текстовый файл и обращение к ней в дальнейшем по

имени файла. Мы будем называть такие файлы командными. В

интерактивных системах их иногда также называют пакетными файлами

(batch file), а в пакетных – файлами процедур JCL. Командный

интерпретатор должен при вводе команды-обращения к такому файлу

распознать тип файла (иногда признак обращения к командному файлу

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

команды из файла.

В простейшем случае командный файл содержит неизменяемую

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

последовательности. Но сервис, обеспечиваемый инвариантными

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

типичным является "сценарий" работы, состоящий из многократного

повторения таких шагов:

• редактирование исходного модуля;

366

• компиляция;

• компоновка;

• выполнение.

Каждый шаг связан с вызовом новой программы, следовательно, с

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

файл мы должны обеспечить для него хотя бы один параметр – имя

исходного модуля. Параметры являются совершенно необходимым

свойством для командных файлов. Параметры нетрудно обрабатывать

простой текстовой подстановкой.

Очевидно также, что в том же сценарии не имеет смысла

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

ней обнаружены ошибки. Отсюда – необходимость управлять

последовательностью выполнения команд в командном сценарии.

Простейшим вариантом такого управления является включение в команду

условия ее выполнения, более сложный и гибкий вариант – условный

переход на ту или иную команду. В условии выполнения или перехода

должен анализироваться код завершения одной или нескольких

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

программ и команд с кодом 0. Код завершения может формироваться

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

exit и восприниматься процессом-родителем (командным

интерпретатором) в системном вызове wait.

Параметры и условия являются тем набором средств, который

обеспечивает минимальный необходимый сервис. Некоторые ОС на этом и

останавливаются. Другие же идут дальше. Пионером в этой области (как и

во многих других) является ОС Unix. Это неудивительно, так как Unix

воплощает "философию дешевых процессов", а для того, чтобы

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

средства интеграции. Просматривая публикации по ОС Unix в

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

наращивались новыми алгоритмическими возможностями, все более

367

приближая его к процедурному языку программирования. В итоге shell

обладает полным набором средств процедурного программирования

(операций и операторов), включая манипулирование с переменными shell-

программы, условный оператор, оператор множественного выбора,

операторы циклов, оператор обработки исключительных ситуаций, а также

возможность создания и вызова функций.

По иному пути пошла фирма IBM, в середине 80-х годов

представившая в составе ОС CMS (гостевой ОС в среде ОС виртуальных

машин VM/370) реструктурированный расширенный язык процедур –

REXX (Restructured EXtended eXecutor language) [46]. Разработчики этого

языка пошли не по пути наращивания командного языка

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

алгоритмический язык (за основу был взят язык PL/1) средств выполнения

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

тех пор время REXX практически не претерпел изменений и сейчас входит

в базовый комплект поставки не только CMS VM/ESA, но всех ОС фирмы.

Наряду со средствами процедурного программирования,

"унаследованными" от PL/1, в REXX включен в качестве базовых

операций языка ряд операций расширенной обработки строк и большое

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

обработкой строк, которыми компенсируется отсутствие того богатого

набора утилит, который имеется в Unix. Кроме того, в REXX имеются

возможности (эти возможности системно-зависимые) работы с текстовыми

файлами и обмена данными через очереди или перенаправление ввода-

вывода не только в файлы, но и в буферы, подобные программным

каналам, но со структурой дека (очереди с двумя концами). Вообще

область применения REXX шире, чем только применение его в качестве

командного интерпретатора ОС. Целый ряд продуктов системного и

промежуточного программного обеспечения IBM использует REXX как

368

интерпретатор своих команд. Оператор ADDRESS задает имя программы-

среды, в которую передается команда.

Оба типа развитых командных языков наряду с одинаковыми

алгоритмическими возможностями обладают также еще одним

принципиально важным общим свойством – они являются языками

интерпретирующего типа. Командный файл REXX или sell не требует

компиляции. Эта означает, что полный анализ такого файла не

производится (или производится только в первом приближении), и

интерпретатор выполняет его команда за командой, "не заглядывая"

вперед. Переменные командного файла имеют единственный тип – "строка

символов", и основные манипуляции над ними представляют собой

строковые операции. При выполнении арифметики строковые данные

прозрачно преобразуются в числовые, а результат операции вновь

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

командном файле. При выполнении каждого очередного оператора

командного файла производится подстановка вместо переменных shell-

или REXX-программы их значений. В обоих языках предусмотрены

средства "экранирования", защищающие строковые литералы от

интерпретации их как переменных. Строка, полученная после выполнения

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

это невозможно – как команда ОС (или другой целевой среды). В REXX

имеется возможность даже сформировать символьную строку в

переменной REXX-программы, а затем выполнить ее как оператор языка.

Таким образом, командные языки ОС обладают всеми

возможностями языков программирования, и, в принципе, пригодны для

создания не только командных процедур, но и некоторых программ

обработки данных. Выполнение командных файлов в режиме

интерпретации, конечно, делает такие программы менее эффективными,

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

369

в них некоторые дополнительные возможности и вырабатывает некоторый

особый стиль программирования.

11.3. Проблема идентификации адресата

При параллельном выполнении нескольких процессов возникает

проблема взаимодействия пользователя с ними: при появлении на экране

сообщения, как определит пользователь, какой из процессов это

сообщение выдал; при вводе сообщения пользователем, как ОС определит,

какому процессу сообщение адресовано? Решение этой проблемы зависит,

прежде всего, от степени интерактивности процессов (насколько часто они

обмениваются сообщениями с пользователем). Если процессы не очень

интерактивны, то им можно разрешить квазиодновременный вывод на

терминал: их сообщения могут чередоваться, но каждое сообщение

должно быть неделимым. В этом случае выводимое сообщение должно

нести в себе и идентификацию процесса, его выдавшего. Дейкстра [11]

подробно рассмотрел реализацию диалогового взаимодействия такого рода

с помощью семафоров. Им показано, что для этого случая ответы

пользователя должны либо также содержать идентификатор процесса-

адресата, либо пара действий вопрос–ответ должна быть одной

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

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

поэтому у пользователя также должна быть возможность откладывания

ответа с последующим возвращением к диалогу с этим же процессом.

Подход, предполагающий явное адресование сообщений, становится

излишне громоздким, если пользователь работает с существенно

интерактивными процессами. Общая идея обеспечения взаимодействия

для такого случая состоит в том, что в каждый момент времени только

одному процессу (по выбору пользователя) разрешается быть

370

интерактивным (foreground – на переднем плане), т.е. иметь доступ к

терминалу. Остальные процессы (background – фоновые) выполняются без

доступа к терминалу. В распоряжении пользователя имеются средства

изменения статуса процесса – перемещения его с заднего плана на

передний (текущий процесс переднего плана при этом отодвигается на

задний план).

Что делать с фоновым процессом, если у него возникла

необходимость выдать сообщение на терминал? Одним из решений может

быть блокировка такого процесса до его выдвижения. Более эффективным

является "скрытый" вывод, при котором обеспечивается для выполнения

процессов несколько параллельных сеансов. В каждом сеансе могут

выполняться один или несколько процессов. С каждым сеансом связан

собственный буфер логического терминала, включающий в себя

логический видеобуфер, логический буфер клавиатуры и логический

буфер мыши. Весь обмен процесс ведет с логическим видеобуфером

терминала. В каждый момент логический буфер только одного (так

называемого активного) сеанса связан с физическими буферами

терминальных устройств. Таким образом, фоновый сеанс может вести

обмен с терминалом (в основном – вывод) без отображения на терминал.

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

физическими устройствами, и на экране видеотерминала отображается

содержимое его логического видеобуфера. В составе API есть также

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

фоновом сеансе, необходимо выдать срочное сообщение, то он может

воспользоваться так называемым "иллюминатором". На время

существования иллюминатора ОС выделяет временный активный

видеобуфер, и все средства обмена с консолью работают с этим буфером.

Это очень сильное средство, используемое только в исключительных

случаях, так как на время существования иллюминатора блокируются