Точно заради многозадачността ти трябват двата - един да пази "отгоре" и един "отдолу". В твоя случай "отгоре" можеш да си го риташ ако искаш и в scheduler-а - според OS-а.

Пък и всяка система ползваща поне прекъсвания автоматично става "многозадачна".

Наистина го премисли малко - може високоприоритетните неща да работят а нископриоритетните - не. И обратното. Освен това вътрешните кучета базирани на броячи са несигурни, а и някои производители се грижат да има errata там.

Прехвърли го из главата си като имаш малко свободно време - въобще какво може да се постигне с едно куче само? Има ли такова място което да гарантира коректност и ако не - защо. Ако искаш мога да се опитам да ти дам псевдодоказателство на хипотезата ми ... на бира. Че това с писането е убийствено.

BTW, тази схема с двете псета ми хрумна веднъж като имах такъв излишък и оттам се роди цялата идея.

EDIT: друго което ползвам в комплект са разни проверки за фатални изцепки тук и там. Реакцията при наличие на такива е много проста - забрана на всякакви прекъсвания и важни изходи и зацикляне с JMP към себе си. Доброто дворно (външно) псе се грижи до половин-една секунда да върне всичко в начална позиция, защото и с вътрешните ресетове има обикновено проблеми.

Цъкането на задачи от ядката не ти гарантира ПО НИКАКЪВ НАЧИН че менюто на дисплея ще е интерактивно и ще върши нещо вместо да виждаш статична картинка, пък дори и курсорът на гризача да шава.

Reset е последна мярка. В рамките на нормална - и възстановима без reset - работа
на системата нещата могат да увиснат така, че таскът, дето трябва да подритне
watchdog-а, да се окаже изместен от по-висши приоритети (а ако нагласиш системата
така, че това да не може да се случи, си направил същото, което би направил,
ако самият scheduler рита кучето, но по по-труден и заобиколен начин).
Това е валидно и за малки, и за големи системи. Правил съм го за HC11 - 3-4
таска в система с 256 байта RAM, и за PPC - система с MMU, VM, 64+M RAM...
Ако на човек му е важна надеждността на дадена система, то тя има много
нива на защита преди watchdog-а, той е, ако системата забие безнадеждно - с
надеждата, че тръгвайки от нула, може и да сколаса да оправи работата.
Това не винаги става, например имам един малък контролер, който следи
захранванията, клавиатура, разни други неща на една голяма система, и
освен всичко е и часовникът (RTC), дето се крепи на батерия. Е, веднъж
се случи (за >10 години) тоя контролер да бъде reset-нат от watchdog-а си,
познах по това, че часовникът му беше занулен... (1.1.2000, 0:0:0).
Загубените данни са си загубени. Защо и как се е случило бих искал
да знам - ама едва ли ще узная някога...

Или инак казано, watchdog-ът е толкова крайна мярка, че има смисъл да
бъде поставена да следи само "пулса" на пациента - докато има пулс (т.е.
тасковете се превключват), ползването на дефибрилатор е неудачно...

Нещо такова имах в предвид де, ама не мога да разбера що кучетата от вашите процесори се разлаяха по моя

Хаха, лузър съм. Проблема е че мен ще ме е....ат ако нещо се издъни, пък било то и в кернела

Въпроса обаче беше по скоро принципен. Като гледам досега се оформя следното мнение

1. Кучето се рефрешва в кернела.

- предимства - може да служи да пази от забиване отделните таскове.
- недостатъци - както каза батето - това ли му е работата на кучето - да пази тасковете. За това си има кернел. кучето да си гледа кокала (кернела).


2. Кучето се рефрешва в някой таск.

- предимства - лесно се прави.
- недостатък - лузърски грешки могат да задействат кучето и да рисетнат системата, а евентуално може и да се мине без това.

като ги претегля си мисля следното:

1. На по прости кернели дето човек може да си бърника - кернела си рефрешва кучето като пази само себе си. Самия кернел (или някой таск) се грижи да пази отделните таскове.

2. На по сложни кернели (бозата или лайнукс) - то май варианта на Хищника е най - удобен - така или иначе там съм на лузърско ниво, нямам много избор, кучето се рефрешва от някой таск. И разчиташ че кернела ще ти пази тасковете (или си организираш отделен таск да следи другите таскове).


Нищо революционно

Ами предполагам защото хората са свикнали да надценяват полезността на
кучетата . Сума ти съседи наоколо държат кучета с мисълта, че ще
ги опазят от крадци (истината е, че могат да им опазят кокошките от лисици,
не и къщите от хора).
Та и електронните кучета понякога хората се изкушават да ги сложат там,
където не им е мястото - да следят дали системното натоварване не е
извън контрол и т.н., което не е работа за reset-ващ watchdog, ама
нали рядко опира до нея, и да не работи както трябва, едва ли
някой скоро ще разбере....

