Файл: А. В. Гордеев А. Ю. Молчанов системное программное обеспечение электронный вариант книги издательства Питер СанктПетербург Челябинск юургу каф. Автоматика и управление 2002 2 Предисловие Настоящий учебник.pdf

431
Для повышения надежности файловой подсистемы создана новая журнали- рующая файловая система JFS (journaling file system). JFS введена для удовлетво- рения потребности в более живучей файловой системе для OS/2 Warp. JFS имеет большую безопасность в структурах данных благодаря технике, разработанной для
СУБД. Работа с файловой системой происходит в режиме транзакций с ведением журнала транзакций. В случае системных сбоев есть возможность обработки жур- нала транзакций с целью занесения или сброса каких-либо изменений, произведён- ных во время системного сбоя, эта система также повышает скорость восстановле- ния файловой системы после сбоя. Сохраняя целостность файловой системы, эта система управления файлами не гарантирует восстановление пользовательских данных. Следует отметить, что файловая система JFS обеспечивает самую высокую скорость работы с файлами из всех известных систем, созданных для ПК, что очень важно для серверной ОС.
Для работы с дисками создан специальный менеджер дисков – LVM
1
. Все ус- танавливаемые файловые системы содержатся в LVM. LVM осуществляет опреде- ление имён дисков для программ, которые этого требуют. Это позволяет избира- тельно назначить любую букву любому разделу. И даже больше – ОС не будет са- ма использовать имена дисков. LVM в совокупности с JFS позволяет объединять несколько томов и даже несколько физических дисков в один большой логический том.

432
фейса. Это позволяет с небольшими доработками перенести необходимое накоп- ленное программное обеспечение в среду операционной системы QNX для органи- зации их работы в среде распределенной обработки.
ОС QNX является сетевой, мультизадачной, многопользовательской (много- терминальной) и масштабируемой. С точки зрения пользовательского интерфейса и API она очень похожа на UNIX. Однако QNX – это не версия UNIX, хотя по- чему–то многие так считают. Она была разработана, что называется «с нуля», ка- надской фирмой QNX Software Systems Limited в 1989 году по заказу Министерст- ва обороны США. Причём эта система построена на совершенно других архитек- турных принципах, отличных от принципов, использованных при создании ОС
UNIX.
QNX была первой коммерческой ОС, построенной на принципах микроядра и обмена сообщениями. Система реализована в виде совокупности независимых (но взаимодействующих через обмен сообщениями) процессов различного уровня (ме- неджеры и драйверы), каждый из которых реализует определенный вид сервиса.
Эти идеи позволили добиться нескольких важнейших преимуществ. Вот как они описаны на сайте, посвященном системе QNX [60].
♦ Предсказуемость, означающая её применимость к задачам жёсткого реаль- ного времени. QNX является операционной системой, которая дает полную гаран- тию в том, что процесс с наивысшим приоритетом начнет выполняться практиче- ски немедленно и что критическое событие (например, сигнал тревоги) никогда не будет потеряно. Ни одна версия UNIX не может достичь подобного качества, по- скольку нереентерабельный код ядра слишком велик. Любой системный вызов из обработчика прерывания в UNIX может привести к непредсказуемой задержке (то же самое касается Windows NT, где реальное время заканчивается между ISR и
DPC).
♦ Масштабируемость и эффективность, достигаемые оптимальным исполь- зованием ресурсов и означающие её применимость для встроенных (embedded)
систем; вы не увидите в каталоге /dev огромной кучи файлов, соответствующих ненужным драйверам. Драйверы и менеджеры можно запускать и удалять (кроме

433
файловой системы, что очевидно) динамически, просто из командной строки. Вы можете иметь только тот сервис, который вам реально нужен, причем это не требу- ет серьезных усилий и не порождает проблем.
♦ Расширяемость и надёжность одновременно, поскольку написанный вами драйвер не нужно компилировать в ядро, рискуя вызвать нестабильность системы.
Менеджеры ресурсов (сервис логического уровня) работают в кольце защиты
3, и вы можете добавлять свои, не опасаясь за систему. Драйверы работают в коль- це с уровнем привилегий 1 и могут вызвать проблемы, но не фатального характера.
Кроме того, их достаточно просто писать и отлаживать.
♦ Быстрый сетевой протокол FLEET
1
, прозрачный для обмена сообщениями,
автоматически обеспечивающий отказоустойчивость, балансирование нагрузки и маршрутизацию между альтернативными путями доступа.
♦ Компактная графическая подсистема Photon, построенная на тех же прин- ципах модульности, что и сама ОС, позволяет получить полнофункциональный
GUI
2
(расширенный Motif), работающий вместе с POSIX-совместимой ОС всего в
4Мбайт памяти, начиная с i80386 процессора.
Вспомним основные принципы, обязательная реализация которых позволят создавать ОСРВ (см. раздел «Требования, предъявляемые к ОС реального време- ни», глава 5). Первым обязательным требованием к архитектуре ОСРВ является
многозадачность в истинном смысле этого слова. Очевидно, что варианты с псев- домногозадачностью (а точнее – не вытесняющая многозадачность) типа MS Win- dows 3.х или Novell NetWare неприемлемы, поскольку они допускают возможность блокировки или даже полного развала системы одним неправильно работающим процессом. Для предотвращения блокировок ОСРВ должна использовать кванто- вание времени (то есть вытесняющую многозадачность), что является достаточно легкой задачей. Вторая проблема (организация надёжных вычислений) может быть эффективно решена при полном использовании возможностей процессоров Intel
80386 и старше, что предполагает работу ОС в 32-разрядном режиме процессора.
Для эффективного обслуживания прерываний ОС должна использовать алгоритм
1
Это фирменная технология, несколько более подробно об этом изложено ниже.

