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.
W swoim programie wielow±tkowym dorobi³em na szybkiego logowanie zdarzeñ w celach debugging i u¿ywam "zakazanej" funkcji printf, jako ¿e jest ona bardzo wygodna zw³aszcza z parsingiem argumentów typu %d lub %x w tek¶cie... :-)
Spodziewa³em siê jakich¶ efektów zwi±zanych z niereentrantno¶ci± tej funkcji, ale to co dosta³em trochê mnie zaskoczy³o...
Otó¿ co widzê, to ¿e na wyj¶ciu generowanym przez t± funkcjê fprintf (strumieñ znaków RS232, "plikiem" dla fprintf jest port szeregowy) widzê ¿e w±tek o ni¿szym priorytecie wchodzi z butami w liniê tekstu w±tka o wy¿szym priorytecie i wciêcie jest tam, gdzie fprintf robi ten parsing argumentów %d.
Podam przyk³ady. Oto niezaburzona linia z tasku o najwy¿szym priorytecie (Barrier 0):
"Barrier 0: s:14 M: a8c09, M: b98f, M: 6e71b, M: d14a5, M: 3422e, M: 96ff6, M: f9d77"
A oto podobna linia z wciêciami siê od tasków o ni¿szych priorytetach (Barrier 4):
"Barrier 0: s:14 M: c5aa5Barrier 4: handling legacy sensor readings (time:1607) Barr 4: Decrement counter (26) for legacy sensor (time:1607) Barrier task 4, 'unknown' - wait one dev delay increment... (time:1608) , M: 28521, M: 8b227, M: eddfc, M: 50b03, M: b365c, M: 223b1, M: 66cf0"
Task o priorytecie 3 schodki ni¿ej, wci±³ siê w ¶rodek fprintf'a od tasku o prawie najwy¿szym priorytecie i to w miejscu, gdzie skoñczy³o siê parsowanie argumentu %x i zacz±³ text printf'a.
Tu inny przyk³ad, ta sama sytuacja (barrier 7 to task o priorytecie 8): "Barrier 0: s:09 R: 152ba, R: 78080Barrier 7: handling legacy sensor readings (time:1613) Barr 7: Decrement counter (42) for legacy sensor (time:1613) Barrier task 7, 'unknown' - wait one dev delay increment... (time:1613) , R: dae06, R: 3db91, R: a091a, R: 36a4, R: 66445, R: c91aa"
Jak wyt³umaczyæ takie efekty?
Rozumiem, ¿e skoro wywo³ania fprintf'a z tasków dotycz± tego samego portu szeregowego, przekazanego fprintf'owi jako argument nazwy pliku (globalna zmienna) to mo¿e siê co¶ kiep¶ciæ, i linie siê bêda przeplataæ, ale nie rozumiem jak taski o ni¿szym priorytecie mog³y siê wstrzeliæ z TRZEMA OSOBNYMI WYWO£ANIAMI fprintf'a w jedn± liniê tasku o wy¿szym priorytecie? Przecie¿ wed³ug filozofii MicroC/OS-II task bariery 0, w czasie chodzenia sobie po kodzie fprintfa nie powinien byæ przerwany i taski o priorytetach 4 czy tym bardziej 8 powinny grzecznie czekaæ a¿ fprintf wywo³any przez task o priorytecie 1 ukoñczy zadanie i odda sterowanie systemowi operacyjnemu (nie ma tu wyw³aszczania).
Czy kto¶ móg³by mi to wyt³umaczyæ?