Теперь вернемся к тому, о чем мы говорили в разделе «Кто послал сообщение?»). Параметр struct _msg_info содержит, среди всего прочего, два дескриптора узлов:
struct _msg_info {
int nd;
int srcnd;
...
};
Мы определили в описании для этих двух полей, что:
• nd — дескриптор принимающего узла с точки зрения передающего;
• srcnd — дескриптор передающего узла с точки зрения принимающего.
Так, для приведенного выше примера, где узел wintermute — локальный, а узел magenta — удаленный, когда узел magenta посылает нам (узлу wintermute) сообщение, эти поля заполняются следующим образом:
• nd равен 7;
• srcnd равен 4.
Одним из интересных моментов в операционных системах реального времени является феномен инверсии приоритетов.
Инверсия приоритетов наблюдается, например, в случае, когда поток с низким приоритетом потребляет все процессорное время, в то время как в состоянии готовности находится поток с более высоким приоритетом.
Вы, наверное, сейчас думаете: «Минуточку! Вы утверждали ранее, что поток с более высоким приоритетом будет всегда вытеснять поток с более низким приоритетом! Как же такое может быть?»
Вы абсолютно правы. Поток с более высоким приоритетом всегда будет вытеснять поток с более низким приоритетом. Но при этом все-таки может произойти кое-что интересное. Давайте рассмотрим сценарий с тремя потоками (в трех различных процессах, для простоты рассмотрения), где «L» — поток с низким приоритетом, «Н» — поток с высоким приоритетом, и «S» — сервер. На рисунке показаны все три потока со своими приоритетами.
Три потока с различными приоритетами.
В данный момент выполняется поток Н. Потоку сервера 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. Мы увидим, как и почему мы должны использовать таймеры, а также рассмотрим теоретические положения, которые этому сопутствуют. Далее мы обсудим способы опроса и настройки часов реального времени.
