Студопедия  
Главная страница | Контакты | Случайная страница

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Архитектура операционных систем

Читайте также:
  1. DSM — система классификации Американской психиатрической ассоциации
  2. EIS и DSS системы.
  3. ERP-система
  4. GRID- системи
  5. I Объективные характеристики (потребление материальных благ; продолжительность жизни; система образования; время труда; показатель преступности);
  6. I. Общеметодологические (общесистемные) принципы.
  7. I. Судебно-следственная практика формирования системы доказательств по уголовному делу (постановка проблемы).
  8. I.1. Инновационный подход к системе освоения ценностей физической культуры и спорта.
  9. ICQ - это способ общения в сети, который позволяет вести беседу с любым зарегистрированным в системе ICQ и подключенным в данный момент к Интернету пользователем.
  10. Internet/Intranet-технологии в корпоративных информа­ционных системах.

 


Перечислим основные типы внутренней архитектуры операционных систем и в качестве примеров рассмотрим архитектуру наиболее распространенных операционных систем – систем UNIX и Windows.

Разливают всего три базовых типа архитектуры операционных систем:
• монолитная архитектура;
• многоуровневая архитектура;
• архитектура типа клиент-сервер на основе микроядра.
Рассмотрим каждый из этих типов архитектуры более подробно.

Монолитная архитектура операционной системы

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

 


При использовании монолитной архитектуры, аппаратно зависимый и аппаратно независимый код в составе операционной системы тесно переплетаются, что крайне затрудняет развитие операционной системы или ее перенос на другую аппаратную платформу. Наличие бессистемных разветвленных связей между компонентами операционной системы с монолитной архитектурой приводит к необходимости коррекции многих компонентов системы при реальной потребности изменения только одного из них. При этом может наблюдаться эффект снежной лавины – изменение одной процедуры потребовало изменение нескольких других, каждая из которых потребовала изменение еще нескольких других процедур и т.д.
Еще большие неудобства могут доставить глобальные данные, т.к. даже незначительное изменение их формата, необходимое для какой-то частной процедуры, в большинстве случаев потребует коррекции практически всех остальных процедур операционной системы.
Серьезные трудности возникают при сопровождении и технической поддержке операционной системы с монолитной архитектурой, в период ее эксплуатации, особенно если система находится в эксплуатации длительное время, и сопровождение выполняют специалисты, которые не участвовали в разработке этой операционной системы с самого начала проекта.
В результате, по мере роста и усложнения монолитной операционной системы, ее поддержка все более затрудняется. В конечном итоге, довольно быстро наступает момент, когда дальнейшее развитие системы становится нецелесообразным – легче написать все заново, чем модифицировать имеющийся код.
Довольно скоро ограничения монолитной архитектуры стали столь значительными, что для построения расширяемых и переносимых операционных систем необходимо было искать новые решения, и они были предложены. Но прежде, чем перейти к изучению этих новых решений, рассмотрим, каким требованиям должна удовлетворять современная архитектура операционной системы.

Многоуровневая архитектура

Многоуровневая архитектура появилась как ответ на ограничения монолитной архитектуры в плане расширяемости, переносимости и совместимости. Основная идея многоуровневой архитектуры состоит в следующем:
1. Полная функциональность операционной системы разделяется на уровни, например уровень управления аппаратурой, уровень управления памятью, уровень файловой системы, уровень управления процессами и т.п.
2. Для каждого уровня определяются интерфейс взаимодействия, т.е. некоторый набор правил, согласно которым следует обращаться за услугами данного уровня.
3. Взаимодействие уровней строится таким образом, что каждый уровень может обращаться за услугами только к соседнему нижележащему уровню через его интерфейс.
4. Внутренние структуры данных каждого уровня не доступны другим уровням, а реализации процедур уровня скрыты и не зависят от реализаций процедур внутри других уровней.

Обязательным условием для разбиения функциональности на уровни является взаимодействие только между соседними уровнями. В многоуровневых системах за-прещаются прямые обращения к любым уровням, минуя соседний уровень

 

 

Многоуровневая архитектура предполагает взаимодействие между уровнями исключительно через их интерфейсы, при этом внутренняя реализация уровней скрыта от других уровней. Это позволяет в случае необходимости изменять внутренние реализации процедур уровня на более эффективные. Можно даже полностью заменить весь уровень, требуется только обеспечить стандартный интерфейс взаимодействия с другими уровнями.
Разбиение функциональности операционной системы на уровни выполняется на этапе ее проектирования и сохраняется на весь срок жизни операционной системы. При этом, по мере развития операционной системы, интерфейсы уровней могут дополняться новыми вызовам. Однако интерфейсы не могут сокращаться, т.к. необходимо обеспечивать совместимость с программами, разработанными для предыдущих версий операционной системы, и использующими старые интерфейсы.
Расширение интерфейса обычно связано с введением в операционную систему новой функциональности, например, при появлении новых аппаратных средств. Другой причиной дополнения интерфейса может стать новая, более оптимальная реализация некоторого алгоритма работы операционной системы, при этом старый интерфейс необходимо сохранить в целях совместимости.
Одной из первых операционных систем, разработанных на основе многоуровневой архитектуры, стала операционная система THE, разработанная профессором Дейк-строй и его студентами в 1968 году. Операционная система THE имела 6 уровней, про-нумерованных от 0 до 5:
Уровень 0. Этот уровень выполнял распределение ресурсов процессора и переключал процессы по истечению кванта времени или при возникновении прерывания.
Уровень 1. Этот уровень осуществлял управление виртуальной памятью.
Уровень 2. Этот уровень обеспечивал каждый запущенный процесс собственной консолью, т.е. организовывал виртуальные терминалы.
Уровень 3. Этот уровень осуществлял управление средствами ввода-вывода и предоставлял вышележащим уровням аппаратно независимые средства ввода-вывода. Кроме того, третий уровень осуществлял буферизацию ввода-вывода, т.е. обеспечивал кэширование.
Уровень 4. На этом уровне выполнялись пользовательские процессы, которые обеспечивались аппаратно независимыми услугами со стороны нижележащих уровней операционной системы.
Уровень 5. На этом уровне выполнялся процесс системного администратора.
В последующем многоуровневая архитектура получила очень широкое распространение. На ее базе были реализованы весьма сложные операционные системы, которые смогли удержаться на рынке в течение длительного времени. Например, на базе многоуровневой архитектуры построена широко распространенная операционная система UNIX.
Главное преимущество многоуровневой архитектуры перед монолитной архитектурой проявляются не столько на этапе начальной разработки, сколько на этапе сопровождения операционной системы. При использовании многоуровневой архитектуры, для внесения новой функциональности в операционную систему достаточно внести изменения только в код отдельного уровня, при этом все остальные уровни могут быть оставлены без изменений. При переносе операционной системы на другую аппаратную платформу, аппаратно зависимый уровень может быть просто заменен.
Однако, не смотря на видимые отличия, многоуровневая архитектура является прямым развитием монолитной архитектуры, в которую просто введена более четкая структуризация. Поэтому, по мере дальнейшего усложнения операционных систем и с ростом динамики их развития, обнаружились недостатки многоуровневой архитектуры.
По мере развития операционной системы интерфейс уровня становится все более громоздким, а сложность реализации отдельного уровня может превзойти сложность всей операционной системы первых версий. В таких условиях заменить уровень новым или нарастить его функциональность становится весьма сложной задачей.
Интересно отметить, что сам факт фиксированного разделения функциональности на уровни является сдерживающим фактором в развитии операционной системы, так как разделение, сделанное в начале жизненного пути операционной системы, может стать неоптимальным по мере ее развития, но изменять разбиение уже нельзя из соображений совместимости.
Поэтому классическая многоуровневая архитектура в наиболее современных операционных системах вытесняется архитектурой типа клиент-сервер.

Архитектура типа клиент-сервер на основе микроядра

Архитектура типа клиент-сервер в настоящее время является наиболее совершенной с точки зрения расширяемости и переносимости операционных систем.
Идея архитектуры клиент-сервер состоит в следующем: все компоненты операционной системы разделяются на программы – поставщики услуг (программы серверы, выполняющие определенные действия по запросам других программ), и программы – потребители услуг (программы клиенты, обращающиеся к серверам для выполнения определенных действий). Заметим здесь, что одна и та же программа может быть одновременно сервером по отношению к одному виду услуг и клиентом по отношению к другому виду услуг.
Запущенные в системе процессы-серверы постоянно находится в состоянии ожидания клиентских запросов. В случае необходимости, клиенты посылают серверам запросы на оказание требуемых им услуг, например запрос на чтение файла, запрос на выделение памяти, запрос на вывод результатов на экран и т.п.
Получив запрос от клиента, сервер выполняет его, при этом он сам может обратиться за услугами к другим серверам. После выполнения запроса сервер отсылает клиенту сообщение о завершении задания и результаты работы.
При этом клиенты и серверы никогда не общаются напрямую. Если некоторый процесс нуждается в каких-либо услугах со стороны операционной системы, то он посылает соответствующее сообщение диспетчеру в составе микроядра операционной сис-темы. Получив запрос, микроядро определяет сервер, который может его обслужить, пробуждает его процесс и переадресовывает ему запрос клиента. Очевидно, что серверы должны быть предварительно зарегистрированы в системе. При этом микроядро само является сервером по отношению к запросам, связанным с управлением аппаратурой. В процессе выполнения запросов от пользовательских программ, системные серверы, выступая в роли клиентов, обращаются за аппаратно-зависимыми услугами к микроядру, при этом сами серверы операционной системы выполняются в режиме задачи, наравне с обычными пользовательскими процессами, и не имеют прямого доступа к аппаратуре.

Уменьшено

 

Для архитектуры типа клиент-сервер характерно горизонтальное разделение функциональности между равноправными серверами, вместо вертикального иерархического распределения в многоуровневой архитектуре. При этом, каждый сервер отвечает за выполнение отдельной достаточно простой операции и ни в коей мере не является эквивалентом уровня в многоуровневой архитектуре.
Таким образом, архитектура клиент-сервер обеспечивает следующие основные преимущества:
• переносимость операционной системы, т.к. серверы, работающие в пользовательском режиме, аппаратно независимы;
• расширяемость операционной системы, т.к. новая функциональность может быть легко введена за счет введения нового сервера, и это никак не затронет существующую функциональность;
• гибкость операционной системы, т.к. пользователь может запустить только те сервисы, которые ему действительно нужны, и не расходовать ресурсы системы на поддержку невостребованной функциональности, при этом пользователь может изменять набор запущенных серверов без перезапуска системы.
Указанные преимущества делают архитектуру клиент-сервер наиболее подходя-щей для построения операционных систем, удовлетворяющих современным требованиям.
К сожалению, архитектура клиент-сервер, наряду с указанными преимуществами, имеет один серьезный недостаток – производительность операционной системы, функционирующей на основе обмена сообщениями между клиентами и серверами через микроядро, заметно ниже производительности операционной системы, функционирование которой основано на простых вызовах функций.
Поэтому идеализированная модель операционной системы на базе архитектуры клиент-сервер, когда ядро операционной системы выполняет только функции диспетчера сообщений и сервера для управления аппаратурой, довольно редко применяется на практике.
В реальных операционных системах, основанных на архитектуре клиент-сервер, ядро обычно выполняет существенно больший объем работы, так, что иногда точнее говорить о гибридной архитектуре, сочетающей многоуровневое ядро и серверы за преде-лами ядра для выполнения некоторых операций.
Такая организация операционной системы позволяет достичь удачного компромисса гибкость/производительность, и, в конечном итоге, получить производительность, близкую к производительности классической многоуровневой системы в сочетании с максимально простой переносимостью и расширяемостью.

 




Дата добавления: 2015-01-30; просмотров: 40 | Поможем написать вашу работу | Нарушение авторских прав

1 | 2 | <== 3 ==> | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 |


lektsii.net - Лекции.Нет - 2014-2024 год. (0.006 сек.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав