extracted_text:
ресурсы вычислительной системы. управление ресурсами
тема 3 вопрос 2
К ресурсам вычислительной системы относят такие ее средства, которые могут быть выделены
процессу обработки данных.
Ресурсы вычислительной системы можно разбить на первичные – аппаратные ресурсы и вторичные –
логические, программные и информационные ресурсы.
К числу первичных ресурсов современных вычислительных систем относятся процессоры, основная
память, диски и др., за которыми стоят реальные аппаратные средства. Они являются наиболее
значимыми для вычислительного процесса.
Вторичные ресурсы связаны с техническими устройствами косвенно, так как являются логическими,
виртуальными. Однако их введение – это необходимая абстракция, удобная не только для создателей
ОС, но и для пользователей.
Управление ресурсами вычислительной системы с целью наиболее эффективного их использования
составляет важную часть функций любой ОС. Критерии эффективности, в соответствии с которыми
ОС организует управление ресурсами, могут различаться. Например, в одних системах важна
пропускная способность вычислительной системы, а в других – время её реакции. Зачастую ОС
должны одновременно удовлетворять нескольким противоречащим друг другу критериям, что
доставляет разработчикам серьезные трудности.
Управление ресурсами включает решение следующих общих, не зависящих от типа ресурса задач:
1)планирование ресурса – определение, какому процессу, когда и в каком количестве (если ресурс
может быть разбит на части) следует выделить данный ресурс;
2) удовлетворение запросов на ресурсы;
3) отслеживание состояния и учет использования ресурса – поддержание оперативной информации о
занятости ресурса и распределенной его доли;
4) разрешение конфликтов между процессами, использующими один ресурс.
Для решения этих общих задач управления ресурсами разные ОС используют алгоритмы, особенности
которых в конечном счете и определяют внешний облик ОС в целом, включая характеристики их
производительности, область применения и пользовательский интерфейс. Разработка и реализация
алгоритмов управления ресурсами является очень важным этапом при проектировании системы.
Организация эффективного совместного использования ресурсов несколькими процессами – это
весьма сложная задача, обусловленная в основном случайным характером возникновения запросов на
потребление ресурсов. Анализ и определение оптимальных параметров обслуживания запросов
является предметом специальной области прикладной математики – теории массового обслуживания.
В рамках этой теории разработано множество методов, позволяющих планировать распределение
критически важных ресурсов с учетом всевозможных стохастических и детерминированных событий.
ВЫЧИСЛИТЕЛЬНАЯ СИСТЕМА И ЕЕ РЕСУРСЫ
Вычислительная система (ВС)  это взаимосвязанная совокупность аппаратных средств
вычислительной техники и программного обеспечения, предназначенная для обработки информации.
Иногда под ВС понимают совокупность технических средств ЭВМ, в которую входит не менее двух
процессоров, связанных общностью управления и использования общесистемных ресурсов (память,
периферийные устройства, программное обеспечение и т.п.).
Ресурсы вычислительной системы
К ресурсам вычислительной системы относят такие средства вычислительной системы, которые могут
быть выделены процессу обработки данных на определенный квант времени. Основными ресурсами
ВС являются процессоры, области оперативной памяти, наборы данных, периферийные устройства,
программы.

file_name: тема 3 вопрос 2.docx

title: Лекция "Ресурсы вычислительной системы. "


extracted_text:
тема 3 вопрос 4
Классическая архитектура
Наиболее общим подходом к структуризации операционной системы является разделение всех
ее модулей на две группы:
∙  ядро – модули, выполняющие основные функции операционной системы;
∙  модули, выполняющие вспомогательные функции операционной системы.
Модули ядра выполняют такие базовые функции операционной системы, как управление
процессами, памятью, устройствами вводавывода и т. п. Ядро составляет сердцевину
операционной системы, без него она является полностью неработоспособной и не сможет
выполнить ни одну из своих функций.
В состав ядра входят функции, решающие внутрисистемные задачи организации
вычислительного процесса, такие как переключение контекстов, загрузка/выгрузка станиц,
обработка прерываний. Эти функции недоступны для приложений. Другой класс функций ядра
служит для поддержки приложений, создавая для них так называемую прикладную программную
среду. Приложения могут обращаться к ядру с запросами – системными вызовами – для
выполнения тех или иных действий, например для открытия и чтения файла, вывода
графической информации на дисплей, получения системного времени и т. д. Функции ядра,
которые могут вызываться приложениями, образуют интерфейс прикладного программирования
– API.
Функции, выполняемые модулями ядра, являются наиболее часто используемыми функциями
операционной системы, поэтому скорость их выполнения определяет производительность всей
системы в целом. Для обеспечения высокой скорости работы операционной системы все модули
ядра или большая их часть постоянно находятся в оперативной памяти, то есть являются
резидентными.
Некоторые компоненты операционной системы оформлены как обычные приложения, то есть в
виде исполняемых модулей стандартного для данной операционной системой формата, поэтому
очень сложно провести четкую грань между операционной системой и приложениями.
Вспомогательные модули операционной системы обычно подразделяются на следующие группы:
∙  утилиты – программы, решающие отдельные задачи управления и сопровождения
компьютерной системы, такие, например, как программы сжатия дисков, архивирования данных
на магнитную ленту;
∙  системные обрабатывающие программы – текстовые или графические редакторы,
компиляторы, компоновщики, отладчики;
∙  программы предоставления пользователю дополнительных услуг – специальный вариант
пользовательского интерфейса, калькулятор и даже игры;
∙  библиотеки процедур различного назначения, упрощающие разработку приложений, например
библиотека математических функций, функций вводавывода и т. д.
Для надежного управления ходом выполнения приложений операционная система должна иметь
по отношению к приложениям определенные привилегии. Иначе некорректно работающее
приложение может вмешаться в работу системы и, например, разрушить часть ее кодов.
Обеспечить привилегии операционной системе невозможно без специальных средств аппаратной
поддержки. Аппаратура компьютера должна поддерживать как минимум два режима работы —
пользовательский режим (user mode) и привилегированный режим, который также называют
режимом ядра (kernel mode). На рисунке 5 представлено такое разделение режимов.
Приложения ставятся в подчиненное положение за счет запрета выполнения в пользовательском
режиме некоторых критичных команд, связанных с переключением процессора с задачи на
задачу, управлением устройствами вводавывода, доступом к механизмам распределения и
защиты памяти.
Уровней привилегий может быть несколько – 2, 3, 4 и т. д. Между количеством уровней
привилегий, реализуемых аппаратно, и количеством уровней привилегий, поддерживаемых
операционной системой, нет прямого соответствия. Так, на базе четырех уровней,
обеспечиваемых процессорами компании Intel, операционная система OS/2 строит трехуровневую систему привилегий, а операционные системы Windows NT, UNIX и некоторые
другие ограничиваются двухуровневой системой.
Повышение устойчивости операционной системы, обеспечиваемое переходом ядра в
привилегированный режим, достигается за счет некоторого замедления выполнения системных
вызовов. Системный вызов привилегированного ядра инициирует переключение процессора из
пользовательского режима в привилегированный, а при возврате к приложению – переключение
из привилегированного режима в пользовательский (Рисунок 6). Во всех типах процессоров изза
дополнительной двукратной задержки переключения переход на процедуру со сменой режима
выполняется медленнее, чем вызов процедуры без смены режима.
Вычислительную систему, работающую под управлением операционной системы на основе ядра,
можно рассматривать как систему, состоящую из трех иерархически расположенных слоев:
нижний слой образует аппаратура, промежуточный – ядро, а утилиты, обрабатывающие
программы и приложения, составляют верхний слой системы Каждый слой обслуживает
вышележащий слой, выполняя для него некоторый набор функций, которые образуют
межслойный интерфейс.
Поскольку ядро представляет собой сложный многофункциональный комплекс, то
многослойный подход обычно распространяется и на структуру ядра.
Ядро может состоять из следующих слоев.
∙  Средства аппаратной поддержки операционной системы. К операционной системе относят,
естественно, не все аппаратные устройства компьютера, а только средства её аппаратной
поддержки, то есть те, которые прямо участвуют в организации вычислительных процессов:
средства поддержки привилегированного режима, систему прерываний, средства переключения
контекстов процессов, средства защиты областей памяти и т. п.
∙  Машиннозависимые компоненты операционной системы. Этот слой образуют программные
модули, в которых отражается специфика аппаратной платформы компьютера. В идеале этот
слой полностью экранирует вышележащие слои ядра от особенностей аппаратуры.
∙  Базовые механизмы ядра. Этот слой выполняет наиболее примитивные операции ядра, такие
как программное переключение контекстов процессов, диспетчеризацию прерываний,
перемещение страниц из памяти на диск и обратно и т. п.
∙  Менеджеры ресурсов. Этот слой состоит из мощных функциональных модулей, реализующих
стратегические задачи по управлению основными ресурсами вычислительной системы. Обычно
на данном слое работают менеджеры (называемые также диспетчерами) процессов, ввода
вывода, файловой системы и оперативной памяти.
∙  Интерфейс системных вызовов. Этот слой является самым верхним слоем ядра и
взаимодействует непосредственно с приложениями и системными утилитами, образуя
прикладной программный интерфейс операционной системы. Функции API, обслуживающие
системные вызовы, предоставляют доступ к ресурсам системы в удобной и компактной форме,
без указания деталей их физического расположения.
Приведенное разбиение ядра операционной системы на слои является достаточно условным. В
реальной системе количество слоев и распределение функций между ними может быть и иным.
Архитектура операционной системы, основанная на привилегированном ядре и приложениях
пользовательского режима, стала, по существу, классической. Ее используют многие популярные
операционные системы, в том числе многочисленные версии UNIX, IBM OS/390, OS/2, и с
определенными модификациями – Windows NT.
6.Классическая архитектура ОС.
Любая сложная система должна иметь понятную и рациональную структуру, или делиться на
модули, имеющие законченное функциональное назначение с четко оговоренными правилами
взаимодействия. Ясное понимание каждого модуля существенно упрощает его понимание и
развитие.
Широкая функциональность ОС неизбежно приводит к сложности ее архитектуры, под которой
понимают структурную организацию ОС на основе различных модулей. Обычно в состав ОС
входят исполняемые модули и объектные модули стандартных для данной ОС форматов,
библиотеки разных типов, программные модули специальных формата (например, загрузчик и
драйверы), конфигурационные файлы, документация и т.д. Большинство современных ОС представляют собой хорошо структурированные модульные
системы, способные к развитию, расширению и переносу на другие платформы. Какой либо
единой архитектуры ОС не существует, но есть универсальные подходы к структурированию
ОС.
Ядро и вспомогательные модули
В состав ядра входят функции решающие внутрисистемные задачи организации вычислительного
процесса, такие как переключение контекстов, загрузка станиц, обработка прерываний. Эти
функции недоступны для приложений. Другой задачей ядра является поддержка приложений,
использую так называемую прикладную программную среду. Приложения могут обращаться к
ядру с запросами  системными вызовами  для выполнения тех или иных действий. Функции
ядра которые могут быть вызваны приложениями образуют интерфейс прикладного
программирования API.
Функции которые выполняет ядро наиболее часто востребованы, поэтому скорость их
выполнения определяет производительность системы в целом. Для обеспечения высокой
скорости работы ОС все модули ядра или большая их часть находятся постоянно в памяти, то
есть являются резидентными.
Обычно ядро оформляется в виде программного модуля некоторого специального формата,
отличающегося от формата пользовательских приложений.
Остальные модули ОС выполняют полезные, но менее обязательные функции. Решение о
принадлежности программы к ОС принимает производитель.
Вспомогательные модули ОС обычно подразделяют на следующие группы:
Утилиты  программы, решающие задачи управления и сопровождения компьютерной системы.
Системные обрабатывающие программы текстовые и графические редакторы, компиляторы и
т.д.
Программы предоставления пользователю дополнительных услуг специальный вариант
пользовательского интерфейса или игры.
Библиотеки процедур различного назначения, упрощающие разработку приложений. Разделение
ОС на ядро и модули обеспечивает легкую расширяемость.
Дополнительные модули ОС обычно загружаются в оперативную память только на время
выполнения, т.е. являются транзитивными.
Важным свойством ОС основанной на ядре, является возможность защиты кодов и данных ОС за
счет выполнения функций ядра в привилегированном режиме.
Ядро
Работает в привилегированном режиме, защищено от приложений пользователя
Распределяет основные ресурсы системы
Выполняет роль арбитра в споре приложений за ресурсы
Аппаратура компьютера должна поддерживать как минимум два режима работы:
Режим пользователя
Режим супервизора
ОС должна работать с исключительными полномочиями, для того чтобы играть роль арбитра в
споре приложений за ресурсы компьютера в мультипрограммном режиме.
Для обеспечения уровней привилегий, без поддержки аппаратуры  не обойтись. Аппаратура
должна поддерживать как минимум для режима  пользовательский и привилегированный
режим.




