[alexander55 0]

Вопрос, конечно, правильный.

Можно все завести в один процесс, но хочется для самообразования это знать.

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

 

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();

}

}

}

//---------------------------------------------------------------------------

Хочу увидеть критику и ценные замечания.

Изменено 3 октября, 2007 пользователем alexander55

[Сергей Борщ 122]

Хочу увидеть критику и ценные замечания.

OS::TEventFlag FL1(OS::TEventFlag::efOn);
OS_PROCESS void TProc1::Exec()
{
   for(;;)

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

[alexander55 0]

OS::TEventFlag FL1(OS::TEventFlag::efOn);

Спасибо.

[alexander55 0]

Правильно ли я понимаю, что

минимальный джентальментский набор средств межпроцессного взаимодействия (при этом сохраняя всю функциональность):

1.OS:message

2.OS::channel

[Сергей Борщ 122]

Правильно ли я понимаю, что

минимальный джентальментский набор средств межпроцессного взаимодействия (при этом сохраняя всю функциональность):

1.OS:message

2.OS::channel

Нет, OS::TService :) Оно работает, но еще не готово к выпуску в широкие массы.

А если серьезно - вопрос философский. Я TEventFlag и TMutex использую чаще чем channel и message.

[alexander55 0]

Нет, OS::TService :) Оно работает, но еще не готово к выпуску в широкие массы.

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

 

А если серьезно - вопрос философский.

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

[dxp 35]

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

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

 

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

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

[alexander55 0]

Спасибо всем за ответы.

Предлагаю выкладывать в этом топике ответы на вопросы по использованию встроенных средств межпроцессного взаимодействия в scmRTOS. Это будет интересно всем, кто использует scmRTOS.

Например (мой скромный вклад) .

Вопрос. Как средствами scmRTOS организуется выполнение процесса с заданной частотой.

Ответ.

...

OS::TEventFlag FL3;

...

OS_PROCESS void TProc3::Exec()

{

for(;;)

{

FL3.Wait(100);

...

}

}

Пояснение. Процесс 3 запускается через 100 тактов системного таймера (период процесса 3 - 100 мс при периоде таймера 1 мс).

[dxp 35]

Спасибо всем за ответы.

Предлагаю выкладывать в этом топике ответы на вопросы по использованию встроенных средств межпроцессного взаимодействия в scmRTOS. Это будет интересно всем, кто использует scmRTOS.

Например (мой скромный вклад) .

Вопрос. Как средствами scmRTOS организуется выполнение процесса с заданной частотой.

Ответ.

...

OS::TEventFlag FL3;

...

OS_PROCESS void TProc3::Exec()

{

for(;;)

{

FL3.Wait(100);

...

}

}

Пояснение. Процесс 3 запускается через 100 тактов системного таймера (период процесса 3 - 100 мс при периоде таймера 1 мс).

OS_PROCESS void TProc3::Exec()
{
    for(;;)
    {
        Sleep(100);
        ...
    }
}

[alexander55 0]

OS_PROCESS void TProc3::Exec()
{
    for(;;)
    {
        Sleep(100);
        ...
    }
}

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

Изменено 8 октября, 2007 пользователем alexander55

[Сергей Борщ 122]

Как средствами scmRTOS организуется выполнение процесса с заданной частотой.

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

[alexander55 0]

Оба варианта неправильные - не учитывают время исполнения самого процесса. По-честному надо бы считывать системное время, смотреть сколько осталось до "Часа Х" и засыпать уже на это время. Вот только есть одна грабля - если времени не осталось, то вместо исполнения без ожидания получим 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. Так вроде чисто получается. :yeah:

[Сергей Борщ 122]

PS. Так вроде чисто получается. :yeah:

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

typedef TTimeout timeout_t;
    timeout_t Time_X = OS::GetTickCount() + timeout;     // now + timeout

    for(;;)
    {
        timeout_t Timeout = Time_X - OS::GetTickCount();
        if((timeout_t)(Timeout - 1) > timeout )
            return 0;
        if(!pUART->getchar(RxData, Timeout))            // timeout, packet broken
            return 0;

[alexander55 0]

Ну, совсем для красоты я бы сделал FL3 членом TTImer.

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

 

typedef TTimeout timeout_t;
    timeout_t Time_X = OS::GetTickCount() + timeout;     // now + timeout

    for(;;)
    {
        timeout_t Timeout = Time_X - OS::GetTickCount();
        if((timeout_t)(Timeout - 1) > timeout )
            return 0;
        if(!pUART->getchar(RxData, Timeout))            // timeout, packet broken
            return 0;

return 0;

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

[Сергей Борщ 122]

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

Какой камень? Что-то я сегодня туго соображаю.

return 0;

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

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