Взаимодействие между процессами

Операционная система UNIX в полной мере отвечает требованиям технологии «клиент-сервер». Эта универсальная модель служит основой построения любых сколь угодно сложных систем, в том числе и сетевых. Разработчики СУБД, коммуникационных систем, систем электронной почты, банковских систем и т. д. во всем мире широко используют технологию «клиент-сервер». Для построения программных систем, работающих по принципам модели «клиент-сервер», в UNIX существуют следующие механизмы:

· сигналы;

· семафоры;

· программные каналы;

· очереди сообщений;

· сегменты разделяемой памяти;

· вызовы удаленных процедур.

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

Сигналы

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

· обработка исключительных ситуаций;

· средства обработки внешних и внутренних прерываний;

· средства управления системой прерываний (маскирование и демаскирование).

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

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

Семафоры

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

· значения семафора;

· идентификатора процесса, который хронологически последним работал с семафором;

· числа процессов, ожидающих увеличения значения семафора;

· числа процессов, ожидающих нулевого значения семафора.

Для работы с семафорами имеются следующие три системных вызова:

· semget — создание и получение доступа к набору семафоров;

· semop — манипулирование значениями семафоров (именно этот системный вызов позволяет с помощью семафоров организовать синхронизацию процессов);

· semctl — выполнение разнообразных управляющих операций над набором семафоров.

Системный вызов semget имеет следующий синтаксис:

id = semget(key, count, flag);

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

Основным системным вызовом для манипулирования семафором является semop:

oldval = semopdd. oplist, count);

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

· номер семафора в указанном наборе семафоров;

· операция;

· флаги.

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

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

· Если значение поля операции равно нулю и значение семафора также равно нулю, выбирается следующий элемент массива oplist. Если же значение поля операции равно нулю, а значение семафора отлично от нуля, то ядро увеличивает на единицу число процессов, ожидающих нулевого значения семафора, причем обратившийся процесс переводится в состояние ожидания (засыпает — в терминологии UNIX).

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

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

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

Системный вызов semctl имеет следующий формат:

semctKid. number, and arg);

Здесь id — это дескриптор группы семафоров, number — номер семафора в группе, cmd — код операции, arg — указатель на структуру, содержимое которой интерпретируется по-разному в зависимости от операции. В частности, с помощью вызова semctl можно уничтожить индивидуальный семафор в указанной группе. Однако Детали этого системного вызова настолько громоздки, что лучше рекомендовать в случае необходимости обращаться к технической документации используемого варианта операционной системы.

Программные каналы

Программные каналы (pipes) в системе UNIX являются очень важным средством взаимодействия и синхронизации процессов. Теоретически программный канал позволяет взаимодействовать любому числу процессов, обеспечивая дисциплину FIFO (First In First Out — первый пришедший первым и выбывает). Другими словами, процесс, читающий из программного канала, прочитает те данные, которые были записаны в программный канал раньше других. В традиционной реализации программных каналов для хранения данных использовались файлы. В современных версиях операционных систем семейства UNIX для реализации программных каналов применяются другие средства взаимодействия между процессами (в частности, очереди сообщений).

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

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

Системный вызов pipe имеет следующий синтаксис:

pipe(fdptr);

Здесь fdptr — это указатель на массив из двух целых чисел, в который после создания неименованного программного канала будут помещены дескрипторы, предназначенные для чтения из программного канала (с помощью системного вызова read) и записи в программный канал (с помощью системного вызова write). Дескрипторы неименованного программного канала — это обычные дескрипторы файлов, то есть такому программному каналу соответствуют два элемента таблицы открытых файлов процесса. Поэтому при последующих системных вызовах read и write процесс совершенно не обязан отличать случай использования программных каналов от случая использования обычных файлов (собственно, на этом и основана идея перенаправления ввода-вывода и организации конвейеров). Для создания именованных программных каналов (или получения доступа к уже существующим каналам) используется обычный системный вызов open. Основным отличием от случая открытия обычного файла является то, что если именованный программный канал открывается для записи и ни один процесс не открыл тот же программный канал для чтения, то обращающийся процесс блокируется до тех пор, пока некоторый процесс не откроет данный программный канал для чтения. Аналогично обрабатывается открытие для чтения.

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

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

Очереди сообщений

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

· msgget — образование новой очереди сообщений или получение дескриптора существующей очереди;

· msgsnd — отправка сообщения (точнее, его постановка в указанную очередь сообщений);

· msgrcv — прием сообщения (точнее, выборка сообщения из очереди сообщений);

· msgctl — выполнение ряда управляющих действий.

Ядро хранит сообщения в виде связного списка (очереди), а дескриптор очереди сообщений является индексом в массиве заголовков очередей сообщений.

Системный вызов msgget имеет следующий синтаксис:

msgqid = msgget(key. flag):

Здесь параметры key и flag имеют то же значение, что и в вызове semget при запросе семафора.

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

Для отправки сообщения используется системный вызов msgsnd:

msgsnd(msgqid, msg , count, flag):

Здесь msg — указатель на структуру, содержащую определяемый пользователем целочисленный тип сообщения и символьный массив (собственно сообщение); count — размер сообщения в байтах; flag — значение, которое определяет действия ядра при выходе за пределы допустимых размеров внутренней буферной памяти. Для приема сообщения используется системный вызов msgrcv:

count » msgrcvdd, msg. maxcount, type, flag);

Здесь msg — указатель на структуру данных в адресном пространстве пользователя, предназначенную для размещения принятого сообщения;maxcount — размер области данных (массива байтов) в структуре msg; type — тип сообщения, которое требуется принять; flag — значение, которое указывает ядру, что следует предпринять, если в указанной очереди сообщений отсутствует сообщение с указанным типом. Возвращаемое значение системного вызова задает реальное число байтов, переданных пользователю.

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

msgctl(id. cmd, mstatbuf);

Разделяемая память

Для работы с разделяемой памятью используются четыре системных вызова:

· shmget — создает новый сегмент разделяемой памяти или находит существующий сегмент с тем же ключом;

· shmat — подключает сегмент с указанным дескриптором к виртуальной памяти обращающегося процесса;

· shmdt — отключает от виртуальной памяти ранее подключенный к ней сегмент с указанным виртуальным адресом начала;

· shmctl — служит для управления разнообразными параметрами, связанными с существующим сегментом.

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

Синтаксис системного вызова shmget выглядит следующим образом:

shmid = shmget(key, size, flag):

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

Подключение сегмента к виртуальной памяти выполняется путем обращения к системному вызову shmat:

virtaddr = shmatdd, addr. flags):

Здесь id — ранее полученный дескриптор сегмента; addr — требуемый процессу виртуальный адрес, который должен соответствовать началу сегмента в виртуальной памяти. Значением системного вызова является реальный виртуальный адрес начала сегмента (его значение не обязательно совпадает со значением параметра addr). Если значением addr является нуль, ядро выбирает подходящий виртуальный адрес начала сегмента.

Для отключения сегмента от виртуальной памяти используется системный вызов shmdt:

shmdt(addr);

Здесь addr — виртуальный адрес начала сегмента в виртуальной памяти, ранее полученный с помощью системного вызова shmat. При этом система гарантирует (опираясь на данные таблицы сегментов процесса), что указанный виртуальный адрес действительно является адресом начала разделяемого сегмента в виртуальной памяти данного процесса.

Для управления памятью служит системный вызов shmctl:

shmctKid, cmd, shsstatbuf):

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

Вызовы удаленных процедур

Во многих случаях взаимодействие процессов соответствует отношениям клиент-сервер. Один из процессов (клиент) запрашивает у другого процесса (сервера) некоторую услугу (сервис) и не продолжает свое выполнение до тех пор, пока эта услуга не будет выполнена (то есть пока процесс-клиент не получит соответствующие результаты). Видно, что семантически такой режим взаимодействия эквивалентен вызову процедуры. Отсюда и соответствующее название — вызов удаленной процедуры (Remote Procedure Call, RPC). Другими словами, процесс обращается к процедуре, которая не принадлежит данному процессу. Она может находиться даже на другом компьютере. Операционная система UNIX по своей «идеологии» идеально подходит для того, чтобы быть сетевой операционной системой, на основе которой можно создавать распределенные системы и организовывать распределенные вычисления. Свойства переносимости позволяют создавать «операционно-однородные» сети, включающие разнородные компьютеры. Однако остается проблема разного представления данных в компьютерах разной архитектуры. Поэтому одной из основных идей RPC является автоматическое обеспечение преобразования форматов данных при взаимодействии процессов, выполняющихся на разнородных компьютерах.

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

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

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

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

Операционная система Linux

Linux — это современная UNIX -подобная операционная система для персональных компьютеров и рабочих станций, удовлетворяющая стандартуPOSIX.

Как известно, Linux — это свободно распространяемая версия UNIX -систем, которая первоначально разрабатывалась Линусом Торвальдсом(torvalds@kruuna.helsinki.fi ) в университете Хельсинки (Финляндия). Он предложил разрабатывать ее совместно и выдвинул условие, согласно которому исходные коды являются открытыми, любой может их использовать и изменять, но при этом обязан оставить открытым и свой код, внесенный в тот или иной модуль системы. Все компоненты системы, включая исходные тексты, распространяются с лицензией на свободное копирование и установку для неограниченного числа пользователей.

Таким образом, система Linux была создана с помощью многих программистов и энтузиастов UNIX -систем, общающихся между собой через Интернет. К данному проекту добровольно подключились те, кто имеет достаточно навыков и способностей развивать систему. Большинство программLinux разработаны в рамках проекта GNU из Free Software Foundation (Кембридж, штат Массачусетс). Но в него внесли свою лепту и многие программисты со всего мира.

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

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

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

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

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

Система Linux достаточно хорошо совместима с рядом стандартов для UNIX (насколько можно говорить о стандартизации UNIX) на уровне исходных текстов, включая IEEE POSIX.l, System V и BSD. Она и создавалась с расчетом на такую совместимость. Большинство свободно распространяемых через Интернет программ для UNIX может быть откомпилировано для Linux практически без особых изменений. Кроме того, все исходные тексты для Linux,включая ядро, драйверы устройств, библиотеки, пользовательские программы и инструментальные средства распространяются свободно. Другие специфические внутренние черты Linux включают контроль работ по стандарту POSIX (используемый оболочками, такими как csh и bash),псевдотерминалы (pty), поддержку национальных и стандартных раскладок клавиатур динамически загружаемыми драйверами клавиатур. Linuxподдерживает различные типы файловых систем для хранения данных. Некоторые файловые системы, такие как EXT2FS, были созданы специально дляLinux. Поддерживаются также другие типы файловых систем, например Minix- 1 и Xenix. Кроме того, реализована система управления файлами на основеFAT, позволяющая непосредственно обращаться к файлам, находящимся в разделах с этой файловой системой. Поддерживается также файловая системаISO 9660 CD-ROM для работы с дисками CD-ROM. Имеются системы управления файлами и на томах с HPFS и NTFS, правда, они работают только на чтение файлов. Созданы варианты системы управления файлами и для доступа к FAT32; эта файловая система в операционной системе Linux называетсяVFAT.

Linux, как и все UNIX -системы, поддерживает полный набор протоколов стека TCP/IP для сетевой работы. Программное обеспечение для работы в Интернет/интранет включает драйверы устройств для многих популярных сетевых адаптеров технологии Ethernet, протоколы SLIP (Serial Line Internet Protocol), PLIP (Parallel Line Internet Protocol), PPP (Point-to-Point Protocol), NFS (Network File System) и пр. Поддерживается весь спектр клиентов и услуг TCP/IP, таких как FTP, telnet, NNTP и SMTP.

Ядро Linux сразу было создано с учетом возможностей защищенного режима 32-разрядных процессоров 80386 и 80486 фирмы Intel. В частности, вLinux используется парадигма описания памяти в защищенном режиме и другие новые свойства процессоров с архитектурой ia32. Для защиты пользовательских программ друг от друга и операционной системы от них Linux работает исключительно в защищенном режиме, реализованном в процессорах фирмы Intel. В защищенном режиме только программный код, исполняющийся в нулевом кольце защиты, имеет непосредственный доступ к аппаратным ресурсам компьютера — памяти и устройствам ввода-вывода. Пользовательские и системные обрабатывающие программы работают в третьем кольце защиты. Они обращаются к аппаратным ресурсам компьютера исключительно через системные подпрограммы, функционирующие в нулевом кольце защиты. Таким образом, пользовательским программам предоставляются только те услуги, которые реализованы разработчиками операционной системы. При этом системные подпрограммы обеспечивают выполнение только тех функций, которые безопасны с точки зрения операционной системы.

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

В отличие от старых версий UNIX, в которых задачи выгружались во внешнюю память на магнитных дисках целиком, ядро Linux использует аппаратную поддержку процессорами страничного механизма организации виртуальной памяти. Поэтому в Linux замещаются отдельные страницы. То есть с диска в память загружаются те виртуальные страницы образа, которые сейчас реально требуются, а неиспользуемые страницы выгружаются на диск в файл подкачки. Возможно разделение страниц кода, то есть использование одной страницы, физически уже один раз загруженной в память, несколькими процессами. Другими словами, реентерабельность кода, присущая всем UNIX -системам, осталась. В настоящее время имеются ядра для этой системы, оптимизированные для работы с процессорами Intel и AMU последнего поколения, хотя основные архитектурные особенности защищенного режима работы изменились мало. Уже разработаны ядра для работы с 64-разрядными процессорами от Intel и AMD.

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

Исполняемые программы задействуют динамически связываемые библиотеки (Dynamic Link Library, DLL), то есть эти программы могут совместно использовать библиотеку, представленную одним физическим файлом на диске. Это позволяет занимать меньше места на диске исполняемым файлам, особенно тем, которые многократно вызывают библиотечные функции. Есть также статические связываемые библиотеки для тех, кто желает пользоваться отладкой на уровне объектных кодов или иметь «полные» исполняемые программы, не нуждающиеся в разделяемых библиотеках. В Linuxразделяемые библиотеки динамически связываются во время выполнения, позволяя программисту заменять библиотечные модули своими собственными.

Операционная система FreeBSD

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

В противоположность Linux операционная система FreeBSD имеет такого координатора — это университет в Беркли, Калифорния. Любой может изучить тексты кодов этой операционной системы и предложить внести в нее свои изменения, но это не означает, что так и будет сделано, даже если изменения разумны. Только координирующая группа BSD имеет на это право.

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

 

ТЕМА 2. СЕТЕВАЯ ОПЕРАЦИОННАЯ СИСТЕМА РЕАЛЬНОГО ВРЕМЕНИ QNX

Вспомним основные принципы, обязательная реализация которых позволяет создавать операционные системы реального времени (ОСРВ). Первым обязательным требованием к архитектуре операционной системы реального времени является многозадачность в истинном смысле этого слова. Очевидно, что варианты с псевдомногозадачностью (а точнее, с невытесняющей многозадачностью) в системах Windows 3.Xили Novell NetWare неприемлемы, поскольку они допускают возможность блокировки или даже полного развала системы одним неправильно работающим процессом. Для предотвращения блокировок вычислений ОСРВ должна использовать квантование времени (то есть использовать вытесняющую, а не кооперативную многозадачность), что сделать достаточно просто. Вторая проблема — организация надежных вычислений — может быть эффективно решена за счет специальных аппаратных возможностей процессора. При построении системы для работы на персональных компьютерах типа IBM PC для этого необходимы процессоры типа Intel 80386 и выше, чтобы иметь возможность организовать функционирование операционной системы в защищенном (32-разрядном) режиме работы процессора. Для эффективного обслуживания прерываний операционная система должна использовать алгоритм диспетчеризации, обеспечивающийвытесняющее планирование, основанное на приоритетах. Наконец, крайне желательна эффективная поддержка сетевых коммуникаций и наличие развитых механизмов взаимодействия между процессами, поскольку реальные технологические системы обычно управляются целым комплексом компьютеров и/или контроллеров. Весьма желательно также, чтобы операционная система поддерживала многопоточность (не только мультипрограммный, но и мультизадачный режимы) и симметричную мультипроцессорность. И наконец, при соблюдении всех перечисленных условий операционная система должна быть способна работать на ограниченных аппаратных ресурсах, поскольку одна из ее основных областей применения — встроенные системы. К сожалению, данное условие обычно реализуется путем простого урезания стандартных сервисных средств.

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

Основным языком программирования в системе является С. Основная операционная среда соответствует стандарту POSIX. Это позволяет с небольшими доработками переносить ранее разработанное программное обеспечение в QNX для организации их работы в среде распределенной обработки.

Операционная система QNX, будучи сетевой и мультизадачной, в то же время является многопользовательской (многотерминальной). Кроме того, она масштабируема. С точки зрения пользовательского интерфейса и интерфейса прикладного программирования она очень похожа на UNIX, поскольку выполняет требования стандарта POSIX. Однако QNX — это не версия UNIX, хотя почему-то многие так считают. Система QNX была разработана, что называется, «с нуля» канадской фирмой QNX Software Systems Limited в 1989 году по заказу Министерства обороны США, причем на совершенно иных архитектурных принципах, нежели использовались при создании операционной системы UNIX.

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

 Предсказуемость означает применимость системы к задачам жесткого реального времени. QNX является операционной системой, которая дает полную гарантию того, что процесс с наивысшим приоритетом начнет выполняться практически немедленно, и критически важное событие (например, сигнал тревоги) никогда не будет потеряно. Ни одна версия UNIX не может достичь подобного качества, поскольку нереентерабельный код ядра слишком велик. Любой системный вызов из обработчика прерывания в UNIX может привести к непредсказуемой задержке (то же самое можно сказать про Windows NT).

 Масштабируемость и эффективность достигаются оптимальным использованием ресурсов и означают применимость QNX для встроенных(embedded) систем. В данном случае мы не увидим в каталоге /dev множества файлов, соответствующих ненужным драйверам, что характерно для UNIX -систем. Драйверы и менеджеры можно запускать и удалять (кроме файловой системы, что очевидно) динамически, просто из командной строки. Мы можем иметь только те услуги, которые нам реально нужны, причем это не требует серьезных усилий и не порождает проблем.

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

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

 Компактная графическая подсистема Photon, построенная на тех же принципах модульности, что и сама операционная система, позволяет получить полнофункциональный интерфейс GUI (расширенный интерфейс Motif), работающий вместе с POSIX -совместимой операционной системой всего в 4 Мбайт памяти, начиная с i80386 процессора.

Архитектура системы QNX

Итак, QNX — это операционная система реального времени для персональных компьютеров, позволяющая эффективно организовать распределенные вычисления. В системе реализована концепция связи между задачами на основе сообщений, посылаемых от одной задачи к другой, причем задачи эти могут решаться как на одном и том же компьютере, так и на разных, но связанных между собой локальной вычислительной сетью. Реальное время и концепция связи между процессами посредством сообщений оказывают решающее влияние и на разрабатываемое для операционной системы QNX программное обеспечение, и на программиста, стремящегося с максимальной выгодой использовать преимущества системы. Микроядро операционной системы QNX имеет объем всего в несколько десятков килобайтов (в одной из версий — 10 Кбайт, в другой — менее 32 Кбайт, хотя есть вариант и на 46 Кбайт), то есть это одно из самых маленьких ядер среди всех существующих операционных систем. В этом объеме помещаются:

 механизм передачи сообщений между процессами IPC (Inter Process Communication — взаимодействие между процессами);

 редиректор (redirector) прерываний;

 блок планирования выполнения задач (иначе говоря, диспетчер задач);

 сетевой интерфейс для перенаправления сообщений (менеджер Net).

Механизм IPC обеспечивает пересылку сообщений между процессами и является одной из важнейших частей операционной системы, так как все взаимодействие между процессами, в том числе и системными, происходит через сообщения. Сообщение в операционной системе QNX — это последовательность байтов произвольной длины (0-65 535 байт) произвольного формата. Протокол обмена сообщениями может выглядеть, например, таким образом. Задача блокируется для ожидания сообщения. Другая задача посылает первой сообщение и при этом блокируется сама, ожидая ответа. Первая задача деблокируется, обрабатывает сообщение и отвечает, деблокируя вторую задачу.

Сообщения и ответы, пересылаемые между процессами при их взаимодействии, находятся в теле отправляющего их процесса до того момента, когда они могут быть приняты. Это означает, что, с одной стороны, снижается вероятность повреждения сообщения в процессе передачи, а с другой — уменьшается объем оперативной памяти, необходимый для работы ядра. Кроме того, становится меньше пересылок из памяти в память, что разгружает процессор. Особенностью процесса передачи сообщений является то, что в сети, состоящей из нескольких компьютеров, работающих под управлениемQNX, сообщения могут прозрачно передаваться процессам, выполняющимся на любом из узлов. Определены в QNX еще и два дополнительных метода передачи сообщений — метод представителей (proxy) и метод сигналов (signal).

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

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

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

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

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

К выполнению своих функций как диспетчера ядро приступает в следующих случаях:

 какой-либо процесс вышел из блокированного состояния;

 истек квант времени для процесса, владеющего центральным процессором;

 работающий процесс прерван каким-либо событием.

Диспетчер выбирает процесс для запуска среди неблокированных процессов в порядке значений их приоритетов в диапазоне от 0 (наименьший) до 31 (наибольший). Обслуживание каждого из процессов зависит от метода его диспетчеризации (приоритет и метод диспетчеризации могут динамически меняться во время работы). В QNX существуют три метода диспетчеризации:

 очередь (First In First Out, FIFO) — раньше пришедший процесс раньше обслуживается;

 карусель (Round Robin, RR) — процессу выделяется определенный квант времени для работы, после чего процессор предоставляется следующему процессу;

 адаптивный метод (используется чаще других).

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

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

Процесс, работающий в соответствии с адаптивным методом, ведет себя следующим образом:

 если процесс полностью использует выделенный ему квант времени, а в системе есть готовые к исполнению процессы с тем же уровнем приоритета, его приоритет снижается на 1;

 если процесс с пониженным приоритетом остается необслуженным в течение секунды, его приоритет увеличивается на 1;

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

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

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

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

Основные механизмы организации распределенных вычислений

QNX является сетевой операционной системой, которая позволяет организовать эффективные распределенные вычисления. Для этого на каждой машине, называемой узлом, помимо ядра и менеджера процессов должен быть запущен уже упомянутый ранее менеджер Net. Менеджер Net не зависит от аппаратной реализации сети. Эта аппаратная независимость обеспечивается за счет сетевых драйверов. В операционной системе QNX имеются драйверы для сетей с различными технологиями: Ethernet и FastEthernet, Arcnet, IBM Token Ring и др. Кроме того, имеется возможность организации сети через последовательный канал или модем.

В QNX версии 4 полностью реализовано встроенное сетевое взаимодействие типа «точка-точка». Например, сидя за машиной А, вы можете скопировать файл с гибкого диска, подключенного к машине В, на жесткий диск, подключенный к машине С. По существу, сеть из машин с операционными системами QNX действует как один мощный компьютер. Любые ресурсы (модемы, диски, принтеры) могут быть добавлены к системе простым их подключением к любой машине в сети. QNX обеспечивает возможность одновременной работы в сетях Ethernet, Arcnet, Serial и Token Ring, более одного пути для связи и балансировку нагрузки в сетях. Если кабель или сетевая плата выходит из строя и связь через эту сеть прекращается, система автоматически перенаправит данные через другую сеть. Все это происходит в режиме подключения (on-line), предоставляя пользователю автоматическую сетевую избыточность и увеличивая эффективность взаимодействия во всей системе.

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

Сетевое взаимодействие является узким местом в большинстве операционных систем и обычно создает значительные проблемы для систем реального времени. Для того чтобы обойти это препятствие, разработчики операционной системы QNX создали собственную специальную сетевую технологию FLEET и соответствующий протокол транспортного уровня FTL (FLEET Transport Layer). Этот протокол не базируется ни на одном из распространенных сетевых протоколов вроде IPX или NetBios и обладает рядом качеств, которые делают его уникальным. Основные его качества зашифрованы в аббревиатуре FLEET, которая расшифровывается следующим образом:

 Fault-Tolerant Networking — QNX может одновременно использовать несколько физических сетей, при выходе из строя любой из них данные будут «на лету» перенаправлены через другую сеть;

 Load-Balancing on the Fly — при наличии нескольких физических соединении QNX автоматически распараллеливает передачу пакетов по соответствующим сетям;

 Efficient Performance — специальные драйверы, разрабатываемые фирмой QSSL для широкого спектра оборудования, позволяют использовать это оборудование с максимальной эффективностью;

 Extensable Architecture — любые новые типы сетей могут быть поддержаны путем добавления соответствующих драйверов;

 Transparent Distributed Processing — благодаря отсутствию разницы между передачей сообщений в пределах одного узла и между узлами нет необходимости вносить какие-либо изменения в приложения, для того чтобы они могли взаимодействовать через сеть.

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

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

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

Когда ядро получает запрос на передачу данных процессу, находящемуся на удаленном узле, он переадресовывает этот запрос менеджеру Net, в подчинении которого находятся драйверы всех сетевых карт. Имея перед собой полную картину состояния всего сетевого оборудования, Net может отслеживать состояние каждой сети и динамически перераспределять нагрузку между ними. В случае, когда одна из сетей выходит из строя, поток данных автоматически перенаправляется в другую доступную сеть, что очень важно при построении высоконадежных систем. Кроме поддержки собственного протокола, Net обеспечивает передачу пакетов TCP/IP, SMB (Server Message Block) и многих других, используя то же сетевое оборудование. При этом производительность компьютеров с операционной системой QNX в сети приближается к производительности аппаратного обеспечения — настолько малы задержки, вносимые операционной системой.

При проектировании системы реального времени, как правило, необходимо обеспечить одновременное выполнение нескольких приложений. ВQNX/Neutrino параллельность выполнения достигается за счет использования потоковой модели POSIX, в которой процессы в системе представляются в виде совокупности потоков выполнения. Поток является минимальной единицей выполнения и диспетчеризации для ядра Neutrino; процесс определяет адресное пространство для потоков. Каждый процесс состоит минимум из одного потока. Операционная система QNX предоставляет богатый набор функций для синхронизации потоков. В отличие от потоков, само ядро не подлежит диспетчеризации. Код ядра исполняется только в том случае, когда какой-нибудь поток вызывает функцию ядра, или при обработке аппаратного прерывания.

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

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

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

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

Кроме того, операционная система QNX обеспечивает объединение сообщений в структуру данных, называемую очередью. Очередь сообщений — это просто область данных в третьей, отдельной задаче, которая временно принимает передаваемое сообщение и немедленно отвечает передатчику. В отличие от стандартной передачи сообщений, передатчик немедленно освобождается для того, чтобы продолжить свою работу. Задача администратора очереди — хранить в себе сообщение до тех пор, пока приемник не будет готов прочитать его; делает он это, запрашивая сообщение у администратора очереди. Любое количество сообщений (ограничено только возможностью памяти) может храниться в очереди. Сообщения хранятся и передаются в том порядке, в котором они были приняты. Может быть создано любое количество очередей. Каждая очередь идентифицируется своим именем.

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

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

С портом может быть выполнено три операции:

 присоединить порт,

 отсоединить порт,

 послать сигнал в порт.

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

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

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

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

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

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

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

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

 

ТЕМА 3. СЕМЕЙСТВО ОПЕРАЦИОННЫХСИСТЕМ OS/2 WARP КОМПАНИИ IBM

История появления, расцвета и практического ухода со сцены операционных систем под общим названием OS/2 и странна, и поучительна. Будучи одной из самых лучших операционных систем для персональных компьютеров по очень большому числу параметров и появившись существенно раньше систем своих основных конкурентов, она тем не менее не смогла стать самой распространенной, хотя могла бы, и с легкостью. Основная причина тому — законы бизнеса (умение рекламировать свой товар, всячески поддерживать его продвижение, вкладывать деньги в завоевание рынка), а не качество самой операционной системы. Во-первых, компания IBM не сочла необходимым продвигать свою операционную систему на рынок программного обеспечения, ориентированного на конечного пользователя, а решила продолжить свою практику работы исключительно с корпоративными клиентами. А этот рынок (корпоративного программного обеспечения) оказался существенно уже для персональных компьютеров, чем рынок программного обеспечения для конечного пользователя, ибо компьютеры типа IBM PC прежде всего являются персональными. Во-вторых, основные доходы компания IBM получала не от продажи системного программного обеспечения для персональных компьютеров, а за счет продаж дорогостоящих серверов и другого оборудования. Доходы от продажи операционной системы OS/2 не представлялись руководству компании IBM значимыми. Чтобы добиться успеха на рынке операционных систем для персональных компьютеров, необходимо было обеспечить всестороннюю поддержку своей системы соответствующей учебной литературой, широкой рекламой, заинтересовать разработчиков программного обеспечения. Увы, этого сделано не было, и сегодня уже практически мало кто знает о системах семейства OS/2. В то же время следует отметить, что те организации и предприятия, которые в свое время освоили эту систему и создали для нее соответствующее прикладное программное обеспечение, до сих пор не переходят на ныне чрезвычайно популярные операционные системы Windows NT/2000/XP, поскольку последние требуют существенно больше системных ресурсов. Любопытный факт: всем известные банкоматы работают под управлением OS/2.

Семейство 32-разрядных операционных систем OS/2 для IBM -совместимых персональных компьютеров начало свою историю с появления первой OS/2 v 2.0 в 1992 году. Ей предшествовала 16-разрядная операционная система с таким же названием — OS/2, которая была разработана для микропроцессора i80286. Этот микропроцессор, несмотря на множество принципиальных новаций, оказался неудачным. Защищенный режим работы этого 16-разрядного микропроцессора был несовершенным. Он обеспечивал работу с относительно небольшим объемом оперативной памяти, имел слабую аппаратную поддержку для организации виртуальной памяти, слишком низкое быстродействие (для того, чтобы выступать в качестве основы для построения мультизадачных операционных систем). Неудачная судьба 16-разрядной системы OS/2 1.x во многом повлияла и на 32-разрядную операционную систему, хотя по очень многим позициям архитектура 32-разрядной версии операционной системы OS/2 принципиально отличалась от своей предшественницы. Компания IBM оставила этот проект, когда его версия имела номер 4.5. Сейчас из состава IBM отделилась небольшая компания, которая, выкупив проект OS/2, продолжает над ним работу и обеспечивает приверженцев этой операционной системы пакетами обновления и всевозможными добавлениями.

Все последние версии операционной системы OS/2 в своем названии имеют слово Warp, что переводится с английского как «основа». Операционная система OS/2 Warp 4.0 практически представляет собой OS/2 Warp 3.0 (вышедшую еще в 1994 году) с несколько улучшенной поддержкой DOS -задач и обновленными элементами объектно-ориентированного интерфейса. Для этой системы характерны:

 вытесняющая многозадачность (preemptive multitasking) и поддержка DOS- и Windows- (Win32s) приложений;

 по-настоящему интуитивно понятный и действительно удобный объектный пользовательский интерфейс;

 поддержка стандарта открытого объектного документооборота OpenDoc;

 поддержка стандарта OpenGL;

 поддержка Java -апплетов и встроенных средств разработки на языке Java;

 поддержка шрифтов True Type (TTF);

 управление голосом без предварительной подготовки (технология Voice Type);

 полная поддержка сетевых технологий Интернет/интранет, доступ в сети CompuServe;

 средства построения одноранговых сетей и клиентские части для сетевых операционных систем IBM LAN Server, Windows, Lantastic, Novell Netware4.1 (в том числе поддержка службы каталогов);

 система удаленного доступа через модемные соединения;

 файловая система Mobile File System для поддержки мобильных пользователей;

 стандарт автоматического распознавания аппаратных устройств (Plug-and-Play), но без столь навязчивого механизма, который реализован вWindows;

 набор офисных приложений (базы данных^, электронные таблицы, текстовый процессор, генератор отчетов, деловая графика, встроенная система приема-передачи факсимильных сообщений, информационный менеджер);

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

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

Операционная система OS/2 Warp предлагает единый интерфейс прикладного программирования (API), совместимый с рядом операционных систем, что позволяет снизить стоимость разработок. Все версии операционных систем OS/2 и LAN Server, включая текущие версии OS/2 Warp и OS/2 Warp Server4.5, совместимы по восходящей линии, что позволяет экономить средства, необходимые для поддержания уже существующих прикладных программ.

Чрезвычайно важным для пользователей является тот факт, что компания IBM для всех версий своей операционной системы регулярно выпускает пакеты обновления (FixPak). Эти пакеты исправляют обнаруженные ошибки, а также вносят новые функции. Для пользователей такая практика сопровождения фирмой своей операционной системы, безусловно, более выгодна, нежели практика частого выпуска новых версий операционных систем (ей следует компания Microsoft).

Так, например, для одной из своих самых удачных операционных систем — Windows NT 4.0 — компания Microsoft выпустила всего 6 пакетов обновления (ServicePak), тогда как для уже совсем старой операционной системы OS/2 Warp 3.0, которая вышла в свет в 1994 году, компания IBMвыпустила уже несколько десятков пакетов FixPak. Для операционной системы OS/2 Warp 4.0 вышло более 15 пакетов исправлений и обновлений.

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

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

Весьма полезным, как для управления приложениями, так и для создания несложных собственных программ, является наличие системы программирования на языке высокого уровня REXX, который иногда называют языком процедур. Можно сказать, что это встроенный командный язык, который служит для тех же целей, что и язык для пакетных (batch) файлов в среде DOS, но он обладает несравнимо большими возможностями. Это язык высокого уровня с нетипизированными переменными. Язык легко расширяем, любая программа OS/2 может добавлять в него новые функции. Помимо встроенного интерпретатора с языка REXX имеется система программирования Visual REXX. Имеется и объектно-ориентированная версия языка REXX с соответствующим интерпретатором.

Наиболее сильное впечатление при работе в операционной системе OS/2 оставляет объектно-ориентированный графический пользовательский интерфейс, а особой популярностью у программистов эта система пользовалась вследствие очень хорошей организации VDM -машин и высокого быстродействия при выполнении обычных DOS -приложений.

Особенности архитектуры и основные возможности

Строение и функционирование операционной системы OS/2 можно считать практически идеальными с точки зрения теории и довольно неплохими в реализации. В качестве подтверждения этому можно привести один пример, который представляется очень показательным: OS/2 до сегодняшних дней практически неизменна, начиная с версии 2.0, увидевшей свет в 1992 году. Этот факт говорит о глубокой продуманности архитектуры системы, ведь и по сей день OS/2 является одной из самых мощных и продуктивных операционных систем. Здесь самым показательным примером являются тесты серверов. В одной из вычислительных лабораторий Санкт-Петербургского государственного университета аэрокосмического приборостроения (ГУАП) с 1995 года в течение нескольких лет функции сервера кафедры вычислительных систем и сетей выполняла система OS/2 Warp Advanced Server. При переходе на сервер Windows NT 4.0 пришлось в два раза увеличить объем оперативной памяти и поменять процессор (с Pentium 90 на Pentium II З00), и даже после этого скорость работы обычных приложений на рабочих станциях не достигла той производительности, какую имели пользователи при работе сервера под управлением OS/2. Аналогичные замечания не так давно можно было прочесть и в зарубежных публикациях — однопроцессорная машина под управлением OS/2 Warp Server обгоняет по производительности двухпроцессорную машину под управлением Windows NT.

Разработчики системы OS/2 решили не использовать всех возможностей защищенного режима, заложенных в микропроцессоры i80 x 86. Например, обработка прерываний чаще всего ведется через коммутаторы прерываний, а не через коммутаторы задач. Используется плоская модель памяти. Хорошо продуманная архитектура, в которой задействована модель « клиент-сервер» , и тщательное кодирование позволили получить систему, требующую очень небольших вычислительных ресурсов. Очень удачно реализована диспетчеризация задач. Представление различных системных информационных структур в статической форме (в виде таблиц) привело к более высокому быстродействию.

В OS/2 имеется несколько видов виртуальных машин для выполнения прикладных программ. Собственные 32- и 16-разрядные программы OS/2 выполняются на отдельных виртуальных машинах в режиме вытесняющей многозадачности и могут общаться между собой с помощью средств DDE OS/2. Прикладные программы DOS и Win 16 могут запускаться на отдельных виртуальных машинах в многозадачном режиме. При этом они поддерживают полноценные связи DDE и OLE 2.0 друг с другом, а также связи DDE с 32-разрядными программами OS/2. Кроме того, при желании можно запустить несколько программ Win 16 на общей виртуальной машине Win 16, где они работают в режиме невытесняющей многозадачности, как в Windows 3.x. Конечно, нынче это уже неактуально, поскольку появилось огромное количество приложений, использующих API Win32, но в 90-е годы XX века эти факты имели существенное значение.

Разнообразные сервисные функции API OS/2, в том числе SOM (System Object Model — модель системных объектов), обеспечиваются с помощью системных библиотек DLL, к которым можно обращаться без требующих затрат времени переходов между кольцами защиты. Ядро операционной системы OS/2 предоставляет многие базовые сервисные функции API, обеспечивает поддержку файловой системы, управление памятью, имеет диспетчер аппаратных прерываний. В ядре виртуальных DOS -машин (Virtual DOS Machine, VDM), или в VDM -ядре, осуществляется эмуляция DOS и процессора 8086, а также управление VDM. Драйверы виртуальных устройств обеспечивают уровень аппаратной абстракции. Драйверы физических устройств напрямую взаимодействуют с аппаратурой.

Модуль реализации механизмов виртуальной памяти в ядре OS/2 поддерживает большие постраничные разбросанные адресные пространства, составленные из объектов памяти. Каждый объект памяти управляется так называемым пейджером — задачей вне ядра, обеспечивающей резервное хранение страниц объекта памяти. Адресные пространства управляются путем отображения или размещения объектов памяти внутри них. Ядро управляет защитой памяти и ее распределением на основе объектов памяти абстрактным образом, вне зависимости от каких-либо конкретных аппаратных средств трансляции процессорных адресов. В частности, ядро интенсивно использует режим копирования при записи для придания программам способности делить объекты памяти, не копируя множество страниц, когда новое адресное пространство получает доступ к объекту памяти. Новые копии страниц создаются, только когда программа в одном из адресных пространств обновляет их. Когда ядро принимает страничный сбой в объекте памяти и не имеет страницы памяти в наличии, или когда оно должно удалить страницы из памяти по требованию других работающих программ, ядро с помощью механизмаIPC уведомляет пейджер об объекте памяти, в котором произошел сбой. После этого пейджер сервера приложений определяет, каким образом предоставить или сохранить данные. Это позволяет системе устанавливать различные семантики для объектов памяти, основываясь на потребностях программ, которые их используют.

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

Для поддержки операций ввода-вывода и доступа к внешним устройствам ядро операционной системы OS/2 обеспечивает доступ к ресурсам ввода-вывода, таким как устройства с отображаемой памятью, порты ввода-вывода и каналы прямого доступа к памяти (Direct Memory Access, DMA), а также возможность отображать прерывания на драйверы устройств, исполняемые в пользовательском пространстве. Службы ядра позволяют приоритетным программам получать устройства в свое владение: такими программами обычно являются программы, не связанные с заданиями, вроде серверов драйверов устройств, работающих как приложения. Поскольку ядро обязано обслужить все прерывания (в силу того, что прерывания обычно выдаются в приоритетном состоянии компьютера, а также в целях поддержания целостности системы), оно имеет логику, которая определяет, должно ли оно обрабатывать прерывание или его следует отобразить на сервер. Если прерывание следует отобразить на приложение, это приложение должно быть зарегистрировано в ядре и содержать код, контролирующий отображение прерывания. Сразу после отображения в приложении запускается поток по обработке прерывания.

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

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

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

Особенности интерфейсов

В операционных системах OS/2 Warp в качестве стандартной графической оболочки используется среда Workplace Shell (WPS), организованная логичней и удобней, чем известный Windows -интерфейс. Оболочка Workplace Shell основана на модели системных объектов (SOM) фирмы IBM — мощной технологии, специально разработанной для решения таких проблем, как жесткая привязка объектов к их клиентам и необходимость использования одного и того же языка программирования. Объекты Workplace Shell работают в среде SOM, доступ в которую можно реализовать почти на всех языках программирования, где предусмотрены внешние процедуры, в том числе и на языке REXX.

В отличие от интерфейса GUI в Windows, где ярлыки (shortcuts) объектов никак не связаны между собой, в WPS объекты, имеющие аналогичные ярлыки (shadow в терминологии WPS), просто имеют дополнительное свойство — возможность многократно отображаться почти как самостоятельные объекты. Можно сделать несколько таких ярлыков из уже существующего ярлыка или из объекта. При этом любые ярлыки могут перемещаться в любое место и при этом их связи с основным объектом не теряются. Вроде бы то же самое происходит в GUI, но в WPS можно переместить основной объект, и его ярлыки тут же изменят свои параметры, тогда как в GUI произойдет разрушение связей, поскольку связи являются односторонними.

Про SOM можно сказать, что это не связанная ни с одним конкретным языком объектно-ориентированная технология для создания, хранения и использования двоичных библиотек классов. Ключевые слова здесь «двоичные» и «не связанная ни с одним конкретным языком». Хотя нынче многие считают OS/2 технологией прошлого, модель SOM на самом деле представляет собой одну из наиболее интересных разработок в области компьютерной индустрии даже на сегодняшний день. По существу, некоторые идеи, реализованные в OS/2 в начале 90-х годов прошлого столетия, сейчас только обещают реализовать в новом поколении операционных систем Windows с кодовым названием Whistler. Объектно-ориентированное программирование (ООП) заслужило безоговорочное признание в качестве основной парадигмы, однако его применению в коммерческом программном обеспечении препятствуют отсутствие в языках ООП средств обращения к библиотекам классов, подготовленным на других языках, и необходимость поставлять с библиотеками классов исходные тексты. Многим независимым разработчикам библиотек классов приходится продавать заказчикам исходные тексты, поскольку разные компиляторы по-разному отображают объекты. Настоящий потенциал модели SOM заключается в ее совместимости практически с любой платформой и любым языком программирования. Технология SOM соответствует спецификации CORBA (Common Object Request Broker Architecture— общая архитектура посредника объектных запросов), которая определяет стандарт условий взаимодействия между прикладными программами в неоднородной сети.

Графический интерфейс в системах OS/2 не единственный. Интересно отметить тот факт, что существует довольно много альтернативных оболочек для операционных систем OS/2, начиная с программы FileBar, которая хотя и кажется примитивной, но зато отлично работает на компьютерах с оперативной памятью объемом 4 Мбайт, и кончая мощной системой Object Desktop, которая значительно улучшает внешний вид экрана OS/2 и делает работу более удобной.

Помимо оболочек, улучшающих интерфейс операционной системы OS/2, имеется также ряд программ, расширяющих ее функциональность. В первую очередь, это Xfree86 for OS/2 — полноценная система X- Window, которая может использоваться как графический терминал при работе в сети сUNIX -машинами, а также для запуска программ, перенесенных из UNIX в OS/2. К сожалению, таких программ немного, однако большое количество UNIX -программ поставляется вместе с исходными кодами, которые, как правило, практически не нужно изменять для перекомпиляции под Xfree86/OS2.

Серверная операционная система OS/2 Warp 4.5

Серверная операционная система компании IBM, предназначенная для работы на персональных компьютерах и вышедшая в свет в 1999 году, носит название OS/2 WarpServer for e-Business, что подчеркивает ее основное назначение. Однако в процессе ее создания система носила кодовое название Аврора (Aurora), поэтому все ее так теперь и называют.

Как известно, предыдущие версии системы OS/2 могли предоставить программисту только 512 Мбайт виртуального адресного пространства для «родных» 32-разрядных приложений. В свое время это было очень много. Однако хотя задачи, требующие столь большого объема оперативной памяти, встречаются пока еще редко, некоторые считают ограничение в 512 Мбайт серьезным недостатком. Поэтому в последней версии системы это ограничение снято (напомним, что в операционной системе Windows NT 4.0 объем виртуального адресного пространства для задач пользователя составляет 2 Гбайт), и теперь максимальный объем виртуальной памяти для задачи в операционной системе OS/2 v. 4.5 по умолчанию составляет 2 Гбайт, но командойVIRTUALADDRESSLIMIT=3072 в конфигурационном файле CONFIG.SYS он может быть увеличен до 3 Гбайт.

В операционной системе OS/2 v. 4.5 разработчики постарались все «остатки» старого 16-разрядого кода, который еще частично оставался в предыдущих версиях системы, полностью заменить 32-разрядными реализациями, что повысило быстродействие системы. Прежде всего, обеспечена поддержка 32-раздядных драйверов устанавливаемых файловых систем (IFS), ибо в предыдущих системах работа с ними велась через трансляцию вызовов 32bit — >16bit—>32bit. В то же время для совместимости со старым программным обеспечением помимо 32-раздядного используется и 16-раздядный интерфейс API.

Создана новая файловая система JFS (Journaling File System — файловая система с протоколированием), призванная повысить надежность и живучесть файловой подсистемы по сравнению с файловой системой HPFS386.IFS. Файловая система JFS обеспечивает большую безопасность в структурах данных благодаря технике, разработанной для систем управления базами данных. Работа с JFS происходит в режиме транзакций с ведением журнала транзакций. В случае системных сбоев есть возможность обработки журнала транзакций с целью принятия или отмены изменений, произведенных во время системного сбоя. Эта система управления файлами также повышает скорость восстановления файловой системы после сбоя. Сохраняя целостность файловой системы, она, подобно файловой системе NTFS, не гарантирует восстановление пользовательских данных. Следует отметить, что файловая система JFS обеспечивает самую высокую скорость работы с файлами из всех известных систем, созданных для персональных компьютеров, что очень важно для серверной операционной системы.

