Hi, Thanks for your answer.
2011/6/28 Gilles Chanteperdrix <[email protected]> > The problem is that the "rt_task_spawn" service causes its caller to > switch to secondary mode. This means, that the task is no longer real-time. > I wasn't aware of this fact. It could be annoying if we have to create several RT Tasks... It's only true for rt_task_spawn or for all Xenomai services ? A better practice will to first make several rt_task_create and after activate them by rt_task_start services? > Normally, root thread priority coupling should allow to avoid that. > Unfortunately, there is a small hole in this functionality which make it > not work in some conditions (and fixing this hole would introduce a > possibility of priority inversion). > My advisor (jerome Delatour from ESEO) want to better understand this point, where could I find explanations on this point ? > As for the influence of the length of the call to rt_task_sleep, a short > rt_task_sleep will cause the "go" task to switch to primary mode and > preempt the task "WorkingTask1" before it is completely started. > OK, I will also make some test around this. > Nevertheless(2), xenomai needs linux to run in order to work correctly, > so, the real-time tasks should always suspend to let linux run. I bet if > you put an rt_task_sleep in WorkingTask1 and WorkingTask2 loop, the test > will no longer hang. > Yes, even a rt_task-sleep(0) or rt_task_sleep(1) works, but I thought because in that case we force a call to the Xenomai scheduler > > Please no private mails. > I apologize, my gmail didn't work as expected. Adrien, Engineering student at ESEO
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
