RE: Старт задачи в остановленном (suspended) состоянии.

[Андрей Чуйкин]

Внимание. Текущая реализация данной функциональности в общем случае не работает.
Но уже придумано решение без недостатков (и совершенно без накладных run-time расходов).
Но реализация потребует времени. Так что надо пока не использовать эту функциональность. И может быть откатить назад внесенные изменения.

Проблема вот в чем.
Если процесс-инициализатор самый приоритетный и, если в процессе инициализации, он не отдавал управление, то ни одна инструкция остальных процессов выполнена не будет, в том числе и инструкция sleep(0) в функции suspended_exec(). Поэтому, когда процесс-инициализатор будет будить suspended процессы, ни один из них в спящем состоянии находится не будет и команды force_wake_up будут "пустыми". А когда процесс-инициализатор отдаст управление, выполнится упомянутая выше sleep(0), что приведет к подвисанию процесса.

> -----Original Message-----
> From: scmrt...@googlegroups.com [mailto:scmrt...@googlegroups.com]
> On Behalf Of Harry Zhurov
> Sent: Thursday, July 09, 2015 10:20 AM
> To: scmrt...@googlegroups.com
> Subject: Re: Старт задачи в остановленном (suspended) состоянии.
>
> 09.07.2015 9:02, Андрей Чуйкин пишет:
> > Так (?): enum StartState { ssRunning, ssSuspended };
> >
> Годится.
>
> --
> HZ
>
>
> --
> --
> Страница группы -- http://groups.google.com/group/scmrtos-ru
> ---
> Вы получили это сообщение, поскольку подписаны на группу scmrtos-ru.
>
> Чтобы отменить подписку на эту группу и больше не получать от нее
> сообщения, отправьте письмо на электронный адрес scmrtos-
> ru+unsu...@googlegroups.com.
> Настройки подписки и доставки писем: https://groups.google.com/d/optout.

[Чуйкин Андрей]

Внимание. Текущая реализация данной функциональности в общем случае не работает.

Но вреде бы наклевывается другое решение. Но его реализация потребует времени. Так что надо пока не использовать эту функциональность. И может быть откатить назад внесенные изменения.

[Harry Zhurov]

20.07.2015 13:43, Андрей Чуйкин пишет:

> Внимание. Текущая реализация данной функциональности в общем случае
> не работает. Но уже придумано решение без недостатков (и совершенно
> без накладных run-time расходов). Но реализация потребует времени.
> Так что надо пока не использовать эту функциональность. И может быть
> откатить назад внесенные изменения.

Наверное, мы неправильно поступили, внося фичу сразу в trunk, всё-таки
для этого служат ветки. К сожалению, svn не поощряет работу с ветками.

Поскольку внесённые изменения не портят работу остального и не мешают
тем, кто не использует данную фичу, то не вижу смысла что-либо менять на
данном этапе. Даже если кто-то сделает checkout/export trunk::HEAD, то
он получит работосособный код, а про эту фичу он и знать не будет знать
до тех пор, пока она не будет документирована.

> Проблема вот в чем. Если процесс-инициализатор самый приоритетный и,
> если в процессе инициализации, он не отдавал управление, то ни одна
> инструкция остальных процессов выполнена не будет, в том числе и
> инструкция sleep(0) в функции suspended_exec(). Поэтому, когда
> процесс-инициализатор будет будить suspended процессы, ни один из них
> в спящем состоянии находится не будет и команды force_wake_up будут
> "пустыми". А когда процесс-инициализатор отдаст управление,
> выполнится упомянутая выше sleep(0), что приведет к подвисанию
> процесса.
>

А может, делать процесс-инициализатор не самым приоритетным, а наоборот?
Или это как-то противоречит исходному замыслу?

--
HZ

[Андрей Чуйкин]

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

> -----Original Message-----
> From: scmrt...@googlegroups.com [mailto:scmrt...@googlegroups.com]
> On Behalf Of Harry Zhurov
> Sent: Monday, July 20, 2015 2:15 PM
> To: scmrt...@googlegroups.com
> Subject: Re: Старт задачи в остановленном (suspended) состоянии.
>

[Кондратов Сергей Анатольевич]

Здравствуйте, Андрей
Вы писали:

> --

Инициализацию делать в IDLE процессе, а остальные по умолчанию спят


С уважением,
Кондратов С.А.
mailto:avr_...@mail.ru

[Андрей Чуйкин]

А что будет, если во время инициализации вызвать sleep(1) из idle процесса?

[Андрей Чуйкин]

Мы с Антоном весь день думали и вот что придумали.
Самый верный путь - это правильно сформированный ReadyProcessMap в TKernel. Сформировать это вызовом TBaseProcess:: set_unready() нельзя. Но можно сделать так.

1. Весь функционал относящийся к данной теме обрамляется в #ifdef с соответствующим макросом в scmRTOS_config.h, чтобы для тех кто не пользует не было оверхеда.
2. Заводится глобальная переменная TProcessMap SuspendedProcessMap; (как вариант TKernel:: ReadyProcessMap делается статической).
3. В конструкторе процесса добавляется код, сбрасывающий нужный битик в SuspendedProcessMap/ ReadyProcessMap, если данный процесс указан как ssSuspended.
4. В OS::run() добавляется код, замещающий значение Kernel. ReadyProcessMap значением из SuspendedProcessMap.
5. Профит.

> -----Original Message-----
> From: scmrt...@googlegroups.com [mailto:scmrt...@googlegroups.com]

> On Behalf Of Кондратов Сергей Анатольевич
> Sent: Monday, July 20, 2015 4:01 PM
> To: Андрей Чуйкин

[Кондратов Сергей Анатольевич]

Здравствуйте, Андрей
Вы писали:

> А что будет, если во время инициализации вызвать sleep(1) из idle процесса?

А если сделать
#if (scmRTOS_SYSINIT_HOOK_ENABLE != 0)
void OS::SystemInitUserHook() { }
#endif

Узнать какой из них самый низкоприоритетный всегда можно, зная scmRTOS_PROCESS_COUNT
в начало всех процессов кроме низкоприоритетного вставлять
#if (scmRTOS_SYSINIT_HOOK_ENABLE != 0)
sleep(0);
#endif
а в начало низкоприоритетного
#if (scmRTOS_SYSINIT_HOOK_ENABLE != 0)
SystemInitUserHook();
force_wake_up();
#endif

[Андрей Чуйкин]

Предложенное исправление реализовано.
Ждем нормальной работы sf.

Т.к. все убрано под #ifdef, то для не использующих фичу ничего не изменилось.
Для использующих: +24 байта (и +8 байт на каждый спящий процесс) флеша, +4 байта ОЗУ.