Для работы с дисками создан специальный менеджер дисков — LVM (Logical Volume Manager — менеджер логических дисков). LVM хранит информацию обо всех устанавливаемых файловых системах и определяет имена дисков для программ, которые этого требуют. Это позволяет избирательно назначить любую букву любому разделу диска, что в ряде случаев можно считать удобным. И даже больше — теперь операционной системе более не нужно использовать имена дисков. Менеджер логических дисков в совокупности с файловой системой JFS позволяет объединять несколько томов и даже несколько физических дисков в один большой логический том.

 

ТЕМА 4. СРЕДСТВА МОНИТОРИНГА ОПЕРАЦИОННЫХ СИСТЕМ РЕАЛЬНОГО ВРЕМЕНИ

Архитектура средств мониторинга

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

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

Рис. 4. Архитектура отладчика, осуществляющего мониторинг

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

● сбор данных;

● анализ данных;

● профилирование системы;

● « посмертный» анализ.

1) Сбор данных

Существует несколько способов сбора данных на целевой машине и передачи их менеджеру:

● Передавать данные на инструментальную сторону по мере их поступления. Этот способ применяется при оперативной отладке.

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

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

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

● начать сбор данных (указывается способ сбора, буфер или имя файла, период сбора, время между циклами или время завершения);

● прервать сбор данных;

● запланировать начало и/или конец сбора данных по времени, получению сигнала или произошедшему событию.

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

Один из способов протоколирования событий заключается в том, что на функции, исполнение которых приводит к некоторому событию, ставится специального вида точка прерывания (eventpoint). Такой подход позволяет пользователю определять собственные события (как это сделано в WindView — Wind River Systems, целевая система VxWorks).

Теперь рассмотрим технологию сбора данных на примере StethoScope (Wind River Systems, целевая система VxWorks). При сборе данных о функции используется механизм вставки исполняемого кода перед и после вызова отлаживаемой функции. Его суть в том, что пользователь может задать функции, вызовы которых будут предварять и завершать исполнение требуемой процедуры. Этот механизм используется и в служебных целях, например при трассировке задачи. Реализовать его можно так: на первую инструкцию отлаживаемой функции ставится точка прерывания, обрабатываемая особым образом, а именно:

a. ставится точка прерывания на точку возврата из отлаживаемой функции;

b. передается управление функции, которая должна быть вызвана перед отлаживаемой (если такая определена);

c. запускается выполнение отлаживаемой функции.

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

При сборе информации о динамическом выделении памяти можно использовать такой подход (RTILib — Real-Time Innovations, целевая система VxWorks). Заменить функции выделения и освобождения памяти (malloc, calloc, realloc, free) на соответствующие функции, выполняющие, помимо работы с памятью, некоторые отладочные действия, а именно: маркировку границ выделенного блока и последующий контроль за ее сохранностью (так можно фиксировать выход за границы), установку флага доступа к блоку (для запрещения/разрешения обращения к этому блоку), сбор статистики по использованию памяти, протоколирование информации по выделенным блокам.

2) Анализ данных

Нас интересует следующая классификация видов анализа:

● Анализ на инструментальной стороне.

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

● Анализ на целевой стороне.

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

● Распределенный анализ.

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

a. протоколирование переключения контекстов

b. протоколирование состояний задач

c. протоколирование статусов системных объектов.

3) Профилирование системы

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

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

Сбор данных запускается либо специальной высокоприоритетной задачей, либо посредством ISR (Interrupt Service Routine). Существует два уровня профилирования: профилирование задачи способом «процедура за процедурой» (procedure-by-procedure) и профилирование системы способом «задача за задачей» (task-by-task). Основные параметры профилирования: частота выборки (sample rate) — частота, с которой производится сбор данных; частота анализа (analysis rate) — частота, с которой производится анализ имеющихся в буфере выборок. Анализирующая процедура представляет собой низкоприоритетную задачу, которая подсчитывает среднее из значений для задач и функций из всех выборок буфера и значений, полученных в ходе предыдущего анализа.

Цель профилирования задачи — выявить наиболее часто исполняемые блоки для последующей их оптимизации. Для этого служит способ «процедура за процедурой», позволяющий получать информацию о каждой вызываемой в процессе профилирования функции. Эта информация состоит из среднего времени, которое функция выполнялась, с учетом и без учета времени вызова из нее других функций. Также подсчитывается число ее вызовов. В результате анализа стека строится так называемое дерево выполнения (execution tree), показывающее маршрут вызова каждой функции.

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

4) «Посмертный» (post-mortem) анализ

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

Пользовательский интерфейс

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

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

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

Помимо описанных в предыдущей главе команд представления данных у активных отладчиков средства мониторинга могут располагать также такими командами:

 исполнение некоторой последовательности действий при произошедшем событии, поступившем сигнале или наступлении определенного момента времени;

 определение пользователем собственных событий (eventpoints в WindView) и сигналов (комбинации известных сигналов «derived signals» в StethoScope).

 

ТЕМА 5. ОСОБЕННОСТИ ОТЛАДКИ МНОГОПЛАТФОРМЕННЫХ РАСПРЕДЕЛЕННЫХ СИСТЕМ

Особенности архитектуры

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

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

 наличия на каждом компоненте системы агента отладки;

 способности менеджера работать со всеми процессорами системы;

 возможности агентов отладки осуществлять связь между собой и с менеджером.

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

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

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

 Файл описания интерпретируется внутренними средствами менеджера.

В «Panorama : a portable , extensible parallel debugger » описан отладчик Panorama, платформо-зависимые черты, которого вынесены в отдельные файлы: файл описания платформы (агента) и tcl-скрипт, в котором описаны необходимые функции. Таким образом, имея встроенный tcl-интерпретатор, Panorama способен работать с новой платформой без пересборки менеджера. Архитектура этого отладчика приведена на рис. 7.

Рис. 7. Отладчик Panorama

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

Некоторые подходы к отладке распределенных приложений

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

Взаимодействие задач, исполняемых на разных процессорах, можно протоколировать, используя вместо стандартных функции связи, передающие необходимую информацию менеджеру. Чем более полной является эта информация, тем проще менеджеру с ней работать, но тем большее влияние на работу системы оказывает сеанс отладки, в результате чего могут возникать новые динамические ошибки. В «High level tools for the debugging of real-time multiprocessor systems» описана система DARTS (Debug Assistant for Real-Time Systems). С ее помощью можно проводить полноценный сеанс отладки без наличия какой-либо отладочной информации в приложении. Для этого необходимо правильно сопоставить полученный от системы поток событий с исходными текстами приложения. Этот процесс происходит в 2 этапа: разбор исходных текстов и непосредственно само сопоставление.

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

● системные вызовы;

● условные конструкции;

● циклы;

● вызовы функций, описанных в программе;

● библиотечные вызовы.

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

● системные вызовы сравниваются по именам и параметрам;

● условная конструкция считается обнаруженной в протоколе, если присутствует один из вариантов;

● цикл считается найденным, если он присутствует в протоколе 0 и более раз (каждый раз ищется максимальное число его вхождений);

● программные вызовы идентифицируются по вхождению в протокол тела подпрограммы;

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

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

Еще один подход к отладке распределенных приложений предложен в «The Ariadne debugger : scalable application of event -based abstraction ». Описанный там отладчик Ariadne позволяет проверять, произошла ли некоторая заданная для конкретной задачи последовательность событий. Механизм проверки осуществлен следующим образом.Сперва создается граф хода выполнения приложения, построенный на протоколе работы приложения. Затем пользователь задает цепи — последовательности событий, которые будут искаться в графе хода выполнения приложения. Следующим шагом является создание p-цепей — это цепи, для которых указаны конкретные задачи, где ожидается возникновение данной последовательности событий. В итоге формируется шаблон поиска — pt-цепи, которые представляют собой логические композиции p-цепей. Если в графе хода выполнения встречается pt-цепь, то считается, что запрос удовлетворен, и возвращается так называемое абстрактное событие — подграф, содержащий встретившиеся экземпляры событий. Эти экземпляры удаляются из графа хода выполнения, и анализ событий продолжается. Если все pt-цепи присутствуют в графе, то тест считается успешно завершенным. Ввиду асинхронности выполнения ошибка может состоять в том, что нарушен порядок возникновения абстрактных событий. Для локализации таких ошибок в Ariadne реализованы следующие соотношения между абстрактными событиями:

● A предшествует B, если существует зависимость некоторого события из B от некоторого события из A;

● A параллельно B, если события в A и в B независимы;

● A перекрывает B, если существует как зависимость события из A от события из B, так и обратная зависимость.

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

В «Distributed real-time systems. Monitoring, visualization, debugging, and analysis» излагается способ отладки РСРВ посредством моделирования системы сетями Петри с временными ограничениями (timing constraint Petri nets, TCPN). TCPN — это граф ; где P — множество позиций; T — множество переходов; F — множество дуг, соединяющих позиции и переходы; C — множество целочисленных пар (TCmin(pt),TCmax(pt)), где pt может быть и позицией, и переходом; D — множество чисел FIRE(pt), обозначающих время срабатывания pt; и М — множество маркеров.

Говорят, что переход t разрешен, если каждая из входных позиций содержит по крайней мере один маркер. Если к моменту Т0 переход t разрешен, то он может сработать в течении времени от Т0 + ТCmin(t) до T0 + TCmax(t). Переход t сработал успешно, если он продолжался не более FIRE(t) временных единиц, иначе происходит срабатывание других переходов. В случае, когда не срабатывает ни один из переходов, все маркеры остаются на своих местах. Таким образом локализуются ошибки в РСРВ.

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

В «Nondeterminacy : testing and debugging in message passing parallel programs » описан подход к обнаружению недетерминированности в системах, использующих в качестве связи между задачами сообщения. В таких системах недетерминированность может быть вызвана либо задержками сообщений, либо сменой алгоритма планирования. Следует отметить, что в приложении может быть специально заложена некая недетерминированность, поэтому нужно такой случай выделять. Предлагается такая стратегия обнаружения ошибочной недетерминированности:

● для каждого сообщения определяется некоторый идентификатор;

● при получении сообщения идентификатор обрабатывается, и создается некоторая, специфическая для получившей задачи, интерпретация сообщения;

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

Способы представления данных

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

● карта процессоров (процессоры и их соединения, а также текущие сообщения между ними);

● окно отладки (состояния задач, данные, и т.п.);

