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

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

440
полняемых на одном узле. В том случае, если потоки находятся на разных узлах сети, ядро переадресует запрос менеджеру сети. Для организации обмена в сети используется надёжный и эффективный протокол транспортного уровня FLEET.
Каждый из узлов может принадлежать одновременно нескольким QNX-сетям. В
том случае если сетевое взаимодействие может быть реализовано несколькими пу- тями, для передачи выбирается незагруженная и более скоростная сеть.
Сетевое взаимодействие является узким местом в большинстве операционных систем и обычно создаёт значительные проблемы для систем реального времени.
Для того чтобы обойти это препятствие, разработчики QNX создали собственную специальную сетевую технологию FLEET и соответствующий протокол транс- портного уровня FTL (FLEET transport layer). Этот протокол не базируется ни на одном из распространенных сетевых протоколов типа IPX или NetBios и обладает рядом качеств, которые делают его уникальным. Основные его качества зашифро- ваны в аббревиатуре FLEET, которая расшифровывается следующим образом.

441
Например, утилита make в QNX автоматически распараллеливает компиляцию пакетов из нескольких модулей на все доступные узлы сети, а затем собирает ис- полняемый модуль по мере завершения компиляции на узлах. Специальный драй- вер, входящий в комплект поставки, позволяет использовать для сетевого взаимо- действия любое устройство, с которым может быть ассоциирован файловый деск- риптор, например последовательный порт, что открывает возможности для созда- ния глобальных сетей.
Достигаются все эти удобства за счёт того, что поддержка сети частично обес- печивается и микроядром (специальный код в его составе позволяет QNX фактиче- ски объединять все микроядра в сети в одно ядро). Разумеется, за такие воз- можности приходится платить тем, что мы не можем получить драйвер для какой–
либо сетевой платы от кого-либо ещё, кроме фирмы QSSL, то есть использоваться может только то оборудование, которое уже поддерживается. Однако ассортимент такого оборудования достаточно широк и периодически пополняется новейшими устройствами.
Когда ядро получает запрос на передачу данных процессу, находящемуся на удалённом узле, он переадресовывает этот запрос менеджеру Net, в подчинении которого находятся драйверы всех сетевых карт. Имея перед собой полную карти- ну состояния всего сетевого оборудования, менеджер Net может отслеживать со- стояние каждой сети и динамически перераспределять нагрузку между ними. В
случае когда одна из сетей выходит из строя, информационный поток автоматиче- ски перенаправляется в другую доступную сеть, что очень важно при построении высоконадёжных систем. Кроме поддержки своего собственного протокола, Net обеспечивает передачу пакетов TCP/IP, SMB и многих других, используя то же се- тевое оборудование. Производительность QNX в сети приближается к производи- тельности аппаратного обеспечения.
При проектировании системы реального времени, как правило, необходимо обеспечить одновременное выполнение нескольких приложений. В QNX/Neutrmo
1
параллельность выполнения достигается за счёт использования потоковой модели
1
Neutrino – один из проектов микроядерной ОС.

442
POSIX, в которой процессы в системе представляются в виде совокупности пото- ков. Поток является минимальной единицей выполнения и диспетчеризации для ядра Neutrino, процесс определяет адресное пространство для потоков. Каждый процесс состоит минимум из одного потока. QNX представляет богатый набор функций для синхронизации потоков. В отличие от потоков само ядро не подлежит диспетчеризации. Код ядра исполняется только в том случае, когда какой-нибудь поток вызывает функцию ядра или при обработке аппаратного прерывания.
Напомним, что QNX базируется на концепции передачи сообщений. Передачу сообщений, а также их диспетчеризацию осуществляет ядро системы. Кроме того,
ядро управляет временными прерываниями. Выполнение остальных функций обеспечивается задачами-администраторами. Программа, желающая создать зада- чу, посылает сообщение администратору задач (модуль task) и блокируется для ожидания ответа. Если новая задача должна выполняться одновременно с порож- дающей её задачей, администратор задач task создает её и, отвечая, выдает порож- дающей задаче идентификатор (id) созданной задачи. В противном случае никакого сообщения не посылается до тех пор, пока новая задача не закончится сама по себе.
В этом случае в ответе администратора задач будут содержаться конечные харак- теристики закончившейся задачи.
Сообщения отличаются количеством данных, которые передаются от одной задачи точно к другой задаче. Данные копируются из адресного пространства пер- вой задачи в адресное пространство второй, и выполнение первой задачи приоста- навливается до тех пор, пока вторая задача не вернёт ответное сообщение. В дейст- вительности обе задачи кратковременно взаимодействуют во время выполнения передачи. Ничто, кроме длины сообщения (максимальная длина 65 535 байт), не заботит QNX при передаче сообщения. Существует несколько протоколов, которые могут быть использованы для сообщений.
Основные операции над сообщениями – это послать, получить и ответить, а также несколько их вариантов для обработки специальных ситуаций. Получатель всегда идентифицируется своим идентификатором задачи, хотя существуют спосо- бы ассоциировать имена с идентификатором задачи. Наиболее интересные вариан-

