Введение в QNX/Neutrino 2. Руководство по программированию приложений реального времени в QNX Realtime Platform

Три потока с различными приоритетами.

В данный момент выполняется поток Н. Потоку сервера S, имеющему наивысший приоритет, пока делать нечего, так что он находится в режиме ожидания и блокирован на функции MsgReceive. Поток L и хотел бы работать, но его приоритет ниже, чем у потока Н, который выполняется в данный момент. Все как вы и предполагали, да?

А теперь представьте себе, что поток Н принял решение «прикорнуть» на 100 миллисекунд — возможно, чтобы подождать медленное оборудование. Теперь выполняется поток L.

Вот тут-то все интересное и начинается.

В пределах своего нормального функционирования поток L посылает сообщение потоку сервера S, принуждая этим сервер S перейти в состояние READY и (поскольку поток S имеет высший приоритет из всех готовых к выполнению потоков) начать выполняться. К великому сожалению, сообщение, которое поток L направил к потоку сервера S, было сформулировано так: «Вычислить значение Пи с точностью до 50 знаков после запятой».

Очевидно, это займет более чем 100 миллисекунд. Поэтому, когда 100 миллисекунд сна потока Н истекут, поток Н перейдет в состояние READY — угадайте, что дальше? Поток Н не активизируется, постольку в состоянии READY находится поток S, имеющий более высокий приоритет!

Что здесь произошло? Произошло то, что поток с низким приоритетом «отстранил» от работы поток с более высоким приоритетом путем передачи процессора потоку с еще более высоким приоритетом. Это явление называется инверсией приоритетов.

Чтобы научиться не допускать таких вещей, мы должны поговорить о наследовании приоритетов. Простой вариант реализации наследования приоритета — заставить сервер S унаследовать приоритет клиентского потока:

Блокированные потоки.

При таком сценарии по истечении 100-миллисекундного интервала бездействия потока Н этот поток переходит в состояние READY и немедленно ставится на выполнение как имеющий наивысший приоритет.

Неплохо; однако, здесь есть еще один тонкий момент.

Предположим, что потоку Н вдруг становится нужно выполнить какие-то вычисления — например, найти 5034-е по порядку простое число. Он посылает сообщение потоку сервера S и блокируется.

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

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

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

Повышение приоритета сервера.

Здесь мы немного «обделяем» другие потоки, позволяя заданию потока L выполняться с приоритетом выше, чем он сам, но зато гарантируем, что поток Н получит свою заслуженную порцию процессорного времени.

Так в чем тут хитрость?

Никакой хитрости нет, QNX/Neutrino делает все для вас автоматически.

В QNX/Neutrino этот механизм реализован только на один уровень вглубь, так что если клиент посылает серверу сообщение, а этот сервер, в свою очередь, передает это сообщение другому серверу, то второй сервер наследует нормальный приоритет первого, а не приоритет, который первый унаследовал от клиента. Это означает, что если на первом сервере блокируется поток с более высоким приоритетом, то соответственно повышен будет приоритет только первого сервера (а поскольку первый сервер в этот момент блокирован на втором, приоритет которого уже не повышается и остается прежним, толку от этого не будет абсолютно никакого). Будьте внимательны!

Однако, и здесь есть еще одна тонкость. Как обеспечить возврат приоритета на тот уровень, который был до изменения?

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

Рассмотрим два варианта развития событий.

• После обслуживания клиента сервер выполняет еще какие-то дополнительные действия. Это он должен сделать на своем приоритете, а не на приоритете клиента.

• После обслуживания клиента сервер немедленно вызывает MsgReceive снова для обработки следующего запроса.

В первом случае для сервера было бы некорректно работать на приоритете клиента, поскольку он больше не делает для этого клиента никакой работы. Решение здесь очень простое. Используйте функцию pthread_setschedparam (мы ее обсуждали в главе «Процессы и потоки») для возврата приоритету нужного значения.

Что касательно второго случая, то ответ достаточно прост. Кому какое дело?

Подумайте об этом. Какая разница, станет сервер RECEIVE-блокированным на приоритете 29 или на приоритете 2?

Главное — что он RECEIVE-блокирован! А коль скоро в этом состоянии он не расходует процессорное время, его приоритет является несущественным. Как только функция MsgReceive разблокирует сервер, сервером будет унаследован приоритет нового клиента, и все будет работать как полагается.

Резюме

Обмен сообщениями представляет собой чрезвычайно мощную концепцию и является одним из основополагающих принципов, на которых построена QNX/Neutrino (как и все предыдущие версии QNX).

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

Основные преимущества передачи сообщений:

• Содержание сообщения не зависит от местоположения адресата (локально или удаленно в сети).

• Сообщения обеспечивают четкую границу развязки клиентов и серверов.

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

Глава 3 Часы, таймеры и периодические уведомления

Часы и таймеры

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