-
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!not
-for-mail
From: "Pszemol" <P...@P...com>
Newsgroups: pl.comp.programming,pl.misc.elektronika
Subject: printf i wielozadaniowosc (MicroC/OS-II)
Followup-To: pl.comp.programming
Date: Tue, 29 Sep 2009 10:42:52 -0500
Organization: http://onet.pl
Lines: 59
Message-ID: <h...@p...onet.pl>
Reply-To: "Pszemol" <P...@B...com>
NNTP-Posting-Host: gw.petrovend.com
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Trace: news.onet.pl 1254239064 32102 204.248.56.195 (29 Sep 2009 15:44:24 GMT)
X-Complaints-To: n...@o...pl
NNTP-Posting-Date: Tue, 29 Sep 2009 15:44:24 +0000 (UTC)
X-Posting-Agent: Hamster/1.3.13.0
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Newsreader: Microsoft Windows Live Mail 14.0.8064.206
X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206
Xref: news-archive.icm.edu.pl pl.comp.programming:183673 pl.misc.elektronika:572207
[ ukryj nagłówki ]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ć?
Następne wpisy z tego wątku
- 29.09.09 16:18 Zbych
- 29.09.09 16:47 Pszemol
- 29.09.09 16:59 A.L.
- 29.09.09 18:08 grg12
- 29.09.09 18:35 Pszemol
- 29.09.09 20:46 Adam Dybkowski
- 29.09.09 21:04 Jerry1111
- 29.09.09 22:06 Pszemol
- 30.09.09 13:25 Zbych
- 30.09.09 14:20 Pszemol
- 30.09.09 14:45 jotefka
- 30.09.09 15:25 Pszemol
- 30.09.09 18:43 Pszemol
- 30.09.09 20:35 DJ
- 30.09.09 21:09 Pszemol
Najnowsze wątki z tej grupy
- "Wuj dobra rada" z KDAB rozważa: Choosing the Right Programming Language for Your Embedded Linux Device
- Nowa ustawa o ochronie praw autorskich - opis problemu i szkic ustawy
- Alg. kompresji LZW
- Popr. 14. Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- Arch. Prog. Nieuprzywilejowanych w pełnej wer. na nowej s. WWW energokod.pl
- 7. Raport Totaliztyczny: Sprawa Qt Group wer. 424
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
Najnowsze wątki
- 2025-04-05 Dziwny wymiar wyroku
- 2025-04-05 Prunt z dachu
- 2025-04-05 Taśma LED
- 2025-04-05 Kraków => MS Dynamics 365BC/NAV Developer <=
- 2025-04-05 Warszawa => Strategic Account Manager <=
- 2025-04-05 co w Anglii dziś w Polsce za 30 lat
- 2025-04-05 Wrocław => SOC Tech Lead <=
- 2025-04-05 Gdynia => Przedstawiciel handlowy / KAM (branża TSL) <=
- 2025-04-05 Wyrok dożywocia dla Polki
- 2025-04-04 Prezydium Sejmu Tuskiego orzekło: Poseł KO mecenas Roman Giertych NIE jest mordercą (w żadnym sensie tego słowa?)
- 2025-04-04 Reset komóry
- 2025-04-04 Lublin => JavaScript / Node / Fullstack Developer <=
- 2025-04-04 Zielonka => Key Account Manager IT <=
- 2025-04-04 Warszawa => Ekspert IT (obszar systemów sieciowych) <=
- 2025-04-04 Warszawa => Mid/Senior IT Recruiter <=