Тема 2-1 Архитектура операционной системы

Раздел 2. Машинно-зависимые свойства операционных систем

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

Лекция 4. Структурное построение операционных систем

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

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

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

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

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

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

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

Сетевые операционные системы

Структура сетевой операционной системы

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

Рис. 1.1. Структура сетевой ОС

В сетевой операционной системе отдельной машины можно выделить несколько частей (рисунок 1.1):

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

• Средства предоставления собственных ресурсов и услуг в общее пользование - серверная часть ОС (сервер). Эти средства обеспечивают, например, блокировку файлов и записей, что необходимо для их совместного использования; ведение справочников имен сетевых ресурсов; обработку запросов удаленного доступа к собственной файловой системе и базе данных; управление очередями запросов удаленных пользователей к своим периферийным устройствам.

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

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

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

На рисунке 1.2 показано взаимодействие сетевых компонентов. Здесь компьютер 1 выполняет роль "чистого" клиента, а компьютер 2 - роль "чистого" сервера, соответственно на первой машине отсутствует серверная часть, а на второй - клиентская. На рисунке отдельно показан компонент клиентской части - редиректор. Именно редиректор перехватывает все запросы, поступающие от приложений, и анализирует их. Если выдан запрос к ресурсу данного компьютера, то он переадресовывается соответствующей подсистеме локальной ОС, если же это запрос к удаленному ресурсу, то он переправляется в сеть. При этом клиентская часть преобразует запрос из локальной формы в сетевой формат и передает его транспортной подсистеме, которая отвечает за доставку сообщений указанному серверу. Серверная часть операционной системы компьютера 2 принимает запрос, преобразует его и передает для выполнения своей локальной ОС. После того, как результат получен, сервер обращается к транспортной подсистеме и направляет ответ клиенту, выдавшему запрос. Клиентская часть преобразует результат в соответствующий формат и адресует его тому приложению, которое выдало запрос.

Рис. 1.2. взаимодействие компонентов операционной системы при взаимодействии компьютеров

На практике сложилось несколько подходов к построению сетевых операционных систем (рисунок 1.3).

Рис. 1.3. Варианты построения сетевых ОС

Первые сетевые ОС представляли собой совокупность существующей локальной ОС и надстроенной над ней сетевой оболочки. При этом в локальную ОС встраивался минимум сетевых функций, необходимых для работы сетевой оболочки, которая выполняла основные сетевые функции. Примером такого подхода является использование на каждой машине сети операционной системы MS DOS (у которой начиная с ее третьей версии появились такие встроенные функции, как блокировка файлов и записей, необходимые для совместного доступа к файлам). Принцип построения сетевых ОС в виде сетевой оболочки над локальной ОС используется и в современных ОС, таких, например, как LANtastic или Personal Ware.

Однако более эффективным представляется путь разработки операционных систем, изначально предназначенных для работы в сети. Сетевые функции у ОС такого типа глубоко встроены в основные модули системы, что обеспечивает их логическую стройность, простоту эксплуатации и модификации, а также высокую производительность. Примером такой ОС является система Windows NT фирмы Microsoft, которая за счет встроенности сетевых средств обеспечивает более высокие показатели производительности и защищенности информации по сравнению с сетевой ОС LAN Manager той же фирмы (совместная разработка с IBM), являющейся надстройкой над локальной операционной системой OS/2.

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

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

Тенденции в структурном построении ОС

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

Монолитные системы

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

Рис. 4.1. Монолитная структура ОС

Для построения монолитной системы необходимо скомпилировать все отдельные процедуры, а затем связать их вместе в единый объектный файл с помощью компоновщика (примерами могут служить ранние версии ядра UNIX или Novell NetWare). Каждая процедура видит любую другую процедуру ( в отличие от структуры, содержащей модули, в которой большая часть информации является локальной для модуля, и процедуры модуля можно вызвать только через специально определенные точки входа).

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

1. Главная программа, которая вызывает требуемые сервисные процедуры.

2. Набор сервисных процедур, реализующих системные вызовы.

3. Набор утилит, обслуживающих сервисные процедуры.

В этой модели для каждого системного вызова имеется одна сервисная процедура. Утилиты выполняют функции, которые нужны нескольким сервисным процедурам. Это деление процедур на три слоя показано на рисунке 4.2.

Рис. 4.2. Простая структуризация монолитной ОС

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

Лекция 6 Модель клиент-сервер

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

Рис. 4.3. Структура ОС клиент-сервер

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

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

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