o
o

file_name: тема 3 вопрос 3.docx

intro:
Наиболее общим подходом к структуризации операционной системы является разделение всех ее модулей на две группы:
•  ядро – модули, выполняющие основные функции операционной системы;
•  модули, выполняющие вспомогательные функции операционной системы.
Модули ядра выполняют такие базовые функции операционной системы, как управление процессами, памятью, устройствами ввода-вывода и т. п. Ядро составляет сердцевину операционной системы, без него она является полностью неработоспособной и не сможет выполнить ни одну из своих функций.

информатика

group: Дисциплины

title: Лекция "Классическая архитектура"


extracted_text:
тема 3 вопрос 4
классическая архитектура ос
6.Классическая архитектура ОС.
Любая сложная система должна иметь понятную и рациональную структуру, или делиться
на модули, имеющие законченное функциональное назначение с четко оговоренными
правилами взаимодействия. Ясное понимание каждого модуля существенно упрощает его
понимание и развитие.
Широкая функциональность ОС неизбежно приводит к сложности ее архитектуры, под
которой понимают структурную организацию ОС на основе различных модулей. Обычно в
состав ОС входят исполняемые модули и объектные модули стандартных для данной ОС
форматов, библиотеки разных типов, программные модули специальных формата
(например, загрузчик и драйверы), конфигурационные файлы, документация и т.д.
Большинство современных ОС представляют собой хорошо структурированные модульные
системы, способные к развитию, расширению и переносу на другие платформы. Какой либо
единой архитектуры ОС не существует, но есть универсальные подходы к
структурированию ОС.
Ядро и вспомогательные модули
В состав ядра входят функции решающие внутрисистемные задачи организации
вычислительного процесса, такие как переключение контекстов, загрузка станиц,
обработка прерываний. Эти функции недоступны для приложений. Другой задачей ядра
является поддержка приложений, использую так называемую прикладную программную
среду. Приложения могут обращаться к ядру с запросами  системными вызовами  для
выполнения тех или иных действий. Функции ядра которые могут быть вызваны
приложениями образуют интерфейс прикладного программирования API.
Функции которые выполняет ядро наиболее часто востребованы, поэтому скорость их
выполнения определяет производительность системы в целом. Для обеспечения высокой
скорости работы ОС все модули ядра или большая их часть находятся постоянно в памяти,
то есть являются резидентными.
Обычно ядро оформляется в виде программного модуля некоторого специального
формата, отличающегося от формата пользовательских приложений.
Остальные модули ОС выполняют полезные, но менее обязательные функции. Решение о
принадлежности программы к ОС принимает производитель.
Вспомогательные модули ОС обычно подразделяют на следующие группы:
Утилиты  программы, решающие задачи управления и сопровождения компьютерной
системы.
Системные обрабатывающие программы текстовые и графические редакторы,
компиляторы и т.д. Программы предоставления пользователю дополнительных услуг специальный вариант
пользовательского интерфейса или игры.
Библиотеки процедур различного назначения, упрощающие разработку приложений.
Разделение ОС на ядро и модули обеспечивает легкую расширяемость.
Дополнительные модули ОС обычно загружаются в оперативную память только на время
выполнения, т.е. являются транзитивными.
Важным свойством ОС основанной на ядре, является возможность защиты кодов и данных
ОС за счет выполнения функций ядра в привилегированном режиме.
Ядро
 Работает в привилегированном режиме, защищено от приложений пользователя
 Распределяет основные ресурсы системы
 Выполняет роль арбитра в споре приложений за ресурсы
 Аппаратура компьютера должна поддерживать как минимум два режима работы:
o Режим пользователя
o Режим супервизора
ОС должна работать с исключительными полномочиями, для того чтобы играть роль
арбитра в споре приложений за ресурсы компьютера в мультипрограммном режиме.
Для обеспечения уровней привилегий, без поддержки аппаратуры  не обойтись.
Аппаратура должна поддерживать как минимум для режима  пользовательский и
привилегированный режим.

file_name: тема 3 вопрос 4.docx

title: Лекция "Классическая архитектура ОС"


extracted_text:
тема 3 вопрос 5
 Микроядерная архитектура ОС.
Микроядерная   архитектура   является   альтернативой   классическому   способу
построения   ОС.   В   отличие   от   традиционной   архитектуры,   согласно   которой   ОС
представляет   собой   монолитное   ядро,   реализующее   основные   функции   по   управлению
аппаратными   ресурсами   и   организующее   среду   для   выполнения   пользовательских
процессов, микроядерная архитектура распределяет функции ОС между микроядром и
входящими   в   состав   ОС   системными   сервисами,   реализованными   в   виде   процессов,
равноправных с пользовательскими приложениями.
Главной особенностью данного подхода является то, что в привилегированном режиме
остается работать только очень малая часть ОС, называемая соответственно микроядром.
Микроядро защищено  от остальных частей ОС и пользовательских приложений. Набор
входящих   в   состав   микроядра   функций,   как   правило,   соответствует   слою   базовых
механизмов обычного ядра, хотя в состав микроядра включаются далеко не все базовые
функции   ядра,   а   только   функции   управления   процессами,   обработки   прерываний,
управления виртуальной памятью, пересылки сообщений, управления устройствами ввода
вывода.   Выполнение   таких   функций   ОС   практически   невозможно   реализовать   в
пользовательском   режиме.   Все   машиннозависимые   модули   ОС   также   включаются   в
микроядро.
Не   вошедшие   в   состав   микроядра   высокоуровневые   функции   и   модули   ядра
оформляются в виде обычных приложений, работающих в пользовательском режиме. При
этом на разработчика ОС ложится далеко неоднозначная задача принятия решения о том,
какой   из   модулей
  будет   работать   в   привилегированном   режиме,   а   какой   в
