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


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.


> 
> the two codes fragments following above mentioned code fragment in
> both the functions are slightly different.
> 
> timeslice_cpu
> -------------
> if( queue->get_head() != thread )
>     sched->set_need_reschedule();
> 
> timeslice_count[cpu_this] = CYGNUM_KERNEL_SCHED_TIMESLICE_TICKS;
> 
> yield
> -----
> if( queue->get_head() != thread )
>     sched->set_need_reschedule();
> 
> #ifdef CYGSEM_KERNEL_SCHED_TIMESLICE
>     // Reset the timeslice counter so that this thread gets a full
>     // quantum.
>     else Cyg_Scheduler::reset_timeslice_count();
> #endif
> 
> The confusion is about timeslice_cpu function -
> - shouldn't "timeslice_count.....= ... " be under #ifdef ??

No, the whole routine is ifdeffed.

> - shouldn't it be "else timeslice_count.... = ..." ??

When we handle the timeslice we know that the counter is zero, and so
need to reset it. When handling a yield we do not know what state the
timslice count it in. So we only reset it under certain circumstances.

>    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.



-- 
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


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