Пфу май всички взеха да стават на едно мнение. Отиде ни спора на кино. Имате по една бира като се сберем. Което като гледам може да съвпадне с пускането на метрото.

Мненията могат да бъдат много в зависимост кой какво прави а и конкретно какъв ОС ползва.

В моя случай ползвам следните правила:
1) Нито в ОС-а нито в лузерския ми код има изрична забрана на прекъсвания, т.е. няма опасност някой да забрани прекъсванията и да забрави да ги пусне и така да умре половината хардуер.
2) Невъзможно е да се прехване прекъсване без драйвер. Демек лузера няма работа в прекъсвания, това не означава че не може да се пишат драйвери или пък като се напишат няма бъгове - има... просто е сведено до по-ниско ниво.
3) Приоритетите на тасковете са абсолютни - на момента в който някой таск с висок приоритет иска ЦПУ го получава, ниските приоритети духат супата.


Та така, за мен няма абсолютно никакво значение дали ще сложа кучето в кърнела или в таск с висок приоритет. Всичко се движи от таймер - като цъкне таймера - кърнела получава управление, проверява за спящи красавици и евентуално ги събужда. След което подава управлението на най-високата красавица. Ако това е красавицата с кучето - тя ще го получи. Ако не го получи - значи има бъг някъде и значи е по-добре да не го получава

При nonepreemptive осове някой ниско приоритетен таск може да захапе управлението и да не го пусне - затова както каза tqi се вземат защитни мерки. В моя случай няма такава опасност - или таска с най-висок приоритет има ЦПУ-то винаги, или има бъг...

Смисъла е, че ако си галиш кучето в не-риълтайм тред, още повече в нископриоритетен, може да се случи системата да се рестартира без да има нужда от това. Идеята е, че докато платформата работи нормално все пак няма нужда да се рестартира, когато някой процес е потънал в по-дълбоки сметки.

Не и ако си си направил сметката правилно с приоритетите...

Макар че има различни типове шедулъри, но да кажем че в 99% от случаите се използва RMA.
Значи Rate Monotonic Algorithm (RMA) по принцип изиксва приоритетите на тасковете да се задават не според личните предпочетания на лузера, а на база честота с която се създава работа на съответния таск.
Примерно таска който храни кучето ако го храни на 1 секунда има приоритет 1. Съответно таск който има склонност да се замисля по 2-3 секунди, трябва да има приоритет 2-3 пъти по-нисък от тоя на кучето.

Всъщност и в DPS, и в разните малки системи, дето съм писал някакъв scheduler,
няма деление preemtive/cooperative. Всички са и двете - тасковете се
държат често пъти като cooperative, т.е. в цикъла, в който чакат събитие,
има по един xtask$ scall, който има същата функция, каквато би имало
външно прекъсване (от съответния таймер). Напълно легитимно е и някой
таск да си цикли и смята все едно, че нищо друго няма занчение - той ще
си бъде прекъснат и изваден, когато му дойде времето. Всъщност и двете
събития са много вероятни през живота на даден таск; например докато
чака да мръдне мишката таскът ще излиза доброволно през цялото време
(и така няма да консумира почти нищо), а като получи, каквото му е трябвало
и хукне например да регенерира целия прозорец, ще бъде ваден насила,
ако не свърши в рамките на позволеното време.
Приоритетите в DPS са малко по-сложно решени, не са "строго фиксирани".
Това би довело до някой нископриоритетен таск никога да не получи
време, ако има по-високоприоритетни, които искат все те да работят.
В DPS всеки таск има два приоритета: базов и текущ. Базовият приоритет е
постоянен; когато някой таск получи време, текущият му приоритет
се приравнява на базовия. При решаване кой да получи време се сравняват
текущите приоритети; на всеки таск, загубил решаването, текущият
приоритет му се увеличава с 1 - така евентуално и таскът с най-нисък приоритет
след определн брой загубени битки гарантирано получава своя timeslice.

И тъй като е гарантирано, че scheduler-ът ще решава кой таск да получи
време поне веднъж на всеки 10-тина mS, очевидното място на watchdog-а
е там. Докато тасковете се превключват, имаме жива система с "пулс",
няма нужда да бъде морена с дефибрилатори. Все някой таск трябва
да може да свърши работата по събуждането... Умре ли обаче - да няма
пулс - ами време е за крайната мярка - която обикновено има по-лека
или тежка амнезия като последица... .