История и версии сетевой ОС 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, и тогда она сможет поддерживать практически все имеющиеся на рынке сети персональных компьютеров.

История Mach

Система 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.

История развития OS/2 и ее место на рынке

Аналитики, занимающиеся 32-х битными операционными системами для персональных компьютеров, всегда концентрируют свое внимание на битве между Microsoft Windows и IBM OS/2, предполагая, что Microsoft имеет преимущество. Но не все согласны с такой точкой зрения. OS/2 v.2.0 была первой доступной и работающей 32-х битной операционной системой для персональных компьютеров. И она первой начала очередной круг состязаний - версия OS/2 Warp, предназначенная для клиентских машин сетей клиент-сервер и одноранговых сетей, появилась на рынке раньше Windows 95, позиционированной аналогичным образом. OS/2 Warp была также первой системой, включившей набор средств поддержки Internet, а также средств объектной ориентации.

История Windows NT

В конце 88-го года Microsoft поручила Дэвиду Катлеру (David Cutler) возглавить новый проект в области программного обеспечения: создать новую ОС фирмы Microsoft для 90-х годов. (Дэвид Катлер - главный консультант фирмы DEC, который 17 лет проработал там, разрабатывая ОС и компиляторы: VAX/ VMS, ОС для MicroVAX I, OS RSX-11M, компиляторы VAX PL/1, VAX C). Он собрал команду инженеров для разработки ОС новой технологии (New Technology - NT).

Первоначально планировалось разработать NT с пользовательским и программным (API) интерфейсами в стиле OS/2, однако OS/2 плохо продавалась, а Windows 3.0 имела большой и постоянный успех на рынке. Увидев рыночные ориентиры и сложности, связанные с развитием и поддержкой двух несовместимых систем, Microsoft решила изменить свой курс и направить своих инженеров в сторону стратегии единой цельной операционной системы. Эта стратегия состоит в том, чтобы разрабатывать семейство базирующихся на Windows операционных систем, которые охватывали бы множество типов компьютеров, от самых маленьких ноутбуков до самых больших мультипроцессорных рабочих станций. Windows NT, как было названо следующее поколение Windows-систем, занимает самое высокое место в семействе Windows. Она поддерживает графический интерфейс (GUI) пользователя Windows, а также является первой базирующейся на Windows операционной системой фирмы Microsoft, поддерживающей Win32 API, 32-х битный программный интерфейс для разработки новых приложений. Win32 API делает доступными для приложений улучшенные свойства ОС, такие как многонитевые процессы, синхронизацию, безопасность, I/O, управление объектами.

В июле 1993 года появились первые ОС семейства NT - Windows NT 3.1 и Windows NT Advanced Server 3.1.

Элеваторный поиск

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

Эмуляция BSD UNIX в Mach

В ядре Mach имеется различные серверы, которые работают над ним. Наверно, наиболее важным сервером является программа, которая содержит большое количество кодов BSD UNIX (например, весь код файловой системы). Этот сервер представляет собой основной эмулятор UNIX. Такая конструкция - отражение реальной истории Mach как модифицированной версии BSD UNIX.

Рис. 6.15. Эмуляция UNIX в Mach

Реализация механизма эмуляции UNIX в среде Mach состоит из двух частей, сервера UNIX и библиотеки эмуляции системных вызовов, как это показано на рисунке 6.15. Когда система стартует, сервер UNIX инструктирует ядро, чтобы оно перехватывало все прерывания системных вызовов и отображало вектора этих прерываний на адреса внутри библиотеки эмуляции процесса UNIX'а, по которым расположены обрабатывающие данные вызовы функции. Любой системный вызов, который делается UNIX-процессом, приводит к кратковременной передаче управления ядру, а затем к немедленной передаче управления библиотеке эмуляции. Значения машинных регистров в момент передачи управления библиотеке становятся теми же, что и в момент прерывания. Такой метод иногда называют методом батута.

Как только библиотека эмуляции получает управление, она проверяет регистры для того, чтобы определить, какой системный вызов нужно обработать. Затем библиотека делает вызов RPC другого процесса, сервера UNIX, который и должен выполнить эту работу. После завершения обработки вызова пользовательская программа снова получает управление. Эта передача управления не проходит через ядро.

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

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

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

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

Во время цикла копирования может случиться страничный отказ, если некоторые страницы файла не находятся в памяти. Каждый отказ приводит к тому, что Mach посылает сообщение внешнему менеджеру памяти, управляющему отображением файла. Этот менеджер памяти представляет собой нить внутри UNIX-сервера, называемую пейджером i-узла (i-node pager). Менеджер читает с диска нужную страницу файла и отображает ее в адресное пространство прикладной программы. Он также синхронизирует операции над файлами, которые открыты несколькими UNIX-процессами одновременно.

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

Этапы выполнения RPC

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

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

Рис. 3.2. Remote Procedure Call

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

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

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

Рисунок 3.3 показывает последовательность команд, которую необходимо выполнить для каждого RPC-вызова, а рисунок 3.4 - какая доля общего времени выполнения RPC тратится на выполнение каждого их описанных 14 этапов. Исследования были проведены на мультипроцессорной рабочей станции DEC Firefly, и, хотя наличие пяти процессоров обязательно повлияло на результаты измерений, приведенная на рисунке гистограмма дает общее представление о процессе выполнения RPC.

Рис. 3.3. Этапы выполнения процедуры RPC



Рис. 3.4. Распределение времени между 14 этапами выполнения RPC

Кэширование

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

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

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

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

Во-вторых, необходимо определить правило замены данных при заполнении кэш-памяти. Здесь можно использовать любой стандартный алгоритм кэширования, например, алгоритм LRU (least recently used), соответствии с которым вытесняется блок, к которому дольше всего не было обращения.

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

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

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

Рис. 3.11. Различные способы выполнения кэша в клиентской памяти

а - без кэширования; б - кэширование внутри каждого процесса; в - кэширование в ядре;

г - кэш-менеджер как пользовательский процесс

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

Третьим вариантом организации кэша является создание отдельного процесса пользовательского уровня - кэш-менеджера.


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

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

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

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

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

Следующим шагом в этом направлении является принятие сессионной семантики, в соответствии с которой запись файла на сервер производится только после его закрытия. Этот алгоритм называется "запись-по-закрытию".


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

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

Четыре алгоритма управления кэшированием обобщаются следующим образом:

1. Сквозная запись. Этот метод эффективен частично, так как уменьшает интенсивность только операций чтения, а интенсивность операций записи остается неизменной.

2. Отложенная запись. Производительность лучше, но результат чтения кэшированного файла не всегда однозначен.

3. "Запись-по-закрытию". Удовлетворяет сессионной семантике.

4. Централизованное управление. Ненадежен вследствие своей централизованной природы.

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

Кэширование диска

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

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

Кэширование файлов

В NetWare для достижения высокой производительности файловой системы реализован обширный динамический кэш файлов в оперативной памяти. Этот кэш построен на блочной основе. Когда приложение читает или пишет в файл, NetWare копирует нужные блоки данных файла в кэш (если они не находятся уже там). Когда файловая кэш-память полностью заполняется, NetWare выполняет процедуру выгрузки в соответствии с алгоритмом "наименее используемый в последнее время" (Least Recently Used, LRU).

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

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

В NetWare в буферах кэш-системы хранятся не только блоки данных файлов, но и такие элементы файловой системы, как FAT, Turbo FAT, кэш-таблица и входы каталогов. Turbo FAT представляет собой таблицу, в которой непосредственно перечислены все блоки файла, если их количество превышает 64. Это обеспечивает быстрый доступ к большим файлам.