пользовательском. Как правило, на это решение сильное влияние  оказывает специфика
применения данной ОС и критерии, которым она должна удовлетворять. В общем случае
многие менеджеры ресурсов, являющиеся неотъемлемой частью ядра ОС с классической
архитектурой, остаются за пределами микроядра и работают в пользовательском режиме.
Работающие в пользовательском режиме менеджеры ресурсов имеют принципиальные
отличия от традиционных утилит ОС и системных обрабатывающих программ ОС, хотя
при микроядерной архитектуре всеэти программные компоненты также оформлены в виде
приложений.   Утилиты   и   обрабатывающие   программы   вызываются   в   основном
пользователями.   Ситуации,   когда   одному   приложению   требуется   выполнение   функции
другого приложения, возникают крайне редко, поэтому в ОС с классической архитектурой
отсутствует механизм, с помощью которого одно приложение могло бы вызвать функции
другого. Принципиально другая ситуация возникает в том случае, если в форме обычного
приложения   оформляется   часть   ОС.   По   определению   основным   назначением   такого
приложения   является   обслуживание   запросов   других   приложений,   например   создание
процесса, выделение памяти, проверка прав доступа к ресурсу и т.д. Вследствие этого
вынесенные в пользовательский режим менеджеры ресурсов являются  серверами ОС, то
есть   модулями,   основное   назначение   которых   –   обслуживание   запросов   локальных
приложений   и   других   модулей   ОС.   Совершенно   очевидно,   что   при   реализации
микроядерной   архитектуры   необходимо   обеспечить   наличие   в   ОС   удобного   и
эффективного способа вызова процедур одного процесса из другого. Поддержка такого
механизма является одной из главных задач, возложенных на микроядро ОС.
          Клиент, которым может быть как пользовательская прикладная программа, так и
другой компонент ОС, запрашивает у соответствующего сервера выполнение некоторой
функции, посылая ему сообщение. Микроядро ОС, выполняющееся в привилегированном
режиме, имеет доступ к адресным пространствам каждого из этих приложений и поэтому
может выступать в качестве посредника при передаче сообщений. Микроядро сначала
передает сообщение, содержащее имя и параметры вызываемой процедуры
соответствующему серверу, затем сервер выполняет запрошенную операцию, после чего
микроядро возвращает результаты клиенту посредством другого сообщения. Таким образом, работа микроядерной ОС соответствует известной модели клиентсервер, в
которой роль транспортных средств выполняет микроядро
Микроядерная архитектура является альтернативой классическому способу
построения операционной системы, в которой многослойное ядро, выполняется в
привилегированном режиме.
Суть микроядерной архитектуры состоит в следующем. В привилегированном
режиме остается работать только очень небольшая часть ОС, называемая
микроядром (рис. 3.10). Микроядро защищено от остальных частей ОС и приложений.
В состав микроядра обычно входят машиннозависимые модули, а также модули,
выполняющие базовые (но не все!) функции ядра по управлению процессами, обработке
прерываний, управлению виртуальной памятью, пересылке сообщений и управлению
устройствами вводавывода, связанные с загрузкой или чтением регистров устройств.
Набор функций микроядра обычно соответствует функциям слоя базовых механизмов
обычного ядра. Такие функции операционной системы трудно, если не невозможно,
выполнить в пространстве пользователя.
Все остальные более высокоуровневые функции ядра оформляются в виде приложений,
работающих в пользовательском режиме. Однозначного решения о том, какие из
системных функций нужно оставить в привилегированном режиме, а какие перенести
в пользовательский, не существует. В общем случае многие менеджеры ресурсов,
являющиеся неотъемлемыми частями обычного ядра — файловая система,
подсистемы управления виртуальной памятью и процессами, менеджер безопасности
и т. п., — становятся «периферийными» модулями, работающими в пользовательском
режиме.
Работающие в пользовательском режиме менеджеры ресурсов имеют
принципиальные отличия от традиционных утилит и обрабатывающих программ
операционной системы. Они обслуживают запросы локальных приложений, и поэтому
называются серверами ОС. Очевидно, что для реализации микроядерной архитектуры
необходимым условием является наличие в операционной системе эффективного
способа вызова процедур одного процесса из другого. Поддержка такого механизма и
является одной из главных задач микроядра.
Схематично механизм обращения к функциям ОС, оформленным в виде серверов,
выглядит следующим образом (рис. 3.11). Клиент, которым может быть либо
прикладная программа, либо другой компонент ОС, запрашивает выполнение
некоторой функции у соответствующего сервера, посылая ему сообщение.
Непосредственная передача сообщений между приложениями невозможна, так как их
адресные пространства изолированы друг от друга. Микроядро, выполняющееся в
привилегированном режиме, имеет доступ к адресным пространствам каждого из
этих приложений и поэтому может работать в качестве посредника. Микроядро
сначала передает сообщение, содержащее имя и параметры вызываемой процедуры
нужному серверу, затем сервер выполняет запрошенную операцию, после чего ядро возвращает результаты клиенту с помощью другого сообщения. Таким образом,
работа микроядерной операционной системы соответствует известной модели
клиентсервер, в которой роль транспортных средств выполняет микроядро.

 2. Преущества и недостатки микроядерной архитектуры
 перационные системы, основанные на концепции микроядра, по сравнению с
предыдущими, имеют лучшую переносимость, расширяемость, надежность и создают
хорошие предпосылки для поддержки распределенных приложений. За эти
достоинства приходится платить снижением производительности, и это
является основным недостатком микроядерной архитектуры.
Высокая степень переносимостиобусловлена тем, что весь машиннозависимый код
изолирован в микроядре, поэтому для переноса системы на новый процессор требуется
меньше изменений и все они логически сгруппированы вместе.
Расширяемость присуща микроядерной ОС в очень высокой степени. В традиционных
системах даже при наличии многослойной структуры нелегко удалить один слой и
поменять его на другой по причине множественности и размытости интерфейсов между
слоями. Добавление новых функций и изменение существующих требует хорошего знания
операционной системы и больших затрат времени. В то же время ограниченный набор четко
определенных интерфейсов микроядра открывает путь к упорядоченному росту и
эволюции ОС. Добавление новой подсистемы требует разработки нового приложения, что
никак не затрагивает целостность микроядра. Микроядерная структура позволяет не
только добавлять, но и сокращать число компонентов операционной системы, что также
бывает очень полезно. Например, не всем пользователям нужны средства безопасности или
поддержки распределенных вычислений, а удаление их из традиционного ядра чаще всего
невозможно. Обычно традиционные операционные системы позволяют динамически
добавлять в ядро или удалять из ядра только драйверы внешних устройств — ввиду частых
изменений в конфигурации подключенных к компьютеру внешних устройств подсистема
вводавывода ядра допускает загрузку и выгрузку драйверов «на ходу», но для этого она
разрабатывается особым образом (например, среда STREAMS в UNIX или менеджер
вводавывода в Windows NT). При микроядерном подходе конфигурируемость ОС не
вызывает никаких проблем и не требует особых мер .
Использование микроядерной модели повышает надежность ОС. Каждый сервер
выполняется в виде отдельного процесса в своей собственной области памяти и таким
образом защищен от других серверов операционной системы, что не наблюдается в традиционной ОС, где все модули ядра могут влиять друг на друга. И если отдельный
сервер терпит крах, то он может быть перезапущен без останова или повреждения
остальных серверов ОС. Более того, поскольку серверы выполняются в пользовательском
режиме, они не имеют непосредственного доступа к аппаратуре и не могут
модифицировать память, в которой хранится и работает микроядро. Другим
потенциальным источником повышения надежности ОС является уменьшенный объем кода
микроядра по сравнению с традиционным ядром — это снижает вероятность появления
ошибок программирования.
Производительность. При классической организации ОС (рис. 3.12, а) выполнение
системного вызова сопровождается двумя переключениями режимов, а при микроядерной
организации (рис. 3.12, б) — четырьмя. Таким образом, операционная система на основе
микроядра при прочих равных условиях всегда будет менее производительной, чем ОС с
классическим ядром. Именно по этой причине микроядерный подход не получил такого
широкого распространения, которое ему предрекали.

