-
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
- Współczesny falomierz
- Zasilacz 7V na szynę DIN
- Waga z legalizacją
- Wietnam wykłada 500M$ i chce zbudować fabrykę za 50G$
- Pendrive zdycha, czy coś jeszcze innego? Problem z plikami.
- Odkurzacz Smapp Dynamic - dawny Zelmer
- Nagra IV i zewnętrzny pilot
- Fejk muzyczny czy nie fejk
- Raspberry Pi 3 Model B+
- Kuchenka elektryczna
- test
- Cewka elektrozaworu
- zapytanie o chip r5f21275nfp
- nie naprawiam więcej telewizorów
- Zrobił TV OLED z TV LCD
Najnowsze wątki
- 2025-03-29 Warszawa => Specjalista rekrutacji IT <=
- 2025-03-28 A gdyby to był elektryk?
- 2025-03-28 Współczesny falomierz
- 2025-03-28 Rzeszów => WEBCON Developer <=
- 2025-03-28 Szczecin => Specjalista ds. public relations <=
- 2025-03-28 Warszawa => Staż w dziale Sprzedaży B2B <=
- 2025-03-28 Warszawa => MENA New Business Manager <=
- 2025-03-28 Środa Wielkopolska => SAP FI/CO Internal Consultant <=
- 2025-03-28 Białystok => Generative AI Engineer <=
- 2025-03-28 China-Kraków => Key Account Manager IT <=
- 2025-03-28 Warszawa => SQL Developer <=
- 2025-03-28 Gliwice => Ekspert IT (obszar systemów sieciowych) <=
- 2025-03-28 Gliwice => IT Expert (Network Systems area) <=
- 2025-03-28 Warszawa => International Freight Forwarder <=
- 2025-03-28 Ostrów Wielkopolski => Konsultant Wdrożeniowy Comarch XL/Optima (Ksi