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

[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 недостатков.

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

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

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

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

[Harvester]

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

Что-то теперь я совсем запутался. Как может указатель на запись"отдельно болтаться", если именно его необходимо класть в очередь после заполнения фрейма буфера. И потом, если уж мы используем два указателя, т.е. организуем кольцевой буфер, то какой смысл в очереди? Проще ведь будет использовать счетный семафор, да и по ресурсам выгоднее.

[zltigo]

Что-то теперь я совсем запутался. Как может указатель на запись"отдельно болтаться", если именно его необходимо класть в очередь после заполнения фрейма буфера.

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

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

То, что Вы пытаетесь описать, вообще буфера не требует , поскольку Вы упорно предполагаете, что в кольцевом буфере по определению рассчитанном на МНОГО фреймов лежит ОДИН. Для одного нужен ОДИН указатель - нет вопросов. Если Мы действительно используем кольцевой буфер, как буфер, а не лишнюю приблуду, то в нем могут лежать МНОГО фреймов, для них нужно МНОГО указателей. Эти указатели и лежат в очереди до того момента, когда процесс передачи извлечет очередной и начнет по нему вытаскивать из буфера информацию.

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

Поверье мне, что ошибок Вы и так наделаете.

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

Ненужные выкрутасы на ровном месте для ЧАСТНОГО случая. Ничего, кроме лишнего разнообразия в решении не дает.

[Dima_G]

Поверье мне, что ошибок Вы и так наделаете.

Ненужные выкрутасы на ровном месте для ЧАСТНОГО случая. Ничего, кроме лишнего разнообразия в решении не дает.

Это я уже обсуждать не буду, а то тема сведется к холивару С vs С++.
Остановимся на том, что почему-то мне так удобнее

а можно аргументировать? сам применяю new/delete и пытаюсь понять - будут грабли или нет.

Можно столкнуться с фрагментацией памяти
Ненормированное время выделения памяти
Нереентерабельность выделения памяти
Ну и мое ИМХО - при статическом распределении ресурсов система более предсказуема

вот, почитайте - зедсь есть немного про это
http://www.embedded.com/story/OEG20020222S0026

Сообщение отредактировал Dima_G - Nov 27 2009, 16:15

[zltigo]

Это я уже обсуждать не буду, а то тема сведется к холивару С vs С++.
Остановимся на том, что почему-то мне так удобнее

C++ тут АБСОЛЮТНО ни причем - на любом языке можете наваять оберток не имеющих никакого смысла и главное годящихся только для частного случая. Изобразить, например, "специальную очередь" для какого-либо фрейма можно по любому, только кроме лишнего исходного текста и лишних сущностей такие выкрутасы не дают ничего.

Можно столкнуться с фрагментацией памяти

А можно и нет, если принять меры.

Ненормированное время выделения памяти

Ну не надо использовать, например, линукс с файлами подкачки и прочим. Хотя именно в том-же линуксе драйвера делают и много много более мрачные системные вызовы

Нереентерабельность выделения памяти

Ну это если совсем без головы на плечах.

Ну и мое ИМХО - при статическом распределении ресурсов система более предсказуема

Эх, конечно. Только вот если с ресурсами напряг и всем нарезать их про запас не хватает?

[dxp]

C++ тут АБСОЛЮТНО ни причем - на любом языке можете наваять оберток не имеющих никакого смысла и главное годящихся только для частного случая. Изобразить, например, "специальную очередь" для какого-либо фрейма можно по любому, только кроме лишнего исходного текста и лишних сущностей такие выкрутасы не дают ничего.

Вы хотите сказать, что очередь на основе void* ничем не хуже очереди на основе TypeName*? С точки зрения удобства и безопасности использования.

[zltigo]

Вы хотите сказать, что очередь на основе void* ничем не хуже очереди на основе TypeName*? С точки зрения удобства и безопасности использования.

Я хочу сказать, что TypeName* ничем не лучше и делать нечто самодельное похожее на очередь ВМЕСТО механизма очередей системы, по причине того, что очередь с void* есть глупость.

Причем эта поделка не годится, если мы в очередь кладем разные сообщения. Да и если только один тип, то пользы от нее как от козла молока, ибо извлечение из очереди в большинстве случаев в одном месте и ошибиться с приведением (TypeName *) это надо сильно постараться, как и запихнуть в одном-нескольких местах программы очередь нечто другое. Эти экзерсисы что-то вроде подстелить несколько пучков соломки на землю для страховки при возможном падении с 5 этажа - хуже не будет, но и реальной пользы от лишних телодвижений никакой. Родить какую-нибудь конструкцию, например

#define put_typename( x ) { TypeName *tmp = x; put( tmp ); }

для "защиты" и создания лишней "своей" очереди я могу и на 'C', только находясь в здравом уме делать такого не буду, а уж тем более изготавливать костыли с TypeName* ВМЕСТО штатной очереди.

[dxp]

Я хочу сказать, что TypeName* ничем не лучше

Лучше принципиально. Наличием четкого статического контроля типов.

и делать нечто самодельное похожее на очередь ВМЕСТО механизма очередей системы, по причине того, что очередь с void* есть глупость.

Если системная очередь ограничена в виду используемого "системного" яыка С типом void*, то при наличие возможностей ++ имеет смысл не полениться написать обертку для работы с нормальными средствами языка, а не использовать затычку void*.

Причем эта поделка не годится, если мы в очередь кладем разные сообщения.

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

Да и если только один тип, то пользы от нее как от козла молока, ибо извлечение из очереди в большинстве случаев в одном месте и ошибиться с приведением (TypeName *) это надо сильно постараться, как и запихнуть в одном-нескольких местах программы очередь нечто другое. Эти экзерсисы что-то вроде подстелить несколько пучков соломки на землю для страховки при возможном падении с 5 этажа - хуже не будет, но и реальной пользы от лишних телодвижений никакой.

Ну, не все же такие "укротители кода", большинству людей свойствено ошибаться. И код пишется часто не только для себя. И цель - так спроектировать программу, чтобы в ней в идеале не было ни одного ручного преобразования типов (что, к сожалению, не всегда удается, но реально оправданные случаи - это, как правило, стыковка с "железом" - например, преобазование целого в адрес (указатель)). И не зря не последние люди в Computer Science говорят, что ручное преобразование типа чаще всего указывает на ошибку проектирования.

для "защиты" и создания лишней "своей" очереди я могу и на 'C', только находясь в здравом уме делать такого не буду, а уж тем более изготавливать костыли с TypeName* ВМЕСТО штатной очереди.

Да, на С ничего, кроме костылей не получается. Именно поэтому и появился С++ - именно как средство устранения горбатостей предка, с сохранением совместимости, но без костылей. И сегодня уже достаточно все это развито и доступно. Нет ни одной причины не использовать. И уж если некогда/не хочется/лень/т.п. в плане использования - это личное дело, но и обосновывать эту позицию тоже ни к чему - за этим ничего, кроме личного субъективизма нет.

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

[zltigo]

все вышеприведенное вас ни в чем не убедило. Т.ч. это скорее не к вам пост, а просто как флаг того, что есть и другое мнение по этому вопросу. Для сомневающихся, так сказать.

А должно было ? Самые главные плюсы плюсов, и это неизбежно, связаны с накладными расходами (и благодаря системному подходу эти расходы чаще всего МЕНЬШЕ, нежели неумелые реализации подобного на 'C' ), но именно в этом сила. Использование С++ только из-за того,что-бы местами в частных случаях избавится от какого-нибудь void * притянуто за уши .

Ну, не все же такие "укротители кода", большинству людей свойствено ошибаться.

Мне тоже - много и жестоко, только я точно могу сказать, что в 99% моих ошибок выявляющихся в процессе компиляции и легкой отладки и 99,999% ошибок выявляющихся в процессе эксплуатации используемый язык написания совсем не виноват .
P.S.
В 90x мне пришлось столкнуться с ADA - был один телекоммуникационный проект на западников. Вот уж язык,который старались создавать,как безошибочный, но доведенный до абсурда в том числе и с заветной целью военных взять военных специалистов и они все безошибочно напишут все, что и как нужно военным. Так вот, человек,который руководил поминаемым мной проектом, будучи и оставаясь ярым ADA-вцем буквально сбежал разорвав контракт с большими для себя потерями, когда в его предыдущий военный проект начали прикомандировывать военных специалистов прошедших курс обучения языку ADA. Им, и это совершенно естественно, легко удавалось делать умопомрачительное количество ошибок.

Если это Вас задело - извиняюсь. Я вкладывал в эту фразу следующий смысл
"Сишник работает с данными, как с куском памяти. Плюсовик - как с объектом"

Вы НИЧЕГО не знаете о программировании. Совсем Не путайте дурное "программирование", с Программированием.

[dxp]

Самые главные плюсы плюсов, и это неизбежно, связаны с накладными расходами

Главные плюсы плюсов основаны на использовании классов, как типов, определяемых пользователем. Это дает модель программы как прототипа реального мира. Где тут накладные расходы?

Использование С++ только из-за того,что-бы местами в частных случаях избавится от какого-нибудь void * притянуто за уши .

Не "избавиться от какого-нибудь void*", а привести программу к виду, в котором нет потенциально опасного кода из-за отсутствия контроля типов. И если это можно сделать без накладных расходов, добавив читабельности и безопасности использования, то это вполне достойная цель.

[zltigo]

добавив читабельности и безопасности использования, то это вполне достойная цель.

Цель нормальная, только, как я уже писал, от львиной доли ошибок сие не избавит. Как и использования классов не избавляет от их использования через анальное отверстие . И вынужден уже третий раз просить обратить внимание на то, с чего начались мои возражения и прямо ответить на вопрос (можете самому себе ) - писать самодельную очередь на C++ или использовать готовую системную пусть и с void* ? Как тут дела обстоят в этом конкретном случае и послужившим началом всего этого флейма с "улучшить читаемость, надежность и сопровождаемость программы"?

[dxp]

И вынужден уже третий раз просить обратить внимание на то, с чего начались мои возражения и прямо ответить на вопрос (можете самому себе ) - писать самодельную очередь на C++ или использовать готовую системную пусть и с void* ? Как тут дела обстоят в этом конкретном случае и послужившим началом всего этого флейма с "улучшить читаемость, надежность и сопровождаемость программы"?

Не вижу проблем инкапсулировать код системной void* очереди в класс/шаблон. Даже накладных каких-то не предвижу. И пользоваться этой безопасной и удобной оберткой. И писанины тоже много не должно быть - не так много функционала у очереди - push/pop, read/write, flush + еще может быть несколько сервисных функций.