"Правильное" использование OS::message Опции

[Zeal0t]

Добрый день.
Осваиваю scmRTOS.
Пробую простой пример.

Исходные данные:
Лишнее убрал.
Оставлена только суть.

CODE

struct tagMessageFQ {
uint16_t Value;
};

typedef OS::process<OS::pr0, 200> TProcessFQ;
typedef OS::process<OS::pr1, 200> TProcessAPP;

typedef OS::message<tagMessageFQ> TMessageFQ;

CODE

namespace OS
{
template <> OS_PROCESS void TProcessFQ::exec()
{
FOREVER {
// if (MessageFQ.wait(2)) { // вариант 1
if (MessageFQ.is_non_empty()) { // вариант 2
TP2.On();
{
MessageFQ.out(msgFQ);
MessageFQ.reset();
regFQPWM = msgFQ.Value;
}
TP2.Off();
}
sleep(1);
}
}
}

CODE

static tagMessageFQ msgFQ;

namespace OS
{
template <> OS_PROCESS void TProcessAPP::exec()
{
msgFQ.Value = 0;

FOREVER {

TP1.On();
msgFQ.Value = msgFQ.Value+1;
MessageFQ = msgFQ;
MessageFQ.send();
TP1.Off();

sleep(1);
}
}
}

TP1, TP2 - просто пины на процессоре, куда зацеплены щупы скопа.
TP1 - желтый
TP2 - синий

Процесс APP шлет для FQ новое значение через message.
Если проверку наличия сообщения делать через вариант [1] то получаем вот такую картинку:



Т.е. процесс увидел сообщение и его прочитал. Все верно. Но т.к. ожидание через wait идет с параметром
то получаем как бы задержку внутри желтого импульса.

Если используем вариант [2] то получаем следующее:



Т.е. сообщение было получено и на следующем витке планировщика процесс FQ "увидел" данные и их забрал.

Все работает корректно в обоих случаях.
Но если далее процесс FQ будет расти то и задержка для процесса APP будет расти.
В связи с чем вопрос: я неверно понял принцип использования сообщений или это нормально и можно использовать любой вариант?

[AHTOXA]

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

[Zeal0t]

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

Я пробовал на каналах. Логика, в принципе, у них такая же - передать для другого процесса данные. Но после просмотра листинга от компилятора они мне показались избыточны для передачи одного единственного значения. Слишком там много кода получается.

[AHTOXA]

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