Серьезность этого недостатка хорошо иллюстрирует история развития Windows NT. В
версиях 3.1 и 3.5 диспетчер окон, графическая библиотека и высокоуровневые драйверы
графических устройств входили в состав сервера пользовательского режима, и вызов
функций этих модулей осуществлялся в соответствии с микроядерной схемой. Однако
очень скоро разработчики Windows NT поняли, что такой механизм обращений к часто
используемым функциям графического интерфейса существенно замедляет работу
приложений и делает данную операционную систему уязвимой в условиях острой
конкуренции. В результате в версию Windows NT 4.0 были внесены существенные
изменения — все перечисленные выше модули были перенесены в ядро, что отдалило эту
ОС от идеальной микроядерной архитектуры, но зато резко повысило ее
производительность.
Этот пример иллюстрирует главную проблему, с которой сталкиваются разработчики
операционной системы, решившие применить микроядерный подход, — что включать в
микроядро, а что выносить в пользовательское пространство. В идеальном случае
микроядро может состоять только из средств передачи сообщений, средств
взаимодействия с аппаратурой, в том числе средств доступа к механизмам привилегированной защиты. Однако многие разработчики не всегда жестко
придерживаются принципа минимизации функций ядра, часто жертвуя этим ради
повышения производительности. В результате реализации ОС образуют некоторый спектр,
на одном краю которого находятся системы с минимально возможным микроядром, а на
другом — системы, подобные Windows NT, в которых микроядро выполняет достаточно
большой объем функций.
ОСНОВНЫЕ ПОЛОЖЕНИЯ МИКРОЯДЕРНОЙ АРХИТЕКТУРЫ 1
    Микроядерная архитектура является альтернативой рассмотренному выше классическому
способу построения ОС. В отличие от традиционной архитектуры, согласно которой ОС
представляет собой монолитное ядро, реализующее основные функции по управлению аппаратными
ресурсами и организующее среду для выполнения пользовательских процессов, микроядерная
архитектура распределяет функции ОС между микроядром и входящими в состав ОС системными
сервисами, реализованными в виде процессов, равноправных с пользовательскими приложениями.
    Рассмотрим концепцию микроядерной архитектуры построения ОС. Главной особенностью
данного подхода является то, что в привилегированном режиме остается работать только очень
малая часть ОС, называемая соответственно микроядром. Микроядро защищено от остальных частей
ОС и пользовательских приложений. Набор входящих в состав микроядра функций, как правило,
соответствует слою базовых механизмов обычного ядра, хотя в состав микроядра включаются
далеко не все базовые функции ядра, а только функции управления процессами, обработки
прерываний, управления виртуальной памятью, пересылки сообщений, управления устройствами
вводавывода. Выполнение таких функций ОС практически невозможно реализовать в
пользовательском режиме. Все машиннозависимые модули ОС также включаются в микроядро.
    Не вошедшие в состав микроядра высокоуровневые функции и модули ядра оформляются в виде
обычных приложений, работающих в пользовательском режиме. При этом на разработчика ОС
ложится далеко неоднозначная задача принятия решения о том, какой из модулей  будет работать в
привилегированном режиме, а какой в пользовательском. Как правило, на это решение сильное
влияние оказывает специфика применения данной ОС и критерии, которым она должна
удовлетворять. В общем случае многие менеджеры ресурсов, являющиеся неотъемлемой частью ядра
ОС с классической архитектурой, остаются за пределами микроядра и работают в пользовательском
режиме. На рисунке ниже можно видеть основные различия в построении ОС с монолитным ядром
(рис. 5а) и с микроядерной архитектурой (рис. 5б).
    Работающие в пользовательском режиме менеджеры ресурсов имеют принципиальные отличия от
традиционных утилит ОС и системных обрабатывающих программ ОС, хотя при микроядерной
архитектуре все эти программные компоненты также оформлены в виде приложений. Утилиты и
обрабатывающие программы вызываются в основном пользователями. Ситуации, когда одному
приложению требуется выполнение функции другого приложения, возникают крайне редко, поэтому
в ОС с классической архитектурой отсутствует механизм, с помощью которого одно приложение
могло бы вызвать функции другого. Принципиально другая ситуация возникает в том случае, если в
форме обычного приложения оформляется часть ОС. По определению основным назначением такого
приложения является обслуживание запросов других приложений, например создание процесса,
выделение памяти, проверка прав доступа к ресурсу и т.д. Вследствие этого вынесенные в
пользовательский режим менеджеры ресурсов являются серверами ОС, то есть модулями, основное назначение которых  обслуживание запросов локальных приложений и других модулей ОС.
Совершенно очевидно, что при реализации микроядерной архитектуры необходимо обеспечить
наличие в ОС удобного и эффективного способа вызова процедур одного процесса из другого.
Поддержка такого механизма является одной из главных задач, возложенных на микроядро ОС.
    Рассмотрим типичный пример организации механизма обращения приложений к функциям ОС,
оформленным в виде серверов (рис. 6).
    Клиент, которым может быть как пользовательская прикладная программа, так и другой
компонент ОС, запрашивает у соответствующего сервера выполнение некоторой функции, посылая
ему сообщение. Следует заметить, что непосредственная передача сообщений между приложениями
невозможна, поскольку их адресные пространства изолированы друг от друга. Микроядро ОС,
выполняющееся в привилегированном режиме, имеет доступ к адресным пространствам каждого из
этих приложений и поэтому может выступать в качестве посредника при передаче сообщений.
Микроядро сначала передает сообщение, содержащее имя и параметры вызываемой процедуры
соответствующему серверу, затем сервер выполняет запрошенную операцию, после чего микроядро
возвращает результаты клиенту посредством другого сообщения. Таким образом, работа
микроядерной ОС соответствует известной модели клиентсервер, в которой роль транспортных
средств выполняет микроядро. Стандартизованные протоколы предоставления сервиса или ресурсов
позволяют серверу обслуживать клиента независимо от деталей их реализации, что открывает перед
разработчиками широкие возможности для построения распределенных систем. Инициатором
обмена обычно является клиент, который посылает запрос на обслуживание серверу, находящемуся
в состоянии ожидания. Один и тот же процесс может быть клиентом по отношению к одним
ресурсам и сервером для других. Данная модель успешно применяется не только при построении
ОС, но и при создании программного обеспечения любого уровня. Применение модели клиентсервер
по отношению к ОС состоит в реализации не вошедших в состав ядра компонентов ОС в виде
множества серверов, каждый из которых предназначен для обслуживания определенного ресурса
(например, управления памятью, процессами, контроля доступа и т. д.). Наиболее полно раскрыть
преимущества технологии клиентсервер позволяет применение методов объектноориентированного
проектирования и программирования. Если каждый сервер обслуживает только один тип ресурсов и
представляет его клиентам в виде некоторой абстрактной модели, то такой сервер можно
рассматривать как объект, так как ему присущи все необходимые для этого качества. Объект
должен обладать состоянием, поведением и индивидуальностью. Действительно, каждый сервер
выполняется в виде отдельного процесса и поэтому обладает индивидуальностью. Для каждого
сервера существует четко определенная модель состояний и переходов между ними. И, наконец,
"поведение" каждого сервера однозначно регламентируется протоколом его взаимодействия с
клиентами. Соответственно, можно создавать модель ОС, построенной по этим принципам, в виде
иерархии серверов и моделей представляемых ими ресурсов, а также описывать существующие
между ними взаимосвязи с помощью объектных отношений наследования, использования и
включения.
    Рассмотрим, как на практике применется концепция микроядерной архитектуры построения ОС.
    Одной из первых представила понятие микроядра фирма Next, которая использовала в своих
компьютерах систему Mach, прошедшую большой путь развития в университете КарнегиМеллона
при содействии Министерства обороны США. Теоретически ее небольшое привилегированное ядро,
окруженное службами пользовательского режима, должно было обеспечить беспрецедентную
гибкость и модульность. Но на практике это преимущество несколько уменьшилось изза наличия монолитного сервера ОС UNIX BSD 4.3, который выполнялся в пользовательском пространстве над
микроядром Mach. Однако Mach дал Next возможность предоставить службу передачи сообщений и
объектноориентированные средства, которые предстали перед потребителями в виде элегантного
интерфейса пользователя с графической поддержкой конфигурирования сети, системного
администрирования и разработки программного обеспечения.
    Затем пришла Microsoft Windows NT, рекламировавшая в качестве ключевых преимуществ
использования микроядра не только модульность, но и переносимость. Конструкция NT позволила
ей применить системы на основе процессоров Intel, MIPS и Alpha (и последующих) и поддерживать
симметричную многопроцессорность. Изза того что NT должна была выполнять программы,
написанные для DOS, Windows, OS/2 и ОС, использующих соглашения POSIX, Microsoft выбрала
модульность, присущую микроядерному подходу для того, чтобы сделать структуру NT не
3    Структурно Windows NT может быть представлена в виде двух слагаемых: часть ОС,
работающая в режиме пользователя, и часть ОС в режиме ядра.
    Часть, работающая в режиме ядра, называется executive Windows NT  исполнительной частью.
Она включает ряд компонентов, которые управляют виртуальной памятью, объектами (ресурсами),
вводомвыводом, файловой системой (включая сетевые драйверы), взаимодействием процессов и
частично системой безопасности. Эти компоненты контактируют между собой с помощью
межмодульных связей. Каждый компонент вызывает другие с помощью набора тщательно
специфицированных внутренних процедур.
    Вторую часть, работающую в режиме пользователя, составляют серверы  защищенные подсистемы