При разработке серверных приложений при использовании стандартных функций API работы с файлами программисту нет необходимости задумываться об особенностях реализации системы кэширования файлов. Однако NetWare предоставляет разработчику специальные функции чтения данных непосредственно из буферов кэша (API асинхронного чтения AsyncRead API). Этот API позволяет увеличить производительность NLM-приложений.

Классификация ОС

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

Ниже приведена классификация ОС по нескольким наиболее основным признакам.

Коммерческие объектно-ориентированные средства

Объектно-ориентированный подход к построению операционных систем, придающий порядок процессу добавления модульных расширений к небольшому ядру был принят на вооружение многими известными фирмами, такими как Microsoft, Apple, IBM, Novell/USL (UNIX Systems Laboratories) и Sun Microsystems - все они развернули свои операционные системы в этом направлении. Taligent, совместное предприятие IBM и Apple, надеется опередить всех со своей от начала до конца объектно-ориентированной операционной системой. Тем временем Next поставляет Motorola- и Intel-версии NextStep, наиболее продвинутой объектно-ориентированной операционной системы из имеющихся. Хотя NextStep и не имеет объектной ориентированности сверху донизу, как это планируется в разработках Taligent, но она доступна уже сегодня.

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

Microsoft OLE (Object Linking and Embedding - связывание и внедрение объектов),

стандарт OpenDoc от фирм Apple, IBM, WordPerfect, Novell и Borland,

DSOM (Distributed System Object Model - объектная модель распределенных систем)

фирмы IBM,

PDO (Portable Distributed Objects - переносимые распределенные объекты) фирмы Next,

каркасы (frameworks) фирмы Taligent,

архитектура CORBA объединения OMG.

Коммерческие версии микроядер

Одной из первых представила понятие микроядра фирма Next, которая использовала в своих компьютерах систему Mach, прошедшую большой путь развития в университете Карнеги-Меллона при помощи агентства Министерства обороны США DARPA. Теоретически, ее небольшое привилегированное ядро, окруженное службами пользовательского режима, должно было обеспечить беспрецедентную гибкость и модульность. Но на практике это преимущество было несколько уменьшено наличием монолитного сервера операционной системы BSD 4.3, который выполнялся в пользовательском пространстве над микроядром Mach. Однако Mach дал Next возможность предоставить службу передачи сообщений и объектно-ориентированные средства, которые предстали перед конечными пользователями в качестве элегантного интерфейса пользователя с графической поддержкой конфигурирования сети, системного администрирования и разработки программного обеспечения.

Затем пришла Microsoft Windows NT, рекламировавшая в качестве ключевых преимуществ применения микроядра не только модульность, но и переносимость. Конструкция NT позволяет ей работать на системах на основе процессоров Intel, MIPS и Alpha (и последующих), и поддерживать симметричную многопроцессорность. Из-за того, что NT должна была выполнять программы, написанные для DOS, Windows, OS/2 и использующих соглашения POSIX, Microsoft использовала модульность, присущую микроядерному подходу для того, чтобы сделать структуру NT не повторяющей ни одну из существующих операционных систем. Вместо этого NT поддерживает каждую надстроенную операционную систему в виде отдельного модуля или подсистемы.

Более современные архитектуры микроядра были предложены Novell, USL, Open Software Foundation, IBM, Apple и другими. Одним из основных соперников NT на арене микроядер является микроядро Mach 3.0, которое и IBM и OSF взялись привести к коммерческому виду. (Next в качестве основы для NextStep пока использует Mach 2.5, но при этом внимательно присматривается к Mach 3.0.). Основной соперник Mach - микроядро Chorus 3.0 фирмы Chorus Systems, выбранный USL за основу для своих предложений. Это же микроядро будет использоваться в SpringOS фирмы Sun, объектно-ориентированном преемнике Solaris.

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

Коммуникации в ядре Mach

Основной целью, которую ставили перед собой разработчики средств коммуникации ядра Mach, являлась поддержка различных стилей коммуникаций в сочетании с надежностью и гибкостью. Коммуникационные средства ядра Mach могут поддерживать асинхронную передачу сообщений, RPC, потоки байт (streams), а также другие способы. Механизм взаимодействия процессов Mach базируется на соответствующих механизмах своих предшественников - RIG и Accent. Из-за своего эволюционного развития этот механизм приспособлен больше для локального использования, а не для распределенных систем.

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

Концепция удаленного вызова процедур

Идея вызова удаленных процедур (Remote Procedure Call - RPC) состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть. Средства удаленного вызова процедур предназначены для облегчения организации распределенных вычислений. Наибольшая эффективность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удаленными компонентами с небольшим временем ответов и относительно малым количеством передаваемых данных. Такие приложения называются RPC-ориентированными.

Характерными чертами вызова локальных процедур являются:

Асимметричность, то есть одна из взаимодействующих сторон является инициатором;

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

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

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

Эти и некоторые другие проблемы решает широко распространенная технология RPC, лежащая в основе многих распределенных операционных систем.

Конфигурирование NDS

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

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

Контекст и дескриптор процесса

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

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

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

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

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

создать информационные структуры, описывающие данный процесс, то есть его дескриптор и контекст;

включить дескриптор нового процесса в очередь готовых процессов;

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

Критическая секция

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

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

Рис. 2.4. Реализация критических секций с использованием блокирующих переменных

Другим способом является использование блокирующих переменных. С каждым разделяемым ресурсом связывается двоичная переменная, которая принимает значение 1, если ресурс свободен (то есть ни один процесс не находится в данный момент в критической секции, связанной с данным процессом), и значение 0, если ресурс занят. На рисунке 2.4 показан фрагмент алгоритма процесса, использующего для реализации взаимного исключения доступа к разделяемому ресурсу D блокирующую переменную F(D). Перед входом в критическую секцию процесс проверяет, свободен ли ресурс D. Если он занят, то проверка циклически повторяется, если свободен, то значение переменной F(D) устанавливается в 0, и процесс входит в критическую секцию. После того, как процесс выполнит все действия с разделяемым ресурсом D, значение переменной F(D) снова устанавливается равным 1.

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

Реализация критических секций с использованием блокирующих переменных имеет существенный недостаток: в течение времени, когда один процесс находится в критической секции, другой процесс, которому требуется тот же ресурс, будет выполнять рутинные действия по опросу блокирующей переменной, бесполезно тратя процессорное время. Для устранения таких ситуаций может быть использован так называемый аппарат событий. С помощью этого средства могут решаться не только проблемы взаимного исключения, но и более общие задачи синхронизации процессов. В разных операционных системах аппарат событий реализуется по своему, но в любом случае используются системные функции аналогичного назначения, которые условно назовем WAIT(x) и POST(x), где x - идентификатор некоторого события. На рисунке 2.5 показан фрагмент алгоритма процесса, использующего эти функции. Если ресурс занят, то процесс не выполняет циклический опрос, а вызывает системную функцию WAIT(D), здесь D обозначает событие, заключающееся в освобождении ресурса D. Функция WAIT(D) переводит активный процесс в состояние ОЖИДАНИЕ и делает отметку в его дескрипторе о том, что процесс ожидает события D. Процесс, который в это время использует ресурс D, после выхода из критической секции выполняет системную функцию POST(D), в результате чего операционная система просматривает очередь ожидающих процессов и переводит процесс, ожидающий события D, в состояние ГОТОВНОСТЬ.

Обобщающее средство синхронизации процессов предложил Дейкстра, который ввел два новых примитива. В абстрактной форме эти примитивы, обозначаемые P и V, оперируют над целыми неотрицательными переменными, называемыми семафорами. Пусть S такой семафор. Операции определяются следующим образом:

