Деревянко А.С., Солощук М.Н. Операционные системы.Часть I. Построение и функционирование операционных систем
Подождите немного. Документ загружается.
121
Глава 4. Порождение программ и процессов
В первой главе мы дали строгое определение понятия процесса.
Прикладной программист, однако, разрабатывает не "процесс", а
"программу", не задумываясь обычно над тем, как и какие механизмы ОС
обеспечат ее представление в виде процесса. Ряд авторов (например, [12,
41]) нестрого определяют процесс как "программу в стадии выполнения".
Такое определение, "адаптированное" для уровня прикладного
программиста, в ряде случаев может считаться справедливым и весьма
удобным, так как соответствует интуитивному пониманию этого термина.
Программа превращается в процесс в тот момент, когда ОС создает
для нее блок контекста; последний отвечает за состояние процесса и
представляет процесс в состязаниях за обладание ресурсами. Блок
контекста, однако, не определяет содержание процесса. Содержательная
часть процесса представляется для ОС другой структурой – адресным
пространством процесса. Ядро ОС не обрабатывает содержимое адресного
пространства, а только отвечает за размещение его в памяти.
В первых двух разделах данной главы мы рассматриваем начальное
формирование содержимого адресного пространства: этапы компиляции,
компоновки и загрузки. Эти этапы в терминах функций управления
памятью (рисунок 3.1) выполняют функцию именования. Как правило, эти
этапы выполняются не ядром ОС, а утилитами, задолго до создания блока
контекста процесса. Таким образом, на этих этапах мы имеем дело не с
процессом, а с программой. Два следующих раздела рассматривают
управление адресным пространством программы при ее превращении в
процесс.
122
4.1. Компиляция
Этот этап реализуется не ОС, а системами программирования,
которые представляют собой "системы, образуемые языком
программирования, компиляторами или интерпретаторами программ,
представленных на этом языке, соответствующей документацией, а также
вспомогательными средствами для подготовки программ в форме,
пригодной для выполнения" [8]. Системы программирования – предмет
изучения отдельного курса, им посвящена обширная литература
(например, [3, 7, 24]), здесь мы остановимся только на тех их аспектах,
которые имеют отношение к ОС и аппаратным средствам вычислительной
системы.
Основным функциональным назначением системы
программирования является генерация объектного кода программы
(машинных команд). Компиляторы предварительно формируют структуру
виртуального адресного пространства: определяют состав сегментов и
формируют содержимое (образы) кодовых сегментов и сегментов
инициализированных статических данных.
Система программирования создает также дополнительный
интерфейс между программистом и ОС. Состав и спецификации этого
интерфейса могут быть либо стандартными для языка, либо определяться
конкретной системой программирования. Везде в этом пособии мы
описываем системные вызовы ОС как некоторые процедуры или функции
высокоуровневого языка программирования. В конкретных системах
программирования набор таких процедур составляет библиотеки
системных вызовов, эти процедуры обеспечивают передачу вызовов ОС в
той форме, в какой они специфицированы для данной ОС (например, в
виде программного прерывания с передачей параметров через регистры
общего назначения). Многие процедуры систем программирования
123
включают в себя интегрированный системный сервис – выполнение в
составе одной процедуры нескольких системных вызовов с некоторой
обработкой их результатов. Можно говорить о том, что системы
программирования продолжают тенденцию виртуализации ресурсов: они
формируют на базе примитивов, обеспечиваемых системными вызовами
ОС, ресурсы более высокого уровня, доступные через средства системы
программирования. Так, работая на языке высокого уровня, мы имеем в
своем распоряжении виртуальную ЭВМ, в которой "система команд"
представлена операциями, операторами и стандартными процедурами
языка, а адресация выполняется в пространстве символьных имен.
Некоторые языки или их конкретные системы программирования могут
включать в себя и более сложные средства управления ресурсами, такие
как: буферизацию ввода/вывода (см. главу 6), работу с файлами сложной
логической структуры (см. главу 7), средства синхронизации и
взаимодействия процессов (см. главу 8) и т.д.
С целью получения наиболее эффективного объектного кода
компиляторы могут выполнять оптимизацию обрабатываемой программы.
Можно выделить три стадии такой оптимизации:
• системно-независимая;
• системно-зависимая, но аппаратно-независимая;
• аппаратно-зависимая.
Ни одна из указанных стадий не является строго обязательной. На
первой стадии выполняется оптимизация логической структуры
программы и ее виртуальной памяти. К оптимизационным процедурам
этого этапа можно отнести: оптимизацию циклов, устранение избыточных
вычислений, преобразование индексных выражений, сокращение числа
переменных и т.п. Эти методы требуют не пооператорного просмотра, а
анализа всей программы или ее участка. Такая оптимизация может
осуществляться либо на уровне исходного языка, либо на уровне
124
некоторого промежуточного языка. Подавляющее большинство
современных языков высокого уровня воплощает принципы структурного
программирования [10], а это означает, что, с одной стороны,
эффективность алгоритма зачастую приносится в жертву его ясности, но, с
другой, – что логическая структура программы получается строгой и,
следовательно, легко анализируемой и оптимизируемой. Общность
принципов структурного программирования для разных языков позволяют
также формировать единое промежуточное представление разноязыковых
программ и применять оптимизационные процедуры, не зависящие от
языка.
Системно-зависимая стадия оптимизации связана более всего с
дисциплинами управления памятью в ОС. Если компилятор "знает", какие
алгоритмы управления памятью (например, страничного обмена)
применяет ОС, он может "помочь" ОС. Поскольку компилятор, в отличие
от ОС, обладает возможностью глобального анализа программы, он может
предсказывать будущую потребность в тех или иных страницах памяти,
влиять на размер и состав рабочего набора процесса. Компилятор может
также перестроить программу таким образом, чтобы повысить степень
локализации обращений к памяти и тем самым снизить интенсивность
страничного обмена.
Роль аппаратно-зависимой оптимизации все более возрастает с
развитием процессорных архитектур. Мы уже отмечали, что на
компилятор, таким образом, возлагается задача расположения команд
программы в такой последовательности, чтобы обеспечить максимальную
загрузку конвейерных линий. Рассмотрим пример возможного
дальнейшего развития этой идеи.
Недостатком современных суперскалярных процессоров является
необходимость для процессора в каждом цикле анализировать поток
команд, чтобы определить, какие конвейерные линии могут быть
125
использованы. Это является препятствием как для увеличения числа
линий, так и для сокращения времени цикла. Перспективной для RISС-
процессоров, по-видимому, является идея упаковки нескольких простых
команд в одну большую команду фиксированной длины. Такая команда
называется VLIW (very long instruction word – очень длинное командное
слово). Составляющие VLIW-команды должны выполняться строго
последовательно, сами VLIW-команды могут выполняться параллельно.
Процессор, таким образом, просто загружает очередную VLIW-команду в
очередную конвейерную линию, не занимаясь анализом командного
потока. Задача формирования VLIW-команд с оптимизацией их под
данную платформу ложится на компилятор. На сегодняшний день
подобные подходы применяются, например, в процессорах фирмы Hewlett-
Packard и процессоре Itanium фирмы Intel.
4.2. Компоновка и загрузка
Очевидно, что ни одно сколько-нибудь сложное программное
изделие не может быть реализовано в виде единственного модуля.
Модульность программ и данных является необходимым условием
структурного программирования при применении его как нисходящего,
так и восходящего вариантов. Преимущества модульного конструирования
могут, однако, в полной мере проявиться только, если обеспечивается
раздельная компиляция модулей. Но если результаты раздельной
компиляции представляют собой также отдельные объектные модули, то
должен быть этап в подготовке программы, который бы компоновал из
объектных модулей единую программу, готовую к выполнению, –
загрузочный модуль. Кроме того, если компилятор обрабатывает каждый
модуль отдельно, он не имеет возможности полностью выполнить
функцию именования, – в объектном модуле остаются
126
непреобразованными обращения к процедурам и данным, определенным в
других модулях. Обеспечение обращений к внешним по отношению к
модулю именам называется связыванием. Операции компоновки и
связывания выполняются специальными программами-компоновщиками
(синоним – редактор связей, linker) и связывающими загрузчиками.
В соответствии с декларированной нами в предыдущей главе
"свободой выбора" операцию связывания можно выполнять на разных
этапах подготовки программы:
• статическое связывание этапа подготовки – выполняется
компоновщиком, вызываемые модули включаются в загрузочный
модуль программы;
• статическое связывание этапа загрузки – выполняется
связывающим загрузчиком, вызываемые модули подключаются к
программе уже в оперативной памяти;
• динамическое связывание этапа загрузки – отличается от
предыдущего варианта тем, что обеспечивает совместное
использование одних и тех же копий модулей в памяти разными
программами;
• динамическое связывание этапа выполнения – загрузка модулей и
установка связей происходит при выполнении программы и
управляет ими сама программа.
Статическое связывание обеспечивается соглашениями о формате
объектных модулей. В любых вариантах эти форматы предусматривают
наличие в объектном модуле двух таблиц – таблицы входов и таблицы
внешних ссылок. В первой перечисляются имена и относительные адреса в
модуле тех процедур и элементов данных, к которым разрешены
обращения из других модулей. Во второй – имена внешних точек, к
которым имеются обращения из данного модуля, с каждым таким именем
связан также список адресов внутри модуля, которые содержат обращения
127
к этому внешнему имени. При статическом связывании создается таблица
входных точек – глобальная для всей программы. По мере компоновки
программы из входящих в нее модулей их входные точки заносятся в эту
таблицу, а их локальные адреса в модуле заменяются адресами в общем
адресном пространстве программы. Затем в каждом модуле находятся (по
таблице внешних ссылок) обращения к внешним модулям и имена в этих
обращениях заменяются на адреса, получаемые из глобальной таблицы
входных точек.
При статическом связывании может происходить также и
формирование оверлейной структуры адресного пространства программы,
рассмотренное в предыдущей главе.
Вспомним, что на этапе загрузки может происходить также
трансляция виртуальных адресов программы в физические адреса. В этом
случае загрузочный модуль должен содержать таблицу перемещений –
список тех адресов в программе, которые должны быть модифицированы
при загрузке базовым адресом программы. Эти операции выполняются
перемещающим загрузчиком, пример такого загрузчика – загрузчик EXE-
файлов в MS DOS.
Статическое связывание и загрузка выполняются системными
утилитами, не входящими в ядро ОС, они не составляют основной предмет
нашего рассмотрения. Алгоритмы функционирования редакторов связей и
перемещающих загрузчиков подробно рассматриваются, например, в [3,
13], здесь же мы остановимся на проблемах динамического связывания,
выполняемого ОС.
Современные ОС позволяют сочетать статическую компоновку с
динамической. Хотя в литературе, посвященной этим ОС, возможность
динамического связывания описывается как принципиально новая, на
самом деле она была впервые реализована еще в 1965 году в ОС MULTICS
[30], и с тех пор ее механизмы не претерпели значительных изменений. В
128
современных ОС модули, подключаемые к программам динамически,
носят название библиотек динамической компоновки (dynamic link library),
соответственно, файлы, содержащие образы таких модулей имеют
расширения DLL.
Выполнение динамической компоновки иллюстрируется рисунком
4.1. Структуры данных динамической компоновки в принципе сходны со
структурами для компоновки статической. Для модуля основной
программы компоновщик создает таблицу, функционально идентичную
таблице внешних ссылок. В этой таблице указывается имя файла для
каждого динамически подключаемого модуля и имена тех процедур в
модуле, к которым имеются обращения в программе. Вызовы процедур в
теле программы содержат обращения к соответствующим элементам этой
таблицы. С другой стороны, при компоновке модуля, предназначенного
для динамического подключения, для него создается таблица входов. При
компоновке загрузчик (на этапе загрузки) или ядро ОС (на этапе
выполнения) выполняет установку связей: находит в памяти или загружает
в память динамически подключаемый модуль и по его таблице входов
находит требуемую процедуру. Строка таблицы внешних ссылок
модифицируется – теперь она содержит переход по адресу найденной
процедуры. Последующие обращения к этой же входной точке уже не
вызывают каких-либо дополнительных действий.
129
а) модули до связывания
б) модули после связывания
Рисунок 4.1 Установка межмодульных связей при динамической компоновке
При совместном использовании процедур, входящих в состав
модулей DLL, несколькими процессами все процессы используют один и
тот же экземпляр кода DLL, но для каждого использования создается
отдельный стек, таким образом, для каждого использования имеется свой
набор экземпляров локальных переменных процедуры.
Динамическая компоновка при загрузке совершенно прозрачна для
программы. При подготовке программных и DLL-файлов требуются
специальные директивы для компоновщика, но в самом тексте программы
обращения к динамически подключаемым процедурам ничем не
отличаются от обращений к процедурам, подключенным статически. В
современных ОС динамически подключаемые библиотеки широко
используются для системного программного обеспечения. API ОС,
средства работы с терминалом, графические средства и т.п. представляют
собой библиотеки динамической компоновки, совместно используемые
всеми программами. При загрузке любой программы эти модули, как
правило, уже находятся в памяти.
Динамическая компоновка несколько ухудшает быстродействие
программы: во-первых, расходуется время на установление связей при
130
выполнении, во-вторых, при уже установленных связях обращение
производится через посредство таблицы внешних ссылок. Преимущества
же динамической компоновки бесспорны: во-первых, достигается
экономия оперативной памяти за счет совместного использования
модулей, во-вторых, достигается экономия внешней памяти за счет
уменьшения объема загрузочных модулей, в-третьих, создается
возможность модификации и полной замены модулей динамической
компоновки без изменения двоичного кода главной программы.
Динамическая компоновка на этапе выполнения дает возможность
программе самой управлять порядком загрузки модулей и установки
связей. Программа может, например, менять загруженный в память набор
модулей в разных фазах своего выполнения или использовать разные
модули в зависимости от конфигурации вычислительной системы или
условий выполнения и т.п. Для обеспечения таких возможностей ОС
должна предоставлять в распоряжение программиста соответствующий
набор системных вызовов. Этот набор может быть следующим.
Системный вызов:
mod_handle = loadModule (mod_name);
загружает модуль из файла с указанным именем. Если указанного модуля
нет в памяти, ОС производит загрузку его из файла, если же модуль в
памяти уже есть, ОС просто увеличивает на 1 счетчик использований этого
модуля. Вызов должен возвращать манипулятор модуля, используемый
для его идентификации во всех последующих операциях с ним.
Возможна модификация этого вызова:
mod_handle = getModuleHandle (mod_name);
получить манипулятор модуля: если модуль уже есть в памяти, вызов
возвращает его манипулятор (и увеличивает счетчик использований), если
нет – возвращает признак ошибки. В последнем случае программа может