Обучающий сайт

QNX в реальном времени

Синхронизация в распределенных системах.

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

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

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

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

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

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

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

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

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

Задержка прерывания

Задержка диспетчеризации

Стек прерываний

Задержка прерывания

Задержка прерывания - это интервал времени между аппаратным прерыванием и выполнением первой команды программного обработчика прерывания. QNX практически все время оставляет прерывания полностью разрешенными, поэтому задержка прерывания, как правило, не существенна. Однако некоторые критические фрагменты кода требуют, чтобы прерывания были временно запрещены. Максимальная продолжительность такого запрета обычно определяет худший случай задержки прерывания - в QNX это очень небольшая величина.
Следующая диаграмма иллюстрирует случай, когда аппаратное прерывание обрабатывается в установленном обработчиком прерывании. Обработчик прерывания либо просто выполнит команду возврата, либо при возврате запустит прокси.

Обработчик прерывания просто завершается.
Задержка прерывания (Til) на приведенной выше диаграмме отражает минимальную задержку - случай, когда прерывания были полностью разрешены в момент, когда произошло прерывание. В худшем случае задержка прерывания составит это время плюс наибольшее время, в течение которого QNX или выполняющийся процесс запрещает прерывания ЦП.

Задержка прерываний для различных процессоров
Следующая таблица содержит типичные значения задержки прерывания для разных процессоров:

Задержка диспетчеризации

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

Обработчик прерывания завершает работу и запускает прокси.
Важно отметить, что обработка большинства прерываний завершается без запуска прокси. В большинстве случаев обработчик прерывания сам может выполнить все необходимые действия. Запуск прокси, чтобы "разбудить" драйвер, процесс более высокого уровня, происходит только при наступлении важного события. Например, обработчик прерывания для драйвера последовательного порта при каждом прерывании "регистр передачи свободен" будет передавать один байт данных и запустит процесс более высокого уровня (Dev) только тогда, когда выходной буфер, наконец, опустеет.

Задержка диспетчеризации для различных процессоров
Следующая таблица содержит типичные значения задержки диспетчеризации для разных процессоров:

Стек прерываний

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

Выполняется процесс A. Прерывание IRQx вызывает выполнение обработчика прерывания Intx, который вытесняется IRQy и его обработчиком Inty. Inty запускает прокси, вызывающее выполнение процесса B, а Intx запускает прокси, вызывающее выполнение процесса C.

! ! ! Вы можете пройти тест нажав эту ссылку

Введение Связь между процессами Архитектура QNX Именование в QNX QNX в реальном времени Тест