Windows NT. Серверы Windows NT называются защищенными, так как каждый из них выполняется в
отдельном процессе, память которого отделена от других процессов системой управления
виртуальной памятью NT executive. Так как подсистемы автоматически не могут совместно
использовать память, они общаются друг с другом посредством посылки сообщений. Сообщения
передаются как между клиентом и сервером, так и между двумя серверами. Все сообщения проходят
через исполнительную часть Windows NT.
    Поддержку защищенных подсистем обеспечивает исполнительная часть  Windows NT executive,
которая работает в пространстве микроядра и никогда не сбрасывается на диск. Ее составными
частями являются:
    1) менеджер объектов, создающий, удаляющий и управляющий объектами NT executive
абстрактными типами данных, используемыми для представления ресурсов системы;
    2) монитор безопасности, устанавливающий правила защиты на локальном компьютере. Охраняет
ресурсы ОС, выполняет защиту и регистрацию исполняемых объектов;
    3) менеджер процессов, создающий и завершающий, приостанавливающий и возобновляющий
процессы, а также хранящий о них информацию;
    4) менеджер виртуальной памяти;
    5) подсистема вводавывода, включающая в себя следующие компоненты:
     менеджер вводавывода, предоставляющий средства вводавывода, независимые от устройств;  файловые системы  NTдрайверы, выполняющие файлориентированные запросы на вводвывод
и транслирующие их в вызовы обычных устройств;
     сетевой редиректор и сетевой сервер  драйверы файловых систем, передающие удаленные
запросы на вводвывод на машины сети и получающие запросы от них;
     драйверы устройств NT executive  низкоуровневые драйверы, непосредственно управляющие
устройством;
     менеджер кэша, реализующий кэширование диска.
    Исполнительная часть, в свою очередь, основывается на службах нижнего уровня микроядра NT. В
функции микроядра входит:
     планирование процессов;
     обработка прерываний и исключительных ситуаций;
     синхронизация процессоров для многопроцессорных систем;
     восстановление системы после сбоев.
    Микроядро работает в привилегированном режиме и никогда не удаляется из памяти. Обратиться
к нему можно только посредством прерывания. Микроядро расположено над уровнем аппаратных
абстракций (Hardware Abstraction Level, HAL), который концентрирует в одном месте большую
часть машиннозависимых процедур. HAL располагается между NT executive и аппаратным
обеспечением и содержит такие детали, как контроллеры прерываний, интерфейсы вводавывода и
механизмы взаимодействия между процессорами. Такое решение позволяет легко переносить
Windows NT с одной платформы на другую путем замены только слоя HAL.
    При создании NT разработчики руководствовались задачами повышения производительности и
расширения сетевых возможностей, а также требованием поддержки определенного набора
прикладных сред. Эта цель была достигнута продуманным разделением функций между модулями
4микроядра и остальными модулями. Например, передача данных в файловую систему и по сети
производится быстрее в пространстве микроядра, поэтому внутри микроядра NT выделены буферы
для небольших по объему (от 16 до 32 Кб) операций чтения и записи, являющихся типичными для
приложений клиентсервер и распределенных приложений. Размещение этих функций вводавывода
внутри микроядра, может, и портит его академичность, но соответствует цели создания NT.
    Защищенные подсистемы Windows NT работают в пользовательском режиме и создаются Windows
NT во время загрузки ОС. Сразу после создания они начинают бесконечный цикл своего выполнения,
отвечая на сообщения, поступающие к ним от прикладных процессов и других подсистем. Среди
защищенных подсистем можно выделить подкласс, называемый подсистемами окружения.
Подсистемы окружения реализуют интерфейсы приложений ОС (API). Другие типы подсистем,
называемые интегральными подсистемами, исполняют функции, необходимые для ОС. Например,
большая часть системы безопасности Windows NT реализована в виде интегральной подсистемы,
сетевые серверы также выполнены как интегральные подсистемы.
    Наиболее важной подсистемой окружения является Win32  подсистема, которая обеспечивает
доступ для приложений к 32разрядной Windows API. Дополнительно эта система обеспечивает графический интерфейс пользователя и управляет вводомвыводом данных пользователя. Также
поддерживаются подсистемы POSIX, OS/2, 16разрядная Windows и MSDOS.
    Каждая защищенная подсистема работает в режиме пользователя, вызывая системный сервис NT
executive для выполнения привилегированных действий в режиме ядра. Сетевые серверы могут
выполняться как в режиме пользователя, так и в режиме ядра в зависимости от того, как они
разработаны.
    Подсистемы связываются между собой путем передачи сообщений. Когда, например,
пользовательское приложение вызывает какуюнибудь APIпроцедуру, подсистема окружения,
обеспечивающая эту процедуру, получает сообщение и начинает работать над ней либо обращаясь к
микроядру, либо посылая сообщение другой подсистеме. После завершения процедуры подсистема
окружения посылает приложению сообщение, содержащее возвращаемое значение. Посылка
сообщений и другая деятельность защищенных подсистем невидима для пользователя.
    Основным средством, скрепляющим все подсистемы Windows NT в единое целое, является
механизм вызова локальных процедур (Local Procedure Call, LPC). LPC представляет собой
оптимизированный вариант более общего средства  удаленного вызова процедур (Remote Procedure
Call, RPC), которое используется для связи клиентов и серверов, расположенных на разных машинах
сети.
    Средства LPC поддерживают несколько способов передачи данных между клиентами и серверами:
один обычно используется для передачи коротких сообщений, другой  для длинных сообщений, а
третий оптимизирован специально для использования подсистемой Win32. Каждая подсистема
устанавливает порт  канал связи, посредством которого с ней могут связываться другие процессы.
    Windows NT использует защищенные подсистемы для того, чтобы:
     обеспечить несколько программных интерфейсов (API), по возможности не усложняя при этом
базовый программный код (NT executive);
     изолировать базовую ОС от изменений или расширений в поддерживаемых API;
     объединить часть глобальных данных, требующихся всем API, и в то же время отделить данные,
использующиеся каждым отдельным API от данных других API;
     защитить окружение каждого API от приложений и окружения других API, а также защитить
базовую ОС от различных окружений;

позволить ОС расширяться в будущем за счет новых API.
    Таким образом, реализация частей ОС в виде серверов, выполняющихся в режиме пользователя,
является важнейшей частью проекта Windows NT, оказывающей глубокое воздействие на
функционирование всей системы.
    Микроядро NT служит, главным образом, средством поддержки для переносимой основной части
ОС  набора пользовательских сред. Концентрация машиннозависимых программ внутри микроядра
делает перенос NT на разнообразные процессоры относительно легким. Но в то время как некоторые
микроядра (Mach и Chorus) предполагается поставлять в качестве самостоятельного программного
продукта, из ОС Windows NT ядро вряд ли может быть вычленено для отдельного использования.
Это является одной из причин того, что некоторые специалисты не считают Windows NT истинно микроядерной ОС в том смысле, в котором таковыми являются Mach и Chorus. Те же критики
отмечают также, что NT не исключает, как это положено, все надстроенные службы из пространства
ядра и что драйверы устройств в NT по минимуму взаимодействуют с микроядром, предпочитая
работать непосредственно с лежащим ниже слоем аппаратной абстракции HAL.
2 повторяющей ни одну из существующих ОС. В результате NT поддерживает каждую надстроенную
ОС в виде отдельного модуля или подсистемы.
    Более современные архитектуры микроядра были предложены Novell, USL, Open Software
Foundation, IBM, Apple и др. Одним из основных соперников NT в части микроядер является
микроядро Mach 3.0, которое и IBM, и OSF взялись привести к коммерческому виду. Основной
соперник Mach   микроядро Chorus 3.0 фирмы Chorus Systems, выбранный USL за основу своих
предложений. Это же микроядро будет использоваться в SpringOS фирмы Sun  объектно
ориентированном преемнике ОС Solaris.
    Сегодня стало ясно, что имеется тенденция движения от монолитных систем в сторону
использования небольших ядер. Именно такой подход уже использовался компаниями QNX Software
и Unisys, в течение нескольких лет успешно поставляющих ОС на основе микроядра. ОС QNX
фирмы QNX Software обслуживает рынок систем реального времени, а ОС CTOS фирмы Unisys
популярна в области банковского дела.
    Теперь рассмотрим основные концепции построения двух наиболее популярных систем: Windows
NT и UNIXсистемы, основанной на микроядре Mach.
    Во многих UNIXподобных системах в качестве основы для построения выбрано микроядро Mach.
Разработка прообраза такой структуры началась в 1975 году в университете КарнегиМеллона. На
базе микроядра Mach эмулировались UNIX и другие ОС. Ядро Mach обеспечивает управление
памятью, процессами коммуникации и функции вводавывода. Идея построения ядра Mach состоит в
обеспечении механизмов, необходимых для работы системы, но стратегия использования этих
механизмов реализуется на уровне пользовательских процессов. Ядро управляет пятью главными
абстракциями:
     процессами;
     нитями;
     объектами памяти;
     портами;
     сообщениями.
    Процесс в Mach  это базисная единица распределения ресурсов, он имеет адресное пространство,