На одном краю этого спектра находится разрабатываемая фирмой IBM на основе микроядра Mach операционная система Workplace OS, придерживающаяся чистой микроядерной доктрины, состоящей в том, что все несущественные функции ОС должны выполняться не в режиме ядра, а в непривилегированном (пользовательском) режиме. На другом - Windows NT, в составе которой имеется исполняющая система (NT executive), работающая в режиме ядра и выполняющая функции обеспечения безопасности, ввода-вывода и другие.

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

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

Есть два пути решения этой проблемы. Один путь - разместить несколько таких, чувствительных к режиму работы процессора, серверов, в пространстве ядра, что обеспечит им полный доступ к аппаратуре и , в то же время, связь с другими процессами с помощью обычного механизма сообщений. Такой подход был использован, например, при разработке Windows NT: кроме микроядра, в привилегированном режиме работает часть Windows NT, называемая executive управляющей программой. Она включает ряд компонентов, которые управляют виртуальной памятью, объектами, вводом-выводом и файловой системой (включая сетевые драйверы), взаимодействием процессов, и частично системой безопасности.

Другой путь, заключается в том, чтобы оставить в ядре только небольшую часть сервера, представляющую собой механизм реализации решения, а часть, отвечающую за принятие решения, переместить в пользовательскую область. В соответствии с этим подходом, например, в микроядре Mach, на базе которого разработана Workplace OS, размещается только часть системы управления процессами (и нитями), реализующая диспетчеризацию (то есть непосредственно переключение с процесса на процесс), а все функции, связанные с анализом приоритетов, выбором очередного процесса для активизации, принятием решения о переключении на новый процесс и другие аналогичные функции выполняются вне микроядра. Этот подход требует тесного взаимодействия между внешним планировщиком и резидентным диспетчером.

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

Кроме уже представленных соображений, перемещение планировщика на пользовательский уровень может понадобиться для чисто коммерческих целей. Некоторые производители ОС (например, IBM и OSF со своими вариантами микроядра Mach) планируют лицензировать свое микроядро другим поставщикам, которым может потребоваться заменить исходный планировщик на другой, поддерживающий, например, планирование в задачах реального времени или реализующий какой-то специальный алгоритм планирования. А вот другая ОС - Windows NT, также использующая микроядерную концепцию - воплотила понятие приоритетов реального времени в своем планировщике, резидентно расположенном в ядре, и это не дает возможности заменить ее планировщик на другой.

Как и управление процессами, управление памятью может распределяться между микроядром и сервером, работающим в пользовательском режиме. Например, в Workplace OS микроядро управляет аппаратурой страничной памяти. Пейджер (система управления страничной памятью), работающий вне ядра, определяет стратегию замещения страниц (т.е. решает, какие страницы следует удалить из памяти для размещения страниц, выбранных с диска в ответ на прерывание по отсутствию необходимой страницы), а микроядро выполняет перемещение выбранных пейджером страниц. Как и планировщик процессов, пейджер является заменяемой составной частью.

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

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

Высокая степень переносимости обусловлена тем, что весь машинно-зависимый код изолирован в микроядре, поэтому для переноса системы на новый процессор требуется меньше изменений и все они логически сгруппированы вместе.

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

Расширяемость также является одним из важных требований к современным операционным системам. Является ли операционная система маленькой, как DOS, или большой, как UNIX, для нее неизбежно настанет необходимость приобрести свойства, не заложенные в ее конструкцию. Увеличивающаяся сложность монолитных операционных систем делала трудным, если вообще возможным, внесение изменений в ОС с гарантией надежности ее последующей работы. Ограниченный набор четко определенных интерфейсов микроядра открывает путь к упорядоченному росту и эволюции ОС.

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

Иногда имеется потребность и в сокращении возможностей ОС. На Windows NT или UNIX перешло бы большее число пользователей, если бы для этих операционных систем не требовалось 16 Мб оперативной памяти и 70 Мб и более пространства на жестком диске. Микроядро не обязательно подразумевает небольшую систему. Надстроенные службы, типа файловой системы и системы управления окнами, добавят к ней немало. Конечно же, не всем нужна безопасность класса C2 или распределенные вычисления. Если важные, но предназначенные для определенных потребителей свойства можно исключать из состава системы, то базовый продукт подойдет более широкому кругу пользователей.

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

