> 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:pdero...@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