Re: [ECOS] Round robin scheduler question

[Nick Garnett <nickg at ecoscentric dot com>]

Ian Gilmour <ian.gilmour@ffei.co.uk> writes:

> I'm having problems with round robin scheduling with the multi-level queue
> scheduler so I knocked up a simple test....
> 
> I have a system with a monitor task (TaskA).
> 
> TaskA creates 2 equal priority tasks (TaskB and TaskC) that simply loop,
> each incrementing their own volatile global counter. TaskB and TaskC have
> lower priority than TaskA.
> 
> Task A also creates another high priority task TaskD. TaskD priority is
> lower than TaskA but higher than TaskB and TaskC. TaskD periodically polls
> for Control-C input on the monitor. It polls every NNN clock ticks.
> 
> TaskA periodically (every couple of secs) dumps the contents of the 2 global
> counters until it sees a Control-C flag set by TaskD, at which point it
> kills TaskB, TaskC, and TaskD.
> 
> I have the multi-level queue scheduler enabled and the scheduler timeslicing
> every 5 clock ticks.
> 
> If NNN is greater than or equal to 5 TaskB and TaskC round robin schedule as
> I expect.
> 
> But if NNN is less than 5 TaskC never runs.
> 
> Is this the expected behaviour? Or have I inadvertently set something in the
> ecos config to get this behaviour?
> 
> I expected TaskB and TaskC to get equal time despite neither ever having a
> full 5 clock ticks timeslice.

[These emails are arriving here in a strange order, I have seen some
of Sandeep and Andrew's replies, but probably not all of
them. Apologies if I reiterate anything that has already been
said.]

What's happening here is fairly simple. Thread B gets to run first and
starts to execute for a full timeslice. Since the delay period of
thread D is less than the timeslice period when thread D wakes up it
preempts thread B. The scheduling model of eCos, as with any RTOS, is
that a preempted thread should get put back on the head of the run
queue rather than be cycled to the back. This is necessary to preserve
any realtime properties that thread might have.

So when thread D is finished, it resumes thread B. However, the
scheduler also resets the timeslice counter every time it switches
context. So thread B starts another full timeslice. And of course
thread C never gets to run.

I cannot, at the moment, think of a solution that will fix this
problem and not introduce other problems elsewhere. Making the
timeslice counter a per-thread variable is one option -- we already
have a per-thread timeslice enable. But this just raises the problem
of deciding when to reset it and when not to. We would need to
discriminate between threads that have just woken up, threads that
have just been un-preempted and those that were timesliced. At the
point where we want to reset the counter we don't have this
information available.

I'm tempted to suggest that the example is somewhat pathalogical and
that real-life programs are unlikely to behave like that. However, it
ought to be possible to make this work a little better.

I'll have to mull this over for a while.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss