This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: some doubts in mlqueue.cxx code


Nick Garnett wrote:
> 
> sandeep <shimple0@yahoo.com> writes:
> 
> > There is this code fragment in timeslice_cpu and yield functions in mlqueue.cxx
> >
> > -----------------------------------------------------------------
> > ifdef CYGPKG_KERNEL_SMP_SUPPORT
> >     // In SMP systems we set the head of the queue to point to
> >     // the thread immediately after the current
> >     // thread. schedule() will then pick that thread, or one
> >     // after it to run next.
> >
> >     queue->to_head( thread->get_next() );
> > #else
> >     queue->rotate();
> > #endif
> > -----------------------------------------------------------------
> >
> > I am missing something in understanding the things here.
> >
> > how the actions of rotating and to_head(get_next) are different?
> > except for the case when head is NULL.
> > but will NULL head situation ever arise in these functions?
> 
> rotate() just sets the head of the queue to the second thread in the
> queue.
> 
> 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.
> 

I'm sorry to get back on this topic again.
Me too, I'm having doubts with this code snippet.

Take this situation, that (If I understood everything right...) could
happen with the current implementation.
If, on the currently-highest priority queue, there are more threads than
available processors, there is the possibility that a thread gets
descheduled on a processor, and immediatly rescheduled on another one,
while there might be other threads that, in a single loop of the queue,
have not been scheduled yet. I think this is not a fair scheduling
policy.

This problem doesn't pose if:
1) In timeslice_cpu() and yield() functions we rotate the queue, as in
the
single processor case.
2) Only in the SMP case, in the schedule() member function we update the
queue head after having chosen the thread to schedule (if it is
different from the current queue head)

This way, every queue head always points to the last thread scheduled on
anyone of the
processors, and we are sure that all threads on the queue get scheduled
before a thread
that was descheduled in the current loop of the queue is rescheduled
again.
The problem of determinism shouldn't pose too. In fact all processors
always run the highest priority runnable threads, so even with this
implementation we are sure that we'll look at most N threads in the
queue (if there are N processors) before finding the one to schedule.

Thank you for any comments you'll want to give on this.

Enrico Piria

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]