Эта модель хорошо подходит для распределенных вычислений, так как отдельные серверы могут работать на разных процессорах мультипроцессорного компьютера или даже на разных компьютерах. При получении от процесса сообщения микроядро может обработать его самостоятельно или переслать другому процессу. Так как микроядру все равно, пришло ли сообщение от локального или удаленного процесса, подобная схема передачи сообщений является элегантным базисом для RPC. Однако такая гибкость не дается даром. Пересылка сообщений не так быстра, как обычные вызовы функций, и ее оптимизация является критическим фактором успеха операционной системы на основе микроядра. Windows NT, например, в некоторых случаях заменяет перенос сообщений на коммуникационные каналы с общей памятью, имеющие более высокую пропускную способность. Хотя это и стоит дороже в смысле потребления фиксированной памяти микроядра, данная альтернатива может помочь сделать модель пересылки сообщений более практичной.

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

Лекция 7 Операционная система UNIX

UNIX имеет долгую и интересную историю. Начавшись как несерьезный и почти "игрушечный" проект молодых исследователей, UNIX стал многомиллионной индустрией, включив в свою орбиту университеты, многонациональные корпорации, правительства и международные организации стандартизации.

UNIX зародился в лаборатории Bell Labs фирмы AT&T более 20 лет назад. В то время Bell Labs занималась разработкой многопользовательской системы разделения времени MULTICS (Multiplexed Information and Computing Service) совместно с MIT и General Electric, но эта система потерпела неудачу, отчасти из-за слишком амбициозных целей, не соответствовавших уровню компьютеров того времени, а отчасти и из-за того, что она разрабатывалась на языке PL/1, а компилятор PL/1 задерживался и вообще плохо работал после своего запоздалого появления. Поэтому Bell Labs вообще отказалась от участия в проекте MULTICS, что дало возможность одному из ее исследователей, Кену Томпсону, заняться поисковой работой в направлении улучшения операционной среды Bell Labs. Томпсон, а также сотрудник Bell Labs Денис Ритчи и некоторые другие разрабатывали новую файловую систему, многие черты которой вели свое происхождение от MULTICS. Для проверки новой файловой системы Томпсон написал ядро ОС и некоторые программы для компьютера GE-645, который работал под управлением мультипрограммной системы разделения времени GECOS. У Кена Томпсона была написанная им еще во времена работы над MULTICS игра "Space Travel" - "Космическое путешествие". Он запускал ее на компьютере GE-645, но она работала на нем не очень хорошо из-за невысокой эффективности разделения времени. Кроме этого, машинное время GE-645 стоило слишком дорого. В результате Томпсон и Ритчи решили перенести игру на стоящую в углу без дела машину PDP-7 фирмы DEC, имеющую 4096 18-битных слов, телетайп и хороший графический дисплей. Но у PDP-7 было неважное программное обеспечение, и, закончив перенос игры, Томпсон решил реализовать на PDP-7 ту файловую систему, над который он работал на GE-645. Из этой работы и возникла первая версия UNIX, хотя она и не имела в то время никакого названия. Но она уже включала характерную для UNIX файловую систему, основанную на индексных дескрипторах inode, имела подсистему управления процессами и памятью, а также позволяла двум пользователям работать в режиме разделения времени. Система была написана на ассемблере. Имя UNIX (Uniplex Information and Computing Services) было дано ей еще одним сотрудником Bell Labs, Брайаном Керниганом, который первоначально назвал ее UNICS, подчеркивая ее отличие от многопользовательской MULTICS. Вскоре UNICS начали называть UNIX.

Первыми пользователями UNIX'а стали сотрудники отдела патентов Bell Labs, которые нашли ее удобной средой для создания текстов.

Большое влияние на судьбу UNIX оказала перепись ее на языке высокого уровня С, разработанного Денисом Ритчи специально для этих целей. Это произошло в 1973 году, UNIX насчитывал к этому времени уже 25 инсталляций, и в Bell Labs была создана специальная группа поддержки UNIX.

Широкое распространение UNIX получил с 1974 года, после описания этой системы Томпсоном и Ритчи в компьютерном журнале CACM. UNIX получил широкое распространение в университетах, так как для них он поставлялся бесплатно вместе с исходными кодами на С. Широкое распространение эффективных C-компиляторов сделало UNIX уникальной для того времени ОС из-за возможности переноса на различные компьютеры. Университеты внесли значительный вклад в улучшение UNIX и дальнейшую его популяризацию. Еще одним шагом на пути получения признания UNIX как стандартизованной среды стала разработка Денисом Ритчи библиотеки ввода-вывода stdio. Благодаря использованию этой библиотеки для компилятора С, программы для UNIX стали легко переносимыми.

