Fw: shadow thread/watchdog question

Dmitry Adamushko dmitry.adamushko at datacon.at
Thu Sep 29 09:15:44 CEST 2005


rtai-admin at rtai.org wrote on 28.09.2005 22:09:36:

> If two shadow threads make a system call, do they maintain priority over
> each other in the Linux domain?

Yep. Linux provides a range of priorities for rt tasks (e.g. SHED_FIFO) as
[0 .. MAX_RT_PRIO], where MAX_RT_PRIO is normally 100. Here the lower the
better (i.e. 0 - is the highest one).
The fusion pod by default provides a range [FUSION_LOW_PRIO,
FUSION_HIGH_PRIO] == [1, 99]. 0 is a special case for the root thread, but
it doesn't matter here.
So upon migration, the fusion takes care of the proper adjusting of a
priority of the linux counterpart.

fusion.c: xnshadow_relax()
{
...
    cprio = thread->cprio < MAX_RT_PRIO ? thread->cprio : MAX_RT_PRIO-1;
    rthal_reenter_root(get_switch_lock_owner(),SCHED_FIFO,cprio);
...

This said, if 2 real-time threads have different priorities while running
in the primary domain, they will have different ones (normally, the same
ones) upon migrating and running in the secondary domain as well.

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.



> The watchdog has a bug. If I have a fusion thread that does this:
>
> for(;;) std::cout  << "hi" << std::endl;
>
> then the watchdog will not fire for this thread. I believe this is due to
> the fact the thread is rescheduled when it's relaxed. The watchdog should
be
> able to take care of these cases, otherwise it isn't of much use.

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.

>
> Steven
>
>


---

Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.rtai.org/pipermail/rtai/attachments/20050929/a9b139b1/attachment.htm 


More information about the Rtai mailing list