Деревянко А.С., Солощук М.Н. Операционные системы. Часть II. Обзор операционных систем

Подождите немного. Документ загружается.

191

система устройств и /pipe – виртуальная файловая система программных

каналов.

Некоторые другие интересные свойства BFS также определяются

спецификой этой файловой системы:

• 64-разрядный размер файла – важное обстоятельство, если учесть

то, что многие файлы в BFS содержат мультимедийную

информацию;

• использование многопоточности в работе самих модулей BFS – в

соответствии с общей концепцией всей BeOS;

• журналирование – свойство, которое может показаться роскошью

для настольной ОС, но в BFS оно совершенно необходимо для

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

Интересен способ, который использует BeOS для определения типа

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

визуализацией и обработкой этого файла. В атрибутах файла

обеспечивается идентификация типа в соответствии со спецификациями

MIME (Multipurpose Internet Mail Extensions). Наряду со стандартными

типами MIME BeOS применяет также и собственные типы, не

предусмотренные в MIME, но определяемые также в формате

спецификации MIME. При отсутствии у файла MIME-специфицированных

атрибутов для определения типа используется расширение файла, и BeOS

ведет собственную "базу типов файлов", которые определяют связанные с

типом-расширением приложения. BeOS также представляет пользователю

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

файла или группы файлов.

КОНТРОЛЬНЫЕ ВОПРОСЫ

192

1. Переведите терминологию BeOS, относящуюся к управлению

процессами и нитями в принятую в части I данного учебного пособия.

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

применяются в BeOS?

3. Какую модель памяти обеспечивает API BeOS?

4. Сопоставьте "образы" BeOS с "ресурсами" Mac OS. Что между

ними общее, в чем различия?

5. Каковы оригинальные свойства файловой системы BeOS?

6. Почему в файловой системе настольной BeOS обязательно

должна обеспечиваться целостность?

7. Охарактеризуйте правила диспетчеризации нитей в BeOS.

Классифицируйте их в соответствии с классификацией главы 2 части I.

Глава 10. Операционная система QNX

10.1. Архитектура

Операционная система QNX [32] производится компанией QNX

Software Systems Ltd. с 1980 г. В настоящее время существует версия 6.1

системы. Для нас ОС QNX представляет особый интерес по двум

причинам: во-первых, это ОС реального времени, во-вторых, это ОС,

построенная на концепции микроядра "в чистейшем виде". Как следствие

этого QNX – легко масштабируемая система

Архитектура ОС QNX показана на рисунке 10.1.

193

Рисунок 10.1 Архитектура ОС QNX.

Микроядро QNX имеет минимальный размер (всего 8 Кбайт), и в нем

сосредоточены все операции, выполняемые в режиме ядра. Ядро не имеет

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

вызвавшего. Модули, сосредоточенные в микроядре, выполняют

следующие основные функции:

• планирование и переключение процессов и управление реальной

памятью (планировщик);

• первичную обработку прерываний и перенаправление их

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

• обеспечение связей между процессами (средства взаимодействия);

• сетевые взаимодействия (сетевой интерфейс).

Все эти функции аппаратно-зависимые и/или требуют высокой

эффективности в реализации. Другие функции ОС обеспечиваются

системными процессами-менеджерами, которые, однако, выполняются в

пользовательском режиме и с точки зрения микроядра ничем не

отличаются от процессов пользователей. Типичные конфигурации ОС

QNX включают в себя следующие системные процессы:

• менеджер процессов (Proc);

• менеджер файловой системы (Fsys);

194

• менеджер устройств (Dev);

• сетевой менеджер (Net).

Микроядро QNX выполняет всего 57 системных вызовов, однако

процессы-менеджеры ОС обеспечивают выполнение большого числа

других системных вызовов, что позволило ОС QNX получить сертификат

POSIX. Таким образом, ОС QNX может считаться Unix-подобной

системой, хотя ее внутренняя структура далека от традиционной

структуры ОС Unix.

10.2. Управление процессами

Порождение и планирование процессов обеспечивается менеджером

процессов совместно с планировщиком в микроядре. Менеджер процессов

выполняет порождение новых процессов, загрузку и завершение

процессов. Для создания процессов имеются системные вызовы fork() и

exec() – традиционные для Unix, а также spawn() – создание процесса-

потомка с выполнением в нем новой программы.

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

• готовые ( среди них – и активный процесс);

• ожидающие (6 подвидов – в зависимости от причин ожидания)

• мертвые (уже завершившиеся, но не передавшие информации о

своем завершении).

Планирование процессов в QNX выполняется по абсолютным

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

высоким приоритетом вытесняет активный процесс немедленно. При

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

высшим приоритетом разделение процессора между ними выполняется по

одной из дисциплин на выбор:

195

• FCFS;

• RR;

• динамическое изменение приоритета.

В последнем случае изменение приоритета производится по таким

правилам:

• если активный процесс полностью исчерпал квант времени и есть

еще процессы с таким же приоритетом, приоритет активного

процесса уменьшается на 1;

• если процесс пробыл в очереди готовых процессов, не получая

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

на 1.

Всего в системе имеется 32 градации приоритетов.

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

получают наивысший приоритет (в ущерб всем другим процессам), в QNX

обеспечение работы в реальном времени состоит в том, что всем

процессам обеспечивается высокая реактивность. То есть, если происходит

какое-либо событие (прерывание), требующее выполнения определенного

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

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

реентерабельности модулей микроядра (то есть возможности прервать

выполнение модуля) и высокой эффективности средств взаимодействия

процессов.

Внешнее событие вызывает прерывание. Для обеспечения высокой

реактивности прерывание должно обрабатываться немедленно. Но

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

• выполняется обработка прерывания с более высоким

приоритетом;

196

• выполняется нереентерабельный код микроядра (при этом

обработка прерывания запрещается).

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

второй является нежелательным. В QNX модули микроядра тщательно

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

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

прерываемыми почти в любом месте. Участки кода с запрещенными

прерываниями составляют в среднем всего 9 команд на входе в модуль

микроядра и 14 команд – на выходе из модуля.

10.3. Средства взаимодействия

ОС QNX обеспечивает (на уровне микроядра) три средства

взаимодействия процессов: сигналы, сообщения и поручения (proxy).

Механизм сигналов соответствует тому, который мы рассмотрели в

разделе 9.2 части I. QNX работает с большим количеством типов сигналов,

среди которых:

• стандартные сигналы, определяемые POSIX;

• сигналы, управляющие работой процессов;

• специальные сигналы QNX;

• сигналы, поддерживающие старые версии Unix.

Процесс может определять способы обработки некоторых (но не

всех) сигналов.

Сообщения являются основным способом взаимодействия между

процессами в QNX. В отличие от того смысла, который мы вкладывали в

этот термин в разделе 9.7 части I, в QNX сообщения являются

синхронными, то есть процесс, пославший сообщение, требует

обязательного ответа на него.

197

Обмен сообщениями обеспечиваются вызовами микроядра:

• Send() – посылка сообщения:

• Recive() – прием сообщения;

• Reply() – посылка ответа.

На рисунке 10.2 показан сценарий взаимодействия процессов при

посылке сообщения

Рисунок 10.2 Сценарий взаимодействия процессов при посылке сообщения

В соответствии с протоколом передачи сообщений различаются

следующие подвиды блокировки процесса:

• SEND-блокированный процесс – послал сообщение и ожидает

подтверждения его приема.

• REPLY-блокированный процесс – получил подтверждение приема

и ожидает получения ответа.

• RECIVE-блокированный процесс – запросил прием сообщения и

ожидает его поступления. На рисунке 10.2 состояние RECIVE-

блокировки не показано, в него мог бы попасть Процесс B, если

198

бы выполнил системный вызов Recive() прежде, чем Процесс

A выполнил Send().

Модель сообщений QNX более всего напоминает взаимодействие

процессов по принципу рандеву (см. раздел 8.11 части I), описываемую

как:

A!x; ?y

Для взаимодействия процессов необходима "встреча" готовности

одного процесса (Процесса A) передать сообщение и готовности другого

процесса (Процесса B) принять сообщение. При этом для процессов,

участвующих в рандеву, нет необходимости знать о готовности процесса-

корреспондента. Процесс, первым пришедший в точку рандеву, просто

блокируется (SEND- или RECIVE-блокировкой) до готовности процесса-

партнера.

Передача ответа подтверждения не требует, и выполнение вызова

Reply() не приводит к блокировке процесса, выполнившего этот вызов.

При необходимости процесс может посылать сообщения нулевой

длины и/или ответы нулевой длины – такие приемы применяются для

взаимного исключения и синхронизации без обмена данными.

Несколько процессов могут послать сообщения одновременно

одному адресату. В этом случае сообщения могут обрабатываться

(получаться адресатом) либо в порядке их поступления, либо в

соответствии с приоритетами отправителей.

Еще один вызов микроядра – Crecive() – позволяет процессу

проверить наличие сообщений для него и, таким образом, избежать

RECIVE-блокировки.

Интересно, что, используя механизм сообщений-рандеву, библиотеки

системных вызовов QNX обеспечивают интерфейсы других стандартных

средств взаимодействия процессов, таких как программные каналы или

семафоры.

199

Третий вид взаимодействия – поручения – обеспечивает асинхронное

взаимодействие процессов. Фактически поручения идентичны очередям

сообщений, описанным нами в разделе 9.7 части I.

10.4. Файловая система

Администратор файловой системы ОС QNX позволяет стандартным

образом организовать хранение и доступ к данным файловых подсистем

(томов). С точки зрения логической файловой системы, хранение файлов в

QNX подобно тому, какое обеспечивает ОС Unix: общее дерево каталогов

с возможностью монтирования новых томов как ветвей этого общего

дерева. Обеспечиваются также "жесткие" и "мягкие" связи.

На физическом уровне диск QNX структурирован так, как показано

на рисунке 10.3.

Рисунок 10.3 Структура диска QNX

Загрузчик представляет собой блок начальной загрузки. Он не

осуществляет загрузку собственно ОС, а выполняет выбор загрузочного

файла ОС.

200

Корневой блок имеет структуру каталога и содержит информацию о

следующих специальных файлах:

• файл с именем / – корневой каталог;

• файл с именем /.inodes – файл файловых индексов;

• файл с именем /.boot – загрузочный файл ОС;

• файл с именем /.altboot – альтернативный загрузочный файл

ОС.

Загрузчик загружает операционную систему из файла /.boot,

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

Битовая карта содержит информацию о свободных блоках на диске.

Свободному блоку соответствует бит со значением 0, занятому – 1.

Размещение файла на диске QNX показано на рисунке 10.4.

Рисунок 10.4 Размещение файла на диске QNX

Единицей распределения дискового пространства является блок (512

байт). Пространство файлу выделяется экстентами – непрерывными

последовательностями, состоящими из целого числа блоков. В элементе

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

размер для первого экстента файла. Если файлу выделено более одного

экстента, то в элементе каталога содержится номер блока расширения,

через который адресуются следующие экстенты файла. Если одного блока