Re: [Xenomai-help] Priority coupling broken?

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Henri Roosen wrote:
> 
> Thanks Gilles for your input. This Priority Coupling stuff is a little
> complex and input about the corner cases is always welcome and
> helpful!
> 
> I did a little more tests with xnpod_schedule() commented out on
> LO_WAKEUP_REQ. Scheduling shows as expected to me: the lower and level
> primary tasks don't interrupt the migrated thread while higher
> priority tasks do interrupt that task. I have not seen any deadlocks
> yet or ran into corner cases, but of course I don't know all.
> 
> Now, looking back in the history of shadow.c I see that
> xnpod_schedule() was introduced when the xnsched_renice_root() was
> introduced, which is now part of rpi_clear_local. In my point of view,
> the xnpod_schedule() call is only needed when the
> xnsched_renice_root() has been done, so should be moved inside the if
> of rpi_clear_local. But again, it is my point of view and don't know
> all the corner cases.
> 
> In our case the scheduled task after the switch to secondary is
> actually mostly the IDLE task, thus calling the xnsched_renice_root
> and xnpod_schedule() for doing exactly that what is in the comment. So
> my main question remains: is the call to xnpod_schedule really needed
> here after xnsched_renice_root()? And if so, why doesn't the
> xnpod_schedule not take the priorities on the rpi list into account?

The current task when entering LO_WAKEUP_REQ is not a Xenomai task, so,
rip_clear_local disables the boost. At this point we have no guarantee
that "p" will be the next task scheduled, or that the next call to
schedule will schedule another task at all, so that we will pass by
do_schedule_event.

There may be a way to avoid this, but removing xnpod_schedule() is
certainly not it. Imagine that when we enter LO_WAKEUP_REQ, current is a
Linux real-time task with a higher priority than the Xenomai task, the
root thread will be unduly boosted until the moment where that task is
suspended and the Xenomai task can be at last scheduled. This would be a
plain sort of priority inversion.

-- 
					    Gilles.