Допустим, есть два процесса, 1 и 2. Процесс 1 ушел в спячку, например, с помощью Sleep(20), ессно,
второй получил управление, быстренько отработал, и тоже заснул, скажем, Sleep(1000). Итак, в конечном итоге оба процесса должны бы спать (а прога висеть), но фактически этого не происходит.Вопрос- так что же дает управление процессу 1 после спячки? Ведь планировщик вызывается только в момент впадания в спячку!!!

Что-то помнится, там еще таймер был, по которому шедулер тоже срабатывал...

хм... да нет, вроде только системный таймер в наличии, но в его обработчике шедулером и не пахнет ...

А что фактически происходит?


Так в каком процессе висит прога? Должна в IdleProcess.

Процессов всегда на один больше, чем вы объявляете. Именно он и крутится тогда, когда все остальные тоже ничего не делают.

Посмотрите OS::TKernel::SystemTimer(). Именно там вызывается SetProcessReady(), а перепланировка происходит в момент выхода из прерывания в деструкторе TISRW.

Cобственно, программка простая, потому как тестовая:

OS_PROCESS void TProc1::Exec()
{
for(;;)
{
Led1=1;// Led1, Led2- выводы портов, на коих сидят светодиоды, 1-горит, 0- тухнет
Led2=0;
Sleep(20);
}

}

OS_PROCESS void TProc2::Exec()
{
for(;;)
{
Led1=0;
Led2=1;
Sleep(1000);
}

}

Полагаю, что перемигивание диодов (де-факто) и свидетельствет о переключении и работе процессов. Хотя теоретически, после Sleep(20); и следующего за этим Sleep(1000);- все должны бы баиньки и прога по крайней мере уже не мигала б.




SetProcessReady(), конечно, вызывается, но планировщика там нет! А TISR_Wrapper
тож вроде с планировщиком дело не имеет, -иначе получается, что перепланирование процессов происходит с каждым тиком системотаймера.

Как раз ISR Wrapper и вызыввает перепланировщик при выходе из прерывания в основную программу (т.е. при вложенных прерываниях при выходе из вложенных не вызывается, там есть счётчик уровня вложения прерываний).
В конце деструктора ISR WRAPPER-а стоит вызов Kernel.SchedISR();, в зависимости от стиля переключателя или перепланировка производится немедленно, или генерируется программное прерывание, происходит возврат в прерванный поток и тут же прерывание переключения контекстов. И так происходит в каждом "по-осевому" оформленном прерывании, не только в таймерном.
Я в тестовый пример (единственный пока в avr-gcc порте) натолкал ногодрыжества в процессы и в хуки, временно добавил даже в переключатель контекстов и наснимал в комп осциллограм. Сейчас малой скоростью пишу к ним более-менее подробное описание происходящих процессов.
"Скоро будет"

p.s. Перепланирование может и оставить всё "как есть", в случае с теми Sleep() - оставить выполняться IdleProcess.

Так сколько по-вашему времени "все должны быть баиньки"? Sleep(20) - это баиньки на 20 тиков системного таймера. Сколько у вас длительность этого тика? Обычно, это времена порядка 1-10 мс. Т.е. если тик 1 мс, то 20 тиков - 20 мс, а 1000 тиков - 1 с. С каким периодом у вас светодиоды перемигиваются? Вот если бы вы там в обоих случаях сделали просто Sleep(), это это действительно были бы полные баиньки.

Да, точно! Внимательно перечитал мануал и исходники, - и правда, перепланирование осуществляется с каждым тиком системника...

Кстати, простеньких примеров с осью ,типа обучающих,пока не встречал.



Тик- 1,6мс где-то. Да, и период миганий так и есть 30мс-1,5 сек. А вот если Sleep(20) и Sleep(1000) местами в процессах поменять, то периоды фактически совсем не такие получаются,- один пракически постоянно горит, а другой, скорее всего, совсем коротенько мигает- еле видно. Но это, видимо, эффект разности процессных приоритетов.