9. Семейство операционных систем реального времени QNX................................1
9.1. Структура систем реального времени ..........................................................1
9.2. Управление многозадачностью в ОС реального времени .........................2
9.3. Управление памятью и служба времени в ОС реального времени ..........4
9.4. Средства организации взаимодействия процессов в ОС реального
времени ........................................................................................................................6
9.5. Синхронное и асинхронное взаимодействие в ОС реального времени...8
9.6. Средства обеспечения отказоустойчивости в ОС реального времени.....8
9. Семейство операционных систем реального времени QNX
9.1. Структура систем реального времени
Вспомним основные принципы, обязательная реализация которых
позволяет создавать операционные системы реального времени (ОСРВ).
Первым обязательным требованием к архитектуре операционной системы
реального времени является многозадачность в истинном смысле этого слова.
Очевидно, что варианты с псевдомногозадачностью (а точнее, с
невытесняющей многозадачностью) в системах 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 программное
обеспечение, и на программиста, стремящегося с максимальной выгодой
использовать преимущества системы.
9.2. Управление многозадачностью в ОС реального
времени
Концепция многозадачности (псевдопараллелизм) является
существенной для системы реального времени с одним процессором,
приложения которой должны быть способны обрабатывать многочисленные
внешние события, происходящие практически одновременно. Концепция
процесса, пришедшая из мира UNIX, плохо реализуется в многозадачной
системе, поскольку процесс имеет тяжелый контекст. Возникает понятие
потока (thread), который понимается как подпроцесс, или легковесный
процесс (light-weight process). Потоки существуют в одном контексте
процесса, поэтому переключение между потоками происходит очень быстро,
а вопросы безопасности не принимаются во внимание. Потоки являются
легковесными, потому что их регистровый контекст меньше, т.е. их
управляющие блоки намного компактнее. Уменьшаются накладные расходы,
вызванные сохранением и восстановлением управляющих блоков
прерываемых потоков. Объем управляющих блоков зависит от конфигурации
памяти. Если потоки выполняются в разных адресных пространствах,
система должна поддерживать отображение памяти для каждого набора
потоков.
Итак, в системах реального времени процесс распадается на задачи или
потоки. В любом случае каждый процесс рассматривается как приложение.
Между этими приложениями не должно быть слишком много взаимодействий,
и в большинстве случаев они имеют различную природу – жесткого реального
времени, мягкого реального времени, не реального времени.
В связи с проблемами планирования в ОСРВ изучаются и развиваются
два подхода – статические алгоритмы планирования (RMS – Rate Monotonic
Scheduling) и динамические алгоритмы планирования (EDF – Earliest Deadline
First).
RMS используется для формального доказательства условий
предсказуемости системы. Для реализации этой теории необходимо
планирование на основе приоритетов, прерывающих обслуживание (preemptive
priority scheduling). В теории RMS приоритет заранее назначается каждому
процессу. Процессы должны удовлетворять следующим условиям:
• процесс должен быть завершен за время его периода,
• процессы не зависят друг от друга,
• каждому процессу требуется одинаковое процессорное время на
каждом интервале,
• у непериодических процессов нет жестких сроков,
• прерывание процесса происходит за ограниченное время.
Процессы выполняются в соответствии с приоритетами. При
планировании RMS предпочтение отдается задачам с самыми короткими
периодами выполнения.
В EDF приоритет присваивается динамически, и наибольший приоритет
выставляется процессу, у которого осталось наименьшее время выполнения.
При больших загрузках системы у EDF имеются преимущества перед RMS.
Во всех системах реального времени требуется политика планирования,
управляемая дедлайнами (deadline-driven scheduling). Однако этот подход
находится в стадии разработки.
Обычно в ОСРВ используется планирование с приоритетами,
прерывающими обслуживание, которое основано на RMS. Приоритетное
прерывание обслуживания (preemption) является неотъемлемой составляющей
ОСРВ, т.к. в системе реального времени должны существовать гарантии того,
что событие с высоким приоритетом будет обработано перед событием более
низкого приоритета. Все это ведет к тому, что ОСРВ нуждается не только в
механизме планирования на основе приоритетов, прерывающих обслуживание,
но также и в соответствующем механизме управления прерываниями. Более
того, ОСРВ должна быть способна запрещать прерывания, когда необходимо
выполнить критический код, который нельзя прерывать. Длительность
обработки прерываний должна быть сведена к минимуму.
ОСРВ должна обладать развитой системой приоритетов. Во-первых, это
требуется потому, что система сама может рассматриваться как набор
серверных приложений, подразделяющихся на потоки, и несколько высоких
уровней приоритетов должно быть выделено системным процессам и потокам.
Во-вторых, в сложных приложениях необходимо все потоки реального времени
помещать на разные приоритетные уровни, а потоки не реального времени
помещать на один уровень (ниже, чем любые потоки реального времени). При
этом потоки не реального времени можно обрабатывать в режиме циклического
планирования (RRS – round-robin scheduling), при котором каждому процессу
предоставляется квант времени процессора, а когда квант заканчивается,
контекст процесса сохраняется, и он ставится в конец очереди. Во многих
ОСРВ для планирования задач на одном уровне используется RRS.
Приоритетный уровень 0 обычно используется для холостого режима.
При планировании на основе приоритетов необходимо решить две
обязательные проблемы:
• обеспечить выполнение процесса с наивысшим приоритетом,
• не допустить инверсии приоритетов, когда задачи с высокими
приоритетами ожидают ресурсы, захваченные задачами с более низкими
приоритетами.
Для борьбы с инверсией приоритетов в ОСРВ часто используется
механизм наследования приоритетов, однако при этом приходится
отказываться от планирования на основе RMS, поскольку приоритеты
становятся динамическими.
9.3. Управление памятью и служба времени в ОС
реального времени
Рассмотрим четыре наиболее распространенных в ОСРВ модели защиты
памяти.
• Модель без защиты – системное и пользовательское адресные
пространства не защищены друг от друга, используется два сегмента памяти:
для кода и для данных; при этом от системы не требуется никакого управления
памятью, не требуется MMU (memory management unit – специальное
аппаратное устройство для поддержки управления виртуальной памятью).
• Модель защиты система/пользователь – системное адресное
пространство защищено от адресного пространства пользователя, системные и
пользовательские процессы выполняются в общем виртуальном адресном
пространстве, при этом требуется MMU. Защита обеспечивается страничным
механизмом защиты. Различаются системные и пользовательские страницы.
Пользовательские приложения никак не защищены друг от друга. Процессор
находится в режиме супервизора, если текущий сегмент имеет уровень 0, 1 или
2. Если уровень сегмента – 3, то процессор находится в пользовательском
режиме. В этой модели необходимы четыре сегмента – два сегмента на уровне 0
(для кода и данных) и два сегмента на уровне 3. Механизм страничной защиты
не добавляет накладных расходов, т.к. защита проверяется одновременно с
преобразованием адреса, которое выполняет MMU; при этом ОС не нуждается
в управлении памятью.
• Модель защиты пользователь/пользователь – к модели
система/пользователь добавляется защита между пользовательскими
процессами; требуется MMU. Как и в предыдущей модели, используется
механизм страничной защиты. Все страницы помечаются как
привилегированные, за исключением страниц текущего процесса, которые
помечаются как пользовательские. Таким образом, выполняющийся поток не
может обратиться за пределы своего адресного пространства. ОС отвечает за
обновление флага привилегированности для конкретной страницы в таблице
страниц при переключении процесса. Как и в предыдущей модели
используются четыре сегмента.
• Модель защиты виртуальной памяти – каждый процесс
выполняется в своей собственной виртуальной памяти, требуется MMU. У
каждого процесса имеются свои собственные сегменты и, следовательно, своя
таблица описателей. ОС несет ответственность за поддержку таблиц
описателей. Адресуемое пространство может превышать размеры физической
памяти, если используется страничная организация памяти совместно с
подкачкой. Однако в системах реального времени подкачка обычно не
применяется из-за ее непредсказуемости. Для решения этой проблемы
доступная память разбивается на фиксированное число логических адресных
пространств равного размера. Число одновременно выполняющихся процессов
в системе становится ограниченным.
Фундаментальное требование к памяти в системе реального времени
заключается в том, что время доступа к ней должно быть ограничено (или,
другими словами, предсказуемо). Прямым следствием становится запрет на
использование для процессов реального времени техники вызова страниц по
запросу (подкачка с диска). Поэтому системы, обеспечивающие механизм
виртуальной памяти, должны уметь блокировать процесс в оперативной
памяти, не допуская подкачки. Итак, подкачка недопустима в ОСРВ, потому
что непредсказуема.
Если поддерживается страничная организация памяти (paging),
соответствующее отображение страниц в физические адреса должно быть
частью контекста процесса. Иначе опять появляется непредсказуемость,
неприемлемая для ОСРВ.
Для процессов, не являющихся процессами жесткого реального
времени, возможно использование механизма динамического распределения
памяти, однако при этом ОСРВ должна поддерживать обработку таймаута на
запрос памяти, т.е. ограничение на предсказуемое время ожидания.
В обычных ОС при использовании механизма сегментации памяти для
борьбы с фрагментацией применяется процедура уплотнения после сборки
мусора. Однако такой подход неприменим в среде реального времени, т.к. во
время уплотнения перемещаемые задачи не могут выполняться, что ведет к
непредсказуемости системы. В этом состоит основная проблема применимости
объектно-ориентированного подхода к системам реального времени. До тех
пор, пока проблема уплотнения не будет решена, C++ и JAVA останутся не
самым лучшим выбором для систем жесткого реального времени.
В системах жесткого реального времени обычно применяется статическое
распределение памяти. В системах мягкого реального времени возможно
динамическое распределение памяти, без виртуальной памяти и без
уплотнения.
В ОСРВ используются различные службы времени. Операционная
система отслеживает текущее время, в определенное время запускает задачи
и потоки и приостанавливает их на определенные интервалы. В службах
времени ОСРВ используются часы реального времени. Обычно
используются высокоточные аппаратные часы. Для отсчета временных
интервалов на основе часов реального времени создаются таймеры.
Для каждого процесса и потока определяются часы процессорного
времени. На базе этих часов создаются таймеры; которые измеряют
перерасход времени процессом или потоком, позволяя динамически
выявлять программные ошибки или ошибки вычисления максимально
возможного времени выполнения. В высоконадежных, критичных ко
времени системах важно выявление ситуаций, при которых задача
превышает максимально возможное время своего выполнения, т.к. при этом
работа системы может выйти за рамки допустимого времени отклика. Часы
времени выполнения позволяют выявить возникновение перерасхода
времени и активизировать соответствующие действия по обработке ошибок.
Большинство ОСРВ оперируют относительным временем. Что-то
происходит “до” и “после” некоторого другого события. В системе,
полностью управляемой событиями, необходим часовой механизм (ticker),
т.к. там нет квантования времени (time slicing). Однако, если нужны
временные метки для некоторых событий или необходим системный вызов
типа “ждать одну секунду”, то нужен тактовый генератор и/или таймер.
9.4. Средства организации взаимодействия процессов
в ОС реального времени
Микроядро операционной системы 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.
По умолчанию любой сигнал, полученный процессом, приводит к
завершению процесса (кроме нескольких сигналов, которые по умолчанию
игнорируются). Но процесс с приоритетом уровня суперпользователя может
защититься от нежелательных сигналов. В любом случае процесс может
содержать обработчик для каждого возможного сигнала. Сигналы удобно
рассматривать как разновидность программных прерываний.
9.5. Синхронное и асинхронное взаимодействие в ОС
реального времени
Обработчики прерываний обычно встроены в процессы, хотя каждый из
них исполняется асинхронно с процессом, в который он встроен. Обработчик
исполняется в контексте процесса и имеет доступ ко всем глобальным
переменным процесса. При работе обработчика прерываний прерывания
разрешены, но обработчик приостанавливается только в том случае, если
произошло более высокоприоритетное прерывание. Если это позволяется
аппаратной частью, к одному прерыванию может быть подключено несколько
обработчиков, каждый из которых получит управление при возникновении
прерывания.
При описании управления прерываниями обычно различают две
процедуры, а именно:
• программа обработки прерывания (ISR – interrupt servicing routine) –
программа низкого уровня в ядре с ограниченными системными вызовами,
• поток обработки прерывания (IST – interrupt servicing thread) –
поток уровня приложения, который управляет прерыванием, с доступом ко
всем системным вызовам.
Обычно ISR реализуются производителем аппаратуры, а драйверы
устройств выполняют управление прерываниями с помощью IST. Потоки
обработки прерываний действуют как любые другие потоки и используют ту же
самую систему приоритетов. Это означает, что проектировщик системы может
придать IST более низкий приоритет, чем приоритет потока приложения.
Редиректор прерываний является частью ядра и занимается
перенаправлением аппаратных прерываний в связанные с ними процессы.
Благодаря такому подходу возникает один побочный эффект — с аппаратной
частью компьютера работает ядро, оно перенаправляет прерывания процессам
— обработчикам прерываний.
Этот механизм позволяет пользователю избегать работы с аппаратным
обеспечением напрямую и тем самым избегать конфликтов между различными
процессами, работающими с одним и тем же устройством. Для обработки
сигналов от внешних устройств чрезвычайно важно минимизировать время
между возникновением события и началом непосредственной его обработки.
Этот фактор существен в любой области применения: от работы терминальных
устройств до обработки высокочастотных сигналов.
9.6. Средства обеспечения отказоустойчивости в ОС
реального времени
QNX была первой коммерческой операционной системой, построенной
на принципах микроядра и обмена сообщениями. Система реализована в виде
совокупности независимых (но взаимодействующих путем обмена
сообщениями) процессов различного уровня (менеджеры и драйверы), каждый
из которых реализует определенный вид услуг. Эти идеи позволили добиться
нескольких важнейших преимуществ. Вот как об этом написано на сайте,
посвященном операционной системе QNX:
Предсказуемость означает применимость системы к задачам жесткого
реального времени. QNX является операционной системой, которая дает
полную гарантию того, что процесс с наивысшим приоритетом начнет
выполняться практически немедленно, и критически важное событие
(например, сигнал тревоги) никогда не будет потеряно. Ни одна версия UNIX не
может достичь подобного качества, поскольку нереентерабельный код ядра
слишком велик. Любой системный вызов из обработчика прерывания в UNIX
может привести к непредсказуемой задержке (то же самое можно сказать про
Windows NT).
Масштабируемость и эффективность достигаются оптимальным
использованием ресурсов и означают применимость QNX для встроенных
(embedded) систем. В данном случае мы не увидим в каталоге /dev множества
файлов, соответствующих ненужным драйверам, что характерно для UNIX-
систем. Драйверы и менеджеры можно запускать и удалять (кроме файловой
системы, что очевидно) динамически, просто из командной строки. Мы можем
иметь только те услуги, которые нам реально нужны, причем это не требует
серьезных усилий и не порождает проблем.
Расширяемость и надежность обеспечиваются одновременно, поскольку
написанный драйвер не нужно компилировать в ядро, рискуя вызвать
нестабильность системы. Менеджеры ресурсов (служба логического уровня)
работают в третьем кольце защиты, и вы можете добавлять свои менеджеры, не
опасаясь за систему. Драйверы работают в первом кольце и могут вызвать
проблемы, но не фатального характера. Кроме того, их достаточно просто
писать и отлаживать.
Быстрый сетевой протокол FLEET1 прозрачен для обмена сообщениями,
автоматически обеспечивает отказоустойчивость, балансирование нагрузки и
маршрутизацию между альтернативными путями доступа.
Компактная графическая подсистема Photon, построенная на тех же
принципах модульности, что и сама операционная система, позволяет получить
полнофункциональный интерфейс GUI (расширенный интерфейс Motif),
работающий вместе с POSIX-совместимой операционной системой всего в 4
Мбайт памяти, начиная с i80386 процессора.
Основные механизмы организации распределенных вычислений
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)1 и многих других, используя то же сетевое оборудование. При этом
производительность компьютеров с операционной системой QNX в сети
приближается к производительности аппаратного обеспечения — настолько
малы задержки, вносимые операционной системой.
Помимо сообщений и очередей в операционной системе QNX для
взаимодействия задач и организации распределенных вычислений имеются так
называемые порты, которые позволяют формировать сигнал одного
конкретного условия и механизм исключений, о котором мы уже упоминали
ранее.
Порт подобен флагу, известному всем задачам на одном и том же узле (но
не на разных узлах). Он имеет только два состояния, которые могут
трактоваться как ?присоединить? и ?освободить?, хотя пользователь может
интерпретировать их по-своему, например ?занят? и ?доступен?. Порты
используются для быстрой простой синхронизации между задачей и
обработчиком прерываний устройства. Они нумеруются от нуля до 32
максимум (на некоторых типах узлов возможно и больше). Первые 20 номеров
зарезервированы для операционной системы.
С портом может быть выполнено три операции:
− присоединить порт,
− отсоединить порт,
− послать сигнал в порт.
Одновременно к порту может быть присоединена только одна задача.
Если другая задача попытается ?отсоединиться? от того же самого порта, то
произойдет отказ при вызове функции, и управление вернется к задаче, которая
в настоящий момент присоединена к этому порту. Это самый быстрый способ
обнаружить идентификатор другой задачи, подразумевая, что задачи могут
договориться использовать один номер порта. Напомним, что все
рассматриваемые задачи должны находиться на одном и том же узле. При
работе нескольких узлов специальные функции обеспечивают большую
гибкость и эффективность.
Любая задача может посылать сигнал в любой порт независимо от того,
была она присоединена к нему или нет (предпочтительно, чтобы не была).
Сигнал подобен неблокирующей передаче пустого сообщения. То есть
передатчик не приостанавливается, а приемник не получает какие-либо данные;
он только отмечает, что конкретный порт изменил свое состояние.
Задача, присоединенная к порту, может ожидать прибытия сигнала или
может периодически читать порт. Система QNX хранит информацию о
сигналах, передаваемых в каждый порт, и уменьшает счетчик после каждой
операции ?приема? сигнала (?чтение? возвращает счетчик и устанавливает его в
нуль). Сигналы всегда принимают перед сообщениями, давая им тем самым
больший приоритет над сообщениями. В этом смысле сигналы часто
используются обработчиками прерываний для того, чтобы оповестить задачу о
внешних (аппаратных) событиях. Действительно, обработчики прерываний не
имеют возможности посылать сообщения и должны использовать сигналы.
В отличие от описанных выше методов, которые строго
синхронизируются, исключения обеспечивают асинхронное взаимодействие. То
есть исключение может прервать нормальное выполнение потока задачи. Они,
таким образом, являются аварийными событиями. Операционная система QNX
резервирует для себя 16 исключений, чтобы оповещать задачи о прерываниях с
клавиатуры, нарушении памяти и подобных необычных ситуациях. Остальные
16 исключений могут быть определены и использованы прикладными
задачами. Системная функция может быть вызвана для того, чтобы позволить
задаче реализовать собственный механизм обработки исключений и во время
возникновения исключения выполнять свою внутреннюю функцию. Заметим,
что функция исключения задачи вызывается асинхронно операционной
системой, а не самой задачей. Поэтому исключения могут негативно повлиять
на операции (например, передачу сообщений), которые выполняются в это же
время. Обработчики исключений должны быть написаны очень аккуратно.
Одна задача может установить одно или несколько исключений для
другой задачи. Эти исключения могут быть комбинацией системных
исключений и исключений, определяемых приложениями, обеспечивая другие
возможности для межзадачного взаимодействия.
Благодаря такому свойству QNX, как возможность обмена посланиями
между задачами и узлами сети, программы не заботятся о конкретном
размещении ресурсов в сети. Это свойство придает системе необычную
гибкость. Так, узлы могут произвольно добавляться в систему и изыматься из
системы, не затрагивая системные программы. QNX имеет эту
конфигурационную независимость благодаря концепции виртуальных задач. У
виртуальных задач непосредственный код и данные, будучи на одном из
удаленных узлов, возникают и ведут себя так, как если бы они были
локальными задачами какого-то узла со всеми их атрибутами и привилегиями.
Программа, посылающая сообщение в сеть, никогда не направляет его точно.
Сначала она открывает виртуальный канал. Виртуальный канал связывает
между собой все виртуальные задачи. На обоих концах такой связи имеются
буферы, которые позволяют хранить самое большое послание из тех, которые
канал может нести в данном сеансе связи. Сетевой администратор помещает в
эти буферы все сообщения для соединенных задач. Виртуальная задача, таким
образом, занимает всего лишь пространство, необходимое для буфера и входа в
таблице задач. Чтобы открыть виртуальный канал, необходимо знать
идентификатор узла и задачи, с которой устанавливается связь. Для этого
требуется идентификатор задачи-администратора, ответственного за данную
функцию, или глобальное имя сервера. Не раскрывая здесь подробно механизм
обмена посланиями, добавим лишь, что задача может вообще выполняться на
другом узле, где, допустим, имеется более совершенный процессор.
Комментариев нет:
Отправить комментарий