LAN WorkPlace for DOS

обеспечивает поддержку широко распространенного сетевого протокола TCP/IP и реализует на его основе доступ пользователя рабочей станции NetWare к таким сервисам UNIX-машины, как эмуляция терминала по протоколу telnet и обмен файлами по протоколу FTP. Это дает возможность получить доступ к большому количеству микро- и мини- ЭВМ с различной архитектурой и используемой OS (UNIX, VMS, OS/2), работающих с TCP/IP, к локальным и глобальным сетям (Internet), построенным на этом протоколе.

Реализация TCP/IP в LAN WorkPlace использует ODI (Open Data-link Interface) драйверы, применяемые в NetWare, что автоматически обеспечивает совместимость с широким спектром сетевых адаптеров для различных типов сетей: Ethernet, Token Ring, Arcnet, FDDI, Packet Radio. ODI-технология позволяет при работе в сети NetWare одновременно использовать IPX/SPX и TCP/IP на одном и том же сетевом адаптере.

Реализация TCP/IP дополнена двумя наборами приложений (для DOS и для Windows), которые обеспечивают традиционный UNIX-сервис для передачи файлов (FTP) и эмуляции терминалов (telnet). В дополнение к этому LAN WorkPlace for DOS обеспечивает открытый набор API, на которых базируется большое количество программных систем третьих фирм. В их числе такие "нетривиальные" сетевые продукты, как: DeskView/X фирмы Quarterdeck, X-Vision фирмы VisionWare, SQL*Net for MS-DOS фирмы Oracle, PC Net-Library for DOS фирмы Sybase, система TUXEDO фирмы USL.

Рис. 7.6. Взаимодействие сетей NetWare и UNIX

LAN WorkPlace позволяет также DOS и MS Windows клиентам сети NetWare непосредственно связываться с удаленными серверами NetWare 3.11, которые доступны только через TCP/IP маршрутизаторы, или же работать в сети, где доступным является только TCP/IP протокол. Для этого используется механизм, упаковывающий IPX-датаграммы в TCP/IP пакеты - так называемый "IP Tunneling". Версия 4.1 дополнена поддержкой IP на последовательных каналах по протоколам SLIP, CSLIP и РРР, что существенно расширяет область применения пакета.

Логическая организация файла

Программист имеет дело с логической организацией файла, представляя файл в виде определенным образом организованных логических записей. Логическая запись - это наименьший элемент данных, которым может оперировать программист при обмене с внешним устройством. Даже если физический обмен с устройством осуществляется большими единицами, операционная система обеспечивает программисту доступ к отдельной логической записи. На рисунке 2.33 показаны несколько схем логической организации файла. Записи могут быть фиксированной длины или переменной длины. Записи могут быть расположены в файле последовательно (последовательная организация) или в более сложном порядке, с использованием так называемых индексных таблиц, позволяющих обеспечить быстрый доступ к отдельной логической записи (индексно-последовательная организация). Для идентификации записи может быть использовано специальное поле записи, называемое ключом. В файловых системах ОС UNIX и MS-DOS файл имеет простейшую логическую структуру - последовательность однобайтовых записей.

Рис. 2.33. Способы логической организации файлов

Логическая структура тома

Каждый том имеет таблицу распределения блоков файлов FAT и таблицу входов в каталог DET (Directory Entry Table). Таблица FAT по назначению аналогична таблице FAT MS-DOS, а таблица DET - корневому каталогу диска MS-DOS. Отличие DET от корневого каталога DOS состоит в том, что для каждого файла в нем может находиться несколько записей - входов, если файл имеет не DOS'овский формат.

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

NetWare всегда оперирует с избыточным числом копий FAT и DET для надежности.

Методы распределения памяти без использования дискового пространства

Все методы управления памятью могут быть разделены на два класса: методы, которые используют перемещение процессов между оперативной памятью и диском, и методы, которые не делают этого (рисунок 2.8). Начнем с последнего, более простого класса методов.

Рис. 2.8. Классификация методов распределения памяти

Микроядро Mach

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

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

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

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

Во-вторых, микроядра лицензируются и используются как готовый программный продукт в качестве основы для построения коммерческой сетевой операционной системы. Сейчас имеется несколько коммерческих реализаций операционных систем на основе микроядра Mach (NextStep фирмы Next, UNIX BSD, OSF/1 v.1.3), а также проводится ряд работ по использованию этого ядра. Так как свойства микроядра в значительной степени определяют свойства ОС, построенной на его основе, то знание микроядра помогает в оценке характеристик использующей его ОС.

Многопроцессорная обработка.

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

В наши дни становится общепринятым введение в ОС функций поддержки многопроцессорной обработки данных. Такие функции имеются в операционных системах Solaris 2.x фирмы Sun, Open Server 3.x компании Santa Crus Operations, OS/2 фирмы IBM, Windows NT фирмы Microsoft и NetWare 4.1 фирмы Novell.

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

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

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

Многоуровневые системы

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

Первой системой, построенной таким образом была простая пакетная система THE, которую построил Дейкстра и его студенты в 1968 году.

Система имела 6 уровней. Уровень 0 занимался распределением времени процессора, переключая процессы по прерыванию или по истечении времени. Уровень 1 управлял памятью - распределял оперативную память и пространство на магнитном барабане для тех частей процессов (страниц), для которых не было места в ОП, то есть слой 1 выполнял функции виртуальной памяти. Слой 2 управлял связью между консолью оператора и процессами. С помощью этого уровня каждый процесс имел свою собственную консоль оператора. Уровень 3 управлял устройствами ввода-вывода и буферизовал потоки информации к ним и от них. С помощью уровня 3 каждый процесс вместо того, чтобы работать с конкретными устройствами, с их разнообразными особенностями, обращался к абстрактным устройствам ввода-вывода, обладающим удобными для пользователя характеристиками. На уровне 4 работали пользовательские программы, которым не надо было заботиться ни о процессах, ни о памяти, ни о консоли, ни об управлении устройствами ввода-вывода. Процесс системного оператора размещался на уровне 5.

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

Дальнейшее обобщение многоуровневой концепции было сделано в ОС MULTICS. В системе MULTICS каждый уровень (называемый кольцом) является более привилегированным, чем вышележащий. Когда процедура верхнего уровня хочет вызвать процедуру нижележащего, она должна выполнить соответствующий системный вызов, то есть команду TRAP (прерывание), параметры которой тщательно проверяются перед тем, как выполняется вызов.
Хотя ОС в MULTICS является частью адресного пространства каждого пользовательского процесса, аппаратура обеспечивает защиту данных на уровне сегментов памяти, разрешая, например, доступ к одним сегментам только для записи, а к другим - для чтения или выполнения. Преимущество подхода MULTICS заключается в том, что он может быть расширен и на структуру пользовательских подсистем. Например, профессор может написать программу для тестирования и оценки студенческих программ и запустить эту программу на уровне n, в то время как студенческие программы будут работать на уровне n+1, так что они не смогут изменить свои оценки.

Многоуровневый подход был также использован при реализации различных вариантов ОС UNIX.

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

Множественные прикладные среды

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

И сейчас дополнительное программное обеспечение позволяет пользователям некоторых ОС запускать чужие программы (например, Mac и UNIX позволяют выполнять программы для DOS и Windows). Но в зарождающемся поколении операционных систем средства для выполнения чужих программ становятся стандартной частью системы. Выбор операционной системы больше не будет сильно ограничивать выбор прикладных программ. Хотя столкновение пользовательских интерфейсов программ для Mac, Windows и UNIX на одном и том же экране и заставит пользователя немного потрудиться, но все равно, множественные прикладные среды операционных систем скоро станут такими же стандартными, как мыши и меню.

