[ECOS] some doubts in mlqueue.cxx code

Nick Garnett nickg@ecoscentric.com
Mon Nov 29 12:11:00 GMT 2004


sandeep <shimple0@yahoo.com> writes:

> > In the SMP case, the current thread may not be the head thread of the
> > run queue. If there are several threads at the same priority then the
> > first N such threads will be running on different CPUs. By setting the
> > queue head to the thread after the current one, we reduce the amount
> > of searching that the scheduler has to do to find a runnable thread.
> got it. it reduces the search by one hop. also it takes advantge of position of
> current thread in list and makes search effort variable for each position.
> while in just rotating it will be fixed effort for all cases.
> 
> >>The confusion is about timeslice_cpu function -
> >>- shouldn't "timeslice_count.....= ... " be under #ifdef ??
> > No, the whole routine is ifdeffed.
> thanks. i missed that earlier.
> 
> >>- shouldn't it be "else timeslice_count.... = ..." ??
> because if "queue->get_head() != thread", need_reschedule is set and that will
> take care of things in unlock_inner. if otherwise is the case then we need to
> reset the timeslice count as it can not be guaranteed that control will go to
> outer if (mentioned below) in unlock_inner.
>  
> >>   won't timeslice_count be reset during scheduling in unlock_inner??
> >>though a redundant action doesn't change much in logic (but for couple
> >>of more instructions executions, if one bothers about little here,
> >>little there).
> >
> > If it happens that the current thread does not get timesliced (if for
> > example it is the only thread at this priority), we still need to
> > restart the counter for the thread. That is what this assignment
> > does. The timeslice counter is only reset in the scheduler if a
> > context switch occurs.
> you mean that, in unlock_inner, control does not go inside
> 
> "if( current->state != Cyg_Thread::RUNNING || get_need_reschedule() ) {" 
> 
> because switching happens inside nested "if( current != next ) {" but
> "reset_timeslice_count();" happens outside this nested if.

This code deals with the case where the current thread is alone on the
run queue. In that case needs_reschedule will not get set, but we must
still reset the timeslice counter.

We spent several iterations getting this code working. The timeslice
code used to just call yield(), but we had to change it to the current
code to fix some problems. One of the changes was the move of
resetting the counter out of the else clause. I don't now recall what
problem that fixed, and I don't have the time to work through it now.

There may well be paths through this code where the timeslice counter
gets reset twice. However any alternative might prevent the counter
getting reset at all. The assignments are cheap, so the cost of this
is minimal.


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


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



More information about the Ecos-discuss mailing list