Особенности методов построения

При описании операционной системы часто указываются особенности ее структурной организации и основные концепции, положенные в ее основу.

К таким базовым концепциям относятся:

• Способы построения ядра системы - монолитное ядро или микроядерный подход. Большинство ОС использует монолитное ядро, которое компонуется как одна программа, работающая в привилегированном режиме и использующая быстрые переходы с одной процедуры на другую, не требующие переключения из привилегированного режима в пользовательский и наоборот. Альтернативой является построение ОС на базе микроядра, работающего также в привилегированном режиме и выполняющего только минимум функций по управлению аппаратурой, в то время как функции ОС более высокого уровня выполняют специализированные компоненты ОС - серверы, работающие в пользовательском режиме. При таком построении ОС работает более медленно, так как часто выполняются переходы между привилегированным режимом и пользовательским, зато система получается более гибкой - ее функции можно наращивать, модифицировать или сужать, добавляя, модифицируя или исключая серверы пользовательского режима. Кроме того, серверы хорошо защищены друг от друга, как и любые пользовательские процессы.

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

• Наличие нескольких прикладных сред дает возможность в рамках одной ОС одновременно выполнять приложения, разработанные для нескольких ОС. Многие современные операционные системы поддерживают одновременно прикладные среды MS-DOS, Windows, UNIX (POSIX), OS/2 или хотя бы некоторого подмножества из этого популярного набора. Концепция множественных прикладных сред наиболее просто реализуется в ОС на базе микроядра, над которым работают различные серверы, часть которых реализуют прикладную среду той или иной операционной системы.

• Распределенная организация операционной системы позволяет упростить работу пользователей и программистов в сетевых средах. В распределенной ОС реализованы механизмы, которые дают возможность пользователю представлять и воспринимать сеть в виде традиционного однопроцессорного компьютера. Характерными признаками распределенной организации ОС являются: наличие единой справочной службы разделяемых ресурсов, единой службы времени, использование механизма вызова удаленных процедур (RPC) для прозрачного распределения программных процедур по машинам, многонитевой обработки, позволяющей распараллеливать вычисления в рамках одной задачи и выполнять эту задачу сразу на нескольких компьютерах сети, а также наличие других распределенных служб.

5. Операционная система, являясь главной частью сетевого программного обеспечения, создает среду для выполнения приложений и во многом определяет, насколько эффективно будут они работать. Очевидно, что главным требованием, предъявляемым к операционной системе, является способность выполнения основных функций: эффективного управления ресурсами и обеспечения удобного интерфейса для пользователя и прикладных программ. Современная ОС, как правило, должна реализовывать мультипрограммную обработку, виртуальную память, поддерживать многооконный интерфейс и прочее. Кроме этих функциональных требований к операционным системам предъявляются не менее важные рыночные требования.

• Расширяемость. Система должна быть написана таким образом, чтобы в нее можно было легко внести дополнения и изменения, если это потребуется, и не нарушить целостность системы.

• Переносимость. Система должна без особых трудностей переноситься с аппаратных средств одного типа на аппаратные средства другого типа.

• Надежность и отказоустойчивость. Система должна быть защищена как от внутренних, так и от внешних ошибок, сбоев и отказов. Ее действия должны быть предсказуемыми, а приложения не должны разрушать ОС.

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

• Безопасность. ОС должна обладать средствами защиты ресурсов одних пользователей от других.

• Производительность. Система должна обладать настолько хорошим быстродействием и временем реакции, насколько это позволяют аппаратные средства.

Оценить сетевую ОС можно по ее соответствию сетевой среде, а именно по возможности:

• совместного использования файлов и принтеров при высокой производительности;

• эффективного выполнения прикладных программ, ориентированных на архитектуру клиент-сервер, в том числе прикладных программ производителей;

• возможность работать на различных платформах и с различным сетевым оборудованием;

• обеспечить интеграцию с сетью Интернет, т. е. поддержку соответствующих протоколов и программного обеспечения Web-сервера;

• дистанционного доступа к сети;

• организации внутренней электронной почты, телеконференций;

• доступа к ресурсам территориально разбросанных, многосерверных сетей с помощью служб каталогов и имен.

6. Перечислим основные типы внутренней архитектуры операционных систем и в качестве примеров рассмотрим архитектуру наиболее распространенных операционных систем – систем UNIX и Windows. Разливают всего три базовых типа архитектуры операционных систем: • монолитная архитектура; • многоуровневая архитектура; • архитектура типа клиент-сервер на основе микроядра. Рассмотрим каждый из этих типов архитектуры более подробно. Монолитная архитектура операционной системы При монолитной архитектуре операционная система не имеет какой-либо явно выраженной внутренней структуры. Это просто набор процедур, использующих общие глобальные данные, и вызываемые друг другом или пользователем. Заметим, что монолитную архитектуру имели самые первые поколения операционных систем.

При использовании монолитной архитектуры, аппаратно зависимый и аппаратно независимый код в составе операционной системы тесно переплетаются, что крайне затрудняет развитие операционной системы или ее перенос на другую аппаратную платформу. Наличие бессистемных разветвленных связей между компонентами операционной системы с монолитной архитектурой приводит к необходимости коррекции многих компонентов системы при реальной потребности изменения только одного из них. При этом может наблюдаться эффект снежной лавины – изменение одной процедуры потребовало изменение нескольких других, каждая из которых потребовала изменение еще нескольких других процедур и т.д. Еще большие неудобства могут доставить глобальные данные, т.к. даже незначительное изменение их формата, необходимое для какой-то частной процедуры, в большинстве случаев потребует коррекции практически всех остальных процедур операционной системы. Серьезные трудности возникают при сопровождении и технической поддержке операционной системы с монолитной архитектурой, в период ее эксплуатации, особенно если система находится в эксплуатации длительное время, и сопровождение выполняют специалисты, которые не участвовали в разработке этой операционной системы с самого начала проекта. В результате, по мере роста и усложнения монолитной операционной системы, ее поддержка все более затрудняется. В конечном итоге, довольно быстро наступает момент, когда дальнейшее развитие системы становится нецелесообразным – легче написать все заново, чем модифицировать имеющийся код. Довольно скоро ограничения монолитной архитектуры стали столь значительными, что для построения расширяемых и переносимых операционных систем необходимо было искать новые решения, и они были предложены. Но прежде, чем перейти к изучению этих новых решений, рассмотрим, каким требованиям должна удовлетворять современная архитектура операционной системы. Требования к архитектуре операционной системы Архитектура операционной системы должна обеспечивать расширяемость операционной системы, переносимость операционной системы и совместимость различных операционных систем. Проблема расширяемости операционной системы Под расширяемостью понимают возможность добавлять в операционную систему новую функциональность без изменения уже существующих компонентов системы. Необходимость расширения функциональности операционной системы связана с быстрым развитием аппаратных средств и технологий программирования. Действительно, операционная система обычно живет довольно долго, например UNIX существует уже более 30 лет, Windows NT – более 10 лет. За время жизни операционной системы неизбежно появляется новое периферийное оборудование, поддержка которого не закладывалась в систему при ее проектировании. Тем не менее, для успешного существования на рынке, операционная система должна быстро реагировать на появление нового оборудования и обеспечивать его поддержку. Примером может служить появление и широкое распространение накопителей на компакт-дисках или Flash-памяти. Помимо развития аппаратных средств ЭВМ, быстро развиваются технологии программирования, что также требует от операционной системы соответствующей поддержки. Например, в последние годы во многие операционные системы введена поддержка легковесных процессов (потоков, нитей) и процессов реального времени. Отметим, что современная операционная система – это очень громоздкая и сложная программа, и если в процессе расширения возможностей системы затрагивается уже существующий код, то это всегда приводит к серьезным проблемам. Наличие в составе операционной системы монолитного ядра, реализующего базовую функциональность всей операционной системы, существенно затрудняет введение в систему новой функциональности. Компоненты ядра сильно связаны между собой, причем обычно даже нет четких границ между различными подсистемами ядра. Введение новой функциональности почти наверняка потребует множества модификаций существующих компонентов ядра, что повлечет необходимость отладки сложного и весьма объемного кода ядра. В результате введение новой функциональности оказывается весьма трудоемким, а надежность работы модифицированной операционной системы снижается. Причем сбои возможны даже в компонентах, стабильно работавших в предыдущей версии системы. Проблема переносимости операционной системы Под переносимостью понимается возможность без кардинальной переработки кода переносить операционную систему на новые аппаратные платформы с полным сохранением имеющейся функциональности. Необходимость переноса операционной системы на новые платформы связана, с одной стороны, с появлением новых, более совершенных, аппаратных платформ за время жизни операционной системы, а с другой стороны, с большим разнообразием аппаратных платформ, существующих одновременно. Для того, чтобы операционная система была бы переносимой, необходимо еще на этапе ее разработки выполнить следующие два условия: 1. выделить весь аппаратно зависимый код операционной системы в отдельный модуль, предоставляющий остальным компонентам операционной системы аппаратно независимые услуги, причем размер этого модуля и его проникновение в структуру операционной системы должны быть по возможности минимальными; 2. реализовать код всех аппаратно независимых модулей операционной системы на языке высокого уровня, так как низкоуровневый язык (ассемблер) сам является аппаратно зависимым. Если указанные условия выполняются, то при переносе операционной системы на другую аппаратную платформу достаточно будет переписать только аппаратно зависимый модуль, в то время как исходные коды остальных компонентов системы, написанных на языке высокого уровня, останутся неизменными, и их достаточно только перекомпилировать. Наличие же в операционной системе монолитного ядра, в котором аппаратно зависимые фрагменты распределены по всему коду, существенно затрудняет перенос операционной системы на другие аппаратные платформы. При этом, процесс переноса становится весьма трудоемким, а стабильность работы операционной системы после переноса резко падает. Проблема совместимости операционной системы Под совместимостью понимается способность операционной системы исполнять прикладные программы, ориентированные на другие операционные системы, или на более ранние версии той же самой операционной системы. Необходимость организации совместимости операционных систем объясняется следующим. У пользователей обычно скапливается некоторая библиотека прикладных программ, в приобретение которых были вложены некоторые средства. Немаловажным является и тот факт, что пользователь уже умеет работать с этими программами, ведь обучение требует времени, а часто и материальных затрат. Поэтому пользователь не примет операционную систему, не совместимую с его старыми программами. Следовательно, если производитель операционной системы заинтересован в ее продвижении, он должен позаботиться о вопросах совместимости. Заметим, что если пользователь даже готов перейти на новые прикладные программы, в первое время после появления новой операционной системы таких программ может еще не быть, и пользователю придется использовать старые программы (вспомните историю развития Windows). Различают совместимость на уровне исходных кодов, и двоичную совместимость. Совместимость на уровне исходных кодов – это способность операционной системы исполнять программы, первоначально ориентированные на другую операционную систему, после перекомпиляции этих программ. Не вдаваясь в технические подробности, отметим, что пользователей в подавляющем большинстве случаев интересует двоичная совместимость, а не совместимость на уровне исходных кодов. Двоичная совместимость – это способность операционной системы загружать исполняемые файлы, первоначально предназначенные для другой операционной системы, и нормально исполнять представленные в них программы. Совместимость с какой-нибудь операционной системой может закладываться в новую операционную систему еще на этапе ее проектирования. Однако на практике задача обеспечения совместимости чаще формулируется следующим образом: Имеются две операционных системы, система A и система B. Обе операционных системы давно и успешно работают на некоторой аппаратной платформе. Необходимо в систему A ввести исполнительную среду системы B, чтобы прикладные программы системы B могли бы исполняться также и в системе A. Таким образом, задача обеспечения совместимости с системой B сводится к задаче расширения функциональности операционной системы A. Но если система A имеет монолитное ядро, введение в нее новой исполнительной системы будет весьма трудоемким и, кроме того, снизит стабильность работы системы. Многоуровневая архитектура Многоуровневая архитектура появилась как ответ на ограничения монолитной архитектуры в плане расширяемости, переносимости и совместимости. Основная идея многоуровневой архитектуры состоит в следующем: 1. Полная функциональность операционной системы разделяется на уровни, например уровень управления аппаратурой, уровень управления памятью, уровень файловой системы, уровень управления процессами и т.п. 2. Для каждого уровня определяются интерфейс взаимодействия, т.е. некоторый набор правил, согласно которым следует обращаться за услугами данного уровня. 3. Взаимодействие уровней строится таким образом, что каждый уровень может обращаться за услугами только к соседнему нижележащему уровню через его интерфейс. 4. Внутренние структуры данных каждого уровня не доступны другим уровням, а реализации процедур уровня скрыты и не зависят от реализаций процедур внутри других уровней.

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

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

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