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

Нити часто полезны и для клиентов. Например, если клиент хочет растиражировать файл на много серверов, он может создать по одной нити для копирования на каждом сервере. Другое использование нитей клиентами - это управление сигналами, такими как прерывание с клавиатуры (del или break). Вместо обработки сигнала прерывания одна нить назначается для постоянного ожидания поступления сигналов. Таким образом, использование нитей может сократить необходимое количество прерываний пользовательского уровня.

Рис. 3.10. Три способа организации нитей в процессе:
а - модель диспетчер/рабочие нити; б - модель "команда"; в - модель конвейера

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

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

4.3 Вопросы реализации нитей

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

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

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

Нити могут быть реализованы как в пользовательском пространстве, так и в пространстве ядра. В первом случае нити работают на базе прикладной системы, управляющей всеми операциями с нитями. Первым преимуществом такого способа является то, что можно реализовать нити в операционной системе, которая их не поддерживает. ОС прикладная среда, управляющая нитями, кажется одним процессом. Все вызовы (ПРИОСТАНОВИТЬ, ПРОВЕРИТЬ СЕМАФОР и т. д.) обрабатываются как вызовы функций этой прикладной среды. Она сохраняет регистры и переключает указатели счетчика команд и стека. В этом случае переключение происходит быстрее, чем с помощью ядра. Такая реализация имеет еще одно преимущество - для каждого процесса можно организовать свою схему планирования. Однако этот подход связан с некоторыми проблемами, одна из которых состоит в следующем. При выполнении блокирующих системных вызовов приостанавливается весь набор нитей, принадлежащих этому процессу. Чтобы избежать этого, можно сделать все системные вызовы неблокирующими, но это требует изменений в ОС, что нежелательно, так как одной из целей реализации нитей в пользовательском пространстве является их работа в существующих операционных системах.

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

4.4 Нити и RPC

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

Идея заключается в следующем. Когда стартует серверная нить S, то она экспортирует свой интерфейс, сообщая о нем ядру. Интерфейс определяет, какие процедуры могут быть вызваны, каковы их параметры и т.п. Когда стартует клиентская нить C, то она импортирует интерфейс из ядра в том случае, если собирается вызвать S, и ей дается специальный идентификатор для выполнения определенного вызова. Ядро теперь знает, что C собирается позже вызвать S и создает специальные структуры данных для подготовки к вызову.

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

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

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

5. Современные концепции и технологии проектирования операционных систем

5.1 Требования, предъявляемые к ОС 90-х годов

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

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

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

Переносимость. Код должен легко переноситься с процессора одного типа на процессор другого типа и с аппаратной платформы (которая включает наряду с типом процессора и способ организации всей аппаратуры компьютера) одного типа на аппаратную платформу другого типа.

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

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

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

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

Рассмотрим более подробно некоторые из этих требований.

5.1.1. Расширяемость

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

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

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

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

Средства вызова удаленных процедур (RPC) также дают возможность расширить функциональные возможности ОС. Новые программные процедуры могут быть добавлены в любую машину сети и немедленно поступить в распоряжение прикладных программ на других машинах сети.

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

5.1.2. Переносимость

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

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

Во-вторых, следует учесть, в какое физическое окружение программа должна быть перенесена. Различная аппаратура требует различных решений при создании ОС. Например, ОС, построенная на 32-битовых адресах, не может быть перенесена на машину с 16-битовыми адресами (разве что с огромными трудностями).

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

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

Для легкого переноса ОС при ее разработке должны быть соблюдены следующие требования:

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

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

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

5.1.3. Совместимость

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

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

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

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

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

Гораздо сложнее достичь двоичной совместимости между процессорами, основанными на разных архитектурах. Для того, чтобы один компьютер выполнял программы другого (например, DOS-программу на Mac), этот компьютер должен работать с машинными командами, которые ему изначально непонятны. Например, процессор типа 680x0 на Mac должен исполнять двоичный код, предназначенный для процессора 80x86 в PC. Процессор 80x86 имеет свои собственные дешифратор команд, регистры и внутреннюю архитектуру. Процессор 680x0 не понимает двоичный код 80x86, поэтому он должен выбрать каждую команду, декодировать ее, чтобы определить, для чего она предназначена, а затем выполнить эквивалентную подпрограмму, написанную для 680x0. Так как к тому же у 680x0 нет в точности таких же регистров, флагов и внутреннего арифметико-логического устройства, как в 80x86, он должен имитировать все эти элементы с использованием своих регистров или памяти. И он должен тщательно воспроизводить результаты каждой команды, что требует специально написанных подпрограмм для 680x0, гарантирующих, что состояние эмулируемых регистров и флагов после выполнения каждой команды будет в точности таким же, как и на реальном 80x86.

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

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

Соответствие стандартам POSIX также является средством обеспечения совместимости программных и пользовательских интерфейсов. Во второй половине 80-х правительственные агентства США начали разрабатывать POSIX как стандарты на поставляемое оборудование при заключении правительственных контрактов в компьютерной области. POSIX - это "интерфейс переносимой ОС, базирующейся на UNIX". POSIX - собрание международных стандартов интерфейсов ОС в стиле UNIX. Использование стандарта POSIX (IEEE стандарт 1003.1 - 1988) позволяет создавать программы стиле UNIX, которые могут легко переноситься из одной системы в другую.

5.1.4. Безопасность

В дополнение к стандарту POSIX правительство США также определило требования компьютерной безопасности для приложений, используемых правительством. Многие из этих требований являются желаемыми свойствами для любой многопользовательской системы. Правила безопасности определяют такие свойства, как защита ресурсов одного пользователя от других и установление квот по ресурсам для предотвращения захвата одним пользователем всех системных ресурсов ( таких как память).

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

Основы стандартов в области безопасности были заложены "Критериями оценки надежных компьютерных систем". Этот документ, изданный в США в 1983 году национальным центром компьютерной безопасности (NCSC - National Computer Security Center), часто называют Оранжевой Книгой.

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

Иерархия уровней безопасности, приведенная в Оранжевой Книге, помечает низший уровень безопасности как D, а высший - как А.

В класс D попадают системы, оценка которых выявила их несоответствие требованиям всех других классов.

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

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

Уровень А является самым высоким уровнем безопасности, он требует в дополнение ко всем требованиям уровня В выполнения формального, математически обоснованного доказательства соответствия системы требованиям безопасности.

Различные коммерческие структуры (например, банки) особо выделяют необходимость учетной службы, аналогичной той, что предлагают государственные рекомендации С2. Любая деятельность, связанная с безопасностью, может быть отслежена и тем самым учтена. Это как раз то, что требует С2 и то, что обычно нужно банкам. Однако, коммерческие пользователи, как правило, не хотят расплачиваться производительностью за повышенный уровень безопасности. А-уровень безопасности занимает своими управляющими механизмами до 90% процессорного времени. Более безопасные системы не только снижают эффективность, но и существенно ограничивают число доступных прикладных пакетов, которые соответствующим образом могут выполняться в подобной системе. Например для ОС Solaris (версия UNIX) есть несколько тысяч приложений, а для ее аналога В-уровня - только сотня.

6. Операционные системы различных фирм производителей программного обеспечения

6.1 Семейство операционных систем UNIX

История и общая характеристика семейства операционных систем UNIX

Система Mach имела в качестве предшественницы систему RIG - Rochester Intelligent Gateway, начало разработки которой пришлось на 1975 год. RIG была написана для 16-битового мини-компьютера компании DataGeneral под названием Elipce. Целью этой разработки была демонстрация возможностей структурирования операционной системы и представления ее в виде набора процессов, которые могут взаимодействовать между собой путем передачи сообщений, в том числе и по сети. Затем эта операционная система была улучшена путем добавления средств защиты и средств прозрачной работы в сети и получила название Accent (в 1981 году, в университете Карнеги-Меллона). В 1984 году она уже использовалась на 150 компьютерах PERQ - ранних графических станциях, но проиграла соревнование с UNIX'ом. Это обстоятельство побудило создать третье поколение ОС, использующей механизм обмена сообщениями. Этот проект и был назван Mach. В связи с тем, что Mach проектировалась как система, совместимая с UNIX, планировалась поддержка большого количества приложений для UNIX. Кроме совместимости с UNIX, в Mach были введены и другие усовершенствования, включая нити, улучшенные механизмы межпроцессного взаимодействия, поддержка многопроцессорных систем, улучшенная виртуальная память и др. В это время агентство DARPA искало операционную систему для поддержки мультипроцессоров. Выбор был сделан в пользу университета Карнеги-Меллона, и работы над ОС Mach были продолжены. Было решено сделать эту систему совместимой с 4.2BSD путем комбинации Mach и 4.2BSD в виде единого ядра. Хотя этот подход привел к большому ядру, он гарантировал абсолютную совместимость. Первая версия Mach была реализована в 1986 году для VAX11/784, 4-х процессорной машины. Вскоре эта ОС была перенесена на IBM PC RT и Sun 3. К 1987 году Mach выполнялась также на мультипроцессорах Encore и Sequent. Хотя Mach и имела сетевые средства, ее скорее можно было отнести к ОС отдельной машины или мультипроцессора, а не к сетевой распределенной прозрачной системе. Вскоре была создана организация производителей компьютеров OSF (IBM, DEC, Hewlett Packard) для того, чтобы отобрать контроль над ОС UNIX у ее собственника AT&T. Они выбрали Mach 2.5 в качестве основы для их первой операционной системы OSF/1. Хотя Mach 2 и OSF/1 содержали большое количество кода Berkeley и AT&T, была надежда, что OSF, по крайней мере, сможет контролировать направление развития UNIX. В 1988 году ядро Mach 2.5 было большим и монолитным из-за того, что содержало большое количество кода Berkeley UNIX. А в 1989 году университет Карнеги-Меллона удалил весь код BSD UNIX из ядра и поместил его в пользовательское пространство. То, что осталось, было микроядром, состоящим из чистого кода Mach. Эта версия 3.0 и используется как основа последующих версий OSF.

6.2.2. Цели Mach

ОС Mach значительно изменилась со времени ее первой реализации в виде RIG. Цели проекта также изменились со временем. На текущий момент основные цели выглядят так:

1. Обеспечение базовых функций для создания других операционных систем (например, UNIX).

2. Поддержка больших разреженных адресных пространств.

3. Обеспечение прозрачного доступа к сетевым ресурсам.

4. Поддержка параллелизма как в системе, так и в приложениях.

5. Обеспечение переносимости Mach на различные типы компьютеров.

6.2.3. Основные концепции Mach

Микроядро Mach было разработано в качестве основы, на базе которой можно эмулировать UNIX и другие ОС. Эта эмуляция осуществляется программным уровнем, который работает вне ядра, в пользовательском пространстве (рис. 6.1). Следует отметить, что несколько эмуляторов могут работать одновременно, так что можно выполнять программы 4.3BSD, System V и MS-DOS на одной машине в одно и то же время.

Ядро Mach, подобно другим микроядрам, обеспечивает управление процессами, управление памятью, коммуникации и функции ввода-вывода. Функции управления файлами, каталогами и другие традиционные для операционных систем функции выполняются в пользовательском пространстве. Идея построения ядра Mach состоит в обеспечении механизмов, необходимых для работы системы, но стратегия использования этих механизмов реализуется на уровне пользовательских процессов.

Ядро управляет пятью главными абстракциями:

1. Процессы

2. Нити

