-
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
- 30.09.09 14:20 Pszemol
- 30.09.09 14:45 jotefka
- 30.09.09 15:25 Pszemol
- 30.09.09 18:10 Jan Kowalski
- 30.09.09 18:43 Pszemol
- 30.09.09 20:28 Jerry1111
- 30.09.09 20:35 DJ
- 30.09.09 21:09 Pszemol
- 30.09.09 21:15 Pszemol
- 30.09.09 21:58 Jerry1111
- 02.10.09 06:11 Artur M. Piwko
- 13.10.09 21:06 AK
- 13.10.09 21:34 Jerry1111
- 13.10.09 21:47 Pszemol
- 19.10.09 22:31 Pszemol
Najnowsze wątki z tej grupy
- supercap
- Procesor NMOS i karta CF
- Jak sprawdzic uC
- radyjko znalazłem
- Telewizor przestał widzieć sygnał z anteny
- LED
- System operacyjny dla 6800?
- Przyłączenie działki do sieci elektrycznej
- Działalność nierejestrowana/definicja sprzętu elektronicznego/misie i kolejki
- Smukły, długi ściągacz izolacji do kynaru
- rezystor 3 omy 400W
- [newbie] Jaki multimetr za 2-4 stówy?
- szafka sieciowa
- Raspberry Pi 5 + dyski SATA
- lutownica na węgiel
Najnowsze wątki
- 2024-05-26 O co chodzi?
- 2024-05-26 PJ autobus-tramwaj
- 2024-05-26 Renault Trafic i lampka z czerwonym STOP
- 2024-05-26 cena pięciocyfrowa
- 2024-05-26 Re: Jak dobra KE "okrada" złą Rosję "dla Ukrainy"
- 2024-05-25 supercap
- 2024-05-25 Sulzbach => Technischer Rollouter (d/m/w) <=
- 2024-05-25 Warszawa => Senior Account Manager <=
- 2024-05-25 Warszawa => Mid PHP Developer (Laravel) <=
- 2024-05-25 Warszawa => Mid PHP Developer (Laravel) <=
- 2024-05-25 Warszawa => Interactive/Experience Designer <=
- 2024-05-25 Warszawa => Key Account Manager <=
- 2024-05-25 Warszawa => SAP WM Consultant / Execution <=
- 2024-05-25 Warszawa => Key Account Manager <=
- 2024-05-25 Re: znów ten wrocław