shadow thread/watchdog question
kiszka at rts.uni-hannover.de
Fri Sep 30 16:36:35 CEST 2005
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
>>>>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
>>>>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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://mail.rtai.org/pipermail/rtai/attachments/20050930/9bb6d6b5/attachment.pgp
More information about the Rtai