Использование очереди сообщений Опции

[Harvester]

Здравствуйте.

Помогите пожалуйста разобраться с использованием очереди сообщений.
У меня есть процесс (A), периодически передающий пакеты по UART. Второй процесс ( может в произвольные моменты требовать от
него передачи пакетов, определяемых пользователем. Для этого я собираюсь использовать очередь сообщений.
Но ведь в очередь заносится только указатель на пакет, а как быть с самими данными, особенно если пришло несколько запросов подряд?

Правильно ли я понимаю, что мне необходимо помимо очереди создать что-то вроде кольцевого буфера и обернуть функции POST и PEND для очереди сообщений в свои функции, которые будут брать/класть указатель из/в очереди, извлекать данные из буфера и обслуживать указатели этого буфера?

Спасибо.

PS. Пока писал сообщение, в голову пришла ещё одна мысль - процесс B динамически выделяет память, а процесс A после вычитывания сообщения её освобождает.

[Dima_G]

Все зависит от того - что подразумеватеся под элементом очереди. Если буфер (+указатель на следующий элемент), то дополнительного пула не нужно))))

Динамически выделять / освобождать память не сильно хорошая идея в embedded системах

[Harvester]

Все зависит от того - что подразумеватеся под элементом очереди. Если буфер (+указатель на следующий элемент), то дополнительного пула не нужно))))

Динамически выделять / освобождать память не сильно хорошая идея в embedded системах

В большинстве осей, в той же uC/OS в очереди хранятся именно указатели.

А по второму замечанию - полностью согласен. Потому, наверное, эта идея пришла только в самый последний момент (как самая негодная)

Сообщение отредактировал Harvester - Nov 27 2009, 08:47

[Dima_G]

В большинстве осей, в той же uC/OS в очереди хранятся именно указатели.

Ну а что мешает сделать свою очередь?

Ни либо на указателях я бы делал так:
хранил отдельно пул буферов

Создал бы очередь - обозвал бы ее FreeQueue
Создал бы очередь в драйвере - назвал TxQueue;

Далее - приложение берет из очереди FreeQueue указатель (считай - буфер), заполняет буфер и помещает указатель на него в TxQueue

Драйвер обнаруживет в TxQueue пакет, обрабатывает его (передает), и помещает в FreeQueue


как-то так

[Harvester]

Ну а что мешает сделать свою очередь?

Ни либо на указателях я бы делал так:
хранил отдельно пул буферов

Создал бы очередь - обозвал бы ее FreeQueue
Создал бы очередь в драйвере - назвал TxQueue;

Далее - приложение берет из очереди FreeQueue указатель (считай - буфер), заполняет буфер и помещает указатель на него в TxQueue

Драйвер обнаруживет в TxQueue пакет, обрабатывает его (передает), и помещает в FreeQueue


как-то так

А ведь так можно вообще обойтись без очереди - использовать пул буферов и счётный семафор!

[zltigo]

А ведь так можно вообще обойтись без очереди - использовать пул буферов и счётный семафор!

Нафига организовывать очередь руками из дополнительного буфера и семафора, если их поддержка УЖЕ ЕСТЬ в системе.
Если очередь можно пользовать только для указателей, то нужно только добавить к ней один буфер и все.

В большинстве осей, в той же uC/OS в очереди хранятся именно указатели.

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

Динамически выделять / освобождать память не сильно хорошая идея в embedded системах

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

[Dima_G]

Нафига организовывать очередь руками из дополнительного буфера и семафора, если их поддержка УЖЕ ЕСТЬ в системе.
Если очередь можно пользовать только для указателей, то нужно только добавить к ней один буфер и все.

Под буфером, Вы имеете в виду - циклический буфер?

Мне большей частью удобнее НЕ использовать системные очереди. Исключительно из-за их "сишной" природы, как следствие - потери информации о типе вложенного объекта

[zltigo]

Под буфером, Вы имеете в виду - циклический буфер?

Совершенно не имеет значения какой - любой, какой оптимален для данного типа данных, нагрузки и прочего. Довольно часто очень просто и удобно реализуются линейные под фрейм расположенные внутри кольцевого. А если фреймы фиксированной длинны, то сам бог велел так делать - 0 недостатков.

Мне большей частью удобнее НЕ использовать системные очереди. Исключительно из-за их "сишной" природы, как следствие - потери информации о типе вложенного объекта

Еруда полная, а не причина, либо тип фиксирован, либо Вы его по любому будете восстанавливать по, например, заголовку.

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

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

[Dima_G]

Еруда полная, а не причина, либо тип фиксирован, либо Вы его по любому будете восстанавливать по, например, заголовку.

Реализации универсальных сишных очередей, которые я видел - обычно работают с void указателем на элемент:

Код

push(void* pObj_);
void* pop();

соответственно, никто не застрахован от ошибок

В С++ можно использовать такой подход

template <class ELEMENT>\
class TClQueue
{
push(ELEMENT* pclEl_);
ELEMENT* pop();

};

В эту очередь получится запихать либо ELEMENT, либо производные от него