Рис. 5.1. История развития UNIX

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

На рисунке 5.1 показана упрощенная картина развития UNIX, которая учитывает преемственность различных версий и влияние на них принимаемых стандартов. Наибольшее распространение получили две весьма несовместимые линии версий UNIX: линия AT&T - UNIX System V, и линия университета Berkeley-BSD. Многие фирмы на основе этих версий разработали и поддерживают свои версии UNIX: SunOS и Solaris фирмы Sun Microsystems, UX фирмы Hewlett-Packard, XENIX фирмы Microsoft, AIX фирмы IBM, UnixWare фирмы Novell (проданный теперь компании SCO), и список этот можно еще долго продолжать.

Наибольшее влияние на унификацию версий UNIX оказали такие стандарты как SVID фирмы AT&T, POSIX, созданный под эгидой IEEE, и XPG4 консорциума X/Open. В этих стандартах сформулированы требования к интерфейсу между приложениями и ОС, что дает возможность приложениям успешно работать под управлением различных версий UNIX.

Независимо от версии, общими для UNIX чертами являются:

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

• реализация мультипрограммной обработки в режиме разделения времени, основанная на использовании алгоритмов вытесняющей многозадачности (preemptive multitasking),

• использование механизмов виртуальной памяти и свопинга для повышения уровня мультипрограммирования,

• унификация операций ввода-вывода на основе расширенного использования понятия "файл",

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

• переносимость системы за счет написания ее основной части на языке C,

• разнообразные средства взаимодействия процессов, в том числе и через сеть,

• кэширование диска для уменьшения среднего времени доступа к файлам.

Далее мы подробно остановимся на основных концепциях версии UNIX System V Release 4, которая вобрала в себя лучшие черты линий UNIX System V и UNIX BSD.

Версия UNIX System V Release 4 - это незаконченная коммерческая версия операционной системы, т.к. в ее кодах отсутствуют многие системные утилиты, необходимые для успешной эксплуатации ОС, например утилиты администрирования или менеджер графического интерфейса. Версия SVR4 является скорее стандартной реализацией кода ядра, вобравшая в себя наиболее популярные и эффективные решения из различных версий ядра UNIX, такие как виртуальная файловая система VFS, отображаемые в память файлы и т.п. Код SVR4 (частично доработанный) лег в основу многих современных коммерческих версий UNIX, таких как HP-UX, Solaris, AIX и т.д.

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

Лекция 8 Операционная система Windows

Windows 95 представляет собой замечательный пример эволюционного развития архитектуры Windows. Система имеет новый интерфейс, который можно легко настраивать и с помощью которого можно легко путешествовать по ресурсам системы. Эта ОС выполняет 16- и 32-х разрядные приложения, поддерживает технологию "plug-and-play" и содержит встроенные средства для сетевой работы. У многих обозревателей нет сомнений в том, что эта система улучшит жизнь многим миллионам пользователей персональных компьютеров.

Несмотря на все преимущества, Windows 95 - это по-прежнему вариация на тему Windows 3.1. Для большинства пользователей это означает, что заложенные в ней архитектурные анахронизмы могут приводить к неожиданному краху системы. Даже по мнению специалистов Microsoft, для важных бизнес-приложений более предпочтительным является использование Windows NT, которая обеспечивает защиту данных и устойчивость к некорректной работе приложений.

Windows 95 обладает некоторыми уникальными возможностями. Вероятно, она обеспечивает наилучшую среди всех операционных систем поддержку мобильных пользователей, спектр ее коммуникационных средств чрезвычайно широк и гибок, она наконец предоставляет решение застарелой проблемы недостатка памяти для выполнения приложений. Именно для мобильных пользователей, работающих на портативных компьютерах с шиной PCMCIA, наилучшим образом проявляет себя технология "plug-and-play", хотя для персональных компьютеров с шиной ISA могут возникать некоторые проблемы. Windows 95 автоматически отслеживает подключение портативного компьютера к рабочей станции сети и загружает или выгружает соответствующие драйверы. Например, когда пользователь приезжает в офис и подключает свой ноутбук к своей же рабочей станции, то Windows 95 узнает, что она присоединена теперь к внешнему монитору и начинает работать с графикой более высокого разрешения.

Windows 95 также является отличным коммуникационным средством: она поддерживает практически все сетевые протоколы и адаптеры. Для коммуникаций, использующих коммутируемые телефонные линии, Windows 95 предлагает использовать средства Microsoft Exchange. Встроенный клиент Microsoft Exchange имеет подсистемы для пересылки факсов, сообщений электронной почты и сети Microsoft Network, которая занимается рассылкой программного обеспечения и технической поддержкой пользователей в режиме on-line.

