shadow thread/watchdog question

[Jan Kiszka]

Steven Seeger wrote:
> Dmitry, thanks for your detailed answer to my question.
> 
> 
>>
>>>>The only difference is when a pod's priority range is bigger than the one
>>>>provided by linux for rt tasks.
>>>>
>>>>e.g. fusion threads: [1, 255]
>>>>Linux: [0, 100]
>>>>
>>>>in this case, the following code
>>>>
>>>>cprio = thread->cprio < MAX_RT_PRIO ? thread->cprio : MAX_RT_PRIO-1;
>>>>
>>>>transforms any priority of the pod's sub-range [100, 255] to a sole linux
>>>
>>>one 
>>>
>>>>of MAX_RT_PRIO - 1.
>>
>>Wouldn¹t it make more sense to proportionally adjust the priorities when
>>moving to the Linux domain?
>>
>>
>>
>>>>No. This code runs completely in the secondary domain. The fusion's
>>>
>>>watchdog 
>>>
>>>>takes care of the cpu hogs that run in the primary domain.
>>
> Then it is not an useful watchdog. The code example I gave locks up the
> system without any way out but a hard reboot.
> 
> I have a work-around for this, which is having a standard Linux SCHED_OTHER
> thread sending a message every so often to a fusion thread with
> hard-realtime priority, and treating that as a watchdog. That works fine,
> but I need a way to shutdown an app containing fusion threads if one of
> those is locked up in some kind of infinite loop like I showed above with
> the for(;;) std::cout << ³hi² << std::endl;
> 

You could write a Linux watchdog consisting of a normal SCHED_FIFO
thread with a higher Linux priority than your real-time thread has under
fusion. This watchdog thread would then always be prefered over your
potential run-away fusion thread in secondary mode - and it could send a
kill signal to the buggy process. Likely, the main thread of that
process will also require a higher Linux priority in order to be able to
handle that signal and clean itself up. Not tested, but should work.

Actually, this is a generic problem and not fusion related. Any run-away
SCHED_FIFO/RR thread can lock up your box this way.

Jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://mail.rtai.org/pipermail/rtai/attachments/20050930/9bb6d6b5/attachment.pgp