● окно потока сообщений (все сообщения между процессорами во времени (и время приема, и время получения).

В дополнение к графическому способу можно использовать, например, звуковой, как это описано в «Debugging parallel programs using sound ». Преимущество использования звука при отладке состоит в том, что при большом объеме собранных данных может быть сложно обнаружить ошибку визуально. Например, если в процессе работы затерялось какое-то сообщение от одного процессора к другому, то, анализируя графическое представление взаимодействия процессоров, трудно найти потерянное сообщение, так как оно может быть графически просто не представлено. Однако, если каждое сообщение (от посылки до получения) будет сопровождать некоторый звуковой сигнал, то потерянное сообщение будет сразу обнаруживаться.

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

Модуль 4. ОПЕРАЦИОННЫЕ СИСТЕМЫ WINDOWS

 

ТЕМА 1. ИСТОРИЧЕСКАЯ СПРАВКА

Компания Microsoft в 1990 году объявила о начале работ по созданию принципиально новой операционной системы для персональных IBM PC -совместимых компьютеров с прицелом на корпоративный сектор, которая помимо банальной мультизадачности и поддержки виртуальной памяти обладала бы, в частности, такими качествами, как:

 микроядерная архитектура — сказалось влияние идей проекта Mach 3, выполненного в университете Карнеги Меллон (Carnegie Mellone University),которое в то время было очень велико;

 аппаратная независимость (platform independent), что должно было обеспечить легкую переносимость системы;

 мультипроцессорная обработка и масштабируемость (в то время операционные системы семейства UNIX обеспечивали работу на мультипроцессорных компьютерах и фактически доминировали как мощные корпоративные серверные системы);

 возможность выполнения приложений, созданных для других операционных систем, в частности приложений для UNIX и 16-разрядных программ OS/2;

 защита информации и вычислений от несанкционированного доступа;

 наличие высокопроизводительной и надежной файловой системы и возможность работать с несколькими файловыми системами;

 встроенные сетевые функции и поддержка распределенных вычислений.

Этот проект изначально имел название OS/2 version 3.0, однако впоследствии Microsoft назвала его Windows NT. Аббревиатура NT означала «New Technology», что подчеркивало принципиальную новизну этой операционной системы. Операционная система вышла в 1993 г. в двух вариантах и имела название Windows NT 3.1 и Windows NT Advanced Server 3.1. Эти системы обладали большими возможностями. Однако Windows NT 3.1 в качестве рабочей станции уступала системе OS/2, поскольку требовала существенно больше оперативной памяти и имела относительно низкое быстродействие. Кроме этого, при работе с дисками, отформатированными под файловую систему FAT, она не поддерживала длинные имена. Основным конкурентом серверной системы был сервер Novell Netware 3.x. После выхода первой версии Windows NT Microsoft выпустила Windows NT 3.5 для рабочих станций и одноименную серверную операционную систему. Последняя имела встроенное программное обеспечение для связи с серверами от Novell, поддерживала длинные имена при работе с дисками FAT, и много других усовершенствований. В те годы в качестве серверов для локальных вычислительных сетей преимущественно использовалась операционная система Netware 3.x компании Novell. В последующем эта сетевая операционная система была заменена существенно более мощной Netware 4.x, которая была предназначена для больших корпоративных сетей и имела службу каталогов, предназначенную для централизованного хранения информации о сетевых ресурсах. Она имела продуманные механизмы администрирования и была высокоэффективной. Завершилось поколение операционных систем Windows NT 3.x версиями под номером 5.1. Системы Windows NT 3.x не смогли тогда завоевать признание ни в качестве серверных, ни в качестве обычных настольных систем, поскольку требовали очень больших (по меркам того времени) вычислительных ресурсов.

Как ни странно, но еще одним недостатком этих первых систем Windows NT было строгое следование идеям микроядерной архитектуры. Согласно идеологии « клиент-сервер» , которой придерживались разработчики Windows NT 3.x, только ядро и низкоуровневые драйверы работали в нулевом кольце привилегий. А драйверы графической подсистемы, модули GDI, менеджер окон (Window Manager) и другие компоненты графической подсистемы работали как службы, то есть в пользовательском режиме работы процессора. Такое решение обеспечивало высокую надежность системы, но отрицательно сказывалось на ее производительности, поскольку приходилось многократно переключаться из режима ядра в пользовательский режим и обратно. Полезно напомнить, что сделать это можно только через механизм шлюзования. К тому же интерфейс этих первых операционных систем класса NTсоответствовал обычной 16-разрядной системе Windows 3.x, быстро уходившей в прошлое, и заметно отличался от интерфейса Windows 95. Желая исправить эти недочеты, Microsoft запустила проект Cairo и в 1996 г. выпустила операционные системы Windows NT 4.0 Sever и Windows NT 4.0Workstation.

Операционные системы Windows NT 4.0 оказались на редкость удачными. К моменту их выхода вычислительные ресурсы среднего персонального компьютера уже были достаточными для эффективной работы. Эти операционные системы в качестве основного ресурса требовали оперативную память. Официально серверная система требовала 16 Мбайт, а рабочая станция — 12 Мбайт, в то время как для реальной работы памяти нужно было иметь раза в четыре больше. И поскольку стоимость модулей полупроводниковой памяти для персональных компьютеров в те годы очень заметно снизилась, организации и отдельные пользователи стали массово осваивать эти операционные системы. А упомянутый перевод части кода, ответственного за работу графической подсистемы, в привилегированный режим работы процессора существенно увеличил быстродействие при обработке графики и позволил в последующем начать перенос пользовательских операционных систем на NT.

К сожалению, в своей новой операционной системе компания Microsoft отказалась от поддержки высокопроизводительной файловой системы HPFS,с которой работают операционные системы OS/2, хотя при желании пользователь мог сам добавить соответствующие драйверы из дистрибутива предыдущей Windows NT 3.x. Это был один из тех мелких уколов, которые в совокупности помогали компании Microsoft «уводить» пользователей от операционных систем OS/2.

Желая противопоставить свою серверную операционную систему известным сетевым операционным системам корпоративного уровня Novell Netware 4.x и Netware 5.x, компания Microsoft разработала новое семейство операционных систем класса NT, которое должно было изначально называтьсяWindows NT 5.0, однако из маркетинговых соображений было переименовано в Windows 2000. В семейство этих систем вошли четыре операционные системы.

 Windows 2000 Professional — для использования в качестве рабочей станции вместо Windows NT. 40 Workstation или Windows 98. Эта операционная система может работать на 2-процессорных компьютерах.

 Windows 2000 Server — для использования в качестве контроллера домена и/или сервера (файлов, приложений, баз данных, web и/или FTP,печати и т. д.) в относительно небольшой сети, которую могут себе позволить иметь предприятия малого и среднего бизнеса. Эта операционная система поддерживает 4-процессорные конфигурации.

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

 Windows 2000 Datacenter Server — специальная версия операционной системы, предназначенная для работы в вычислительных сетях крупных предприятий. Система хорошо масштабируется, позволяет построить 4-узловой кластер, причем каждая из машин может иметь вплоть до 16 процессоров.

Наверное, самыми главными особенностями этих операционных систем (по сравнению с предыдущими Windows NT 4.0) следует назвать поддержку механизма Plug and Play (как и в системах Windows 9x) и использование службы каталогов как основы для построения сетей клиент-сервер. Служба каталогов Microsoft получила наименование Active Directory. Принципиальной особенностью этой технологии является ее глубокая интеграция с TCP/IP. Кроме этого, нельзя не отметить, что новые операционные системы получили переработанную систему управления файлами, которая получила наименование NTFS5 . Интересно отметить, что были удалены все остатки кода, до этого позволявшие устанавливать файловую систему HPFS.

Для этого поколения операционных систем Microsoft сочла нецелесообразным переносить их на платформы Alpha (DEC), PowerPC, MIPS.

Осенью 2001 года Microsoft обновила операционную систему Windows 2000 Professional до Windows XP (eXPerience). При этом она выпустила две редакции. Одна из них представляла собой «облегченный» вариант системы для домашнего применения. Она получила название Windows XP Home Edition.Эту операционную систему Microsoft считает основной для современного персонального компьютера. Вторая — полноценная система с предназначением работать в качестве рабочей станции, которая, как правило, подключается к локальной вычислительной сети с выходом в Интернет. Эти операционные системы, прежде всего, получили возможность выполнять приложения, которые использовали оба подмножества функций Win32 API: и для Windows 9x, и для систем класса NT. Системы Windows ХР в еще большей мере стали мультимедийными и ориентированными на Интернет. Интересным новшеством для систем Windows стала возможность организовать одновременную работу с компьютером двух пользователей: для одного непосредственно (локально), а для второго удаленно с другого компьютера. В принципе, в этом нет ничего особенного. Например, операционная система UNIX позволяет без проблем организовать не только такое взаимодействие, но и полноценную мультитерминальную работу. Но для систем Windows — это явно новая возможность.

Наконец, весной 2003 года на замену семейству Windows 2000 вышли несколько серверных операционных систем, которые получили в название число 2003. Это следующие 32-разрядные операционные системы для микропроцессоров с архитектурой ia-32.

 Windows Small Business Server 2003 — предназначена для построения небольших локальных вычислительных сетей.

 Windows Server 2003 Web Edition — это самая «облегченная» система, она не может выступать в роли контроллера домена и быть сервером приложений.

 Windows Server 2003 Standard Edition — основная многоцелевая операционная система, пришедшая на смену Windows 2000 Server.

 Windows Server 2003 Enterprise Edition — аналог Windows 2000 Advanced Server.

 Windows Server 2003 Datacenter Edition.

Последние две операционные системы имеют разновидности для 64-разрядных процессоров Itanium 2 производства компании Intel.

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

 

ТЕМА 2. ОСНОВНЫЕ ОСОБЕННОСТИ АРХИТЕКТУРЫ

Наиболее принципиальным отличием между системами класса Windows 9x и Windows NT является то, что у них разная архитектура.

Большинство операционных систем использует такую особенность современных процессоров, как возможность работать в одном из двух режимов:привилегированном (режиме ядра, или режиме супервизора) и пользовательском (режиме выполнения приложений). При описании своей системыWindows NT Microsoft для указания этих режимов использует термины kernel mode и user mode соответственно. Программные коды, которые выполняются процессором в привилегированном режиме, имеют доступ и к системным аппаратным средствам, и к системным данным. Чтобы защитить операционную систему и данные, располагающиеся в оперативной памяти, от ошибок приложений или их преднамеренного вмешательства в чужие вычисления, только системному коду, относящемуся к управляющей (супервизорной) части операционной системы, разрешают выполняться в привилегированном режиме работы процессора. Все остальные программные модули должны выполняться в пользовательском режиме.

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

Системы типа Windows NT построены по микроядерной технологии. Конечно, их ядро никак нельзя назвать маленьким, особенно в сравнении с ядром операционной системы QNX. Однако в целом архитектура Windows NT безусловно отвечает идеям построения операционной системы, в которой управляющие модули организованы с четким выделением центральной части и взаимодействием этой части с остальными по принципу «клиент-сервер». Это означает, что в состав ядра включены только самые важные основообразующие управляющие процедуры, а остальные управляющие модули операционной системы вызываются из ядра как службы. Причем только часть служб использует процессор в режиме ядра, а остальные — в пользовательском режиме, как и обычные приложения пользователей (рис. 11.2). А для обеспечения надежности они располагаются в отдельном виртуальном адресном пространстве, к которому ни один модуль и ни одна прикладная программа, помимо системного кода, не может иметь доступа.

Рис. 11 .2. Архитектура операционных систем класса Windows NT

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

Из рисунка видно, что помимо собственно ядра в том же режиме супервизора работают модуль HAL (Hardware Abstraction Layer — уровень абстракции аппаратных средств), низкоуровневые драйверы устройств и исполняющая система Windows NT, называемая Win32 Executive. Начиная сWindows NT 4.0 в режиме ядра работают и диспетчер окон (Window Manager), который иногда называют «User», и модули графического интерфейса устройств (GDI).

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

Одним из важнейших компонентов операционных систем Windows NT/2000/XP, который появился вследствие следования микроядерному принципу их построения, является исполняющая система (Win32 Executive). Она выполняет такие базовые функции операционной системы, как управление процессами и потоками, управление памятью, взаимодействие между процессами, защиту, операции ввода-вывода (включая файловые операции, кэширование, работу с сетью и некоторые другие). Ниже перечислены компоненты исполняющей системы.

 Диспетчер процессов (Process Manager) создает, отслеживает и удаляет процессы. Для выполнения этих функций создается соответствующий дескриптор, определяются базовый приоритет процесса и карта адресного пространства, создается и поддерживается список всех готовых к выполнению потоков.

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

 Диспетчер объектов (Object Manager) создает и поддерживает объекты. В частности, поддерживаются дескрипторы объектов и атрибуты защиты объектов. Объектами считаются каталоги, файлы, процессы и потоки, семафоры и события и многие другие.

 Монитор безопасности (Security Reference Monitor) обеспечивает санкционирование доступа к объектам, контроль полномочий доступа и ведение аудита. Совместно с процессом входа в систему (logon) и защищенными подсистемами реализует модель безопасности Windows NT.

 Диспетчер ввода-вывода (Input/Output Manager) управляет всеми операциями ввода-вывода в системе. Организует взаимодействие и передачу данных между всеми драйверами, включая драйверы файловых систем, драйверы физических устройств, сетевые драйверы, для чего используются структуры данных, называемые пакетами запросов на ввод-вывод (I/O Request Packet, IRP). Запросы на ввод-вывод обрабатываются в порядке приоритетов, а не в порядке их поступления. Операции ввода-вывода кэшируются, этим процессом управляет диспетчер кэша (Cache Manager).Поддерживаются различные файловые системы, причем драйверы этих систем воспринимаются диспетчером ввода-вывода как драйверы физических устройств. С программное обеспечение (редиректор и сервер )трактуются как сетевые драйверы и также имеют непосредственную связь с диспетчером ввода-вывода.

 Средства вызова локальных процедур (Local Procedure Call, LPC) обеспечивают выполняющиеся подсистемы среды выполнения и приложения пользователей коммуникационным механизмом, в котором взаимодействие строится по принципу «клиент-сервер».

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

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

Диспетчеризация в системах Windows NT/2000/XP организована почти так же, как и в системах Windows 95/98/ME. Все эти операционные системы относятся к мультизадачным и поддерживают потоковые вычисления. 16-разрядные приложения Windows, работая на одной виртуальной машине, разделяют процессорное время кооперативно. 32-разрядные потоки разделяют процессорное время, вытесняя друг друга через некоторые моменты времени. При этом диспетчер задач (планировщик потоков) работает с несколькими очередями. Всего существует 32 уровня приоритетов — от 0 до 31. Распределение приоритетов между выполняющимися процессами и потоками осуществляется по следующим правилам:

 Low — 4 (низкий приоритет);

 BelowNormal — ниже среднего;

 Normal — 8 (нормальный приоритет);

 AboveNormal — выше среднего;

 High — 16 (высокий приоритет);

 RealTime — 24 (приоритет реального времени).

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

Используемые дисциплины диспетчеризации у всех этих операционных систем одинаковы. Однако если внимательно понаблюдать за тем, как ведут себя системы Windows NT/2000/XP и системы Windows 95/98/ME, выполняя параллельно множество запущенных приложений, то можно без особого труда заметить, что многозадачность у первых реализована значительно лучше. Причина такого явления заключается в том, что с разными затратами времени происходят изменения в подсистеме управления памятью. При переключении с одного вычислительного процесса на другой необходимо поменять значение регистра CR3, с помощью которого линейные адреса команд и операндов пересчитываются в реальные физические. В операционных системахWindows NT/2000/XP (как и в OS/2, и в Linux) используется вся та аппаратная поддержка двухэтапного вычисления физических адресов, которая имеется в микропроцессорах. То есть при переключении процессора на новую задачу смена значения регистра CR3, а значит, и замена всех дескрипторных таблиц, описывающих местонахождение виртуальных страниц процесса и его потоков, осуществляется автоматически. А в системах Windows 95/98/ME вместо инициализации одного регистра, указывающего на адрес таблицы PDE ( ), операционная система переписывает все содержимое целой физической страницы, на которую указывает регистр CR3 вместо простой замены содержимого этого регистра. И поскольку такая операция требует совершенно иных затрат времени, мы и наблюдаем тот факт, что многозадачность в системах Windows 95/98/ME реализована намного хуже, чем в системах класса NT.

Полезно знать, что операционные системы, предназначенные для построения рабочих станций (ранее Workstation, позже Professional), и серверные варианты строятся практически на одном ядре, но имеют разные настройки в реестре. Более того, их дистрибутивы почти полностью совпадают (более чем на 90 %). Однако серверы не имеют ограничений на количество сетевых подключений к ним (эти ограничения определяются только количеством приобретенных лицензий) и позволяют установить и выполнять различные сетевые службы, например службу именования Windows для Интернета(Windows Internet Name Service, WINS), систему доменного именования (Domain Name System, DNS), протокол управления динамической адресацией компьютеров (Dynamic Host Control Protocol, DHCP), контроллер домена (domain controller) в локальной вычислительной сети и многие другие. В доказательство этому можно упомянуть известную утилиту NTSwitch.exe, которая при запуске превращает рабочую станцию в сервер или, наоборот, сервер — в рабочую станцию.

В заключение заметим, что мы очень кратко познакомились с архитектурой операционных систем Windows NT/2000/XP. .

 

ТЕМА 3. МОДЕЛЬ БЕЗОПАСНОСТИ

При разработке всех операционных систем семейства Windows NT/2000/XP компания Microsoft уделяла самое пристальное внимание обеспечению информационной безопасности. Как следствие, эти системы предоставляют надежные механизмы защиты, которые просты в использовании и легки в управлении. Сертификат безопасности на соответствие уровню С2 имеют операционные системы Windows NT 3.5 и Windows NT 4.0. Операционные системы семейства Windows 2000 имеют еще более серьезные средства обеспечения безопасности, однако на момент написания этой книги они еще не сертифицировались.

В отличие от операционных систем семейства Windows 9x, как, впрочем, и от системы OS/2, в разработке первой версии которой Microsoft тоже принимала участие, системы класса Windows NT имеют совершенно иную модель безопасности. Средства защиты изначально глубоко интегрированы в операционную систему. Подсистема безопасности осуществляет контроль за тем, кто и какие действия совершает в процессе работы, к каким объектам пытается получить доступ. Все действия пользователя, в том числе и обращения ко всем объектам, как нетрудно догадаться, на самом деле могут быть совершены только через соответствующие запросы к операционной системе. Операционная система использует этот факт и имеет все необходимые механизмы для тотального контроля всех запросов к ней. Запрашиваемые у операционной системы операции и обращения к конкретным объектам разрешаются, только если у пользователя для этого имеются необходимые права и/или разрешения. При этом обязательно следует различать эти понятия.

Права (rights) определяют уровень полномочий при работе в системе. Например, если нет права форматировать диск, то выполнить это действие пользователь не сможет. Кстати, конкретно таким правом при работе с Windows NT/2000/XP обладают только члены группы администраторов. Можно говорить и о праве изменения настроек дисплея, и о праве работать на компьютере. Очевидно, что перечень прав является достаточно большим. Права могут быть изменены посредством применения соответствующих политик.

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

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

Модель безопасности Windows NT гарантирует, что не удастся получить доступ к ее объектам без того, чтобы предварительно пройтиаутентификацию и авторизацию. Для того чтобы иметь право работать на компьютере, необходимо иметь учетную запись (account). Учетные записи хранятся в базе данных учетных записей, которая представлена файлом SAM (Security Account Management). Каждая учетная запись в базе данных идентифицируется не по имени, а по специальному системному идентификатору. Такой идентификатор в Windows NT называется идентификатором безопасности (Security IDentifier, SID). Подсистема безопасности этих операционных систем гарантирует уникальность идентификаторов безопасности. Они генерируются при создании новых учетных записей и никогда не повторяются. Имеются встроенные учетные записи, но они тоже уникальны. Помимо учетных записей пользователей имеются учетные записи групп. Учетные записи имеют и компьютеры. Идентификаторы несут в себе информацию о типе учетной записи.

Учетные записи могут быть объединены в группы. Имеются встроенные группы. Принадлежность учетной записи к одной из встроенных групп определяет полномочия (права, привилегии) пользователя при работе на этом компьютере. Например, члены встроенной группы администраторов имеют максимально возможные права при работе на компьютере (встроенная учетная запись администратора равносильна учетной записи суперпользователя вUNIX -системах).

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

Для этого каждый объект может иметь список управления доступом (Access Control List, ACL) . Список ACL состоит из записей — АСЕ (Access Control Entry). Каждая запись списка состоит из двух полей. В первом поле указывается некий идентификатор безопасности. Во втором поле располагается битовая маска доступа, описывающая, какие разрешения указаны в явном виде, какие не запрещены, и какие запрещены в явном виде для этого идентификатора. При использовании файловой системы NTFS список ACL реально представлен списком DACL (Discretionary Access Control List). Ранее () был изложен механизм работы разрешений NTFS, причем описаны разрешения как для прежней версии NTFS, использовавшиеся вплоть до Windows NT4.0, так и для файловой системы NTFS 5, которая появилась в Windows 2000. Здесь мы лишь заметим, что рекомендуется составлять списки управления доступом, пользуясь не учетными записями пользователей, а учетными записями групп. Во-первых, это позволяет существенно сократить список управления доступом, поскольку групп обычно намного меньше, чем пользователей. Как результат, список будет намного короче, понятнее и удобнее для последующего редактирования. Во-вторых, в последующем можно будет создать нового пользователя (и не единожды) и добавить его в соответствующие группы, что практически автоматически определит его разрешения на те или иные объекты как члена определенных групп. Наконец, в-третьих, список будет быстрее обрабатываться операционной системой.

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

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

Операционные системы Windows NT/2000/XP обеспечивают защиту на локальном уровне. Это означает, что механизмы защиты работают на каждом компьютере с такой операционной системой. Однако это имеет и обратную сторону. Дело в том, что учетные записи пользователей и групп локальны: они действуют только на том компьютере, где их создали. Если же есть необходимость обратиться к общим ресурсам компьютера через сеть, нужно, чтобы для пользователя, который выполняет такое обращение к удаленным объектам, была создана такая же учетная запись. Поскольку становится затруднительным обеспечить наличие учетных записей для каждого пользователя на всех тех компьютерах, с ресурсами которых ему необходимо работать, пользуясь вычислительной сетью, в свое время была предложена технология доменных сетей. В домене, который представляет собой множество компьютеров, должен быть выделен сервер со всеми учетными записями этого домена. Такой сервер называют контроллером домена. Учетные записи домена в отличие от локальных учетных записей, имеющихся на каждом компьютере с операционной системой типа Windows NT, являются перемещаемыми: они могут перемещаться с контроллера домена на любой другой компьютер этого домена. В результате, имея множество компьютеров, объединенных в домен, и контроллер домена, на котором созданы все необходимые учетные записи, мы можем использовать эти учетные записи для управления доступом к различным ресурсам. Более того, мы можем контролировать использование этих ресурсов и регистрировать попытки несанкционированного доступа к тем или иным объектам. Контроль за использованием прав и разрешений, а также их регистрация называется аудитом.

 

ТЕМА 4. РАСПРЕДЕЛЕНИЕ ОПЕРАТИВНОЙ ПАМЯТИ

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

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

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

Рис. 11.3. Модель распределения виртуальной памяти в Windows NT

Прикладным программам выделяется 2 Гбайт локального (собственного) линейного (неструктурированного) адресного пространства от границы 64 Кбайт до 2 Гбайт (первые 64 Кбайт полностью недоступны). Прикладные программы изолированы друг от друга, хотя могут общаться через буфер обмена(clipboard), механизмы DDE (Dynamic Data Exchange —динамический обмен данными) и OLE (Object Linking and Embedding — связывание и внедрение объектов).

В верхней части каждой области прикладной программы размером по 2 Гбайт размещен код системных библиотек DLL кольца защиты 3, который перенаправляет вызовы в совершенно изолированное адресное пространство, где содержится уже собственно системный код. Этот системный код, выступающий как серверный процесс (server process), проверяет значения параметров, исполняет запрошенную функцию и пересылает результаты назад в адресное пространство прикладной программы. Хотя серверный процесс сам по себе остается процессом прикладного уровня, он полностью защищен от вызывающей его прикладной программы и изолирован от нее.

Между отметками 2 и 4 Гбайт расположены низкоуровневые системные компоненты Windows NT кольца защиты 0, в том числе ядро, планировщик потоков и диспетчер виртуальной памяти. Системные страницы в этой области наделены привилегиями супервизора, которые задаются физическими схемами колец защиты процессора. Это делает низкоуровневый системный код невидимым и недоступным по записи для программ прикладного уровня, но приводит к падению производительности из-за переходов между кольцами.

Для 16-разрядных прикладных Windows-программ операционные системы типа Windows NT реализуют сеансы Windows on Windows (WOW) . В отличие от Windows 9x, система Windows NT дает возможность выполнять 16-разрядные Windows -программы индивидуально в собственных пространствах памяти или совместно в разделяемом адресном пространстве. Почти во всех случаях 16- и 32-разрядные прикладные Windows -программы могут свободно взаимодействовать, используя механизм OLE, независимо от того, выполняются они в отдельной или общей памяти. Собственные прикладные программы и сеансы WOW выполняются в режиме вытесняющей многозадачности, основанной на управлении отдельными потоками. Несколько 16-разрядных прикладных Windows-программ в одном сеансе WOW выполняются в соответствии с кооперативной моделью многозадачности.Windows NT может также открыть в многозадачном режиме несколько сеансов DOS. Поскольку Windows NT имеет полностью 32-разрядную архитектуру, не существует теоретических ограничений на ресурсы компонентов GDI и User.

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

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

Процессами выделения памяти, ее резервирования, освобождения и замещения страниц управляет диспетчер виртуальной памяти (Virtual Memory Manager, VMM) Windows NT. В своей работе этот компонент реализует сложную стратегию учета требований к коду и данным процесса для минимизации обращений к диску, поскольку реализация виртуальной памяти часто приводит к большому количеству дисковых операций. Для взаимодействия между выполняющимися приложениями и между приложениями и кодом самой операционной системы используются соответствующие механизмы защиты памяти, поддерживаемые аппаратурой микропроцессора.

Каждая виртуальная страница памяти, отображаемая на физическую страницу, переносится в так называемый страничный кадр (page frame).Прежде чем код или данные можно будет переместить с диска в память, диспетчер виртуальной памяти должен найти или создать свободный или нулевой (заполненный нулями) страничный кадр. Заметим, что заполнение страниц нулями представляет собой одно из требований стандарта на системы безопасности уровня С2, принятого правительством США. Страничные кадры перед своим выделением должны заполняться нулями, чтобы исключить возможность использования их предыдущего содержимого другими процессами. Чтобы кадр можно было освободить, необходимо скопировать на диск изменения в его странице данных, и только после этого кадр можно будет повторно использовать. Программы, как правило, не меняют страниц кода. Такие страницы можно просто расформировать (удалить).

Диспетчер виртуальной памяти может быстро и относительно легко удовлетворить программные прерывания типа страничной ошибки (page fault).Что касается аппаратных прерываний типа страничной ошибки, то они приводят к необходимости подкачки нужных страниц (paging), что снижает производительность системы. Мы уже говорили (), что в Windows NT, к большому сожалению, для замещения страниц выбрана дисциплина FIFO, а не более эффективная дисциплина LRU или LFU, как это сделано в других операционных системах.

Когда процесс использует код или данные, находящиеся в физической памяти, система резервирует место для этой страницы в файле подкачкиPagefile.sys на диске. Это делается с расчетом на то, что данные потребуется выгрузить на диск. Файл Pagefile.sys представляет собой зарезервированныйблок дискового пространства, который используется для выгрузки страниц, помеченных как «грязные», для освобождения физической памяти. Заметим, что этот файл может быть как непрерывным, так и фрагментированным; он может быть расположен на системном диске или на любом другом и даже на нескольких дисках. Размер этого страничного файла ограничивает объем данных, которые могут храниться во внешней памяти при использовании механизмов виртуальной памяти. По умолчанию размер файла подкачки в операционных системах Windows NT 4.0 устанавливается равным объему физической памяти плюс 12 Мбайт, однако пользователь имеет возможность изменить его размер по своему усмотрению. В следующих системах (Windows2000/ХР) начальный размер страничного файла подкачки берется равным полуторакратному объему физической оперативной памяти. То есть, например, для компьютера, имеющего 512 Мбайт оперативной памяти, по умолчанию размер файла Pagefile.sys равен 768 Мбайт. Проблема нехватки виртуальной памяти часто может быть решена за счет увеличения размера файла подкачки. Файл подкачки может быть не один — система поддерживает до 16 файлов подкачки, поэтому лучше создать их несколько и разместить на быстрых жестких дисках.

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

Перемещаемый, или нерезидентный, пул (paged pool) содержит объекты, которые могут быть при необходимости выгружены на диск.Неперемещаемый, или резидентный, пул (nonpaged pool) содержит объекты, которые должны постоянно находиться в памяти. В частности, к такого рода объектам относятся структуры данных, используемые процедурами обработки прерываний, а также структуры, требуемые для предотвращения конфликтов в мультипроцессорных системах. Исходный размер пулов определяется объемом физической памяти, доступной Windows NT. Впоследствии размер пула устанавливается динамически и в зависимости от работающих в системе приложений и служб может изменяться в Широком диапазоне значений.

Вся виртуальная память в Windows NT подразделяется на зарезервированную (reserved), выделенную (committed) и доступную (available).

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

 Память выделена, если диспетчер виртуальной памяти резервирует для нее место в файле Pagefile.sys на тот случай, когда потребуется выгрузить содержимое памяти на диск. Объем выделенной памяти процесса характеризует фактически потребляемый им объем памяти. Выделенная память ограничивается размером файла подкачки. Предельный объем выделенной памяти в системе (commit limit) определяется тем, какой объем памяти можно выделить процессам без увеличения размеров файла подкачки. Если в системе достаточно дискового пространства, то файл подкачки может быть увеличен, тем самым будет расширен предельный объем выделенной памяти.

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

 

ТЕМА 5. ВИРТУАЛЬНЫЕ МАШИНЫ

Исходная версия OS /360 была системой исключительно пакетной обработки. Однако множество пользователей OS /360 желали работать в системе с разделением времени, поэтому различные группы программистов как в самой корпорации IBM , так и вне ее решили написать для этой машины системы с разделением времени. Официальная система с разделением времени от IBM , которая называлась TSS /360, поздно вышла в свет и оказалась настолько громоздкой и медленной, что на нее перешли немногие. В конечном счете от нее отказались, но уже после того, как ее разработка потребовала около 50 млн долларов. Группа из научного центра IBM в Кембридже, штат Массачусетс, разработала в корне отличающуюся от нее систему, которую IBM в результате приняла как законченный продукт. Сейчас она широко используется на еще оставшихся мэйнфреймах.

Эта система, в оригинале называвшаяся CP /CMS , а позже переименованная в VM /370, была основана на следующем проницательном наблюдении: система с разделением времени обеспечивает (1) многозадачность и (2) расширенную машину с более удобным интерфейсом, чем тот, что предоставляется оборудованием напрямую, VM /370 основана на полном разделении этих двух функций.

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

Рис. 1.14.Структура VM/370 с системой CMS

Поскольку каждая виртуальная машина идентична настоящему оборудованию, на каждой из них может работать любая операционная система, которая запускается прямо на аппаратуре. На разных виртуальных машинах могут (а зачастую так и происходит) функционировать различные операционные системы. На некоторых из них для обработки пакетов и транзакций работают потомки OS /360, а на других для интерактивного разделения времени пользователей работает однопользовательская интерактивная система CMS (Conversational Monitor System — система диалоговой обработки).

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

Идея виртуальной машины очень часто используется в наши дни, но в несколько другом контексте: для работы старых программ, написанных для системы MS -DOS на Pentium (или на других 32-разрядных процессорах Intel ). При разработке компьютера Pentium и его программного обеспечения обе компании, Intel и Microsoft , понимали, что возникнет острая потребность в работе старых программ на новом оборудовании. Поэтому корпорация Intelсоздала на процессоре Pentium режим виртуального процессора 8086. В этом режиме машина действует как 8086 (которая с точки зрения программного обеспечения идентична 8088), включая 16-разрядную адресацию памяти с ограничением объема памяти в 1 Мбайт.

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

Возможны два варианта устройства. Первый: сама система MS -DOS загружена в адресное пространство виртуальной машины 8086, так что монитор виртуальной машины только отсылает прерывания назад к MS -DOS , как это происходит на реальной 8086. Когда затем MS -DOS пытается самостоятельно осуществить ввод/вывод, операция перехватывается и выполняется монитором виртуальной машины.

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

Стоит отметить, что ни один из двух описанных методов в действительности не является те же самым, чем была VM /370, потому что смоделированная машина представляет собой только 8086, а не полноценный Pentium . В системе VM /370 можно было запустить на виртуальной машине саму VM /370. На Pentium нельзя запустить, скажем, операционную систему Windows на виртуальной 8086, потому что не существует версий Windows , работающих на этой машине. Даже для самых старых версий Windows необходим как минимум 286-й процессор, а моделирование 286 не поддерживается (не говоря уже об эмуляции Pentium ).

В системе VM /370 каждый пользователь получает точную копию настоящей машины. На Pentium , в режиме виртуальной машины 8086, каждый пользователь получает точную копию другой машины. Шагнув несколько дальше, исследователи из Массачусетсского технологического института изобрели систему, которая обеспечивает каждого пользователя абсолютной копией реального компьютера, но с подмножеством ресурсов. Например, одна виртуальная машина может получить блоки на диске с номерами от 0 до 1023, следующая — от 1024 до 2047 и т. д.

На нижнем уровне в режиме ядра работает программа, которая называется экзоядро (exokernel ). В ее задачу входит распределение ресурсов для виртуальных машин, а после этого проверка их использования (то есть отслеживание попыток машин использовать чужой ресурс). Каждая виртуальная машина на уровне пользователя может работать с собственной операционной системой, как на VM /370 или виртуальных 8086-х для Pentium , с той разницей, что каждая машина ограничена набором ресурсов, которые она запросила и которые ей были предоставлены.

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

 

ТЕМА 6. МОДЕЛЬ «КЛИЕНТ-СЕРВЕР

 « клиент-сервер »

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

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

Рис. 1.15. Модель « клиент-сервер»

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

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

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

Рис. 1.16. Модель « клиент-сервер» в распределенной системе

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

 

 

---

Дата добавления: 2018-08-06; просмотров: 649; Мы поможем в написании вашей работы!

Поделиться с друзьями:

---

---

Мы поможем в написании ваших работ!