Роб Кёртен - Введение в QNX/Neutrino 2. Руководство по программированию приложений реального времени в QNX Realtime Platform
Механизм, который обеспечивает отправку сообщения без блокирования, называют «импульсом» (pulse). Импульс — это миниатюрное сообщение, которое:
• может перенести 40 бит полезной информации (8-битный код и 32 бита данных);
• является неблокирующим для отправителя;
• может быть получено точно так же, как и сообщение другого типа;
• ставится в очередь, если получатель не заблокирован в ожидании сообщения.
Прием импульса
Прием импульса выполняется очень просто: короткое, четко определенное сообщение передается функции MsgReceive(), как будто поток отправил обычное стандартное сообщение. Единственное различие состоит в том, что вы не сможете применить функцию MsgReply() к такому сообщению, поскольку, кроме всего прочего, общая идея импульса состоит в том, что это сообщение по своей сути является асинхронным. В данном разделе мы рассмотрим другую функцию, MsgReceivePulse(), применение которой полезно при обработке импульсов.
Единственно что забавляет при работе с импульсами — это то, что идентификатор отправителя, который возвращается функцией MsgReceive() при их приеме, имеет нулевое значение. Это верный индикатор того, что принятое сообщение является импульсом, а не стандартным сообщением клиента. В коде серверов вы будете часто видеть фрагменты, подобные представленному ниже:
#include <sys/neutrino.h>
rcvid = MsgReceive(chid, ...);
if (rcvid == 0) { // Это импульс
// Определить тип импульса
// Обработать его
} else { // Это обычное сообщение
// Определить тип сообщения
// Обработать его
}
Что внутри импульса?Итак, вы принимаете сообщение с нулевым идентификатором отправителя. Что у него внутри? Вот фрагмент заголовочного файла <sys/neutrino.h>:
struct _pulse {
_uint16 type;
_uint16 subtype;
_int8 code;
_uint8 zero[3];
union sigval value;
_int32 scoid;
};
Элементы type и subtype равны нулю (это еще один признак того, что перед нами импульс); содержимое элементов code и value определяется отправителем. В общем случае элемент code будет указывать на причину, по которой был отправлен импульс, а параметр value будет содержать 32 бита данных, ассоциируемых с данным импульсом. Эти два поля и есть те самые 40 бит контента; другие поля пользователем не настраиваются.
Ядро резервирует отрицательные значения параметра code, оставляя 127 значений для программистов — для использования по своему усмотрению.
Элемент value в действительности является элементом типа union:
union sigval {
int sival_int;
void *sival_ptr;
};
Поэтому (в развитие примера с сервером, представленного выше) вы часто будете видеть программу, подобную этой:
#include <sys/neutrino.h>
rcvid = MsgReceive(chid, ...
if (rcvid == 0) { // Импульс
// Определить тип импульса
switch (msg.pulse.code) {
case MY_PULSE_TIMER:
// Сработал один из наших таймеров,
// надо что-то делать...
break;
case MY_PULSE_HWINT:
// Импульс получен от обработчика прерывания.
// Надо заглянуть в поле «value»...
val = msg.pulse.value.sival_int;
// Сделать что-нибудь по этому поводу...
break;
case _PULSE_CODE_UNBLOCK:
// Это импульс от ядра, разблокирующий клиента
// Сделать что-нибудь по этому поводу...
break;
//и так далее...
}
} else { // Обычное сообщение
// Определить тип сообщения
// Обработать его
}
В этой программе предполагается, конечно, что вы описали структуру msg так, чтобы она содержала элемент «struct _pulse pulse;», и что определены константы MY_PULSE_TIMER и MY_PULSE_HWINT. Код импульса _PULSE_CODE_UNBLOCK — один из тех самых отрицательных кодов, зарезервированных для ядра, как это было упомянуто выше. Вы можете найти полный список этих кодов (а также краткое описание поля value) в <sys/neutrino.h>.
Функция MsgReceivePulse()Функции MsgReceive() и MsgReceivev() могут принимать либо стандартное сообщение, либо импульс. Однако, возможны ситуации, когда вы пожелаете принимать только импульсы. Лучшим примером этого является ситуация с сервером, когда вы приняли запрос от клиента на выполнение чего-нибудь, но не можете выполнить этот запрос сразу (возможно, из-за длительной операции, связанной с аппаратными средствами). В таких случаях следует, как правило, настроить аппаратные средства (или таймер, или что-нибудь еще) на передачу вам импульса всякий раз, когда происходит некое значительное событие.
Если вы напишете ваш сервер по стандартной схеме «ждать сообщения в бесконечном цикле», вы можете оказаться в ситуации, когда один клиент посылает вам запрос, а потом, пока вы ожидаете импульса, который должен сигнализировать об отработке запроса, приходит запрос от другого клиента. Вообще говоря, это как раз то что нужно — в конце концов, мы хотели иметь способность одновременно обслуживать множество клиентов. Однако, у вас могут быть веские основания отказать клиенту в обслуживании — например, если обслуживание клиента слишком ресурсоемко, и надо ограничить численность одновременно обрабатываемой клиентуры.
В таком случае вам потребуется обеспечить возможность «выборочного» приема только импульсов. Тут-то и становится актуальной функция MsgReceivePulse():
#include <sys/neutrino.h>
int MsgReceivePulse(int chid, void *rmsg, int rbytes,
struct _msg_info *info);
Видно, что ее параметры те же, что и у функции MsgReceive() — идентификатор канала, буфер (и его размер), и параметр info — мы обсуждали его в параграфе «Кто послал сообщение?» Заметьте, что параметр info не применяется в импульсах. Вы можете спросить, почему он представлен в списке параметров. Ответ незамысловат: так было проще сделать. Просто передайте NULL!
Функция MgsReceivePulse() способна принимать только импульсы. Так, если бы у вас был канал с множеством потоков, блокированных на нем с помощью функции MsgReceivePulse() (и ни одного потока, блокированного на нем с помощью функции MsgReceive()), и некий клиент попытался бы отправить вашему серверу сообщение, то этот клиент остался бы заблокированным по передаче (Send-blocked) до тех пор, пока какой-либо поток сервера не вызовет MsgReceive(). Тем временем функция MsgReceivePulse() будет спокойно принимать импульсы.
Единственное, что можно гарантировать при совместном применении функций MsgReceivePulse() и MsgReceive(), — что функция MsgReceivePulse() обеспечит прием исключительно импульсов. Функция MsgReceive() сможет принимать как импульсы, так и обычные сообщения! Это происходит потому, что применение функции MsgReceivePulse() зарезервировано специально для случаев, где нужно исключить получение сервером обычных сообщений.
Это немного вводит в замешательство. Так как функция MsgReceive() может принимать и обычные сообщения, и импульсы, а функция MsgReceivePulse() может принимать только импульсы, то как быть с сервером, в котором применяются обе функции? Общий ответ такой. У вас есть пул потоков, выполняющих MsgReceive(). Этот пул потоков (один или более потоков — это зависит от числа клиентов, которое вы хотели бы обслуживать одновременно) отвечает за обработку запросов от клиентов.
Поскольку вы пытаетесь управлять численностью потоков- обработчиков, и некоторым из этих потоков может понадобиться блокироваться в ожидании импульса (например, от оборудования или от другого потока), вы блокируете поток-обработчик при помощи функции MsgReceivePulse(). Функция MsgReceivePulse() принимает только импульсы, а значит, ее применение гарантирует, что пока вы ждете импульса, к вам ненароком не просочится никакой клиентский запрос.
Функция MsgDeliverEvent()
Как было упомянуто выше в параграфе «Иерархический принцип обмена», существуют ситуации, когда приходится нарушать естественное направление передач.
Такой случай возможен, когда у вас есть клиент, который посылает серверу сообщение и при этом не хочет блокироваться, а результат может быть доступен только через некоторое время. Конечно, вы могли бы частично решить эту проблему путем применения многопоточных клиентов, выделяя в клиенте отдельный поток для блокирующих вызовов сервера, но это не всегда с успехом работает в больших системах, поскольку при большом количестве серверов количество ждущих потоков было бы слишком велико. Но допустим, вы не хотите здесь использовать многопоточность, а вместо этого вам нужно, чтобы сервер ответил клиенту сразу, и чем-то вроде «Заказ принят; я скоро вернусь». Здесь, поскольку сервер ответил, клиент теперь свободен продолжать свою работу. После того как сервер отработает запрос клиента, ему потребуется как-то сказать клиенту «Проснись, вот твой заказ.» Очевидно, как мы это уже видели при анализе иерархического принципа обмена, сервер не должен передавать сообщения клиенту, потому что если клиент в это же время отправит сообщение серверу, это может вызывать взаимную блокировку. Так как же сервер может послать сообщение клиенту без нарушения иерархического принципа?