Наконец, переделка средств управления оперативной памятью позволит пользователям загрузить больше приложений прежде, чем система выдаст сообщение о нехватке памяти. Например, в Windows 3.1 обычно можно загрузить от 3 до 5 приложений, а для Windows 95 эти границы составляют 6 - 12 приложений.

Стабильность Windows 95, развитые средства сетевой работы и новый удобный пользовательский интерфейс представляют собой безусловные преимущества по сравнению с DOS или Windows 3.1, но все же не дотягивают до того уровня, к которому привыкли пользователи таких ОС, как OpenVMS, UNIX или Windows NT.

Одной из проблем Windows 3.1 является способность приложения вызвать крах системы, вынудив сделать перезагрузку. В Windows 95 осталось много старого кода, с помощью которого осуществляется выполнение приложений. Например, такие критические компоненты операционной системы, как USER и GDI, которые соответственно обеспечивают управление окнами и предоставляют средства графического интерфейса, являются по-прежнему 16-разрядными и работают в том же адресном пространстве, что и 16-разрядные приложения. Поэтому 16-разрядное приложение, содержащее ошибки, может потенциально "подвесить" виртуальную машину, на которой работают подсистемы USER и GDI, или, что еще хуже, заставить USER или GDI неверно работать, что может привести к краху всей ОС. Даже 32-разрядные приложения могут вызвать останов системы. Большая часть нижней памяти размером в 1 Мбайт, принадлежащая адресному пространству системного кода Windows 95 (то есть системной виртуальной машине System VM), открыта для операций приложения Win32.

Многозадачность - это еще одно потенциально слабое место. Windows 95 пересылает все вызовы USER API через 16-разрядную системную виртуальную машину System VM, которая размещается там же , где и выполняемое 16-разрядное приложение. Если 16-разрядное приложение "подвешивает" машину System VM, отказываясь обрабатывать сообщение (встречающийся чаще всего тип ошибки в существующих приложениях Windows), то все остальные процессы приостанавливаются. Пока пользователь не завершит в принудительном порядке зависшее 16-разрядное приложение (в Windows 95 есть хорошее средство для выполнения этой операции) и тем самым не освободит машину System VM, другие выполняемые программы, даже 32-разрядные, будут заблокированы.

Рисунки 8.4, 8.5 и 8.6 дают возможность сравнить архитектурные решения, положенные в основу операционных систем Windows 3.1, Windows 95 и Windows NT.

Рис. 8.4. Архитектура ОС Windows 3.1

В состав операционной системы Windows 3.1 (рис 8.4) входит системная виртуальная машина System VM, внутри которой размещаются все 16-разрядные приложения Win16, а также код и данные системных DLL, которые обеспечивают выполнение сервисных функций ОС. Приложения Win16 выполняются в общем адресном пространстве внутри системной виртуальной машины. Программы Win16 выполняются в режиме невытесняющей многозадачности. Системные библиотеки USER, GDI и KERNEL предоставляют сервисные функции операционной системы приложениям и отображаются в адресное пространство, совместно используемое приложениями Win16. Приложения DOS запускаются на отдельных виртуальных DOS-машинах (VDM), работающих в режиме вытесняющей многозадачности. Диспетчер устанавливаемых файловых систем (IFS) и драйвер 32-разрядного доступа к файлам (только в Windows for Workgroups 3.11) осуществляют большинство файловых операций в защищенном режиме, что ускоряет доступ к файлам. Драйвер 32-разрядного доступа к диску управляет обменом с диском на физическом уровне.

Рис. 8.5. Архитектура ОС Windows 95

Подсистема управления виртуальными машинами (VM Manager, VMM) предоставляет сервисные функции низкого уровня, такие как распределение процессорного времени между VM и управление виртуальной памятью. Сюда также относятся драйверы виртуальных устройств (VxD) для аппаратуры.