содержащее текст программы и данные. Нить в Mach является единицей выполнения. Она имеет
счетчик команд и набор регистров, связанных с ней. Каждая нить является частью одного процесса.
    Межпроцессное взаимодействие в Mach основано на передаче сообщений. Для того чтобы
получить сообщение, пользовательский процесс просит ядро создать защищенный почтовый ящик,
который называется порт. Порт хранится внутри ядра и способен поддерживать очередь
упорядоченного списка сообщений. Очереди не имеют фиксированной длины, но в целях управления
потоком для каждого порта отдельно устанавливается пороговое значение в n сообщений, так что всякий процесс, пытающийся послать еще одно сообщение в очередь длины n, приостанавливается
для того, чтобы дать порту возможность очиститься.
    Каждый процесс может предоставить другому процессу возможность посылать (или получать)
сообщения в один из принадлежащих ему портов. Такая возможность реализуется в виде мандата
(capability), который включает не только указатель на порт, но и список прав, которыми другой
процесс обладает по отношению к данному порту (например, право выполнить операцию послать
send). Все коммуникации в Mach используют этот механизм. Основной целью, которую ставили
перед собой разработчики средств коммуникации ядра Mach, являлась поддержка различных стилей
коммуникаций в сочетании с надежностью и гибкостью. Коммуникационные средства ядра Mach
поддерживают асинхронную передачу сообщений, механизм для реализации распределенных
вычислений, потоки байт (streams) и другие способы.
    В ядре Mach имеются различные серверы, которые работают поверх него. Наверное, самым
важным сервером является программа, которая содержит большое количество кодов BSD UNIX
(например, весь код файловой системы). Этот сервер представляет собой основной эмулятор UNIX.
Реализация механизма эмуляции UNIX в среде Mach состоит из двух частей  сервера UNIX и
библиотеки эмуляции системных вызовов. Когда система стартует, сервер UNIX инструктирует
ядро, чтобы оно перехватывало все прерывания системных вызовов и отображало векторы этих
прерываний на адреса внутри библиотеки эмуляции процесса UNIX', по которым расположены
обрабатывающие данные вызовы функции. Любой системный вызов, который делается UNIX
процессом, приводит к кратковременной передаче управления ядру, а затем к немедленной передаче
управления библиотеке эмуляции. Значения машинных регистров в момент передачи управления
библиотеке становятся теми же, что и в момент прерывания. Как только библиотека эмуляции
получает управление, она проверяет регистры для того, чтобы определить, какой системный вызов
нужно обработать. Затем библиотека делает вызов сервера UNIX, который и должен выполнить эту
работу.
После завершения обработки вызова пользовательская программа снова получает управление. Эта
передача управления не проходит через ядро.
    Хотя описанный метод выполнения программ UNIX и кажется запутанным, многочисленные
исследования показали, что он работает лучше, чем традиционные монолитные реализации ядра. В
дальнейшем работы над Mach будут фокусироваться на разделении сервера UNIX на несколько
серверов с более специфическими функциями.    ОС Windows NT с самого начала проектировалась
разработчиками компании Microsoft с учетом всех требований, предъявляемых к современным ОС.
При разработке ее структуры была в значительной степени использована концепция микроядра. В
соответствии с этой идеей ОС разделена на несколько подсистем, каждая из которых выполняет
отдельный набор сервисных функций, например сервисы памяти, по созданию процессов или по
планированию процессов. Каждый сервер работает в пользовательском режиме, выполняя цикл
проверки запроса клиента на одну из его сервисных функций. Клиент, которым может быть либо
другая компонента ОС, либо прикладная программа, запрашивает сервис, посылая сообщение на
сервер. Микроядро ОС, действуя в привилегированном режиме, доставляет сообщение нужному
серверу, затем сервер выполняет операцию, после этого ядро возвращает результат клиенту с
помощью другого сообщения.
ПРЕИМУЩЕСТВА И НЕДОСТАТКИ МИКРОЯДЕРНОЙ АРХИТЕКТУРЫ ОС, основанные на концепции микроядра, во многом удовлетворяют требованиям,
предъявляемым к современным ОС, обладая переносимостью, расширяемостью, надежностью, и
создают хорошие предпосылки для поддержки распределенных приложений. Но, к сожалению, все
эти достоинства ОС приобретает в ущерб производительности. Рассмотрим более подробно, чем же
обусловливается наличие перечисленных качеств у ОС, основанных на микроядерной архитектуре.
    Как уже было сказано ранее, микроядерной ОС присуща изолированность всего машинно
зависимого кода в микроядре, вследствие чего для переноса системы на новую аппаратную
платформу требуется минимальное количество изменений, причём все они логически
сгруппированы. Эта особенность ОС с микроядром является их несомненным достоинством.
    Особенности архитектуры микроядерных ОС обеспечивают их высокую степень расширяемости
по сравнению с другими ОС. В классических системах, даже если и реализуется многослойная
архитектура, бывает очень трудно, порой невозможно, поменять один слой на другой по причине
множественности и размытости межслойных интерфейсов. Изменение существующих и добавление
новых функций, а следовательно, изменение межслойных интерфейсов, требует не только глубокого
знания ОС, но и больших временных затрат. Наряду с этим ограниченный набор четко определенных
интерфейсов микроядра позволяет системе упорядоченно расти и эволюционировать. Добавление
очередной подсистемы требует только лишь разработки нового приложения и никоим образом не
затрагивает целостность микроядра. Микроядерная структура позволяет не только увеличивать, но и
сокращать число компонентов ОС, что также бывает необходимо. Например, не всем пользователям
нужны средства безопасности или поддержки распределенных приложений, а удаление их из
традиционного ядра зачастую просто невыполнимая задача. Обычно традиционные ОС позволяют
динамически добавлять в ядро или удалять из ядра только драйверы внешних устройств. Ввиду
частых изменений в конфигурации подключенных к компьютеру внешних устройств подсистема
вводавывода ядра допускает загрузку и выгрузку драйверов "на ходу", но для этого она
разрабатывается особым образом (например, среда STREAMS в UNIX или менеджер вводавывода в
Windows NT). При микроядерном подходе конфигурируемость не вызывает никаких проблем и не
требует особых мер, достаточно изменить файл с настройками начальной конфигурации системы или
же остановить ненужные больше серверы в ходе работы обычными для остановки приложений
средствами.
    Использование микроядерной модели повышает надежность ОС. Каждый сервер выполняется в
виде отдельного процесса в своей собственной области памяти и таким образом защищен от других
серверов ОС, чего не наблюдается в традиционной ОС, где все модули ядра влияют друг на друга. И
если отдельный сервер терпит крах, то он может быть перезапущен без останова или повреждения
остальных серверов ОС. Более того, поскольку серверы выполняются в пользовательском режиме,
они не имеют непосредственного доступа к аппаратуре и не могут модифицировать память, в
которой хранится и работает микроядро. Другим потенциальным источником повышения
надежности ОС является уменьшенный объем кода микроядра по сравнению с классическим ядром
это снижает вероятность появления ошибок программирования.
    Модель с микроядром хорошо подходит для поддержки распределенных вычислений, так как
использует механизмы, аналогичные сетевым,  взаимодействие клиентов и серверов путем обмена
сообщениями. Серверы микроядерной ОС могут работать как на одном, так и на разных
компьютерах. При получении сообщения от приложения микроядро обработает его самостоятельно
и передаст локальному серверу или же перешлет его по сети микроядру, работающему на другом компьютере. Переход к распределенной обработке требует минимальных изменений в работе ОС
просто локальный транспорт заменяется на сетевой.
    Все рассмотренные ранее свойства ОС с микроядерной архитектурой свидетельствовали о
предпочтительности ее использования разработчиками. Однако, как уже говорилось, все эти
качества приобретаются за счет снижения производительности ОС. Что же является этому
причиной?  Дело в том, что при классической организации ОС (рис. 7а) выполнение системного
вызова сопровождается двумя переключениями режимов, а при микроядерной организации (рис. 7б)
 четырьмя.
    Таким образом, ОС на основе микроядра при прочих равных условиях всегда будет менее
производительной, чем ОС с классическим ядром. Именно  поэтому микроядерный подход не
получил такого широкого распространения, которое ему предрекали.
    Серьезность этого недостатка хорошо иллюстрирует история развития ОС Windows NT. В версиях
3.1 и 3.5 диспетчер окон, графическая библиотека и высокоуровневые драйверы графических
устройств входили в состав сервера пользовательского режима и вызов функций этих модулей
осуществлялся в соответствии с микроядерной схемой. Но очень скоро разработчики Windows NT
поняли, что такой механизм обращений к часто используемым функциям графического интерфейса
существенно замедляет работу приложений и делает данную ОС уязвимой в условиях острой
конкуренции. В результате в версию Windows NT 4.0 были внесены существенные изменения  все
перечисленные выше модули были перенесены в ядро, что отдалило эту ОС от идеальной
микроядерной архитектуры, но зато резко повысило ее производительность.
    Данный пример иллюстрирует главную проблему, с которой сталкиваются разработчики ОС,
