[Colobox 0]

Допустим, есть два процесса, 1 и 2. Процесс 1 ушел в спячку, например, с помощью Sleep(20), ессно,

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

[Johnny81 0]

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

[Colobox 0]

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

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

[dxp 18]

но фактически этого не происходит.

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

 

Вопрос- так что же дает управление процессу 1 после спячки?

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

[sergeeff 1]

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

[Сергей Борщ 77]

Вопрос- так что же дает управление процессу 1 после спячки?

...

вроде только системный таймер в наличии

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

[Colobox 0]

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

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

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);- все должны бы баиньки и прога по крайней мере уже не мигала б.

 

 

 

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

SetProcessReady(), конечно, вызывается, но планировщика там нет! А TISR_Wrapper

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

[ReAl 0]

Как раз ISR Wrapper и вызыввает перепланировщик при выходе из прерывания в основную программу (т.е. при вложенных прерываниях при выходе из вложенных не вызывается, там есть счётчик уровня вложения прерываний).

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

Я в тестовый пример (единственный пока в avr-gcc порте) натолкал ногодрыжества в процессы и в хуки, временно добавил даже в переключатель контекстов и наснимал в комп осциллограм. Сейчас малой скоростью пишу к ним более-менее подробное описание происходящих процессов.

"Скоро будет"

 

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

[dxp 18]

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

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

[Colobox 0]

Как раз ISR Wrapper и вызыввает перепланировщик при выходе из прерывания в основную программу (т.е. при вложенных прерываниях при выходе из вложенных не вызывается, там есть счётчик уровня вложения прерываний).

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

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

Я в тестовый пример (единственный пока в avr-gcc порте) натолкал ногодрыжества в процессы и в хуки, временно добавил даже в переключатель контекстов и наснимал в комп осциллограм. Сейчас малой скоростью пишу к ним более-менее подробное описание происходящих процессов.

"Скоро будет"

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

 

 

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

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