434
диспетчеризации, обеспечивающий вытесняющее планирование, основанное на
приоритетах. Наконец, крайне желательны эффективная поддержка сетевых
коммуникаций и наличие развитых механизмов взаимодействия между процесса-
ми, поскольку реальные технологические системы обычно управляются целым комплексом компьютеров и/или контроллеров. Весьма важно также, чтобы ОС
поддерживала множественные потоки управления (не только мультипрограмм-
ный, но и мультизадачный режимы), а также симметричную мультипроцессор- ность.
И, наконец, при соблюдении всех перечисленных условий ОС должна быть способна работать на ограниченных аппаратных ресурсах, поскольку одна из её
основных областей применения – это встроенные системы. К сожалению, данное условие обычно реализуется путём урезания стандартных сервисных средств.
Архитектура системы QNX
QNX – это ОС реального времени, позволяющая эффективно организовать распределённые вычисления. В системе реализована концепция связи между зада- чами на основе сообщений, посылаемых от одной задачи к другой, причём задачи эти могут находиться как на одном и том же компьютере, так и на удалённых, но связанных локальной вычислительной сетью. Реальное время и концепция связи между процессами в виде сообщений оказывают решающее влияние на разрабаты- ваемое для QNX программное обеспечение и на программиста, стремящегося с максимальной выгодой использовать преимущества системы.
Микроядро имеет объем в несколько десятков килобайт (в одной из версий –
10 Кбайт, в другой – менее 32 Кбайт), то есть это одно из самых маленьких ядер среди всех существующих операционных систем. В этом объеме помещаются [54]:
♦ механизм передачи сообщений между процессами (IPC);
♦ редиректор
3
прерываний;
♦ блок планирования выполнения задач;
♦ сетевой интерфейс для перенаправления сообщений (менеджер Net).
2
GUI (graphic user interface) – графический интерфейс пользователя.
3
От redirect - перенаправлять.