Множественные прикладные среды обеспечивают совместимость данной ОС с приложениями, написанными для других ОС и процессоров, на двоичном уровне, а не на уровне исходных текстов. Для пользователя, купившего в свое время пакет (например, Lotus 1-2-3) для MS DOS, важно, чтобы он мог запускать этот полюбившийся ему пакет без каких-либо изменений и на своей новой машине, построенной, например, на RISC-процессоре, и работающей под управлением, например, Windows NT.

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

Этому требованию не могут удовлетворить широко используемые ранее эмулирующие системы. Для сокращения времени на выполнение чужих программ прикладные среды используют имитацию программ на уровне библиотек. Эффективность этого подхода связана с тем, что большинство сегодняшних программ работают под управлением GUI (графических интерфейсов пользователя) типа Windows, Mac или UNIX Motif, при этом приложения тратят большую часть времени, производя некоторые хорошо предсказуемые вещи. Они непрерывно выполняют вызовы библиотек GUI для манипулирования окнами и для других связанных с GUI действий. И это то, что позволяет прикладным средам возместить время, потраченное на эмулирование команды за командой. Тщательно сделанная прикладная среда имеет в своем составе библиотеки, имитирующие внутренние библиотеки GUI, но написанные на родном коде, то есть она совместима с программным интерфейсом другой ОС. Иногда такой подход называют трансляцией для того, чтобы отличать его от более медленного процесса эмулирования кода по одной команде за раз.

Например, для Windows-программы, работающей на Mac, при интерпретировании команд 80x86 производительность может быть очень низкой. Но когда производится вызов функции открытия окна, модуль прикладной среды может переключить его на перекомпилированную для 680x0 подпрограмму открытия окна. Так как библиотекам GUI не нужно дешифрировать и имитировать каждую команду, то в частях программы, относящихся к вызовам GUI ABI (Application Binary Interface - двоичный интерфейс прикладного программирования), производительность может резко вырасти. В результате на таких участках кода скорость работы программы может достичь (а возможно, и превзойти) скорость работы на своем родном процессоре.



Сегодня в типичных программах значительная часть кода занята вызовом GUI ABI. Apple утверждает, что программы для Mac тратят до 90 процентов процессорного времени на выполнение подпрограмм из Mac toolbox, а не на уникальные для этих программ действия. SunSelect говорит, что программы для Windows тратят от 60 до 80 процентов времени на работу в ядре Windows. В результате при эмуляции программы на основе GUI потери производительности могут быть значительно меньше. SunSelect заявляет, что его новая прикладная среда Windows, WABI (Windows Application Binary Interface - двоичный интерфейс прикладных программ Windows), благодаря сильно оптимизированным библиотекам, на некоторых платформах при исполнении одних и тех же тестов может обогнать настоящий Microsoft Windows.

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

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

К усовершенствованным операционным системам, явно содержащим средства множественных прикладных сред, относятся: IBM OS/2 2.x и Workplace OS, Microsoft Windows NT, PowerOpen компании PowerOpen Association и версии UNIX от Sun Microsystems, IBM и Hewlett-Packard.


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

Существует много разных стратегий по воплощению идеи множественных прикладных сред, и некоторые из этих стратегий диаметрально противоположны. В случае UNIX, транслятор прикладных сред обычно делается, как и другие прикладные программы, плавающим на поверхности операционной системы. В более современных операционных системах типа Windows NT или Workplace OS модули прикладной среды выполняются более тесно связанными с операционной системой, хотя и обладают по-прежнему высокой независимостью. А в OS/2 с ее более простой, слабо структурированной архитектурой средства организации прикладных сред встроены глубоко в операционную систему.

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

Модель клиент-сервер и микроядра

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

Рис. 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, например, в некоторых случаях заменяет перенос сообщений на коммуникационные каналы с общей памятью, имеющие более высокую пропускную способность. Хотя это и стоит дороже в смысле потребления фиксированной памяти микроядра, данная альтернатива может помочь сделать модель пересылки сообщений более практичной.

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

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

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

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

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

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

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

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

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

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

Мультиплексирование стеков протоколов

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

Рис. 3.15. Мультиплексирование стеков

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

При использовании технологии мультиплексирования структура коммуникационных средств операционной системы может быть и более сложной. В общем случае на каждом уровне вместо одного протокола появляется целый набор протоколов, а мультиплексоров может быть несколько, выполняющих коммутацию между протоколами разных уровней (рисунок 3.16). Например, рабочая станция может получить доступ к сетям с протоколами NetBIOS, IP, IPX через один сетевой адаптер. Аналогично, сервер, поддерживающий прикладные протоколы NCP, SMB и NFS может без проблем выполнять запросы рабочих станций сетей NetWare, Windows NT и Sun одновременно.

Рис. 3.16. Мультиплексирование протоколов

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

Надежные и ненадежные примитивы

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

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

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

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

Неделимые транзакции

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

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

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

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

BEGIN_TRANSACTION

команды, которые следуют за этим примитивом, формируют транзакцию.

END_TRANSACTION

завершает транзакцию и пытается зафиксировать ее.

ABORT_TRANSACTION

прерывает транзакцию, восстанавливает предыдущие значения.

READ

читает данные из файла (или другого объекта)

WRITE

пишет данные в файл (или другой объект).

<
/p> Первые два примитива используются для определения границ транзакции. Операции между ними представляют собой тело транзакции. Либо все они должны быть выполнены, либо ни одна из них. Это может быть системный вызов, библиотечная процедура или группа операторов языка программирования, заключенная в скобки.

Транзакции обладают следующими свойствами: упорядочиваемостью, неделимостью, постоянством.

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

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

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

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

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

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

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


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

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

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

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



Рис. 3.8. Двухфазный протокол фиксации транзакции

Недостатки

Наилучшая модель для предприятий с небольшим
числом пользователей и ресурсов
Централизованное управление пользовательской
учетной информацией
Нет нужды в управлении доверительными отношениями
Локальные группы нужно определять только однаждыНизкая производительность, если
домен имеет слишком много
пользователей и/или серверов
Невозможность группирования
ресурсов

<
/p> Модель с главным доменом

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

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

Рис. 3.21. Модель с главным доменом



Каждый объект представляет собой ресурс, такой как принтер, том, пользователь или сервер.

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

Еще одна категория объектов, в которую входят, например, объекты типа отдела предприятия, помогают организовывать и упорядочивать другие объекты.

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

Дерево каталогов

NDS использует для хранения информации логическую структуру, называемую деревом каталогов (Directory Tree, DT). Эта иерархическая структура имеет корневой элемент (root) и ветви (рисунок 3.25). Администратору сети NetWare 4.x предоставляется удобная графическая утилита NetWare Administrator, работающая в среде Windows, наглядно представляющая каждый объект дерева каталогов NDS в виде иконки и отражающая связи между объектами. Пользователи также получают удобства прозрачного доступа к ресурсам всей сети, если они пользуются оболочкой NetWare для Windows, которая поддерживает диалог с NDS и представляет доступные пользователю ресурсы в виде вложенных пиктограмм.

Дерево каталогов содержит объекты двух типов:

объекты-контейнеры,

объекты листья.

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

NDS содержит объекты-контейнеры трех типов, которые можно использовать для организации дерева объектов:

Страна (Country) - необязательный объект, который можно использовать в сетях, охватывающих несколько стран.

