[En-Nut-Discussion] Thread priority

[Alexander Baranov]

Well, I'm not so simple :-).
I don't literally reset the timer in ISR. I check various flags, which are 
set or reset in threads, check available heap  etc and if somethig wrong - 
reset the board
Alexander
----- Original Message ----- 
From: "Henrik Maier" <hmlists at focus-sw.com>
To: "Ethernut User Chat (English)" <en-nut-discussion at egnite.de>
Sent: Thursday, May 17, 2007 7:02 PM
Subject: Re: [En-Nut-Discussion] Thread priority


> Petting a watchdog in an timer ISR defeats the purpose (assuming your
> purpose is to detect software defects not only hardware defects). It is
> very likely that your timer ISR is still executed even your main
> application has fully crashed.
>
> Some thought has to be spend on implementing a sensible watchdog
> supervision in a multi-threaded application and there is no general
> answer as it depends how your worker threads are executed. That can be
> event driven, cyclically or something else.
>
> In a concept I have implemented in several designs I supervise all
> threads from a low priority master thread. If that master thread sees
> one worker thread not meeting it's performing criteria, then we stop
> petting the watchdog. The performance criteria depends on what the
> thread is doing and is in most cases simply monitoring a cycle counter.
>
> Is also have event-blocking threads (TCP read/accept etc) time-out so
> they can report to the monitoring thread that they are still alive.
>
> At the end of the day each thread is a self contained execution
> environment which needs to be monitored. Each single thread can lock-up
> in a way that the other thread still executes and this should be taken
> into account in a watchdog concept.
>
>
> Henrik
> http://www.proconx.com
>
> Alexander Baranov wrote:
>> Really I don't rely upon threads and use timer interrupt for that.
>> Alexnder.
>
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>