Операционная система реального времени

Процесс разблокируется

Выполняется обработка сигнала

Функция Send( ) или Receive( ) возвратит код ошибки 

          Если процесс был SEND-блокирован в момент получения сигнала, то проблемы не возникает, потому что получатель еще не получил сообщение. Но если процесс был RECEIVE-блокирован, то вы не узнаете, было ли обработано посланное им сообщение и, следовательно, не будете знать, следует ли повторять Send( ). 
          Процесс, играющий роль сервера (т.е. получающий сообщения), может запросить, чтобы он получал извещение всякий раз, когда его процесс-клиент получает сигнал, находясь в состоянии REPLY-блокирован. В этом случае клиент становится SIGNAL-блокированным с ожидающим сигналом. Сервер получает специальные сообщения, описывающие тип сигнала. Сервер может затем выбрать один из следующих вариантов:          

Закончить выполнение запроса от клиента нормальным образом: клиент (процесс-отправитель) будет уведомлен, что его сообщение было обработано должным образом. 
ИЛИ

Освободить используемые ресурсы и возвратить код ошибки, указывающий, что процесс был разблокирован сигналом: клиент получит четкий признак ошибки. 
          Когда сервер отвечает процессу, который был SIGNAL-блокирован, то сигнал выдается непосредственно после возврата из функции Send( ), вызванной клиентом 
 
 

• Архитектура микроядра системы QNX

     

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

         Микроядро системы QNX координирует работу системных менеджеров.  

         +Настоящее ядро  

         Ядро - это "сердце" любой операционной системы. В некоторых операционных системах на него возлагается так много функций, что ядро, по сути, заменяет всю операционную систему!                   В QNX же Микроядро - это настоящее ядро. Во-первых, как и следует ядру реального времени, ядро QNX имеет очень маленький размер. Во-вторых, оно выполняет две важнейшие функции:

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

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

          Системные процессы 
          Все услуги операционной системы, за исключением тех, которые выполняются ядром, в QNX предоставляются через стандартные процессы. Типичная конфигурация QNX имеет следующие системные процессы:

Менеджер процессов (Proc)

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

Менеджер устройств (Dev)

Менеджер сети (Net) 

          Системные и пользовательские процессы 
          Системные процессы практически ничем не отличаются от любых написанных пользователем программ - они не имеют какого-либо скрытого или особого интерфейса, недоступного пользовательским процессам.
          Именно за счет такой системной архитектуры QNX обладает уникальной наращиваемостью. Так как большинство услуг операционной системы предоставляются стандартными процессами QNX, то расширение операционной системы требует всего лишь написания новой программы, обеспечивающей новую услугу!
          Фактически, граница между операционной системой и прикладной программой может быть очень размыта. Единственный критерий, по которому мы можем отличить прикладные процессы и системные сервисные процессы, состоит в том, что процесс операционной системы управляет каким-либо ресурсом в интересах прикладного процесса 
          Предположим, что вы написали сервер базы данных. Как же должен быть классифицирован этот процесс? 
          Точно так же, как сервер файловой системы принимает запросы (в QNX реализованные через механизм сообщений) на открытие файлов и запись или чтение данных, это будет делать и сервер базы данных. Хотя запросы к серверу базы данных могут быть и более сложными, сходство обоих серверов заключается в том, что оба они обеспечивают доступ к ресурсу посредством запросов. Оба они являются независимыми процессами, которые могут быть написаны пользователем и запускаться по мере необходимости. 
          Сервер базы данных может рассматриваться как процесс в одном случае и как приложение в другом. Это действительно не имеет значения! Важно то, что создание и выполнение таких процессов в QNX не требует абсолютно никаких изменений в стандартных компонентах операционной системы. 

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

Стать расширением  определенного системного процесса.

Продолжать  выполнение как независимый процесс 
 
 

• Именование в распределенных системах
• (Сначала рассмотрим, как реализуется именование в распределенных системах)

    

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

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

         Имена в распределенных системах могут быть двух видов:

Глобальное имя. Обозначает одну и туже сущность в независимости от того, где в системе это имя используется.

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

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

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




• Именование В QNX


      &nbspQNX стимулирует разработку приложений, которые разбиты на несколько взаимодействующих процессов. Такое приложение, которое существует как группа взаимодействующих процессов, имеет большие возможности распараллеливания и может быть распределено по сети для лучшей производительности.
          Однако разделение приложений на взаимодействующие процессы требует ряда специальных соображений. Чтобы взаимодействующие процессы могли установить связь между собой, они должны иметь возможность определить идентификаторы друг друга. Например, допустим, что имеется сервер базы данных, который может обслуживать произвольное количество клиентов. Клиенты могут запускаться и прекращать работу в любое время, однако сервер всегда остается доступным. Как процессы-клиенты узнают идентификатор процесса-сервера базы данных с тем, чтобы послать ему сообщение? 
          В QNX процессы могут присваивать себе символьные имена. В контексте одного узла процесса могут зарегистрировать эти имена у Менеджера процессов на том узле, на котором они выполняются. Остальные процессы могут затем запросить у Менеджера процессов идентификатор процесса, ассоциированный с определенным именем. 
          Ситуация становится более сложной, если мы рассмотрим сеть, в которой сервер обслуживает клиентов, находящихся на различных узлах. Поэтому в QNX предусмотрена поддержка как глобальных , так и локальных имен.  Глобальные имена определены для всей сети, в то время как локальные имена определены только для того узла, на котором они зарегистрированы. 
              Глобальные имена начинаются с косой черты (/). Например: 


         

 Чтобы сделать возможным использование глобальных имен, хотя бы на одном узле сети должен быть запущен процесс, известный как определитель имен (утилита nameloc). Этот процесс ведет учет всех зарегистрированных глобальных имен.
          В каждый момент времени в сети могут быть запущены до десяти определителей имен. Каждый хранит идентичные копии всех активных глобальных имен. Такая избыточность гарантирует нормальное функционирование сети, даже если один или несколько узлов, обеспечивающих определение имен, выйдут из строя одновременно. 
          Чтобы зарегистрировать имя, процесс сервер использует функцию Си qnx_name_attach(). Чтобы определить процесс по имени, процесс клиент использует функцию Си qnx_name_locate(). 
 

• Синхронизация в распределенных системах.
• (Сначала рассмотрим реализацию cинхронизации в распределенных системах)

     

         Синхронизация реального масштаба времени.   

        В автоматизированных системах реального масштаба времени производится обязательная синхронизация всех ЭВМ с единым временем, данную проблему решает служба времени, распределенная по всем ЭВМ системы. Если одна из ЭВМ системы имеет приемник сигналов общемирового времени, то такая ЭВМ называется сервер единого времени.        

Задача службы времени заключается в синхронизации системных часов всех ЭВМ системы с сервером единого времени.  

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

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

        Алгоритм Кристиана . Периодически не реже чем через каждые "дельта" делить на два "ро" единиц времени, каждая ЭВМ посылает серверу единого времени запрос о точном времени. Сервер так быстро как это возможно отвечает сообщением, содержащим значение точного времени.  

        Алгоритм Беркли. Сервер единого времени периодически опрашивает системные часы каждой ЭВМ сети и предлагает им установить их системные часы на новое время.   
 

        Синхронизация процессов   

         Для процессов не критичных к использованию общемирового времени используется синхронизация называемая логические часы Лампорта. 

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

        (Теперь рассмотрим реализацию реального времени в системе QNX)

Несколько слов о реальном времени  
 

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