Re: [Xenomai-help] Low priority primary mode threads scheduling v s linux regular th read.

Re: [Xenomai-help] Low priority primary mode threads scheduling v s linux regular th read.

[Laurent.POYART]

Gilles wrote:
> The problem is that when Tx2 is running in secondary mode, it needs to
> voluntary switch to primary mode. When in secondary mode, Tx2 is
> suspended from Xenomai nucleus point of view, so xnpod_resume_thread
> cause the SIGHARDEN signal to be sent to Tx2, but Tx2 needs to run a
> little bit to handle the signal which will cause it to switch to
> primary mode.
> 
> So, in my opinion (but I may be wrong) TL will continue to run until
> it lets Tx2 run.

I think there is a misundestanding. In my example (see bellow), Tx2 is not in secondary mode . It is a primary mode thread which is blocked while waiting for an RT event (xenomai domain). I wanted to be sure of the scheduling issue between the TL (linux regular thread) which is running and the Tx2 (primary) which becomes runnable.
In my opinion, TL will continue to run (because of the Tx1 status) but I'm not sure.

Regards.
Laurent.


> -----Message d'origine-----
> De : Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> Envoyé : mercredi 28 novembre 2007 14:09
> À : Laurent.POYART@fr.thalesgroup.com
> Cc : xenomai@xenomai.org
> Objet : Re: [Xenomai-help] Low priority primary mode threads 
> scheduling
> vs linux regular th read.
> 
> 
> On Nov 28, 2007 9:24 AM,  <Laurent.POYART@fr.thalesgroup.com> wrote:
> > Hi,
> >
> > It was said in a previous thread under title "scheduling of 
> low priority primary mode Xenomai threads versus high 
> priority secondary mode Xenomai threads":
> > <<Plain regular Linux threads unknown from the Xenomai 
> scheduler are always preempted by primary mode threads, but 
> they _do_ compete for the CPU with secondary mode threads 
> according to their priority and scheduling class>>
> > Consider the following example with 3 Threads (coupling 
> between Xenomai and Linux schedulers is On):
> > *       TL : regular linux thread with high priority 
> (unknown from Xenomai Scheduler) => ready to run.
> > *       Tx1 : xenomai real time thread with medium priority 
> in primary mode => running.
> > *       Tx2 : xenomai real time thread with low priority in 
> primary mode => blocked (waiting for an event).
> > Tx1, which is running, issues a linux system call and then 
> switches to secondary mode. TL and Tx1 compete for the CPU 
> and TL takes the CPU control (am I right?).
> > Then an interrupt occurs and gives the necessary condition 
> to unblock the Tx2 thread. Does the sentence <<Plain regular 
> Linux threads unknown from the Xenomai scheduler are always 
> preempted by primary mode threads>> means that Tx2 will 
> preempt TL or does TL keep control of the CPU because it is 
> still in competition with the secondary mode thread Tx2 which 
> has a higher priority compared to Tx1?
> 
> The problem is that when Tx2 is running in secondary mode, it needs to
> voluntary switch to primary mode. When in secondary mode, Tx2 is
> suspended from Xenomai nucleus point of view, so xnpod_resume_thread
> cause the SIGHARDEN signal to be sent to Tx2, but Tx2 needs to run a
> little bit to handle the signal which will cause it to switch to
> primary mode.
> 
> So, in my opinion (but I may be wrong) TL will continue to run until
> it lets Tx2 run.
> 
> 
> -- 
>                                                Gilles Chanteperdrix
> 

Re: [Xenomai-help] Low priority primary mode threads scheduling v s linux regular th read.

[Philippe Gerum]

Laurent.POYART@fr.thalesgroup.com wrote:
> Gilles wrote:
>> The problem is that when Tx2 is running in secondary mode, it needs to
>> voluntary switch to primary mode. When in secondary mode, Tx2 is
>> suspended from Xenomai nucleus point of view, so xnpod_resume_thread
>> cause the SIGHARDEN signal to be sent to Tx2, but Tx2 needs to run a
>> little bit to handle the signal which will cause it to switch to
>> primary mode.
>>
>> So, in my opinion (but I may be wrong) TL will continue to run until
>> it lets Tx2 run.
> 
> I think there is a misundestanding. In my example (see bellow), Tx2 is not in secondary mode . It is a primary mode thread which is blocked while waiting for an RT event (xenomai domain). I wanted to be sure of the scheduling issue between the TL (linux regular thread) which is running and the Tx2 (primary) which becomes runnable.
> In my opinion, TL will continue to run (because of the Tx1 status) but I'm not sure.
> 

Due to priority coupling, that's correct, provided TL undergoes
SCHED_FIFO. The point of such coupling is to make the kernel temporarily
inherit the real-time priority of the Xenomai thread while the latter
runs in secondary mode, so that the priority scheme is preserved as much
as possible during migrations. As such, TL inherits it too and may
compete for the CPU since it runs in the SCHED_FIFO class.

Said differently, Xenomai and plain Linux real-time threads all run in
the SCHED_FIFO class as seen from the Linux scheduler, and start sharing
a common priority scheme as soon as a Xenomai thread switches to
secondary mode, with priority coupling enabled.  Of course, plain Linux
threads running in the SCHED_NORMAL class cannot compete this way for
the CPU.

-- 
Philippe.