Użytkownik "Pszemol" <P...@P...com> napisał w wiadomości
news:h9sobc.3s8.0@poczta.onet.pl...
> 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.

Nie znam systemu .. ale
-na pewno jest tak jak myslisz ? Moze to wyzszy priorytet sie
wcina, albo takie sa objawy niereentrowalnosci ?

-tak sie zastanawiam .. wyzszy priorytet wysyla bufor [zadania] i
zawisa gdzies na porcie szeregowym. przelaczamy na drugie zadanie,
ktore dochodzi do wysylania, bufor portu zajety .. ale byc moze
zdazylo juz zarejestrowac chec wyslania. I teraz gdzies po
przerwaniu od portu zostanie ten bufor drugiego zadania wyslany ?


> 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?

czekaj .. a fprintf nie ma jakiegos bufora roboczego ?

> 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).

Tylko ze on moze oddac w trakcie printf, wlasnie czekajac na port
szeregowy.

Bez zrodel sie nie dowiesz :-)

J.