QNX.ORG.RU

Разработка => Языки и алгоритмы => Тема начата: mike от Января 18, 2013, 09:18:59 am



Название: какой должен быть приоритет у watchdog?
Отправлено: mike от Января 18, 2013, 09:18:59 am
должен ли watchdog быть самым приоритетным процессом или наоборот?


Название: Re: какой должен быть приоритет у watchdog?
Отправлено: Absolut от Января 18, 2013, 11:40:30 am
Главное чтобы он гарантированно получил квант времени в нужный момент (для своих вотчдоговских операций).
Отсюда наверное и надо плясать.


Название: Re: какой должен быть приоритет у watchdog?
Отправлено: aluv от Января 18, 2013, 12:10:55 pm
Если целевая задача исключает 100% загрузку процессора, то приоритет watchdog можно сделать низким. Для остальных задач приоритет должен быть равен целевым задачам или выше (при условии, что целевые задачи стробируют watchdog).


Название: Re: какой должен быть приоритет у watchdog?
Отправлено: vshemm от Января 18, 2013, 03:39:05 pm
watchdog вообще не должен быть процессом.


Название: Re: какой должен быть приоритет у watchdog?
Отправлено: mike от Января 18, 2013, 04:23:40 pm
vshemm, это как? встраивать в критическое приложение? а если система из нескольких процессов?


Название: Re: какой должен быть приоритет у watchdog?
Отправлено: vshemm от Января 18, 2013, 04:57:27 pm
По хорошему, да. По определению, стробирование должно осуществляться из приложения, причем быть синхронным и на
текущем приоритете (в противном случае можно получить false negatives/positives). Если watchdog - отдельный процесс,
добиться этого проблематично. Наименьшим злом, наверное, будет посылка синхронных сообщений, причем watchdog должен
быть самым приоритетным в системе.


Название: Re: какой должен быть приоритет у watchdog?
Отправлено: ed1k от Января 18, 2013, 08:26:17 pm
А что вы называете вачдогом? Процесс который кормит аппаратную сторожевую собаку? Его приоритет не имеет большого значения, он должен заблокироваться, если его вовремя не покормили другие процессы критического приложения.


Название: Re: какой должен быть приоритет у watchdog?
Отправлено: mike от Января 18, 2013, 09:27:35 pm
да, процесс который кормит сторожевую собаку :)


Название: Re: какой должен быть приоритет у watchdog?
Отправлено: vshemm от Января 18, 2013, 11:40:41 pm
А кто будет кормить процесс, который кормит сторожевую собаку?
Тут приоритет важен, тут собака и порылась таки :)


Название: Re: какой должен быть приоритет у watchdog?
Отправлено: ed1k от Января 19, 2013, 04:24:14 am
А почему не кормить сторожевую собаку напрямую? Многие современные аппаратные сторожевые псы весьма гибкие, позволяют задать колличество задач, и таймауты, если какая-то задача не запишет свой байт в порт своевременно, то все и перегрузится. Помнится мне тут уже подымался этот вопрос, и касательно приоритетов.
С софт собакой, если таки ресетить аппаратно по любому чиху нежелательно, я бы рм написал. С конфигурацией, и укажаниями, что делать, если какой процесс перестал писать свой байт в /dev/watchdog.


Название: Re: какой должен быть приоритет у watchdog?
Отправлено: PoP от Января 19, 2013, 04:53:09 pm
Делать отдельный процесс (поток) только для кормления собаки - вроде как бессмысленно. Проще просто убить её в БИОС-е. Ну, только если в системе живёт единственное приложение, гарантированно не седающее всё время - то поток с минимальным приоритетом. Но потом что-нибудь допишите, сожрёт всё время, и привет.
Под 6-ркой для контроля нескольких процессов можно использовать HAM. Процес, который кормит watchdog, может, таким образом, мониторить только сам HAM.
Под 4-ку нечто аналогичное пришлось писать самому ( кстати, и HAM-а в 6-рке тогда ещё небыло ). Мониторит только зарегистрировавшиеся процессы. По дефолту перезапускается процес, можно попросить убить группуБ перезагрузить систему, только убить процес, просто отметить событие в логах. По ходу работы процес может поменять таймаут, отключить/подключить наблюдение, сменить реакцию на таймаут да и посто отцепиться от ресурса. Как бонус - после регистрации можно спросить первый ли это запуск или перезапуск (и, допустим, не пересоздавать shared memory и т.д. ).
Приоритет в обоих случаях, конечно, должен быть выше, чем у всего контролируемого. Код короткий и тупой, не порождающий новых потоков, проверенный во всех мыслимых и немыслимых вариантах.