443
ты операций включают в себя возможность получать (копировать) только первую часть сообщения, а затем получать оставшуюся часть такими кусками, какие по- требуются. Это может быть использовано для того, чтобы сначала узнать длину сообщения, а затем динамически распределить принимающий буфер. Если необхо- димо задержать ответное сообщение до тех пор, пока не будет получено и обрабо- тано другое сообщение, то чтение первых нескольких байт даёт вам компактный
«обработчик», через который позже можно получить доступ ко всему сообщению.
Таким образом, ваша задача предохраняется от того, чтобы хранить в себе большое количество буферов.
Другие функции позволяют программе получать сообщения только тогда, ко- гда она уже ожидает их приема, а не блокироваться до тех пор, пока не прибудет сообщение, и транслировать сообщение к другой задаче без изменения идентифи- катора передатчика. Задача, которая транслировала сообщение, в транзакции неви- дима.
Кроме этого, QNX обеспечивает объединение сообщений в структуру данных,
называемую очередью. Очередь – это просто область данных в третьей, отдельной задаче, которая временно принимает передаваемое сообщение и немедленно отве- чает передатчику. В отличие от стандартной передачи сообщений, передатчик не- медленно освобождается для того, чтобы продолжить свою работу. Задача админи- стратора очереди хранит в себе сообщение до тех пор, пока приемник не будет го- тов прочитать его; это он делает путем запроса сообщения у администратора оче- реди. Любое количество сообщений (ограничено только возможностью памяти)
может храниться в очереди. Они хранятся и передаются в том порядке, в котором они были приняты. Может быть создано любое количество очередей. Каждая оче- редь идентифицируется своим именем.
Помимо сообщений и очередей в QNX для взаимодействия задач и организа- ции распределённых вычислений имеются так называемые порты, которые позво- ляют формировать сигнал одного конкретного условия, и механизм исключений, о котором мы уже упоминали выше.

444
Порт подобен флагу, известному всем задачам на одном и том же узле (но не на различных узлах). Он имеет точно два состояния, которые могут трактоваться как «присоединить» и «освободить», хотя пользователь может использовать свою интерпретацию; например, «занят» и «доступен». Порты используются для быст- рой простой синхронизации между задачей и обработчиком прерываний устройст- ва. Они нумеруются от нуля до максимум 32 (на некоторых типах узлов возможно и больше). Первые 20 номеров зарезервированы для использования операционной системой.
С портом могут быть выполнены три операции:
♦ присоединить порт;
♦ отсоединить порт;
♦ послать сигнал в порт.
Одновременно к порту может быть присоединена только одна задача. Если другая задача попытается «отсоединиться» от того же самого порта, то произойдёт отказ при вызове функции, и управление вернётся к задаче, которая в настоящий момент присоединена к этому порту. Это самый быстрый способ обнаружить иден- тификатор другой задачи, подразумевая, что задачи могут договориться использо- вать один номер порта. Напомним, что все рассматриваемые задачи должны нахо- диться на одном и том же узле. При работе нескольких узлов специальные функ- ции обеспечивают большую гибкость и эффективность.
Любая задача может посылать сигнал в любой порт независимо от того, была ли она присоединена к нему или нет (предпочтительно, чтобы не была присоеди- нена). Сигнал подобен не блокирующей передаче пустого сообщения. То есть пере- датчик не приостанавливается, а приёмник не получает какие-либо данные; он только отмечает, что конкретный порт изменил своё состояние.
Задача, присоединённая к порту, может ожидать прибытия сигнала или может периодически читать порт. QNX хранит информацию о сигналах, передаваемых в каждый порт, и уменьшает счётчик после каждой операции «приёма» сигнала
(«чтение» возвращает счётчик и устанавливает его в нуль). Сигналы всегда прини- маются перед сообщениями, давая им тем самым больший приоритет над сообще-

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

