Re: [Xenomai] Round robin scheduling seem not working in a specific case...

[Philippe Gerum <rpm@xenomai.org>]

On 11/04/2014 11:34 AM, Christophe Carton wrote:
> Hello,
> 
> I am currently working with Xenomai 2.6.4 with native skin and with a
> Linux kernel 3.14.17.
> The linux and the xenomai have been taken from the following Git
> repositories :
> * http://git.xenomai.org/xenomai-2.6.git - tag v2.6.4
> * http://git.xenomai.org/ipipe.git - tag ipipe-core-3.14.17-x86-4
> 
> I am encountering a problem to enable the Round Robin scheduler in a
> specific case :
> * Two tasks ("rr task 1" and "rr task 2") of priority 10 are launched by
> a task ("init task") of priority 90.
> * All 3 of them are configured with a RR scheduler via "rt_task_slice"
> API before they are started.
> In this case the FIFO scheduling seems to be applied (could be seen via
> rt_printf logs).
> 
> I have found a thread on the mailing list that gives an example
> demonstrating the good behavior of the RR scheduler.
> http://www.xenomai.org/pipermail/xenomai/2011-November/024897.html
> http://www.xenomai.org/pipermail/xenomai/2011-November/024899.html
> This example implies that the tasks are locked via a semaphore at
> startup and that this semaphore is unlocked by the main when all threads
> have been started.
> This is necessary in this case due to the fact that the main function is
> no an RT task.
> 
> This implementation (with the semaphore) applied to my test works. Why
> is the semaphore needed in my case?

init_task() is switched to non-rt mode by rt_task_create(), so that a
regular pthread is first created by the glibc, prior to extending it
with Xenomai capabilities. In 2.6.x, this operation leaves the caller
(i.e. init_task() in your case) in relaxed/secondary mode, which means
that it is assigned the lowest priority level in the Xenomai scheduler,
below the RR class.

Given that, in your code, no Xenomai syscall following the first
rt_task_create() have the requirement to switch the caller back to
primary/rt mode, including rt_task_start() which is issued for task_1.
Hence init_task() won't compete with task() which is assigned the
real-time RR priority you asked for on entry.

IOW, if you don't make the children wait on a barrier until the parent
has set the whole thing up, the first call to rt_task_start() will
unleash task_1, which will in turn start spinning immediately in its
work loop as init_task() is on a lower priority level, locking up CPU#1.

-- 
Philippe.