решившие применить микроядерный подход,  что включить в микроядро, а что вынести в
пользовательское пространство. В идеальном случае микроядро может состоять только из средств
передачи сообщений и средств взаимодействия с аппаратурой, в том числе средств доступа к
механизмам привилегированной защиты. Однако многие разработчики не всегда жестко
придерживаются принципа минимизации функций ядра, часто жертвуя этим ради повышения
производительности. В результате реализации ОС образуют некоторый спектр, на одном краю
которого находятся системы с минимально возможным микроядром, а на другом  системы, в
которых микроядро выполняет достаточно большой объем функций. Конфигурация микроядра
конкретной ОС определяется в соответствии с критериями эффективности, применимыми к данной
системе.

file_name: тема 3 вопрос 5.docx

title: Лекция "Микроядерная архитектура ОС."


extracted_text:
тема 3 вопрос 8
виды Совместимости ОС.
Свойство   ОС,   характеризующее   возможность   выполнения   в   ОС   приложений,
написанных для других ОС, называется совместимостью.
Существует   два   принципиально   отличающихся   вида   совместимости,   которые   не
следует   путать:  совместимость  на  двоичном  уровне
 совместимость  на  уровне
   и

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

  Двоичная совместимость  достигается в том случае, если можно взять исполняемую
программу, работающую в среде одной ОС, и запустить ее на выполнение в среде другой
ОС.
Совместимость   на   уровне  исходных   текстов  требует   наличия   соответствующих
компиляторов   в   составе   программного   обеспечения   компьютера,   на   котором
предполагается   использовать   данное   приложение,   а   также   совместимости   на   уровне
библиотек и системных вызовов. При этом необходима перекомпиляция исходных текстов
программ в новые исполняемые модули.
Таким образом, совместимость на уровне исходных текстов наиболее важное значение
имеет для разработчиков приложений, в распоряжении которых находятся эти исходные
тексты. Для конечных же пользователей практическое значение имеет только двоичная
совместимость, так как только в этом случае они могут без специальных навыков и умений
использовать программный продукт, поставляемый в виде двоичного исполняемого кода, в
различных операционных средах и на разных компьютерах. Для пользователя, купившего в
свое время пакет программ для MSDOS, важно, чтобы он мог запускать этот привычный
ему пакет без какихлибо изменений или ограничений на своей новой машине, работающей,
например, под управлением Windows NT. Множественные прикладные среды как раз и
обеспечивают совместимость данной ОС с приложениями, написанными для других ОС и
процессоров, на двоичном уровне, а не на уровне исходных текстов.
Каким   типом   совместимости   –   двоичной   или   совместимостью   исходных   текстов
обладает ОС, зависит от многих факторов. Самый значительный из  них – архитектура
процессора, на котором работает ОС. Только в том случае, если процессор использует тот
же   набор   команд   (возможно,   даже   более   расширенный,   но   ни   в   коем   случае   не
уменьшенный) и тот же диапазон адресов, двоичная совместимость может быть достигнута
довольно просто. Достаточно соблюсти несколько следующих условий:
   вызовы   функций   API,   которые   содержит   приложение,   должны   поддерживаться
данной ОС;
   внутренняя   структура   исполняемого   файла   приложения   должна   соответствовать
структуре исполняемых файлов данной ОС.
Несравнимо   сложнее   достигнуть  двоичной  совместимости   операционным  системам,
предназначенным для выполнения на процессорах, имеющих различающиеся архитектуры.
Кроме соблюдения приведенных выше условий, необходимо также организовать эмуляцию
двоичного кода.
Совместимость операционных систем
Виды совместимости
Свойство ОС, характеризующее возможность выполнения в ОС приложений,
написанных для других ОС, называется совместимостью.
Существует два принципиально отличающихся вида совместимости, которые не
следует путать: совместимость на двоичном уровне
  и

 совместимость на уровне исходных текстов. Приложения обычно хранятся в компьютере в виде исполняемых
файлов, содержащих двоичные образы кодов и данных.
 Двоичная совместимость достигается в том случае, если можно взять исполняемую
программу, работающую в среде одной ОС, и запустить ее на выполнение в среде другой
ОС.
Совместимость на уровне исходных текстов требует наличия соответствующих
компиляторов в составе программного обеспечения компьютера, на котором
предполагается использовать данное приложение, а также совместимости на уровне
библиотек и системных вызовов. При этом необходима перекомпиляция исходных текстов
программ в новые исполняемые модули.
Таким образом, совместимость на уровне исходных текстов наиболее важное значение
имеет для разработчиков приложений, в распоряжении которых находятся эти исходные
тексты. Для конечных же пользователей практическое значение имеет только двоичная
совместимость, так как только в этом случае они могут без специальных навыков и умений
использовать программный продукт, поставляемый в виде двоичного исполняемого кода, в
различных операционных средах и на разных компьютерах. Для пользователя, купившего в
свое время пакет программ для MSDOS, важно, чтобы он мог запускать этот привычный
ему пакет без какихлибо изменений или ограничений на своей новой машине, работающей,
например, под управлением Windows NT. Множественные прикладные среды как раз и
обеспечивают совместимость данной ОС с приложениями, написанными для других ОС и
процессоров, на двоичном уровне, а не на уровне исходных текстов.
Каким типом совместимости – двоичной или совместимостью исходных текстов
обладает ОС, зависит от многих факторов. Самый значительный из них – архитектура
процессора, на котором работает ОС. Только в том случае, если процессор использует тот
же набор команд (возможно, даже более расширенный, но ни в коем случае не
уменьшенный) и тот же диапазон адресов, двоичная совместимость может быть достигнута
довольно просто. Достаточно соблюсти несколько следующих условий:
 вызовы функций API, которые содержит приложение, должны поддерживаться
данной ОС;
 внутренняя структура исполняемого файла приложения должна соответствовать
структуре исполняемых файлов данной ОС.
Несравнимо сложнее достигнуть двоичной совместимости операционным системам,
предназначенным для выполнения на процессорах, имеющих различающиеся архитектуры.
Кроме соблюдения приведенных выше условий, необходимо также организовать эмуляцию
двоичного кода.
 Способы реализации совместимости
Во многих версиях ОС UNIX транслятор прикладных сред реализуется в виде
обычного приложения. В таких ОС, построенных с использованием микроядерной
концепции, как, например Windows NT или Workspace OS, прикладные среды выполняются
в виде серверов пользовательского режима. А в OS/2 с ее более простой архитектурой
средства организации прикладных сред встроены глубоко в ОС.
Стандартная   многоуровневая   структура   ОС   является   основой   для   наиболее
очевидного варианта реализации множественных прикладных сред. На рис. 9 операционная система ОС1 поддерживает кроме своих “родных” приложений приложения операционных
систем   ОС2   и   ОС3.   Для   этого     в   ее   составе   имеются   специальные   приложения   –
прикладные программные среды, которые транслируют интерфейсы “чужих” операционных
систем API ОС2 и API ОС3 в интерфейс своей “родной” операционной системы API ОС1.
Так, например, в случае, если бы в качестве ОС2 выступала операционная система UNIX, а
в качестве OC1 – OS/2, для выполнения системного вызова создания процесса fork() в
UNIXприложении   программная   среда   должна   была   обратиться   к   ядру   операционной
системы OS/2 с системным вызовом DosExecPgm().
Трудности при такой реализации возникают вследствие того, что поведение почти всех
функций,   составляющих   API   одной   ОС,   как   правило,   существенно   отличается   от
поведения соответствующих (если они вообще есть) функций другой ОС. Например, чтобы
функция  создания  процесса в  OS/2 DosExecPgm()   полностью соответствовала функции
создания процесса fork() в UNIXподобных системах, ее нужно изменить таким образом,
чтобы она поддерживала возможность копирования адресного пространства родительского
процесса в пространство процессапотомка, хотя при нормальном поведении этой функции
память
процессапотомка
инициализируется   на   основе
данных   нового   исполняемого
файла.

  рис.
Другой
вариант
реализации   множественных
прикладных
сред
подразумевает   наличие   в   ОС
равноправных
нескольких
прикладных
программных
интерфейсов.   В   приведенном
  10   примере
на
операционная
система
поддерживает
  приложения,
