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: round-robin behaviour of MLQ wrt particular priority level


On Tue, Oct 26, 2004 at 10:31:56PM +0530, sandeep wrote:
> I was following -
> 
> wake (thread.cxx)
> -> add_thread (mlqueue.cxx)
> --> add_tail (Cyg_CList, clist.hxx)
> ---> insert (Cyg_DNode, clist.hxx)
> 
> shouldn't add_tail call append instead of insert??
> insert adds new node at the beginning of the list, and in next schedule() 
> call get_head() will return the head element from list (Cyg_RunQueue). this 
> means the newer thread added to runqueue at a particular priority level 
> will be given chance first (making it LIFO). MLQ is roundrobin wrt a 
> particular priority level.

Its round robin a task when it uses its full time slice. That is
handled be a differnt bit of code. If a task is been woken, its
obviously not used its full time slice, so round robin does not
apply. What you see most often is tasks get context switched by higher
priority threads. When the higher priority thread gets blocked and the
lower priority thread gets to run again, it makes more sense to
continue running the thread that was descheduled since it more likely
there is something useful in the cache for this thread. The next
thread in the queue has been sleeping for longer so its more likely
its data in the cache has been flushed.

        Andrew

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