Hi,

Thanks for your answer.

2011/6/28 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>

> 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