3. Объекты памяти

4. Порты

5. Сообщения

Рис. 6.1. Абстрактная модель эмуляции UNIX на основе Mach

Кроме этого, ядро работает и с некоторыми другими абстракциями, или связанными с указанными, или менее важными.

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

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

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

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

Процесс может предоставить другому процессу возможность посылать (или получать) сообщения в один из принадлежащих ему портов. Такая возможность реализуется в виде мандата (capability), который включает не только указатель на порт, но и список прав, которыми другой процесс обладает по отношению к данному порту (например, право выполнить операцию ПОСЛАТЬ - SEND). Все коммуникации в Mach используют этот механизм.

6.2.4. Сервер Mach BSD UNIX

Как уже было сказано выше, разработчики системы Mach модифицировали Berkeley UNIX для работы в пользовательском пространстве в форме прикладной программы. Такая структура имеет несколько преимуществ по сравнению с монолитным ядром. Во-первых, система упрощается за счет разделения на часть, которая выполняет управление ресурсами (ядро), и часть, которая обрабатывает системные вызовы (UNIX-сервер), и ею становится легче управлять. Такое разделение напоминает разделение труда в операционной системе VM/370 мейнфреймов IBM, где ядро эмулирует набор "голых" 370-х машин, на каждой из которых реализована однопользовательская операционная система.

Во-вторых, за счет помещения UNIX'а в пользовательское пространство его можно сделать в высокой степени машинно-независимым. Все машинно-зависимые части могут быть удалены из UNIX'а и скрыты внутри ядра Mach.

В-третьих, как уже было упомянуто выше, несколько ОС могут работать одновременно. Например, на процессоре Intel 386 Mach может выполнять программу UNIX и программу MS-DOS одновременно. Аналогично возможно одновременное тестирование новой экспериментальной ОС и работа с основной ОС.

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

6.3 Сетевые продукты фирмы Novell

6.3.1. История и версии сетевой ОС NetWare

Novell - это крупнейшая фирма, которой принадлежит, согласно различным источникам, от 65% до 75% рынка сетевых операционных систем для локальных вычислительных сетей. Наибольшую известность фирма Novell приобрела благодаря своим сетевым операционным системам семейства NetWare. Эти системы реализованы как системы с выделенными серверами.

Основные усилия Novell были затрачены на создание высокоэффективной серверной части сетевой ОС, которая за счет специализации на выполнении функций файл-сервера обеспечивала бы максимально возможную для данного класса компьютеров скорость удаленного доступа к файлам и повышенную безопасность данных. Для серверной части своих ОС Novell разработала специализированную операционную систему, оптимизированную на файловые операции и использующую все возможности, предоставляемые процессорами Intel x386 и выше. За высокую производительность пользователи сетей Novell NetWare расплачиваются стоимостью - выделенный файл-сервер не может использоваться в качестве рабочей станции, а его специализированная ОС имеет весьма специфический API, что требует от разработчиков дополнительных серверных модулей особых знаний, специального опыта и значительных усилий.

Для рабочих станций Novell выпускает две собственные ОС со встроенными сетевыми функциями: Novell DOS 7 с входящей в нее сетевой одноранговой компонентой Personal Ware, а также ОС UnixWare, являющейся реализацией UNIX System V Release 4.2 со встроенными возможности работы в сетях NetWare. (Осенью этого года права на систему UnixWare проданы компании Santa Cruz Operations.) Для популярных ОС персональных компьютеров других производителей Novell выпускает сетевые оболочки с клиентскими функциями по отношению к серверу NetWare.

Первоначально операционная система NetWare была разработана фирмой Novell для сети Novell S-Net, имеющей звездообразную топологию и патентованный сервер с микропроцессором Motorola MC68000. Когда фирма IBM выпустила персональные компьютеры типа PC XT, Novell решила, что NetWare может быть легко перенесена в архитектуру микропроцессоров семейства Intel 8088, и тогда она сможет поддерживать практически все имеющиеся на рынке сети персональных компьютеров.

