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

тема 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 и MS­DOS.      Каждая защищенная подсистема работает в режиме пользователя, вызывая системный сервис 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 были внесены существенные изменения ­ все  перечисленные выше модули были перенесены в ядро, что отдалило эту ОС от идеальной  микроядерной архитектуры, но зато резко повысило ее производительность.     Данный пример иллюстрирует главную проблему, с которой сталкиваются разработчики ОС,  решившие применить микроядерный подход, ­ что включить в микроядро, а что вынести в  пользовательское пространство. В идеальном случае микроядро может состоять только из средств  передачи сообщений и средств взаимодействия с аппаратурой, в том числе средств доступа к  механизмам привилегированной защиты. Однако многие разработчики не всегда жестко  придерживаются принципа минимизации функций ядра, часто жертвуя этим ради повышения  производительности. В результате реализации ОС образуют некоторый спектр, на одном краю  которого находятся системы с минимально возможным микроядром, а на другом ­ системы, в  которых микроядро выполняет достаточно большой объем функций. Конфигурация микроядра  конкретной ОС определяется в соответствии с критериями эффективности, применимыми к данной  системе.