Архитектура Windows 95 (рисунок 8.5) представляет собой немного улучшенную версию архитектуры Windows 3.1. Внутри системной VM выполняются приложения Win16 и Win32. Большая часть кода операционной системы и данных также размещается здесь. Приложения Win32 работают на основе алгоритма вытесняющей многозадачности в отдельных адресных пространствах. Все приложения Win16 выполняются как единый процесс в общем адресном пространстве на основе алгоритма невытесняющей многозадачности. Библиотеки динамической компоновки USER, USER32, GDI, GDI32, KERNEL и KERNEL32, которые предоставляют системные сервисы всем приложениям, загружаются в системную VM и отображаются в адресные пространства каждого прикладного процесса. Это повышает производительность за счет устранения затрат времени на переходы между кольцами защиты при вызове системных функций. Однако с другой стороны, это также ставит под угрозу целостность системы, открывая доступ к частям ОС для прикладных программ. На виртуальных DOS-машинах (VDM) выполняются DOS-программы. Они работают в режиме вытесняющей многозадачности.

Рис. 8.6. Архитектура ОС Windows NT

Подсистема управления файлами Windows 95 работает в нулевом кольце защиты и обрабатывает все вызовы, связанные с вводом-выводом. Большинство вызовов обрабатывается в защищенном режиме, но некоторые по-прежнему приводят к переключению в режим Virtual 86, и обрабатываются в реальном режиме DOS. Диспетчер устанавливаемых файловых систем IFS передает вызовы файлового ввода-вывода драйверу соответствующей файловой системы. Драйвер файловой системы VFAT реализует собственную VFAT-систему Windows 95, которая похожа на файловую систему FAT с добавленными средствами обработки длинных имен файлов. Драйвер CDFS заменяет MSCDEX и управляет операциями по вводу данных с накопителей CD ROM. Редиректор, выполненный в виде драйвера файловой системы, обеспечивает обращение к сетевым накопителям. Можно устанавливать дополнительные драйверы файловых систем. Подсистема блочного ввода-вывода выполняет соответствующие операции на физическом уровне в ответ на запросы драйверов файловых систем.

Подсистема управления виртуальными машинами (VMM) предоставляет низкоуровневые сервисные функции, например, планирование нитей и управление памятью. Сюда также относятся драйверы виртуальных устройств (VxD) для аппаратуры.

На рисунке 8.6 представлена уже знакомая структура Windows NT, в которой каждое из приложений обращается к сервисным функциям (серверам) косвенно, через вызовы локальных процедур (LPC), реализованных в диспетчере LPC, являющемся частью NT Executive и работающем в привилегированном режиме. Приложения Win32 исполняются как отдельные многонитевые процессы. Программы Win16 могут запускаться как однонитевые процессы на общей виртуальной машине, или на собственной виртуальной машине, что обеспечивает им большую степень защищенности от других программ Win16. Приложения DOS выполняются как отдельные процессы на отдельных виртуальных DOS-машинах (VDM). Среда машины в рамках VDM конструируется таким образом, чтобы как можно более точно имитировать среду реального режима DOS. Подсистемы OS/2 и POSIX обеспечивают работу соответствующих прикладных программ в текстовом режиме.

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

Рис. 8.7. Структура сетевых средств Windows 95

Ядро обрабатывает прерывания и исключительные ситуации, переключает нити, синхронизирует процессоры в многопроцессорных системах и выполняет другие низкоуровневые функции, используемые при работе NT Executive.

На рисунке 8.7 представлена организация сетевых средств Windows 95, очень напоминающая аналогичную структуру сетевых средств Windows NT. Это и не удивительно - обе системы поддерживают один и тот же программный интерфейс WNet, с помощью которого приложения и системные утилиты получают доступ к просмотру, отображению и потреблению сетевых ресурсов.

Как видно из следующей таблицы, разбиение версий Windows на два семейства - NT и 95 - явление временное. Оно вызвано скорее не стратегическими соображениями, а тактикой борьбы за пользователей в условиях, когда мощность большей части персональных компьютеров, установленных в настоящее время у пользователей, оказалась явно недостаточной для эффективной работы Windows NT. Ввиду угрозы перетекания конечных пользователей на более компактную и менее ресурсоемкую (по сравнению с Windows NT) OS/2 Warp Connect компания Microsoft и выпустила Windows 95, как некоторую временную ОС с ограниченным сроком годности - не более 5 лет, как это видно из таблицы. И хотя Microsoft планирует выпустить еще 2 версии, улучшающие свойства Windows 95, наличие некоторых общих свойств у Windows NT и Windows 95, а также очевидные слабости Windows 95, говорят о том, что долговременная стратегия Microsoft связана с линией Windows NT, многие из новых свойств которой будут отрабатываться и в версиях линии Windows 95 (как сейчас это произошло с пользовательским интерфейсом и некоторыми системными утилитами типа клиента Microsoft Exchange).

Таблица. 8.1. Существующие и будущие версии операционных систем компании Microsoft