Небольшая проблема с обработкой сообщений, сброс флага "Сообщение пусто" Опции

[sonycman]

Доброго времени суток!

Организую взаимодействие между двумя процессами с помощью сообщений.
Один процесс отправляет сообщение, другой - принимает.

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

CODE

//thread 1
command_message.send();
response_message.wait();
...

//thread 2
if (command_message.is_non_empty())
{
message_placeholder = command_message;
...
response_message.send();
...
}

Оказалось, что это не так, и необходимо после считывания принудительно сбрасывать сообщение функцией reset().

Но, может быть, удобнее было бы сделать автоматический сброс флага NonEmpty после отрабатывания оператора присваивания?

[dxp]

Доброго времени суток!

Организую взаимодействие между двумя процессами с помощью сообщений.
Один процесс отправляет сообщение, другой - принимает.

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

...

Оказалось, что это не так, и необходимо после считывания принудительно сбрасывать сообщение функцией reset().

Но, может быть, удобнее было бы сделать автоматический сброс флага NonEmpty после отрабатывания оператора присваивания?

Не очень понял, что не получалось. Логика работы OS::message (как и OS::TEventFlag) такова, что внутренний флаг NonEmpty взводится только в случае, если посылается сообщение, которое еще никто не ждет. В этом случае, когда какой-то процесс встанет на ожидание сообщения, он сразу обнаружит, что оно уже послано - по этому внутреннему флагу, в этом случае флаг NonEmpty автоматически сбрасывается. Если при вызове OS::message::send уже были ожидающие этого сообщения процессы, то эти процессы переводятся в состояние готовых к выполнению, а внутренний этот флаг NonEmpty не устанавливается - в этом просто нет необходимости - кто ждал, те и так получат управление в очередности, соответствующей их приоритетам.

Таким образом, вам достаточно было дождаться сообщения с помощью функции OS::message::wait, после этого спокойно можно читать тело сообщения. Никаких проверок (is_non_empty и т.п.) не нужно. Это штатный способ использования.

[sonycman]

Таким образом, вам достаточно было дождаться сообщения с помощью функции OS::message::wait, после этого спокойно можно читать тело сообщения. Никаких проверок (is_non_empty и т.п.) не нужно. Это штатный способ использования.

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

Поэтому делается проверка на наличие сообщения функцией is_non_empty(), и далее обработка сообщения только в случае его наличия.

То есть получается такая ситуация:
1. низкоприоритетный процесс отправляет сообщение высокоприоритетному. Последний в это время ожидает другое событие и не может обработать сообщение, поэтому внутри send() устанавливается флаг NonEmpty.
2. процесс получатель высвобождается и проверяет наличие сообщения, а затем вычитывает его оператором =.
3. Приходится вызовом reset() сбрасывать установленный флаг.

Можно ли избежать третьего пункта, добавив в обработчик оператора = сброс NonEmpty?

[dxp]

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

Поэтому делается проверка на наличие сообщения функцией is_non_empty(), и далее обработка сообщения только в случае его наличия.

То есть получается такая ситуация:
1. низкоприоритетный процесс отправляет сообщение высокоприоритетному. Последний в это время ожидает другое событие и не может обработать сообщение, поэтому внутри send() устанавливается флаг NonEmpty.
2. процесс получатель высвобождается и проверяет наличие сообщения, а затем вычитывает его оператором =.
3. Приходится вызовом reset() сбрасывать установленный флаг.

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

Можно ли избежать третьего пункта, добавив в обработчик оператора = сброс NonEmpty?

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

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

[sonycman]

Мне кажется, что у вас тут на уровне проектирования не совсем ладно. У вас получается, что процесс может одновременно ждать несколько сообщений, тогда в этом случае целесообразно применять не message, а channel. Тогда процесс просто ждет любого сообщения из канала, как только оно пришло, вычерпывает его оттуда и обрабатывает. А источники сообщений в своем темпе пихают сообщения в канал.

Ну что же, Вам виднее.

А мой процесс занимается загрузкой данных в память и передачей их по DMA.
В качестве сигнала готовности DMA использую event flag. Не дай бог сильно затянуть с реакцией на загрузку DMA, а если тут под ногами ещё будет путаться второстепенное сообщение...
Думаю, что канал в этом случае лишний.

[dxp]

Ну что же, Вам виднее.
...
Думаю, что канал в этом случае лишний.

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