435
Механизм передачи межпроцессных сообщений занимается пересылкой сооб- щений между процессами и является одной из важнейших частей операционной системы, так как всё общение между процессами, в том числе и системными, про- исходит через сообщения. Сообщение в QNX – это последовательность байтов произвольной длины (0–65 535 байтов) произвольного формата. Протокол обмена сообщениями выглядит таким образом. Например, задача блокируется для ожида- ния сообщения. Другая же задача посылает первой сообщение и при этом блокиру- ется сама, ожидая ответа. Первая задача разблокируется, обрабатывает сообщение и отвечает, разблокируя при этом вторую задачу.
Сообщения и ответы, пересылаемые между процессами при их взаимодейст- вии, находятся в теле отправляющего их процесса до того момента, когда они мо- гут быть приняты. Это значит, что, с одной стороны, уменьшается вероятности по- вреждения сообщения в процессе передачи, а с другой – уменьшается объём опера- тивной памяти, необходимый для работы ядра. Кроме того, уменьшается число пе- ресылок из памяти в память, что разгружает процессор. Особенностью процесса передачи сообщений является то, что в сети, состоящей из нескольких компьюте- ров под управлением QNX, сообщения могут прозрачно передаваться процессам,
выполняющимся на любом из узлов. Определены в QNX ещё и два дополнитель- ных метода передачи сообщений – метод представителей (Proxy) и метод сигналов
(Signal).
Представители используются в случаях, когда процесс должен передать сооб- щение, но не должен при этом блокироваться на передачу. В таком случае вызыва- ется функция qnx_proxy_attach( )
и создаётся представитель. Он накапливает в себе сообщения, которые должны быть доставлены другим процессам. Любой процесс,
знающий идентификатор представителя, может вызвать функцию
Trigger( )
, после чего будет доставлено первое в очереди сообщение. Функция
Trigger ( )
может вы- зываться несколько раз, и каждый раз представитель будет доставлять следующее сообщение. При этом представитель содержит буфер, в котором может храниться до 65 535 сообщений. Как известно, сигналы уже давно используются в ОС UNIX.
Система QNX поддерживает множество сигналов, совместимых с POSIX, большое

436
количество сигналов, традиционно использовавшихся в UNIX (поддержка этих сигналов реализована для совместимости с переносимыми приложениями, и ни один из системных процессов QNX их не генерирует), а также несколько сигналов,
специфичных для самой QNX. По умолчанию любой сигнал, полученный процес- сом, приводит к завершению процесса (кроме нескольких сигналов, которые по умолчанию игнорируются). Но процесс с приоритетом уровня «superuser» может защититься от нежелательных сигналов. В любом случае процесс может содержать обработчик для каждого возможного сигнала. Сигналы удобно рассматривать как разновидность программных прерываний.
Редиректор прерываний является частью ядра и занимается перенаправлением аппаратных прерываний в связанные с ними процессы. Благодаря такому подходу возникает один побочный эффект – с аппаратной частью компьютера работает яд- ро, оно перенаправляет прерывания процессам – обработчикам прерываний. Обра- ботчики прерываний обычно встроены в процессы, хотя каждый из них исполняет- ся асинхронно с процессом, в который он встроен. Обработчик исполняется в кон- тексте процесса и имеет доступ ко всем глобальным переменным процесса. При работе обработчика прерываний прерывания разрешены, но обработчик приоста- навливается только в том случае, если произошло более высокоприоритетное пре- рывание. Если это позволяется аппаратной частью, к одному прерыванию может быть подключено несколько обработчиков, и каждый из них получит управление при возникновении прерывания.
Этот механизм позволяет пользователю избежать работы с аппаратным обес- печением напрямую и тем самым избегать конфликтов между различными процес- сами, работающими с одним и тем же устройством. Для обработки сигналов от внешних устройств чрезвычайно важно минимизировать время между возникнове- нием события и началом непосредственной его обработки. Этот фактор существен в любой области применения, от работы терминальных устройств до возможности обработки высокочастотных сигналов.
Блок планирования выполнения задач (диспетчер задач) занимается обеспече- нием многозадачности. В этой части ОС QNX предоставляет разработчику огром-

437
ный простор для выбора той методики выделения ресурсов процессора задаче, ко- торая обеспечит наиболее подходящие условия для критических приложений или обеспечит такие условия для некритических приложений, что они выполнятся за разумное время, не мешая работе критических приложений.
К выполнению своих функций как диспетчера ядро приступает в следующих случаях:
♦ какой-либо процесс вышел из блокированного состояния;
♦ истёк квант времени для процесса, владеющего CPU;
♦ работающий процесс прерван каким-либо событием.
Диспетчер выбирает процесс для запуска среди неблокированных процессов в порядке значений их приоритетов, которые располагаются в диапазоне от 0 (наи- меньший) до 31 (наибольший). Обслуживание каждого из процессов зависит от ме- тода диспетчеризации, с которым он работает (уровень приоритета и метод дис- петчеризации могут динамически меняться во время работы). В QNX существуют три метода диспетчеризации: FIFO (первым пришел – первым обслужен), round–
robin (процессу выделяется определенный квант времени для работы) и адаптив- ный, который является наиболее используемым.
Первый наиболее близок к кооперативной многозадачности. То есть процесс выполняется до тех пор, пока он не перейдёт в состояние ожидания сообщения, со- стояние ожидания ответа на сообщение или не отдаст управление ядру. При пере- ходе в одно из таких состояний процесс помещается последним в очередь процес- сов с таким же уровнем приоритета, а управление передается процессу с наиболь- шим приоритетом.
Во втором варианте всё происходит так же, как и в предыдущем, с той разни- цей, что период, в течение которого процесс может работать без перерыва, ограни- чивается неким квантом времени. Процесс, работающий с адаптивным методом, в
QNX ведет себя следующим образом:
♦ Когда процесс полностью использовал выделенный ему квант времени, его приоритет снижается на 1, если в системе есть процессы с тем же уровнем приори- тета, готовые к исполнению.

438
♦ Если процесс с пониженным приоритетом остаётся не обслуженным в тече- ние секунды, его приоритет увеличивается на 1.
Если процесс блокируется, ему возвращается оригинальное значение приори- тета.
По умолчанию процессы запускаются в режиме адаптивной многозадачности.
В этом же режиме работают все системные утилиты QNX. Процессы, работающие в разных режимах многозадачности, могут одновременно находиться в памяти и исполняться. Важный элемент реализации многозадачности – это приоритет про- цесса. Обычно приоритет процесса устанавливается при его запуске. Но есть до- полнительная возможность, называемая «вызываемый клиентом приоритет». Как правило, она реализуется для серверных процессов (исполняющих запросы на ка- кое-либо обслуживание). При этом приоритет процесса-сервера устанавливается только на время обработки запроса и становится равным приоритету процесса–
клиента.
Сетевой интерфейс в системе QNX является неотъемлемой частью ядра. Он,
конечно, взаимодействует с сетевым адаптером через сетевой драйвер, но базовые сетевые сервисы реализованы на уровне ядра. При этом передача сообщения про- цессу, находящемуся на другом компьютере, ничем не отличается с точки зрения приложения от передачи сообщения процессу, выполняющемуся на том же компь- ютере. Благодаря такой организации сеть превращается в однородную вычисли- тельную среду. При этом для большинства приложений не имеет значения, с како- го компьютера они были запущены, на каком исполняются и куда поступают ре- зультаты их работы. Такое решение принципиально отличает QNX от остальных
ОС, которые тоже имеют все необходимые средства для работы в сети, и делает системы, работающие под её управлением, по-настоящему распределёнными.
Все сервисы QNX, не реализованные непосредственно в ядре, работают как стандартные процессы в полном соответствии с основными концепциями микро- ядерной архитектуры. С точки зрения операционной системы системные процессы ничем не отличаются от всех остальных. Как, впрочем, и драйверы устройств.
Единственное, что нужно сделать, написав новый драйвер устройства в QNX, что-