Первая версия NetWare была выпущена фирмой Novell в начале 1983 года.

В 1985 году появилась система Advanced NetWare v1.0, которая расширяла функциональные возможности операционной системы сервера.

Версия 1.2 системы Advanced NetWare, выпущенная также в 1985 году, стала первой операционной системой для процессора Intel 80286, работающей в защищенном режиме.

Версия 2.0 системы Advanced NetWare, выпущенная в 1986 году, отличалась от предыдущих версий более высокой производительностью и возможностью объединения разнородных на канальном уровне сетей. Полностью используя возможности защищенного режима процессора 80286, Advanced NetWare обеспечила такую производительность сети, которая была недоступна операционным системам, работающим в реальном режиме и ограниченным 640 Кбайтами памяти. Версия 2.0 впервые обеспечила возможность подключения к одному серверу до четырех сетей с различной топологией, таких как Ethernet, ArcNet и Token Ring.

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

Операционная система NetWare v2.15 появилась на рынке в декабре 1988 года, добавив в NetWare средства поддержки компьютеров семейства Macintosh. У пользователей Macintosh появилась возможность подключать свои компьютеры в качестве клиентов серверов NetWare, получая доступ к ресурсам сети и осуществляя прозрачный поиск и хранение информации на сервере. При этом на пользователей Macintosh распространяются все основные свойства NetWare, включая устойчивость к сбоям и защиту от несанкционированного доступа.

В сентябре 1989 года Novell выпустила свою первую версию 32-разрядной операционной системы для серверов с микропроцессором 80386, которая получила название NetWare 386 v3.0. Она обладала значительно более высокой производительностью по сравнению с предыдущими версиями, усовершенствованной системой защиты от несанкционированного доступа, гибкостью в применении, а также поддержкой различных сетевых протоколов. Она отвечала самым передовым требованиям к среде функционирования распределенных прикладных программ.

В июне 1990 года появилась версия NetWare 386 v.3.1, в которой были усовершенствованы средства обеспечения надежности и управления сетью, повышена производительность, улучшены инструментальные средства для независимых разработчиков.

В 1991 году фирмой Novell операционные системы для процессоров 80286 (SFT, Advanced и ELS NetWare) были заменены на более мощную и удобную систему NetWare v2.2, функционально превосходящую предыдущие версии 2.1x.

Одновременно была выпущена система NetWare v3.11, существенно расширившая возможности NetWare 386. NetWare v3.11 стала первой сетевой операционной системой, обеспечивающей доступ к сетевым ресурсам с рабочих станций DOS, Windows, OS/2, UNIX и Macintosh.

В 1993 году после длительных испытаний начались поставки системы NetWare SFT III v3.11. NetWare System Fault Tolerance Level III (SFT III) v3.11 - сетевая операционная система, разработанная специально для использования в системах, требующих наивысшего уровня надежности. В дополнение к средствам повышения надежности, имеющимся в составе NetWare v3.11, SFT III обеспечивает работу двух серверов в "зеркальном" режиме. При этом один из серверов всегда является активным, а второй находится в горячем резерве, обеспечивая у себя такое же состояние памяти и дисков, как и у основного сервера.

В 1993 году фирма Novell выпустила ОС NetWare v4.0, явившуюся во многих отношениях революционно новым продуктом. Эта система была разработана специально для построения вычислительных сетей "масштаба предприятия" с несколькими файл-серверами, большим количеством сетевых ресурсов и пользователей. Одним из основных нововведений явилась служба каталогов NetWare Directory Services (NDS), хранящая в распределенной по нескольким серверам базе данных информацию о всех разделяемых сетевых ресурсах и пользователях, что обеспечило возможность при одном логическом входе в систему получать прозрачный доступ ко всем ресурсам многосерверной сети.