Организация (Organization) - располагается уровнем ниже, чем объекты-страны (если они используются).



Отдел или подразделение организации (Organizational Unit) - располагается уровнем ниже, чем объекты-организации. Помогает в дальнейшем упорядочивании остальных объектов.



Рис. 3.25. Типичная структура дерева каталогов NDS

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

организатор - используется для таких руководящих лиц фирмы, как руководитель группы или вице-президент,

сервер,

принт-сервер,

очередь печати,

карта каталогов на томе,

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

псевдоним - указывает на оригинальное местонахождения объекта в дереве. Любой объект может быть расположенным в нескольких местах дерева с использованием псевдонимов. Псевдонимы делают использование NDS более гибким и удобным.

Служба NDS и файловая система

Служба NDS предназначена для управления такими сетевыми ресурсами, как серверы и тома NetWare, но она не обеспечивает управление файловой системой. Файлы и каталоги не являются объектами службы NDS. Однако они представляются в виде иконок при использовании графической утилиты NetWare Administrator. Одним из атрибутов объекта-тома является месторасположение физического тома, который содержит файлы и каталоги. Таким образом, объект-том представляет собой связь между NDS и файловой системой.

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

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



Имена и контексты

В именовании объектов служба NDS использует те же принципы, что и файловые системы MS DOS и UNIX. Объект-лист имеет краткое имя, называемое Common Name (CN). Оно может состоять максимум из 64 символов, включая пробелы. Поэтому имя принтера "Быстрый, но часто ломающийся Epson" является законным. Аналогом полного имени файловой системы MS DOS является так называемое "различимое имя" - Distinguished Name. Различимое имя представляет собой конкатенацию всех имен объектов, расположенных на пути этого объекта к корню дерева. Составляющие различимого имени отделяются друг от друга точкой. В отличие от полных имен MS DOS крайней левой составляющей различимого имени является краткое имя объекта, а крайней правой составляющей - имя корневого объекта. Например,

Vova S.NetProgrammers.Microsoft.US

представляет собой различимое имя объекта-пользователя с сетевым именем Vova S, работающего в сетевом отделе фирмы Microsoft, расположенной в США. Возможен и другой вариант записи различимого имени с указанием типов объектов:

CN=Vova s.Ou=NetProgrammers.O=Microsoft.C=US.

Такой вид записи более содержателен.

Средства защиты объектов в NDS

Служба NDS определяет права доступа одних сетевых объектов к другим. Различаются права доступа к объекту в целом и права доступа к его атрибутам.

По отношению к объектам существует следующий набор прав:

Browse - просмотр;

Add - добавление;

Delete - удаление;

Rename - переименование;

Supervisor - обеспечивает все перечисленные выше права.

По отношению к атрибутам объектов используются такие права:

Compare - сравнение значения атрибута;

Read - чтение значения атрибута;

Write - запись нового значения атрибута;

Self - присвоение себя в качестве значения атрибута другого объекта, например, если объект-группа разрешает право Self для объекта User, то последний может сделать себя членом этой группы;

Supervisor - все права по доступу к атрибутам.

С каждым объектом связан список управления доступом (ACL), в котором определяются права доступа к данному объекту со стороны других объектов.



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

После подробного рассмотрения свойств дерева каталогов NDS можно уточнить понятия раздела (partition) и реплики (replica). Раздел представляет собой поддерево общего дерева сети. Для определения раздела необходимо выбрать объект-контейнер в общем дереве, который будет корневым объектом данного раздела. Создание раздела уменьшает объем хранимой на сервере информации базы данных NDS за счет исключения редко используемой информации и делает доступ к локальным объектам более быстрым, хотя объекты, находящиеся в других разделах, также доступны всем клиентам сети.

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

Существуют три типа реплик: главная реплика (master replica), вторичная реплика (read/write replica) и реплика только для чтения (read-only replica).

Главная реплика позволяет проводить над ней такие операции, как создание нового раздела, слияние разделов и удаление раздела.

Вторичная реплика разрешает обновлять информацию об объектах, добавлять новые объекты, но не разрешает создавать новые разделы.

Реплика только для чтения позволяет только читать информацию из ее базы и проводить операции поиска.

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

Любой сервер NetWare, поддерживающий службу NDS, называется сервером имен.

Неизменяемые файлы

. Модификации невозможны, разделение файлов и репликация упрощаются.

в которой были усовершенствованы средства

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

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

Она обладала значительно более высокой

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

В июне 1990 года появилась

NetWare Connect 1.0 фирмы Novell

NetWare Connect - пpогpаммный пpодукт для создания в сетях NetWare мощных коммуникационных центров, pешающих большинство задач асинхpонных коммуникаций как для пользователей сети, так и для стоpонних пользователей, котоpым необходим доступ в сеть NetWare.

NetWare Connect обеспечивает удаленным от сети пользователям DOS, Windows и Macintosh пpозpачный доступ в сеть в качестве pабочих станций NetWare, как будто бы они непосpедственно включены в сеть (режим remote node). Кроме того пользователи сети NetWare могут коллективно использовать такие сетевые ресурсы, как модемы, асинхронные поpты и каналы связи, обоpудование и каналы X.25. NetWare Connect полностью заменяет продукт NetWare Asynchronous Communication Server (NACS) v.3.0.

Реализованный в виде NLM-модуля ОС NetWare 3.x и 4.x, NetWare Connect использует такие ее преимущества, как высокая производительность, безопасность и удобства администрирования. Возможны выгрузка либо динамическое переконфигурирование NetWare Connect без перезагрузки файл-сервера NetWare.

NetWare Connect может предоставить пользователям сети три полезные функции:

коллективный доступ к коммуникационной аппаратуре (сервер модемов и другого коммуникационного оборудования);

сервис удаленного узла сети;

поддержку сервиса удаленного управления.

NetWare Connect предоставляет эффективное решение проблемы коллективного доступа к коммуникационной аппаратуре, например, совместного иcпользования модемов. Без использования NetWare Connect каждый пользователь, котоpому необходимо работать с модемом, должен был установить его на свой компьютер. Модем и телефонный канал выделялись каждому пользователю и большую часть вpемени простаивали. NetWare Connect превращает коммуникационное обоpудование в pазделяемый сетевой ресурс, захватываемый пользователем только на вpемя pаботы. Администратор сети оценивает потребности пользователей в одновременно работающих модемах и устанавливает их в сети NetWare Connect на соответствующее чиcло поpтов.

С любой станции сети становится возможным, используя совместимые с NetWare Connect коммуникационные пpогpаммы, осуществлять доступ к центральным ЭВМ, электронным доскам объявлений (BBS), сетям X.25 и серверам доступа (например, к NetWare Access Services или Citrix WinView for Networks).
Совместимость коммуникационных пакетов третьих фирм c NetWare Connect достигается использованием промышленных стандартов NetWare Asynchronous Services Interface (NASI) или BIOS Int 14. Обеспечивается доступ в локальную сеть удаленных ПК, использующих программы удаленного доступа третьих фирм (напpимер, pcAnywhere).

Важной принципиально новой способностью NetWare Connect является поддержка сервиса удаленного узла сети. Удаленные пользователи DOS, Windows и Macintosh могут звонить на NetWare Connect c удаленной pабочей станции и работать в сети так же, как они делают это при локальном подключении. Сетевой трафик пpотоколов IPX, TCP/IP и AppleTalk направляется по асинхронному каналу связи. Для пользователей DOS и Windows в составе NetWare Connect поставляется программа NetWare Remote Node (NRN), которая взаимодействует с компонентом Remote Node Services (RNS) на сервере NetWare Connect (рисунок 7.5). Перед предоставлением такой связи RNS проверяет имя и пароль удаленного пользователя. После этого поверх NRN на удаленном компьютере могут загружаться программы IPXODI и сетевая оболочка NETX или оболочка выполненная по VLM-технологии, обеспечивая тем самым тот же сервис для удаленного узла, что и для локального. Программа NRN c точки зрения программы IPXODI работает аналогично ODI-драйверу.

