[ECOS] about timeslice

[Nick Garnett]

Jonathan Larmour <jlarmour@redhat.com> writes:

> ylyuan wrote:
> > 
> > Hi,in the DSR of RTC:
> > void Cyg_RealTimeClock::dsr(cyg_vector vector, cyg_ucount32 count, CYG_ADDRWORD data)
> > {
> >    ......
> >    rtc->tick( count );
> > 
> > #ifdef CYGSEM_KERNEL_SCHED_TIMESLICE
> > #if    0 == CYGINT_KERNEL_SCHEDULER_UNIQUE_PRIORITIES
> > 
> >     // If timeslicing is enabled, call the scheduler to
> >     // handle it. But not if we have unique priorities.
> > 
> >     Cyg_Scheduler::scheduler.timeslice();
> > 
> > #endif
> > #endif
> > ......
> > }
> >   if the parameter of count isn't 1,why function  of timeslice only subtract one but the parameter of rtc->tick is count?
> 
> Yes, I can see why this would be a problem. It does look like the
> timeslice() method should take an argument of the tick count as well.
> 
> Nick, any objections to me doing this? Otherwise when interrupts are
> disabled for a long time, or any other reason why a clock DSR may be
> delayed (e.g. long alarm handler), the scheduler will not catch up on its
> missed timeslice.
> 

My take on this is that it probably does not matter. Timeslicing is a
very crude mechanism for load balancing between threads. No program
should be relying on it for any kind of time related activity, so any
small inaccuracies in it should not matter. If timing behaviour does
matter, then the application should be assigning priorities and
scheduling the threads appropriately.

My preference would be to leave this alone. Adding the count argument,
and then dealing with it in timeslice() adds code bloat for a very
minor change in functionality. But if you feel like doing it, I have
no serious objection either.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK