"grg12" <g...@c...at> wrote in message
news:25a0$4ac24d00$506cdd75$32156@news.chello.at...
> Pszemol pisze:
>> W systemie MicroC/OS-II wszystkie wątki uszeregowane są według swoich
>> priorytetów i wątek o niższym priorytecie dostaje procesor TYLKO WTEDY
>> gdy wątek o wyższym priorytecie nie ma nic do roboty i czeka na
>> zdarzenie.
>
> A aktywny wątek o niskim priorytecie może zostać przymusowo "uśpiony"
> na rzecz wątku wysokopriorytetowego czy przełączenie następuje tylko jeśli
> aktywny watek dobrowolnie odda sterowanie (tak było w np. win3.1)?

Wysoki priorytet zwykle śpi bo czeka np. na przerwanie od zegara
lub od urządzenia zewnętrznego, np. RS232. Czyli masz przerwanie
które przychodzi od RS232 a jesteś w tasku o priorytecie 3 to system
obsługuje przerwanie i po obsłudze znowu sprawdza gdzie wrócić.
Ponieważ mam dwa taski gotowe, task o priorytecie 1 czekał na RS232
a już nie czeka, to task 1 powinien dostać sterowanie...

Podsumowując, nie dziwiłbym się że w linii loga od tasku 3 mam
przerwy i z buciorami wchodzi task 0 czy 1 ze swoim tekstem...
Ja się dziwię że linia od tasku 0 została przerwana w połowie
i wszedł w jej środek task 3 Z TRZEMA WYWOŁANIAMI fprintf'a.

> Przypuśćmy że wątek HiPrio pisze sobie coś do bufora łącza szeregowego,
> bufor zostaje zapełniony więc wątek zostaje uśpiony do czasu opróżnienia
> bufora, wątek LowPrio przejmuje pałeczkę, po pewnym czasie próbuje zapisać
> do bufora łącza, który został już opróżniony przez obsługę portu
> szeregowego (jakieś przerywanie zapewne) - wypisuje swoje i grzecznie
> idzie spać. W tym momencie obudzony zostaje wątek HiPrio...

Ja nie widzę tutaj możliwości aby z dwu tasków czekających na
przerwanie od portu szeregowego dorwał się do RS232 ten
o niższym priorytecie i to w połowie parsingu od fprintfa HiPrio.