написанные   для   ОС1,   ОС2   и
ОС3. Это достигается путем размещения непосредственно в пространстве ядра системы
прикладных программных интерфейсов всех этих ОС: API ОС1, API  ОС2 и API ОС3. В
этом варианте функции уровня API обращаются к функциям нижележащего уровня ОС,
которые должны поддерживать все три в общем случае несовместимые прикладные среды.
Несмотря   на   то,   что   в   разных   ОС   поразному   осуществляется   управление   системным
временем,   используется   разный   формат   времени   дня,   на   основании   собственных
алгоритмов   разделяется   процессорное   время   и   т.д.,   функции   каждого   прикладного
программного интерфейса реализуются с учетом специфики соответствующей ОС. Для
каждой ОС будет полностью реализован свой прикладной интерфейс даже  в том случае,
если некоторые из функций  различных интерфейсов имеют аналогичное назначение. Выбор
того   или   иного   варианта   API   осуществляется   на   основании   идентифицирующих
характеристик, передаваемых в ядро соответствующим процессом.
Естественно, существует и способ построения множественных прикладных сред,
использующий концепцию микроядерного подхода. При этом крайне важно отделить
базовые, общие для всех прикладных сред, механизмы ОС от специфических для каждой из
прикладных сред высокоуровневых функций, решающих стратегические задачи. В
соответствии с микроядерной архитектурой все функции ОС реализуются микроядром и
серверами пользовательского режима. Важно заметить, что каждая прикладная среда
оформляется в виде отдельного сервера пользовательского режима и не включает базовых
механизмов (рис. 11). Приложения, используя API, обращаются с системными вызовами к соответствующей прикладной среде через микроядро. Прикладная среда обрабатывает
запрос, выполняет его (возможно, обращаясь для этого за помощью к базовым функциям
микроядра) и отсылает приложению результат. В ходе выполнения запроса прикладной
среде приходится, в свою очередь, обращаться к базовым механизмам ОС, реализуемым
микроядром и другими
серверами ОС.
Такому   подходу   к
конструированию
множественных   прикладных
средств
все
достоинства   и   недостатки
микроядерной   архитектуры,   в
частности:
присущи

   очень   просто   можно
добавлять   и   исключать   прикладные   среды,   что   является   следствием   хорошей
расширяемости микроядерных ОС;
 надежность и стабильность выражаются в том, что при отказе одной из прикладных
сред все остальные сохраняют работоспособность;
   низкая   производительность   микроядерных   ОС   сильно   сказывается   на   скорости
работы прикладных сред, а значит, и на скорости выполнения приложений.
Создание   в   рамках   одной   ОС   нескольких   прикладных   сред   для   выполнения
приложений   различных   ОС   представляет   собой   путь,   который   позволяет   иметь
единственную версию программы и переносить ее между ОС. Множественные прикладные
среды   обеспечивают   совместимость   на   двоичном   уровне   данной   ОС   с   приложениями,
написанными   для   других   ОС.   В   результате   пользователи   получают   большую   свободу
выбора ОС и более легкий доступ к качественному программному обеспечению. Однако
следует   заметить,   что   реализация   совместимости   прикладных   сред   ОС,   кардинально
отличающихся   используемым   аппаратным   обеспечением,   весьма   трудоемкая   и   сложная
работа, а эффект от нее может оказаться слишком малым.
К усовершенствованным ОС, явно содержащим средства множественных прикладных
сред,   относятся:   IBM   OS/2   2.x   и   Workplace   OS,   Microsoft   Windows   NT,   PowerOpen
компании   PowerOpen   Association,   версии   UNIX   от   Sun   Microsystems,   IBM   и   Hewlett
Packard. Кроме того, некоторые компании переделывают свои интерфейсы пользователя в
модули   прикладных   сред,   а   другие   предлагают   продукты   для   эмуляции   и   трансляции
прикладных сред, работающие в качестве прикладных программ.
Рассмотрим, каким образом реализуются множественные прикладные среды   в уже
описанной   нами   ранее   ОС   Windows   NT.   При   разработке   NT   важнейшим   рыночным
требованием являлось обеспечение поддержки по крайней мере двух уже существующих на
то время программных интерфейсов – OS/2 и POSIX, а также возможности достаточно
легкого добавления других API в будущем.
Как   уже   отмечалось,   для   того   чтобы   программа,   написанная   для   одной   ОС,
могла быть выполнена в рамках другой ОС, недостаточно лишь совместимости API.
Кроме   этого,   ей   необходимо   “родное”   окружение:   структура   процесса,   средства
управления памятью, средства обработки ошибок и исключительных ситуаций, механизмы
защиты ресурсов и семантика файлового доступа. Отсюда ясно, что поддержка нескольких прикладных   программных   сред   является   очень   непростой   задачей,   тесно   связанной   со
структурой ОС. Эта задача была успешно решена в Windows NT, при этом в полной мере
использовался опыт разработчиков ОС Mach из университета КарнегиМеллона, которые
смогли в своей клиентсерверной реализации UNIX отделить базовые механизмы ОС от
серверов API различных операционных систем.
Windows NT поддерживает пять прикладных сред операционныхсистем: MSDOS, 16
разрядный Windows, OS/2 1.x, POSIX и 32разрядный Windows (Win32). Все пять
прикладных сред реализованы как подсистемы окружения. Каждая работает в собственном
защищенном пользовательском пространстве. Подсистема Win32 обеспечивает поддержку
дисплея, клавиатуры и мыши для четырех оставшихся подсистем.
16битовые приложения DOS и Windows работают на VDM (virtual DOS machines –
виртуальные машины DOS), каждая из которых эмулирует полный 80x86 процессор с MS
DOS. В NT VDM является приложением Win32, значит, как и обычные модули прикладных
сред   для   UNIX,   приложения   DOS   и   16битовой   Windows   расположены   в   слое
непосредственно над подсистемой Win32.
Подсистемы OS/2 и POSIX построены подругому. В качестве полноценных подсистем
NT они могут взаимодействовать с подсистемой Win32 для получения доступа к вводу и
выводу, но также могут обращаться непосредственно к исполнительной системе NT за
другими   средствами   ОС.   Подсистема   OS/2   может   выполнять   многие   имеющиеся
приложения OS/2 символьного режима, включая OS/2 SQL Server, а также поддерживает
именованные каналы и NetBIOS.
Однако   возможности   подсистемы   POSIX   весьма   ограничены,   несмотря   на
непосредственный   доступ   ее   к   службам   ядра.   Приложения   POSIX   должны   быть
откомпилированы   специально   для   Windows   NT.   NT   не   работает   двоичным   кодом,
предназначенным для таких POSIXсовместимых систем, как UNIX. К тому же подсистема
POSIX NT не поддерживает печать, сетевой доступ, за исключением доступа к удаленным
файловым системам, и многие другие средства Win32, например, отображение на память
файлов и графику.
 NT executive выполняет базовые функции ОС и является той основой, на к

file_name: тема 3 вопрос 8.docx

title: Лекция "Виды Совместимости ОС"


extracted_text:
тема 3 вопрос 8
Виды совместимости ос
4.10 Совместимость ОС.
Свойство ОС, характеризующее возможность выполнения в ОС приложений, написанных для
других ОС, называется совместимостью.
Существует два принципиально отличающихся вида совместимости, которые не следует путать:
совместимость   на   двоичном   уровне
   и

 совместимость   на   уровне   исходных   текстов.

Приложения обычно хранятся в компьютере в виде исполняемых файлов, содержащих двоичные
образы кодов и данных.
 Двоичная совместимость достигается в том случае, если можно взять исполняемую программу,
работающую в среде одной ОС, и запустить ее на выполнение в среде другой ОС.
Совместимость на уровне исходных текстов требует наличия соответствующих компиляторов в
составе программного обеспечения компьютера, на котором предполагается использовать данное
приложение,   а   также   совместимости   на   уровне   библиотек   и   системных   вызовов.   При   этом
необходима перекомпиляция исходных текстов программ в новые исполняемые модули.
Таким образом, совместимость на уровне исходных текстов наиболее важное значение имеет для
разработчиков приложений, в распоряжении которых находятся эти исходные тексты. Для конечных
же пользователей практическое значение имеет только двоичная совместимость, так как только в
этом  случае   они   могут  без   специальных   навыков   и   умений   использовать  программный   продукт,
поставляемый в виде двоичного исполняемого кода, в различных операционных средах и на разных
компьютерах.   Для   пользователя,   купившего   в   свое   время   пакет   программ   для   MSDOS,   важно,
чтобы он мог запускать этот привычный ему пакет без какихлибо изменений или ограничений на
своей   новой   машине,   работающей,   например,   под   управлением   Windows   NT.   Множественные
прикладные среды как раз и обеспечивают совместимость данной ОС с приложениями, написанными
для других ОС и процессоров, на двоичном уровне, а не на уровне исходных текстов.
Каким типом совместимости – двоичной или совместимостью исходных текстов обладает ОС,
зависит от многих факторов. Самый значительный из них – архитектура процессора, на котором
работает ОС. Только в том случае, если процессор использует тот же набор команд (возможно, даже
более расширенный, но ни в коем случае не уменьшенный) и тот же диапазон адресов, двоичная
совместимость   может   быть   достигнута   довольно   просто.   Достаточно   соблюсти   несколько
следующих условий:
 вызовы функций API, которые содержит приложение, должны поддерживаться данной ОС;
 внутренняя структура исполняемого файла приложения должна соответствовать структуре
исполняемых файлов данной ОС.
Несравнимо   сложнее   достигнуть   двоичной   совместимости   операционным   системам,
предназначенным для выполнения на процессорах, имеющих различающиеся архитектуры. Кроме
соблюдения приведенных выше условий, необходимо также организовать эмуляцию двоичного кода.

file_name: тема 3 вопрос 8  вар2.docx

title: Лекция "Виды совместимости ос"