Для пользователей Macintosh, которым необходим доступ к сети AppleTalk, NetWare Connect поддерживает программное обеспечение AppleTalk Remote Access фирмы Apple Computer. В сервере NetWare Connect функции главной машины для удаленного пользователя компьютера Macintosh поддерживает компонента Apple Remote Access Service (ARAS).

Пользователи могут обмениваться почтой, pаботать с файлами и любыми программами, хотя низкая пpопускная способность асинхpонного канала может приводить к слишком большому времени реакции системы, и накладывает опpеделенные огpани-чения на спектр эффективно используемых прикладных программ. При работе в диапазоне 1200 - 9600 б/с наиболее эффективно использование программ копирования файлов и приложений клиент-сервер.

Рис. 7.5. Использование NetWare Connect

NetWare Connect также управляет входящими соединениями для приложений удаленного управления. Удаленные пользователи с помощью какого-либо пакета удаленного управления (например, pcAnywhere фирмы Symantec) могут позвонить на подключенный к NetWare Connect модем и получить удаленное управление рабочей станцией в сети. Например, уезжающий в деловую поездку служащий, может оставить свой офисный компьютер в ожидании соединения, и затем работать на нем удаленно. Компонента NetWare Connect, называемая NASI Connection Service (NCS), управляет как входящими, так и исходящими соединениями.

Серверы приложений (например, NetWare Access Services или WinView for Networks фирмы Citrix) могут использовать NetWare Connect в качестве коммуникационного ресурса для приема входящих звонков. Кроме того, с серверами приложений удаленный пользователь может работать после входа в сеть через NetWare Connect в режиме удаленного узла.

Исходящие соединения могут осуществляться с любой станции сети с использованием NASI-совместимых коммуникационных программ других фирм, которые, как правило, эмулируют терминал, осуществляют доступ к центральным ЭВМ, электронным доскам объявлений (BBS), сетям X.25 и серверам доступа.

Такие компоненты сервера NetWare Connect, как RNS, ARAS и NCS, разделяют его коммуникационные порты между собой. В отличие от NACS, сервер NetWare Connect не требует ручной работы при установлении входящего NASI-соединения или при его разрыве. Вместо этого доступные для удаленного управления компьютеры локальной сети регистрируются на сервере NetWare Connect, но реальное NASI-соединение не выполняется (на назначенном порте) до тех пор, пока не поступит запрос от удаленного пользователя на доступ к какому-либо из этих компьютеров. Это позволяет использовать коммуникационный порт для выполнения других функций до образования NCS-соединения.

NetWare NFS Gateway

предоставляет пользователям рабочих станций сети NetWare доступ к файловой системе удаленных NFS-серверов и поддерживает протоколы NFS, FTP и telnet. Gateway, реализованный как NLM, устанавливается на сервере NetWare и позволяет последнему связываться по протоколу TCP/IP с любым UNIX NFS сервером и монтировать его файловую систему, создавая при этом в дополнение к локальным томам на диске NetWare-сервера том сетевой файловой системы. Эти функции на NetWare-сервере осуществляются в многозадачном режиме, параллельно с выполнением основных функций сервера. С точки зрения рабочих станций NetWare доступ ко всем (NetWare и NFS) томам на сервере абсолютно одинаков. Соединение станций по прежнему осуществляется по протоколу IPX/SPX, и поэтому дополнительного программного обеспечения на рабочих станциях не требуется.

NetWare NFS Gateway, таким образом, производит преобразование протоколов между рабочей станцией и сервером NetWare (NCP и IPX/SPX) с одной стороны и между NetWare и NFS-серверами ( NFS и TCP/IP) с другой. В этом заключается существенное отличие данного решения проблемы доступа к удаленной файловой системе от решения, предоставляемого NFS Client for LAN WorkPlace.

NetWare NFS обеспечивает прозрачную интеграцию

NetWare NFS обеспечивает прозрачную интеграцию UNIX-систем с файловой системой и ресурсами NetWare 3.11, предоставляя пользователям UNIX доступ к среде NetWare из их "родного" программного окружения с использованием привычной для них процедуры монтирования удаленной файловой системы сервера NetWare. UNIX-клиенты могут использовать NetWare NFS для доступа к файлам NetWare и другим сетевым ресурсам совместно с другими NetWare-клиентами, такими как DOS, OS/2 и Macintosh-компьютеры.

NetWare NFS использует коммуникационный транспортный протокол TCP/IP, широко применяемый в UNIX-системах и стандартный для NFS. Благодаря этому не возникает необходимости в дополнительном программном обеспечении на стороне UNIX-клиентов.

Возможности NetWare NFS:

NFS-сервер. Позволяет пользователям UNIX рассматривать файловую систему NetWare как расширение их естественной распределенной файловой системы NFS. Для доступа к томам NetWare используются стандартные команды монтирования UNIX/NFS. NFS-Server поддерживает: transparent support of authentication, отображение атрибутов и имен файлов, блокировку файлов, преобразование прав доступа UNIX и NetWare, удаленное сетевое администрирование.

NFS Namespace NLM. Привносит в файловую систему NetWare file attributes and naming conventions, характерные для UNIX-систем, что обеспечивает прозрачный обмен файлами с DOS, Macintosh и OS/2 станциями.

LPD NLM - сервер печати, позволяющий UNIX-рабочим станциям перенаправлять принтерные запросы в стандартные очереди печати NetWare.

Line Printer Gateway - дает возможность пользователям сети NetWare печатать на принтерах, подключенных к UNIX-машинам.

FTPSERV NLM - сервер FTP протокола, позволяющий любому FTP-клиенту, имеющему соответствующие права доступа, передавать файлы с и на любой сервер NetWare. Lock Manager NLM поддерживает операции блокировки файлов и записей в среде NFS. UNIX-приложения, использующие блокировки, полностью поддерживаются программой Lock Manager.

XCONSOLE - программа для удаленного управления сервером NetWare, дающая возможность администраторам UNIX'а открывать X-Windows сессии с одновременным доступом к консолям нескольких NetWare-серверов.

Management utilities. Широкий набор программ, позволяющий следить за состоянием NFS-сервера, и, при необходимости, реконфигурировать его.

NetWare System Fault Tolerance Level

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

В 1993 году фирма Novell выпустила ОС

функционально превосходящую предыдущие версии

, функционально превосходящую предыдущие версии 2.1x.

Одновременно была выпущена система

в декабре 1988 года, добавив

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

В сентябре 1989 года Novell выпустила свою первую версию 32-разрядной операционной системы для серверов с микропроцессором 80386, которая получила название

существенно расширившая возможности NetWare 386.

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

В 1993 году после длительных испытаний начались поставки системы

представляющую собой усовершенствованный вариант самой

, представляющую собой усовершенствованный вариант самой популярной сетевой ОС фирмы Novell - NetWare v3.11. В версии NetWare 3.12 были устранены замеченные за время эксплуатации версии NetWare 3.11 ошибки и добавлены новые средства: усеченная версия электронной почты Global MHS, средства поддержки клиентов Macintosh и клиентская оболочка для DOS и Windows по технологии VLM, позволяющая динамически загружать и выгружать необходимые для рабочей станции сетевые компоненты.

