RE: [ECOS] eCos scheduling anatomy

["Paul D. DeRocco" <pderocco at ix dot netcom dot com>]

> From: Nodir Kodirov
>
> I am trying to understand internal-mechanism of eCos scheduling fully.
> After reading several sources (J. Massa's book, eCos-discuss forum,
> eCos source code) I could think it as Cyg_Alarm class being the most
> critical for the Cyg_Thread's to be scheduled and meet their
> deadlines.?I tried to draw my idea here
> http://docs.google.com/leaf?id=0B6B0XjcIAcOjMTA3ODgzZjItODE3Yi00ZT
I3LThjZGUtNDFmNWZhYzgzOTkw&sort=name&layout=list&num=50
>
> In my opinion, threads are created and after some time they are marked
> as READY. Each time hardware clock tick happens, tick() function of
> the Cyg_Counter class is running through list of alarms and if it is
> time for some thread's alarm to be triggered, thread attached to that
> Cyg_Alarm is resumed.
>
> Additionally, if particular thread was waiting for IO data and if IO
> data is received, IO interrupt will cause an interrupt, thus marking
> waiting thread's state as READY. Again, in the tick() function, we
> will run through list of threads and we will resume those threads
> (e.g. IO received) making them in ready state, we will
> set_need_reschedule() for particular thread. When need_reschedule is
> TRUE we will run Cyg_ThredSched_Implementation::schedule() method,
> which will makes "highest priority" thread to have a CPU.
>
> Thus, in each clock tick we will run through list of alarms,
> manipulate?need_reschedule variable and call schedule() method. If we
> want to set deadline for the particular thread, we should put an
> *alarm* for that thread to be triggered (AFAIK this is the only way).
>
> Are these assumptions are correct?
> Is there any comments / corrections (to understand eCos
> scheduling *anatomy* fully)?
> Or any additional materials for me to read about this more?

You're not correct. The basic mechanism is simply a priority queue, in which
the head thread gets to run on the CPU. If an I/O operation completes, and
the DSR signals the object at which a thread is waiting, and that thread has
a higher priority than the running thread, it will begin to run immediately
on completion of the DSR, not on the next timer tick. Adding a timer tick
allows for timed delays or time limits, and also allows for time slicing, by
forcing a round-robin execution of all runnable threads that have the same
priority, but that's optional functionality. The timer tick is _not_ what
drives the system.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com
>


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