446
как если бы они были локальными задачами какого-то узла со всеми атрибутами и привилегиями. Программа, посылающая сообщение в сети, никогда не посылает его точно. Сначала она открывает «виртуальную цепочку». Виртуальная цепочка включает все виртуальные задачи, связанные между собой. На обоих концах такой связи имеются буферы, которые позволяют хранить самое большое послание из тех, которые цепочка может нести в данном сеансе связи. Сетевой администратор помещает в эти буферы все сообщения для соединенных задач. Виртуальная зада- ча, таким образом, занимает всего лишь пространство, необходимое для буфера и входа в таблице задач. Чтобы открыть связь, необходимо знать идентификатор узла и задачи, с которой устанавливается связь. Для этого необходимо знать идентифи- катор задачи администратора, ответственного за данную функцию, или глобальное имя сервера. Не раскрывая здесь подробно механизм обмена посланиями, добавим лишь, что наша задача может вообще выполняться на другом узле, где, допустим,
имеется более совершенный процессор.
Контрольные вопросы и задачи
Вопросы для проверки
1 Изложите основные архитектурные особенности ОС UNIX.
2 Перечислите и поясните основные понятия системы UNIX.
3 Что делает системный вызов fork( )? Каким образом осуществляется в UNIX
запуск новой задачи?
4 Изложите основные моменты, связанные с защитой файлов в UNIX.
5 Расскажите об особенностях семафоров в UNIX. Зачем в семафорных опера- циях действия осуществляются сразу над множеством семафоров?
6 Что представляет собой вызов удаленной процедуры (RPC)?
7 Какие механизмы использует OS/2, чтобы уменьшить потребности в опера- тивной памяти и увеличить производительность системы?
8 Почему про QNX часто говорят «сетевая» ОС?
9 Что такое сетевой протокол FLEET?
10 Какие функции реализует ядро QNX?

447 11 В чём вы видите принципиальные отличия между ядром Windows NT 4.0,
которое считают построенным по микроядерным принципам, от ядра QNX?
12 Расскажите об основных механизмах, которые имеются в QNX для органи- зации распределённых вычислений.
ПРИЛОЖЕНИЕ А
Тексты программы параллельных взаимодействующих задач
Здесь приведены тексты программы, реализующей параллельное функциони- рование задач, взаимодействующих между собой в соответствии с рис. 6.6.
program MultiThreads;
uses Forms,
ThrForm in 'ThrForm.pas' {Form1} ,
Threads in 'Threads.pas' ;
($R *.RES}
begin
Application.Initialize;
Application.CreateForm (Tform1,Form1);
Application.Run;
end.
unit ThrForm;
interface uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, Gauges,
StdCtrls, Threads;
type
Tform1 = class (TForm)
StrButton1: TButton;
GaugeA: Tgauge;
GaugeB: Tgauge;
GaugeC: Tgauge;
GaugeD: Tgauge;
GaugeE: Tgauge;
GaugeF: Tgauge;
GaugeG: Tgauge
Memo1: Tmemo;
Label1: Tlabel;
Label2: Tlabel;
Label3: Tlabel;
Label4: Tlabel;
Label5: Tlabel;
Label6: Tlabel;
Label7: Tlabel;
ScrollBar1: TScrollBar;
Label8: Tlabel;
Label9: Tlabel;