Последней на сегодня версией NetWare является ориентированная на корпоративное использование сетевая операционная система

явившуюся во многих отношениях революционно

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

В сентябре 1993 года Novell выпустила систему

Независимый от устройств слой операционной системы

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

Типичными функциями для независимого от устройств слоя являются:

обеспечение общего интерфейса к драйверам устройств,

именование устройств,

защита устройств,

обеспечение независимого размера блока,

буферизация,

распределение памяти на блок-ориентированных устройствах,

распределение и освобождение выделенных устройств,

уведомление об ошибках.

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

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

и представляет собой реализацию клиентской

является дополнением к LAN WorkPlace/LAN WorkGroup и представляет собой реализацию клиентской части широко распространенного протокола NFS фирмы SUN. В силу того, что NFS Client базируется на стандартном TCP/IP протоколе, он позволяет DOS-рабочим станциям непосредственно монтировать файловые системы различных UNIX-систем, поддерживающих NFS.

Функциональные возможности:

Прозрачный доступ к файлам хост-машин NFS путем отображения их файловых систем на логические диски DOS.

Поддержка символических связей UNIX-файловой системы. Возможность запуска многопользовательских DOS-приложений, таких как DBase IV, Paradox, Clipper с NFS сервера, что позволяет существенно уменьшить требуемое пространство на локальном диске рабочих станций.

Возможность поддерживать до 16 ID групп, используемых для доступа к файлам на NFS-сервере, что позволяет работать одновременно с большим количеством файлов, чем при работе с другими PC NFS продуктами.

Механизм блокировки и разделения файлов, доступный в DOS 3.1 и выше, может быть использован для файлов на NFS-сервере, вне зависимости от наличия подобного механизма в используемой реализации NFS.

Поддержка простой схемы маппирования для ID-пользователей, ID-групп и NFS hostnames, которая позволяет не использовать более сложную систему Network Information Service.

Совместное использование принтеров, подключенных к хостам NFS.

Поддержка сетевых возможностей MS Windows. В поставку входят конфигурационные файлы, требуемые для программы SETUP в MS Windows.

Эффективное использование доступной верхней памяти. Для загрузки драйверов и клиентской программы LWPNFS в верхнюю память могут быть использованы известные программы QEMM-386, 386 Max и другие. Предусмотрена также возможность удаления LWPNFS из памяти командой unload.

Нити

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

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

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

Для этих целей современные ОС предлагают использовать сравнительно новый механизм многонитевой обработки (multithreading). При этом вводится новое понятие "нить" (thread), а понятие "процесс" в значительной степени меняет смысл.

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

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

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

Нити иногда называют облегченными процессами или мини-процессами. Действительно, нити во многих отношениях подобны процессам. Каждая нить выполняется строго последовательно и имеет свой собственный программный счетчик и стек. Нити, как и процессы, могут, например, порождать нити-потомки, могут переходить из состояния в состояние. Подобно традиционным процессам (то есть процессам, состоящим из одной нити), нити могут находится в одном из следующих состояний: ВЫПОЛНЕНИЕ, ОЖИДАНИЕ и ГОТОВНОСТЬ. Пока одна нить заблокирована, другая нить того же процесса может выполняться. Нити разделяют процессор так, как это делают процессы, в соответствии с различными вариантами планирования.

Однако различные нити в рамках одного процесса не настолько независимы, как отдельные процессы.


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

Итак, нити имеют собственные:

программный счетчик,

стек,

регистры,

нити-потомки,

состояние.

Нити разделяют:

адресное пространство,

глобальные переменные,

открытые файлы,

таймеры,

семафоры,

статистическую информацию.

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

Широкое применение находит многонитевая обработка в распределенных системах. Смотрите об этом в разделе "Процессы и нити в распределенных системах".

Некоторые прикладные задачи легче программировать, используя параллелизм, например задачи типа "писатель-читатель", в которых одна нить выполняет запись в буфер, а другая считывает записи из него.


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

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

Нити и невытесняющая многозадачность

Другим преимуществом защищенного режима является возможность выполнять несколько программ одновременно. Часто это называют многозадачностью (multitasking). В NetWare реализован механизм "нитей" (thread), который позволяет использовать все преимущества расщепления одного процесса на несколько параллельно выполняемых нитей. Этот механизм описан в разделе 1.2.4 главы 1. NetWare обеспечивает удобные средства для реализации многонитевых процессов.

Существует несколько вариантов реализации алгоритма диспетчирования нитей. NetWare использует метод невытесняющей многозадачности (nonpreemptive multitasking). Это означает, что обычно невозможно прерывание приложений и их нитей другими приложениями и нитями. Иногда этот метод называют "окружением хороших парней", так как ожидается, что приложения будут вести себя вежливо по отношению к системным ресурсам. Фактически, если приложение не отдает периодически управление CPU, чтобы дать возможность другим приложениям выполняться, то будет работать только это приложение. Следовательно, при работе в таком режиме очень важно понимать последствия захвата CPU и быть "хорошим парнем" среди равных. Главным же преимуществом невытесняющей многозадачности является более быстрое переключение с нити на нить по сравнению с вытесняющей многозадачностью (preemptive multitasking), когда нить процесса прерывается в неожиданный и часто неудобный для нее момент времени, и ОС приходится сохранять гораздо больше информации о прерванном состоянии нити, чем в случае, когда нить сама отдает управление ОС.

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

Нити и RPC

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

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

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

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

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

объединяет в себе прогрессивные технологии в области DOS-совмес- тимых операционных систем, средства полной поддержки сетей NetWare и построения одноранговой локальной сети для рабочей группы. Будучи полностью совместимой с используемыми приложениями и драйверами для DOS и Microsoft Windows, DOS 7 расширяет стандартные возможности DOS многозадачностью и поддержкой защищенного режима.

Novell DOS 7 - это первая версия DOS со встроенными функциями для организации одноранговых сетей, и, по мнению фирмы Novell - это главная отличительная особенность этой ОС.

Новый буферный кэш

Расположение данных в файле характеризуется их смещением от начала файла. Так как ядро ссылается на любой файл с помощью структуры vnode, то расположение данных в файле определяется парой vnode/offset. Доступ к файлу по адресу vnode/offset достигается с помощью сегмента виртуальной памяти типа segmap, который подобен сегменту segvn, используемому системой виртуальной памяти. Метод доступа к файлам, основанный на сегментах segmap, называется новым буферным кэшем. Этот способ кэширования использует модель страничного доступа к памяти для ссылок на блоки файлов. Размер страницы, используемой новым буферным кэшем, машиннозависим. Для отображения блоков файлов используется адресное пространство ядра, которое также как и пользовательское виртуальное пространство описывается структурой as. Одним из сегментов в адресном пространстве ядра является сегмент segkmap, который используется для страничного доступа к области файлов.

Рис. 5.15. Организация связи ядра с драйверами

Объектно-ориентированный подход

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

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

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

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

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

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

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

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

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

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

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

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



Для того, чтобы управлять различными объектами единообразно, менеджер объектов требует, чтобы каждый объект содержал несколько полей стандартной информации в определенном месте объекта. До тех пор, пока эти данные имеются, менеджер объектов не заботится о том, что еще хранится в объекте. Каждый объект состоит из двух частей - заголовка объекта и тела объекта, которые содержат стандартные и переменные данные объекта соответственно. Менеджер объектов работает с заголовком объекта, а другие компоненты executive работают с телами объектов тех типов, которые они сами создают. Заголовок объекта используется менеджером без учета типа объекта. В заголовке объекта любого типа содержится имя, каталог, дескриптор безопасности, квоты на использование ресурсов, счетчик открытых описателей, база данных открытых описателей, признак постоянный/временный, режим пользователя/ядра, указатель на тип объекта.

