Re: [Xenomai-help] Priority coupling broken?

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

Philippe Gerum wrote:
> On Tue, 2011-03-29 at 21:11 +0200, Gilles Chanteperdrix wrote:
>> Philippe Gerum wrote:
>>> On Tue, 2011-03-29 at 16:41 +0200, Henri Roosen wrote:
>>>> Hi,
>>>>
>>>> I have several Xenomai RT threads (prio > 0) that get ready to run all
>>>> at the same time. Priority coupling is enabled in the kernel.
>>>>
>>>> If one of them (unfortunately) makes a Linux system call, I see that
>>>> first other lower and same priority Xenomai tasks are scheduled before
>>>> the switched task is run in the Linux domain. As I understand,
>>>> priority coupling should prevent this.
>>>>
>>>> To rule out a problem in the application, this is also tested with a
>>>> simple application based on the rt_print example. In my opinion, with
>>>> priority coupling enabled this should print:
>>>> Wakeup! - I am - awake! - Me too!
>>>> But I get:
>>>> Wakeup! - I am - Me too! - awake!
>>>> So task 2 gets run before task 3 completes in the Linux domain.
>>>>
>>>> Please find attached the test application and the .config file.
>>> The fine print with priority coupling is that it stops immediately
>>> whenever the thread blocks linux-wise; this is actually why, after all
>>> this time debugging it, I'm pondering now whether I should keep this
>>> behavior/feature in 3.x.
>>>
>>> Initially, this was aimed at enforcing the right scheduling sequence
>>> with traditional RTOS APIs, specifically when it comes to create
>>> threads, so that high priority children do run prior to low priority
>>> parents (some legacy apps may expect this). But the fact is that this
>>> behavior also carries a number of uncertainties, and having the thread
>>> de-boosted when blocked by Linux is a serious one.
>> Maybe each thread could have a bit telling whether or not it should run
>> under priority coupling, this bit would be disabled at all times, except
>> during the thread creation routines, and at other times if the user
>> called xnpod_set_mode to enable it if he wants?
>>
> 
> This bit exists, it is XNRPIOFF. What I'm pondering is whether this all
> makes sense to provide priority coupling without any mean to actually
> control the impact the regular kernel may have on it.
> 
without the irq shield you mean :-)

-- 
                                                                Gilles.