Совместное использование ресурсов и управление ими
Одной из важных задач операционной системы является управление имеющимися в ее распоряжении ресурсами (основной памятью, устройствами ввода-вывода, процессором), а также их распределение между разными активными процессами. При разработке стратегии распределения ресурсов необходимо принимать во внимание следующие факторы.
• Равноправность. Обычно желательно, чтобы всем процессам, претендующим на какой-то определенный ресурс, предоставлялся к нему одинаковый
доступ. В особенности это касается заданий, принадлежащих к одному и
тому же классу, т.е. заданий с аналогичными требованиями к ресурсам.
• Дифференциация отклика. С другой стороны, может понадобиться, чтобы
операционная система по-разному относилась к заданиям различного класса, имеющим различные запросы. Нужно попытаться сделать так, чтобы
операционная система выполняла распределение ресурсов в соответствии с целым набором требований. Операционная система должна действовать в
зависимости от обстоятельств. Например, если какой-то процесс ожидает
доступа к устройству ввода-вывода, операционная система может спланировать выполнение этого процесса так, чтобы как можно скорее освободить
устройство для дальнейшего использования другими процессами.
• Эффективность. Операционная система должна повышать пропускную способность системы, сводить к минимуму время ее отклика и, если она работает в системе разделения времени, обслуживать максимально возможное
количество пользователей. Эти требования несколько противоречат друг
другу; насущной проблемой исследования операционных систем является поиск нужного соотношения в каждой конкретной ситуации.
Задача управления ресурсами и их распределения типична для исследований операционных систем; здесь могут применяться математические результаты, полученные в этой области. Кроме того, важно измерять активность системы, что позволяет следить за ее производительностью и вносить коррективы в ее работу.
На рис. 2.11 показаны основные элементы операционной системы, участвующие в планировании процессов и распределении ресурсов в многозадачной среде. Операционная система поддерживает несколько очередей, каждая из которых является просто списком процессов, ожидающих своей очереди на использование какого-то ресурса. В краткосрочную очередь заносятся процессы, которые (или, по крайней мере, основные части которых) находятся в основной памяти и готовы к выполнению. Выбор очередного процесса осуществляется краткосрочным планировщиком, или диспетчером. Общая стратегия состоит в том, чтобы каждому находящемуся в очереди процессу давать доступ по очереди; такой метод называют циклическим (round-robin). Кроме того, процессам можно присваивать различный приоритет.
Рис. 2.11. Ключевые элементы многозадачной операционной системы
В долгосрочной очереди находится список новых процессов, ожидающих возможности использовать процессор. Операционная система переносит их из долгосрочной очереди в краткосрочную. В этот момент процессу необходимо выделить определенную часть основной памяти. Таким образом, операционная система должна следить за тем, чтобы не перегрузить память или процессор, добавляя в систему слишком много процессов. К одному и тому же устройству ввода-вывода могут обращаться несколько процессов, поэтому для каждого устройства создается своя очередь. И здесь операционная система должна решать, какому процессу предоставить освободившееся устройство ввода-вывода в первую очередь.
Во время прерывания управление переходит к обработчику прерываний, который является частью операционной системы. В силу своей функциональности процесс может обратиться к некоторому сервису операционной системы, например к драйверу устройства ввода-вывода. При этом происходит вызов обработчика обращений к сервисам, который становится точкой входа в операционную систему. Независимо от того, произошло ли прерывание или обращение к сервису, после его обработки планировщик выберет из краткосрочной очереди процесс для выполнения.
Далее в этом разделе приводится чисто функциональное описание; эти модули в различных операционных системах имеют разные особенности и устройство.
Структура системы
С добавлением в операционные системы все новых функций, а также с ростом возможностей управляемого операционными системами аппаратного обеспечения и его разнообразия возрастает степень их сложности. Операционная система CTSS, введенная в эксплуатацию в Массачусетском технологическом институте в 1963 году, занимала в памяти около 32000 36-битовых слов. Операционная система OS/360, выпущенная фирмой IBM через год, содержала более миллиона машинных команд. Система Multics, совместная разработка которой была завершена специалистами Массачусетского технологического института и компанией Bell Laboratories к 1975 году, разрослась до 20 миллионов команд. Ради справедливости отметим, что впоследствии на меньших машинах стали появляться операционные системы и попроще, но и они неуклонно усложнялись с развитием аппаратного обеспечения и ростом требований со стороны пользователей. Так, современная система UNIX по своей сложности намного превосходит свой почти игрушечный первоначальный вариант, разработанный несколькими талантливыми программистами в начале 70-х годов. То же самое произошло с простой системой MS-DOS, со временем переросшей в сложные и мощные операционные системы OS/2 и Windows 2000. Так, операционная система Windows NT содержит около 16 миллионов строк кода, а в Windows 2000 этот показатель увеличен более чем в два раза.
Увеличение размера полнофункциональных операционных систем и сложности выполняемых ими задач стало причиной возникновения трех широко распространенных проблем. Во-первых, операционные системы доходят до пользователей с хроническим опозданием. Это касается как выпуска новых операционных систем, так и обновления уже существующих. Во-вторых, в системах появляются скрытые ошибки, которые начинают проявлять себя в рабочих условиях и требуют исправления и доработки системы. В-третьих, рост производительности зачастую происходит не так быстро, как планируется.
Как же следует организовать структуру операционных систем, чтобы упростить работу с ними и преодолеть перечисленные проблемы? Некоторые решения очевидны. Программное обеспечение должно состоять из модулей, что упростит организацию процесса его разработки и облегчит выявление и устранение ошибок. Модули по отношению друг к другу должны иметь тщательно разработанные и максимально простые интерфейсы, что также облегчит задачи программиста. Кроме того, меньше усилий потребует эволюция такой системы. Если взаимодействие модулей друг с другом происходит по простым и четким правилам, изменение любого модуля окажет минимальное влияние на остальные.
Однако оказалось, что для больших операционных систем, код которых состоит из миллионов или десятков миллионов строк, принцип модульного программирования сам по себе не избавляет от всех проблем. По этой причине возросла популярность концепции уровней иерархии, а также информационной абстракции. В иерархической структуре современной операционной системы различные функции находятся на разных уровнях в зависимости от их сложности, временных характеристик и степени абстракции. Систему можно рассматривать как набор уровней, каждый из которых выполняет свой ограниченный круг заданий, входящий в комплекс задач операционной системы. Работа компонентов определенного уровня основывается на работе компонентов, находящихся на более низком уровне; функции более высокого уровня используют примитивы нижнего по отношению к нему уровня. В идеале уровни должны быть определены так, чтобы при изменении одного из них не изменялись остальные.
Как правило, чем ниже уровень, тем меньше время работы его компонентов. Некоторые элементы операционной системы должны непосредственно взаимодействовать с аппаратным обеспечением компьютера, элементарные процессы в котором иногда длятся не более нескольких миллионных долей секунды. Составляющие операционной системы, поддерживающие взаимосвязь с пользователем, находятся на другом конце временного диапазона. Пользователи вводят команды весьма медленно — до одной команды за несколько секунд.
В каждой отдельно взятой операционной системе перечисленные принципы применяются по-разному. Для получения общего представления об операционных системах на данном этапе изложения представим пример обобщенной модели иерархической операционной системы, описанной в [BROW84] и [DENN84]. Она, несомненно, полезна для понимания сути дела, хотя и не соответствует ни одной реальной операционной системе. Сама модель приведена в табл. 2.4 и состоит из следующих уровней.
• Уровень 1. В него входят электронные схемы; объектами данного уровня
являются регистры, ячейки памяти и логические элементы. Над этими объектами выполняются различные действия, такие, как очистка содержимого
регистра или считывание ячейки памяти.
• Уровень 2. Набор команд процессора. В число операций, выполняемых на
этом уровне, входят те, которые допускаются набором команд машинного
языка, например сложение, вычитание, загрузка значения из регистра или
сохранение в нем.
• Уровень 3. Содержит концепцию процедуры (подпрограммы), а также операции вызова и возврата.
• Уровень 4. Уровень прерываний, которые заставляют процессор сохранить
текущий контекст и выполнить подпрограмму обработки прерывания.
На самом деле первые четыре уровня не являются частями операционной системы, они составляют аппаратное обеспечение процессора. Однако на этих уровнях уже появляются некоторые элементы операционной системы, такие, как программы обработки прерываний. Вплотную к операционной системе мы подходим только на пятом уровне, на котором возникают концепции, связанные с многозадачностью.
• Уровень 5. На этом уровне вводится понятие процесса, под которым подразумевается работающая программа. В число фундаментальных требований к
операционной системе, способной поддерживать одновременную работу не
скольких процессов, входят способность приостанавливать процессы и возобновлять их выполнение. Для этого необходимо сохранять содержимое
регистров аппаратного обеспечения, чтобы можно было переключаться с одного процесса на другой. Кроме того, если процессы должны взаимодействовать между собой, необходим механизм их синхронизации. Одной из важнейших концепций устройства операционных систем является семафор — простейший способ передачи сигналов, который рассмотрен в главе 5, "Параллельные вычисления: взаимоисключения и многозадачность".
• Уровень 6. Компоненты этого уровня взаимодействуют со вспомогательными запоминающими устройствами компьютера. На этом уровне происходит
позиционирование считывающих головок и физическая передача блоков
данных. Для планирования работы и уведомления процесса о завершении
запрошенной операции уровень 6 использует компоненты уровня 5.
• Уровень 7. Создает логическое адресное пространство процессов. Уровень
организует виртуальное адресное пространство в виде блоков, которые могут перемещаться между основной памятью и вспомогательным запоминающим устройством. Широко распространены следующие три схемы: использование страниц фиксированного размера, использование сегментов переменного размера и комбинация тех и других. Если нужный блок отсутствует в основной памяти, то данный уровень передает уровню 6 запрос о передаче этого блока.
До сих пор речь шла только о взаимодействии операционной системы с процессором. Компоненты операционной системы, относящиеся к восьмому и более высоким уровням, вступают во взаимодействие с внешними объектами, такими, как периферийные устройства, а возможно — с сетью и компьютерами, подключенными к сети. Объектами этих уровней являются логические именованные объекты, которые могут совместно использоваться несколькими процессами, исполняющимися на одном или на нескольких компьютерах.
• Уровень 8. Отвечает за обмен информацией и сообщениями между процессами.
На этом уровне происходит более богатый обмен информацией, чем на уровне 5,
который обеспечивает работу первичного сигнального механизма для синхронизации процессов. Одним из наиболее мощных инструментов подобного типа является конвейер, представляющий собой логический канал передачи данных
между процессами. Конвейер определяется как канал, передающий вывод одного процесса на вход другого; кроме того, он может быть использован и для связи с процессом внешних устройств или файлов. Эта концепция рассматривается в главе 6, "Взаимоблокировка и голодание".
• Уровень 9. Обеспечивает долгосрочное хранение файлов. На этом уровне данные, хранящиеся на вспомогательном запоминающем устройстве, рассматриваются как абстрактные объекты переменной длины, в противоположность аппаратно-зависимому рассмотрению вторичной памяти как набора дорожек, секторов и блоков фиксированного размера, присущему уровню 6.
• Уровень 10. Предоставляет доступ к внешним устройствам с помощью
стандартных интерфейсов.
• Уровень 11. Поддерживает связь между внешними и внутренними идентификаторами системных ресурсов и объектов. Внешний идентификатор — это имя,
которое может использоваться приложением или пользователем. Внутренний
идентификатор — это адрес или другой индикатор, используемый нижними
уровнями операционной системы для обнаружения объекта и управления им.
Эта связь поддерживается с помощью каталога, который включает в себя не
только взаимное отображение внешних и внутренних идентификаторов, но и
такие характеристики, как, например, права доступа.
• Уровень 12. Предоставляет полнофункциональные средства поддержки
процессов. Возможности этого уровня намного превосходят возможности уровня 5, на котором поддерживается только содержимое регистров процессора, имеющее отношение к процессу, и логика диспетчеризации процессов. На уровне 12 эта информация используется для упорядоченного управления процессами. Сюда же относится и виртуальное адресное пространство процессов, список объектов и процессов, с которыми оно может взаимодействовать, и правила, ограничивающие это взаимодействие; параметры, переданные процессам при их создании, и прочие характеристики процессов, которые могут быть использованы операционной системой для управления.
• Уровень 13. Обеспечивает взаимодействие операционной системы с пользователем. Этот уровень называется оболочкой (shell), так как он отделяет пользователя от деталей внутреннего устройства операционной системы и представляет ее пользователю как набор сервисов. Оболочка принимает команды пользователя или инструкции-управления заданиями, интерпретирует их, создает необходимые процессы и управляет ими. На этом уровне, например, может быть реализован графический интерфейс, предоставляющий пользователю возможность выбора команды с помощью меню и отображающий результаты работы на экране.
Описанная гипотетическая модель операционной системы дает представление о ее структуре и может служить руководством по реализации конкретной операционной системы. В процессе изучения изложенного в настоящей книге курса читателю будет полезно время от времени возвращаться к этой структуре, чтобы лучше понимать, как отдельные компоненты операционных систем соотносятся друг с другом.
Таблица 2.4. Иерархическая модель операционной системы2
Дата добавления: 2016-06-05; просмотров: 2462;