Кроме заголовка объекта, каждый объект имеет тело объекта, формат и содержание которого уникально определяется типом этого объекта; у всех объектов одного и того же типа одинаковый формат тела. При создании объекта исполнительная часть может оперировать данными в телах всех объектов этого типа.

Обеспечение процессорной независимости

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

Делаются попытки переноса NetWare на RISC-платформы. Для этого Novell переписала NetWare на С и отделила ее аппаратно-зависимые части. Так как ранее Novell уже использовала название Portable NetWare для обозначения версий NetWare, работающих в среде VMS и UNIX, то эта действительно переносимая версия NetWare была названа PIN (Processor Independent NetWare). Она будет работать как "родная" на процессорах PowerPC и поддерживать NLM'ы.

Усилия по программе PIN не только отрывают NetWare от команд x86, но и уводят ее от шин PC, архитектуры памяти и системы прерывания. Такое отделение осуществляется с помощью слоя NSI (NetWare Systems Interface), эквивалента Novell слоя HAL в ОС Windows NT. NSI ведет свое происхождение из работы, проведенной фирмой NetFrame Systems, которая с 1989 года занимается адаптацией NetWare для работы на своих суперсерверах, которые хотя и построены на процессорах Intel, но имеют архитектуру более близкую к мейнфреймам, чем к персональным компьютерам.

"Мы купили лицензию на код NetWare и удалили оттуда все ссылки на контроллер прерывания, функции BIOS и все остальное, что было непосредственно связано с процессором Intel" - рассказывает Карл Амдал (Carl Amdahl). Позже эта работа была использована в NetWare 3.11, в которой зависимости от платформы изолированы в модуле, загружающем ядро NetWare. А теперь эти же результаты используются при разработке NSI.

Однако главная проблема состоит в том, нужен ли вообще многоплатформенный вариант NetWare. Поскольку узким местом сервера NetWare, нацеленного в основном на операции с файлами, являются возможности подсистемы ввода-вывода, а не вычислительные операции, то есть сомнения в целесообразности переноса NetWare на платформы с более мощным процессором. Действительно, в существующих NetWare-серверах процессоры семейства Intel, как правило, являются недозагруженными. Этот вопрос очень болезненен для Novell, особенно после того, как ее основной партнер по программе PIN - Hewlett-Packard приостановил работы по переносу NetWare на PA-RISC, а перенос на процессор Alpha отложен на неопределенный срок.

Области использования Windows NT

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

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

Так, под управлением Windows NT Server может работать сервер баз данных Microsoft SQL Server, а также серверы баз данных других известных фирм, такие как Oracle и Sybase, Adabas и InterBase.

На платформе Windows NT Server может быть установлена новая мощная система администрирования Microsoft System Management Server, функцией которой является инвентаризация аппаратной и программной конфигурации компьютеров сети, автоматическая установка программных продуктов на рабочие станции, удаленное управление любым компьютером и мониторинг сети.

Windows NT Server может использоваться как сервер связи с мейнфреймам. Для этого создан специальный продукт Microsoft SNA Server, позволяющий легко объединить в одной сети IBM PC-совместимые рабочие станции и мощные мейнфреймы.

Наконец, Windows NT Server является платформой для нового производительного почтового сервера Microsoft Exchange.

Обработка прерываний

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

Образ, дескриптор, контекст процесса

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

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

При управлении процессами операционная система использует два основных типа информационных структур: дескриптор процесса (структура proc) и контекст процесса (структура user).

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

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

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

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

Общая характеристика

В конце 1994 года IBM выпустила третью главную версию OS/2, которую назвала OS/2 Warp 3 (warp - основа). Его демонстрации и развернутая рекламная компания напоминали рекламную компанию 1992 года, когда была выпущена OS/2 2.0. Во всяком случае один лозунг был точным повторением: в этой системе есть много преимуществ, которые пользователи и корпорации могут извлечь немедленно из 32-х разрядной операционной среды.

OS/2 Warp имеет хорошо продуманный объектно-ориентированный интерфейс с применением техники drug-and-drop при выполнении операций копирования, удаления, печати, а также некоторых других. Перечни свойств объектов легко доступны в меню, вызываемых щелчком правой клавиши мыши. Имеется специальная панель для размещения часто используемых документов или прикладных программ.

В состав OS/2 Warp входит набор утилит BonusPack, который содержит IBM Works - интегрированный программный пакет начального уровня, и Internet Access Kit - самый полный набор средств для сети Internet из всех средств, поставляемых в составе операционных систем, Web Browser и почта Internet Mail. В публикациях встречаются утверждения, что он более совершенен, чем набор для доступа к Internet, реализованный в Windows 95. В феврале 1995 года IBM начала продавать пакет OS/2 Warp 3 Full Pack, который содержит библиотеки Win-OS/2. Эти библиотеки дают возможность выполнять Windows-программы, не приобретая лицензионных копий Microsoft Windows.

Одним из часто критикуемых недостатков OS/2 Warp является то, что она не поддерживает 32-х битные приложения Windows (точнее, она поддерживает API Win32s, но не поддерживает полный API Windows NT, который называется Win32 и который почти полностью поддерживает Windows 95). Однако в ближайшее время этот недостаток не будет критическим, так как приложений Win32 пока немного, зато с приложениями Win16 у OS/2 Warp проблем нет. IBM говорит, что она может обеспечить поддержку приложений Win32, если этого пожелают пользователи.

В то же время в OS/2 Warp ощущается недостаток сетевых функциональных возможностей.
Положение должно измениться, так как летом 1995 года IBM начала продавать следующую версию OS/2 - Warp Connect, которая содержит важнейшие драйверы и утилиты. В число новых средств входят редиректоры для операционных систем NetWare 3.х и 4.1 и OS/2 LAN Server. Версия OS/2 Warp Connect работает с протоколами IPX и NetBIOS, а также с новой реализацией протоколов TCP/IP. Этот новый комплект устанавливает двухточечное соединение по протоколу PPP вместо соединений SLIP, предусмотренных в базовом пакете OS/2 Warp. Этот комплект понизит нагрузку на центральный процессор и обеспечит одновременный доступ к локальной сети и сети Internet.

Кроме того, Warp Connect предоставляет давно ожидаемые в OS/2 средства одноранговой сетевой связи. Согласно сообщению фирмы IBM, в эту версию входит большое число собственных драйвером, которые смогут работать более чем с 70% существующих адаптеров Ethernet и более чем с 90% адаптеров Token Ring. То же самое программное обеспечение дает возможность клиенту Warp Connect подключаться в серверу LAN Server 4.0.

Warp Connect содержит также программу Lan Distance фирмы IBM, которая позволит соединяться через связной сервер с любым подключенным к сети устройством. В отличие от Windows 95 ОС Warp Connect не содержит средств, поддерживающих удаленный доступ через коммутируемые телефонные сети. Еще одним нововведением является справочная база данных ASK PSP на компакт-диске с интерфейсом запросов на языке, близком к естественному английскому.

Что касается почтовых услуг, то IBM выбрала для Warp Connect пакет Lotus Notes Express, а не свой собственный Ultimedia Mail/2. Notes Express позволяет соединиться с любым сервером Notes.

Как и другие версии Warp, Warp Connect тоже будет поставляться в двух версиях: одна без Windows-библиотек, другая, подобно Full Pack, с библиотеками Win-OS/2.

---

---