[katarsis 0]

Есть проблема, понятное дело для телепатов, подругому никак, но может кто встречался с проблемой.

не зависимо от дисциплины обслуживания (mlqueue, bitmap), шедуллер работает только с потоком максимального приоритета. Т.е.

1. (mlqueue) если я делаю 3 потока приоритета скажем 6 - все 3 потока будет обрабатыватьсяпо очереди, а если я делаю 667 или 678, то обрабатывается только поток приоритета 6.

2. (bitmap) делаю 3 потока 678 - опять та же картина, обрабатывается поток 6ого приоритета.

[Andrew2000 0]

Думаю, приоритетные потоки необходимо периодически в sleep загонять.

[axle 0]

В чем собственно вопрос? Все правильно работает.

[katarsis 0]

да нет уже вопросов, скажем так

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

[Quasar 20]

Думаю, приоритетные потоки необходимо периодически в sleep загонять.

В чем собственно вопрос? Все правильно работает.

 

Есть eCos 3.0 с TCP/IP стеком, есть поток работающий с консолью, он получает строчки с терминала, как-то там их обрабатывает и шлет в консоль ответ, получает он эти строчки fgets()'ом. Когда поток входит в fgets контекст перестает переключаться, железка не пингуется... Почему так? Во FreeRTOS вне зависимости от приоритетов такого не было, во FreeRTOS задача блокировалась и просыпалась лишь тогда когда приходил очередной символ, здесь при ожидании очередного символа все тупо останавливается. Если запустить поток, не вызывающий fgets, контекст нормально переключается.

Изменено 10 июля, 2009 пользователем Quasar