Вопрос решил так.

OS::TEventFlag FL1;
OS::TEventFlag FL2;
OS::TEventFlag FL3;

//---------------------------------------------------------------------------
OS_PROCESS void TProc1::Exec()
{
FL1.Signal();
for(;;)
{
if(FL1.Wait())
{ ...
FL2.Signal();
}
}
}
//---------------------------------------------------------------------------
OS_PROCESS void TProc2::Exec()
{
for(;;)
{
if(FL2.Wait())
{ ...
FL3.Signal();
}
}
}
//---------------------------------------------------------------------------
OS_PROCESS void TProc3::Exec()
{
for(;;)
{
if(FL3.Wait())
{ ...
FL1.Signal();
}
}
}
//---------------------------------------------------------------------------
Хочу увидеть критику и ценные замечания.

Сообщение отредактировал alexander55 - Oct 3 2007, 09:47

Но это шлифовка. В остальном должно работать.

Спасибо.

Правильно ли я понимаю, что
минимальный джентальментский набор средств межпроцессного взаимодействия (при этом сохраняя всю функциональность):
1.OS:message
2.OS::channel

Нет, OS::TService Оно работает, но еще не готово к выпуску в широкие массы.
А если серьезно - вопрос философский. Я TEventFlag и TMutex использую чаще чем channel и message.

И когда ждать? Я себя отношу к широким массам.


Вот меня и интересует философия scmRTOS. Мне казалось, автор хотел дать минимальный набор универсальных инструментов для решения максимального количества задач.

Возьмите из репозитория и пробуйте себя в роли автора.


Универсальных в полном смысле нет и быть не может. Как правило, наиболее часто используемые TEventFlag и TMutex. Исходная идея была, действительно, иметь минимально необходимый набор разнокачественных средств, но так, чтобы не страдала производительность и гибкость от недостатка оных. Движение в сторону TService обусловлено тем, что все-таки есть случаи, когда кому-то хочется более специализированного поведения и функциональности, чем имеется в наборе.

Спасибо всем за ответы.
Предлагаю выкладывать в этом топике ответы на вопросы по использованию встроенных средств межпроцессного взаимодействия в scmRTOS. Это будет интересно всем, кто использует scmRTOS.
Например (мой скромный вклад) .
Вопрос. Как средствами scmRTOS организуется выполнение процесса с заданной частотой.
Ответ.
...
OS::TEventFlag FL3;
...
OS_PROCESS void TProc3::Exec()
{
for(;;)
{
FL3.Wait(100);
...
}
}
Пояснение. Процесс 3 запускается через 100 тактов системного таймера (период процесса 3 - 100 мс при периоде таймера 1 мс).

Спасибо, Ваш вариант лучше.

Сообщение отредактировал alexander55 - Oct 8 2007, 07:52

Оба варианта неправильные - не учитывают время исполнения самого процесса. По-честному надо бы считывать системное время, смотреть сколько осталось до "Часа Х" и засыпать уже на это время. Вот только есть одна грабля - если времени не осталось, то вместо исполнения без ожидания получим Sleep(0), т.е. навечно, а если не успели и "час Х" уже прошел - то опять же вместо исполнения без паузы получим ожидание на время переполнения системного таймера.

Вы правы Сергей. Если понадобится точное время, я могу предложить такой вариант.
//-------------------------------------------------
class TTimer {
int Delay;
int Setting;
public:
TTimer(x) { Setting=x;Delay=x;};
void Run(void) { if(--!Delay) {Delay=Setting; FL.Signal();};};
};
//--------------------------------------------------
TTimer Tim100(100);
...
И где-то в системном таймере
...
Tim100.Run();
...
//--------------------------------------------------
Ну а в процессе

OS::TEventFlag FL3;
...
OS_PROCESS void TProc3::Exec()
{
for(;;)
{
FL.Wait();
...
}
}
PS. Так вроде чисто получается.

Ну, совсем для красоты я бы сделал FL3 членом TTImer. Инкапсуляция, так сказать. А сам решаю так:

Здесь есть подводный камень с инициализацией (хотя можно наследовать виртуально). Я бы не стал так делать.


return 0;
Здесь будет выход из цикла for. Это потенциально опасно.

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