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:[EMAIL PROTECTED] > Envoyé : mercredi 28 novembre 2007 14:09 > À : [EMAIL PROTECTED] > Cc : [email protected] > Objet : Re: [Xenomai-help] Low priority primary mode threads > scheduling > vs linux regular th read. > > > On Nov 28, 2007 9:24 AM, <[EMAIL PROTECTED]> 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 > _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
