Dotaz: C / C++ - techniky programovani bez nekonecne smycky

[Tomáš Skočdopole]

Ahoj,

chtel bych se zeptat, jakou technikou se delaji programy, aby nemusely mit nekonecnou smycku while (1) { ... }, ktera zbytecne zatezuje procesor.

Program by mel byt ciste konzolovy, takze pouziti Qt, GTK knihoven neni mozne.

Od programu se ocekava soubezne obsluhovani vice seriovych portu, provadeni periodickych cinnosti (napr odeslani dat po seriovem portu)

a zaroven refresh UI na zaklade urcitych udalosti (prijata data ze SP, periodicke cinnosti atd...).

Vyhovovalo by mi neco jako udalostmi rizene programovani. Ale bohuzel jsem nikde nenasel jak na to.

Diky vsem za help.
Tomas

Odpovědi

[Messa]

Smyčka je základem mnoha programů Na události se čeká, nejlépe pasivně. Buď použitím blokujících IO operací, nebo použitím selectu/epollu. Záleží na tom, s čím budeš pracovat, kernel určitě pro to nějakou podporu mít bude. Může být těžké více věcí ohlídat v jednom vlákně, dá se proto použít více vláken nebo procesů a mezivláknová, resp. meziprocesová (neboli IPC) komunikace a synchronizace.

Takže to UI máš v textové konzoli? Já bych takový program navrhl asi za použití klient-server architektury, server by dělal všechnu tu práci a klienti by byly právě ty UI programy, které by jen hezky zobrazovaly data ze serveru. Takhle se dělá kde co, včetně hudebních přehrávačů. Samozřejmě tam dole pokaždé nějaká smyčka bude, co myslíš, že je v GTK nebo Qt?

BTW. předpokládám, že tohle má být pokračování této diskuze Možná by bylo lepší, kdyby ses více rozepsal o svém projektu, pokud je přínosný a open-source, asi by podle mě bylo vhodnější začít (třeba zde) nějakou spolupráci s někým, kdo je ti ochoten pomoc, protože opakováním v podstatě stejného dotazu se nedozvíš o mnoho víc než minule.

[Tomáš Skočdopole]

Smyčka je základem mnoha programů Na události se čeká, nejlépe pasivně. Buď použitím blokujících IO operací, nebo použitím selectu/epollu. Záleží na tom, s čím budeš pracovat, kernel určitě pro to nějakou podporu mít bude. Může být těžké více věcí ohlídat v jednom vlákně, dá se proto použít více vláken nebo procesů a mezivláknová, resp. meziprocesová (neboli IPC) komunikace a synchronizace.

No v podstate jde o jednosmernou komunikaci od /dev/js0, pak obousmerna komunikace od /dev/ttySx, a ziskani obrazu z kamery, pripadne vstup od uzivatele, (pauza, stop, play). Program v podstate dostane waypointy, po spusteni si ziska informaci z GPS (po seriove lince), pak ze senzoru (po seriove lince) a obraz z kamery. Nasledne tyto data zpracovava (obraz z kamery ve vlastnim vlakne). Behem zpracovani musi byt schopen reagovat na prijate data ze seriovych linek (napr zda ultrazvuky nenasly prekazku) a pak musi periodicky odesilat data na seriovy port. Po zpracovani je vyhodnocen novy prikaz pro pohonou jednotku a cyklus jede znovu. V podstate jenom mi jde o to, abych odstranil 100 zatez CPU, ktera je zpusobena touto smyckou. Zavolat v teto smycce fci sleep s nejakym kratkym intervalem sice vede ke snizeni zateze, ale stejne to neni to, co bych potreboval.

Takže to UI máš v textové konzoli? Já bych takový program navrhl asi za použití klient-server architektury, server by dělal všechnu tu práci a klienti by byly právě ty UI programy, které by jen hezky zobrazovaly data ze serveru. Takhle se dělá kde co, včetně hudebních přehrávačů.

Soucasne to je reseno tak, ze program je pusten po ssh. Neni potreba obsluhovat vice klientu (viz ucel programu napsany dole).

Samozřejmě tam dole pokaždé nějaká smyčka bude, co myslíš, že je v GTK nebo Qt?

No mozna je, ale "nezere" 100 vykon CPU...

BTW. předpokládám, že tohle má být pokračování této diskuze Možná by bylo lepší, kdyby ses více rozepsal o svém projektu, pokud je přínosný a open-source, asi by podle mě bylo vhodnější začít (třeba zde) nějakou spolupráci s někým, kdo je ti ochoten pomoc, protože opakováním v podstatě stejného dotazu se nedozvíš o mnoho víc než minule.

No toto delam jako bakalarskou praci, takze musim sam :) Jde o robota, ktery se ma autonome pohybovat v prostredi. Uvnitr je obycejny PC (s 35W TDP procesorem AMD). Vsechny ridici algoritmy uz mam napsane, ale nelibi se mi ta hlavni smycka. Jelikoz robot je napajen z baterii, mame nastavene CPU frequency scalling, ale pri pusteni toho programu se vykon CPU timto zvysi a zkrati se tak maximalni doba vydrze baterii. Proto bych to chtel nejak odstranit. Nove vlakno jsem vytvoril z duvodu, ze to predchozi bylo mireno na seriovy port, zde jsem se ptal obecne, na techniku programovani tohoto druhu aplikaci.

Snad uz je ted jasnejsi co vlastne potrebuji. Dekuji Tomas

[JS]

Pak patrne zalezi na tom, jak casto je treba celou smycku provadet. No a vzdycky na zacatku zmerit aktualni cas, a na konci pockat dokud neuplyne doba, na kterou je nastavena perioda smycky. Pokud byste ovsem chtel jeste zachytit nejake udalosti v prubehu toho cekani, musel byste napriklad cekat na nejaky jiny thread, ktery by cekal na prislusnem zarizeni a informoval by vas jen v pripade, ze by se tam objevila nova data.

 

[Tomáš Skočdopole]

Pak patrne zalezi na tom, jak casto je treba celou smycku provadet. No a vzdycky na zacatku zmerit aktualni cas, a na konci pockat dokud neuplyne doba, na kterou je nastavena perioda smycky. Pokud byste ovsem chtel jeste zachytit nejake udalosti v prubehu toho cekani, musel byste napriklad cekat na nejaky jiny thread, ktery by cekal na prislusnem zarizeni a informoval by vas jen v pripade, ze by se tam objevila nova data. 

Praveze potrebuji zachycovat udalosti, ktere chodi "nahodne". No to jedno cekaci vlakno by mozna bylo reseni. Ale jakym zpusobem lze informovat to hlavni vlakno, ze se ma rozjet? A jak vubec to hlavni vlakno zastavit?

[Andrej Herceg]

Ak sa používa knižnica pthread, dá sa použiť funkcia pthread_cond_wait() a potom sa použije pthread_cond_signal(), alebo pthread_cond_broadcast().

Nejké informácie sú napr. tu prípadne tu (a samozrejme v dokumentácii k pthreads).

[Josef Kufner]

Toto vlákno diskuse je ukázkou toho, jak to NEdělat. Správné a jednoduché řešení stojí na použití funkce select nebo jí podobné (jak je popsáno v diskusi níže).

[Michal Kubeček]

V diskusi už opakovaně zaznělo, že tazatel potřebuje během čekání na data provádět jinou činnost. To při použití select() těžko zařídíte.

[Tomáš Skočdopole]

Ano prave toto potrebuji. Napriklad kdyz budou probihat algoritmy pro zpracovani obrazu (ktere urcite nedokazu naimplementovat super rychle) a prijde po seriove lince, ze ultrazvuk zachytil prekazku. Tak v momente kdy by si ji ridici program teprv vyzvedl uz by mohlo byt pozde :)

Tomas

[Abraxis]

Rozhodne napis zpracovani jednotlivych kanalu (ser. portu, kamery apod.) do zvlast vlaken (nebo idealne programu, ktere se ti pak budou i lip ladit). Otazkou pak zustava, jak napsat hlavni ridici program. V zasade mas tyhle moznosti jak zasilat a zpracovavat informace z podrizenych programu:

- pres file-descriptory - pak jednoducha smycka se select (vis, ze select muzes provest na vice FD najednou?)

- pres klasicke POSIX signaly (neni moc elegantni)

- pres sockety (klidne i pres TCP a 127.0.0.1) - dobre se ladi a simuluje a v budoucnu skaluje

- pouzij Qt - tohle bych zvolil ja, protoze jejich signal/slots funguje hezky a Qt obecne ti uspori spoustu prace

[Abraxis]

Jo - jeste pro uplnost - vynechal jsem jeste pouziti shared memory a pouziti nejake MPI knihovny, protoze si myslim, ze to je pro tebe over-kill.

[Josef Kufner]

Poslední parametr selectu označuje max. dobu po kterou má čekat. Pokud potřebuje provádět výpočty, dá tam nulu, select jen koukne, jestli se něco zajímavého nestalo a pokud ne, řekne, že timeout.

[Michal Kubeček]

To ale není řešení. Nakonec narazíte na přesně stejný problém, kvůli kterému byly select(), poll() a další vlastně vytvořeny: buď se budete dívat moc často a zbytečně zatěžovat procesor, nebo ne dost často a budete mít dlouhou odezvu.

[Josef Kufner]

Ale ten timeout je tam uveden maximální, nikoliv minimální. Je to hodnota, která říká, jak dlouho má select() na nějakou událost čekat než oznámí timeout. Takže i když bude timeout veliký, reagovat na události z fd to bude okamžitě. A stdin má fd taky...

[Michal Kubeček]

Vy jste navrhoval nulový timeout, takže pak se vám select() hned vrátí a jen řekne, jestli máte data nebo ne. Jenže pokud něco potřebujete aktivně provádět, pak to musíte proložit opakovanými voláními toho select(). To má ale dva problémy: za prvé to nemusí být úplně jednoduché. Za druhé buď budete select(..., 0) volat hodně často a zbytečně tím zatěžovat procesor, nebo méně často a pak se o datech dozvíte až s určitým zpožděním. Což je přesně problém, kvůli kterému select() vůbec vznikl - abyste při čekání na víc deskriptorů nemusel ve smyčce volat neblokující čtení.

Tato situace, kdy potřebujete čekat na deskriptor a zároveň provádět něco, co vám select() nepokryje (tj. něco, co není čekáním na deskriptor nebo signál), je prostě případem, kdy je daleko jednodušší a efektivnější oddělit ty dvě věci do samostatných threadů nebo procesů.

[Semo]

Smarja, ved su aj ine moznosti ako timeout nulovy a nekonecny! Ak potrebujem kazdu sekundu (dosadte si konstantu podla potreby) kontrolovat obrazok z kamery, tak nastavim sekundovy timeout (prip. sekunda minus epsilon, kedze to volanie selectu nieco trva a spracovanie obrazku z kamery tiez). Ked sa mi select vrati, tak sa pozriem ci preto, ze nieco prislo na nejaky filedescriptor alebo preto, ze expiroval. Ak expiroval, tak spracujem kameru a a zavolam select znova. Ak neexpiroval, tak osetrim filedescriptory, nastavim novy timeout na ten, s ktorym sa mi vratil select (prip. este minus epsilon) a zavolam ho znova.

Takze jednoduche je to dostatocne. Zataz procesora nie je vyssia ako nutna, pretoze ho vyuzivam skutocne len vtedy, ked pridu data alebo ak potrebujem spracovat kameru. Nebudim sa zo selectu castejsie ako musim. Ak by som sa rozdelil do dvoch vlaken, tak sice mam nekonecny timeout na selecte, ale to druhe vlakno aj tak kazdu sekundu pouzije CPU na ovladanie kamery. Takze som neusetril nic a prepinanie vlaken tiez nieco stoji. A snazim sa ako mozem, ale spozdenie dat nedokazem najst. Kde by malo byt?

BSD-like Unixe, nenastavuje zvysny cas v timeoute selectu, takze na BSD si treba ukladat systemovy cas pred volanim selectu a porovnavat ho so systemovym casom po navrate z neho.

Pre sietovu cast velkeho skolskeho projektu som programoval pred asi 4 rokmi nieco velmi podobne. Drzat mnozstvo otvorenych TCP spojeni, cez ktore pritekaju a odetkaju data. Ziadne spojenie nesmelo trvat dlhsie ako definovany cas (ochrana pred DOSom), ak pretiahalo, tak bolo ukoncene. A stale som musel byt schopny reagovat aj na "signaly" zo zvysnej casti programu = ostatnych vlaken (sifrovacich, hlavneho ovladacieho atd.). V zadani projektu bola vyzadovana prenositelnost minimalne na Linux, Mac, Win. Takze na POSIXove signaly so mmohol zabudnut (co ja by som dal za pselect()). Riesil som to vytvorenim TCP spojenia, ktoreho oba konce drzal program samotny a jeho citaci koniec bol zaraadeni do mnoziny filedescriptorov pre select. Ked chcel niekto zobudit cakajuce sietove vlakno, tak zapisal spravu do konca tohoto spojenia urceneho pre zapis (to bolo dostupne vsetkym). Tym sa prerusil select a standardnou cestou sa zistilo, ze nejaky vlaknovy kolega po mne nieco chce (napriklad restart, alebo zmena maximalneho poctu spojeni, zmena timeoutu pre spojenia a pod.). Systemovy cas expirovania kazdejo spojenia bol vo utriedenej fronte a vzdy rozdiel medzi jej prvym prvokom a systemovym casom urcoval timeout pre select. Do fronty sa pridavalo iba na koniec, odoberalo zo zaciatku a nemusela sa v kazdom kroku prepocitavat. V pripade spojenia, ktore stihlo poslat vsetky data este pred vyexpirovanim je nutne najst zaznam uprostred fronty - moze sa spravit kruhova v poli a binarnym vyhladavanim znizit tuto zlozitost na logaritmicku. Alebo mat vyhladaciu tabulku indexovanu cislom descriptoru ukazujucu do fronty a mat to konstantne.

Testovane to bolo v 24h v skolskom labe s desiatkami pocitacov, kde kazdy komunikoval s kazdym a kazdy drzal desiatky otvorenych spojenia a zataz sietoveho vlakna zanedbatelna oproti sifrovacim vlaknam. Programuje sa to trocha zlozitejsie ako Hello world, ale nez si nechat v systeme zit a prepinat 100 vlaken (nech aj v poole), kde kazde obsluhuje jedno spojeni...

[Michal Kubeček]

Ta konstrukce z prvního odstavce sice zní rozumně, ale je to řešení pro úplně jinou situaci, než jakou řeší tazatel.

Takze som neusetril nic a prepinanie vlaken tiez nieco stoji. A snazim sa ako mozem, ale spozdenie dat nedokazem najst. Kde by malo byt?

Pokud budete select(..., 0) volat s periodou t, pak přijdou-li data, zpracujete v průměru se zpožděním t/2 (ale při troše smůly to může být skoro t). Zvolíte-li t nízké, budete zbytečně zatěžovat procesor neustálým voláním syscallu select(), zvolíte-li ho vysoké, pak bude úměrně tomu vysoká i odezva. Pokud použijete nenulový timeout, pak během čekání nemůžete dělat nic jiného.

[Josef Kufner]

Otázkou je, co to "něco" je. Pokud to je update nějaké animace nebo něčeho podobného, co není třeba provádět neustále, tak se jen selectu nedá nula ale nějaká vhodnější hodnota.

Pokud to "něco" je třeba provádět opravdu neustále (což je celkem výjimečný případ), bude nejspíš nejjednodušším řešením smyčka for(;;) { if(nová data) { posbírej_je()} ; udělej_něco() }. Pokud toto budeš řešit pomocí vláken, výsledkem zamykání bude totéž. Otázkou pak už jen je, zda je rychlejší volat select() nebo pthread_mutex_lock() + pthread_mutex_unlock() a zda to stojí za obtížnější ladění.

V ostatních případech bych se vrátil k návrhu programu jako celku a zamyslel se, kde mám chybu.

[Michal Kubeček]

Tak si přečtěte ty ostatní příspěvky. Tazatel potřebuje provádět časově náročné algoritmy pro analýzu obrazu a během jejich zpracování mohou přijít nějaká data na sériový port; pokud k tomu dojde, potřebuje je zpracovat pokud možno okamžitě. Ano, není to úplně typická situace, ale on právě takovou situaci má a právě takovou situaci potřebuje řešit.

Co se časové náročnosti týká, když jsem to kdysi měřil (nějaký Athlon64 kolem 2 GHz), časová náročnost páru lock+unlock byla podle typu mutexu 27-30 nanosekund. Sice jsem nezkoušel měřit select(), ale už s ohledem na to, že je to syscall, zdá se mi nepravděpodobné, že by jeho náročnost mohla být na stejné úrovni. Ale jestli chcete, klidně to zkusím.

[Josef Kufner]

Hm, ten začátek jsem nečetl moc důkladně, spíš jsem reagoval na ty obskurnosti s vlákny kvůli čekání na různé události.

Přidání časově náročného výpoču na věci nic moc nemění. Řídící smyčka bude stejná, jak jsem popsal dříve, jen tam bude o jeden event ke zpracování více -- "výpočet je hotový". Oznámení se může provédst buď pomocí již zmíněného signalfd, obyčejnou rourou (pipe()) nebo prostým posláním signálu, který přeruší čekající select(), takže k žádným prodlevám dochazet nebude.

Pro asynchroní spuštění vlastního výpočtu už je použití vlákna celkem rozumné (s tím, že se nemusí vytvářet pro každý výpočet nové), ale to není to s čím měl tazatel problém.

[tuxmartin]

 

Uvnitr je obycejny PC (s 35W TDP procesorem AMD). Vsechny ridici algoritmy uz mam napsane, ale nelibi se mi ta hlavni smycka. Jelikoz robot je napajen z baterii, mame nastavene CPU frequency scalling, ale pri pusteni toho programu se vykon CPU timto zvysi a zkrati se tak maximalni doba vydrze baterii.

Je nutne pouzit bezny PC? Neslo by treba pouzit alix3d3 nebo BR-6104KP?

 

[Tomáš Skočdopole]

 

Smyčka je základem mnoha programů Na události se čeká, nejlépe pasivně. Buď použitím blokujících IO operací, nebo použitím selectu/epollu. Záleží na tom, s čím budeš pracovat, kernel určitě pro to nějakou podporu mít bude. Může být těžké více věcí ohlídat v jednom vlákně, dá se proto použít více vláken nebo procesů a mezivláknová, resp. meziprocesová (neboli IPC) komunikace a synchronizace.

Takže to UI máš v textové konzoli? Já bych takový program navrhl asi za použití klient-server architektury, server by dělal všechnu tu práci a klienti by byly právě ty UI programy, které by jen hezky zobrazovaly data ze serveru. Takhle se dělá kde co, včetně hudebních přehrávačů. Samozřejmě tam dole pokaždé nějaká smyčka bude, co myslíš, že je v GTK nebo Qt?

BTW. předpokládám, že tohle má být pokračování této diskuze Možná by bylo lepší, kdyby ses více rozepsal o svém projektu, pokud je přínosný a open-source, asi by podle mě bylo vhodnější začít (třeba zde) nějakou spolupráci s někým, kdo je ti ochoten pomoc, protože opakováním v podstatě stejného dotazu se nedozvíš o mnoho víc než minule.

Jeste jsem uvazoval o tom pouziti modelu klient/server. Mozna by to bylo vyhodne uz jen proto, ze by bylo mozne ovladat aplikaci i vzdalene a moznost udelat i nejake GUI, misto textoveho UI v konzoli.

 

Rikal jsem si, ze by byl nejaky daemon, ktery by naslouchal na urcitem portu. A mel by nastarost komunikaci s hardwarem (seriove porty, joystick, kamera). Zde by byla funkce select pro obsluhu jednotlivych zarizeni. K tomuto serveru by se pak pripojila hlavni aplikace, ve ktere by byly naimplementovany ridici algoritmy ktere by pak komunikovaly s hardwarem prostrednictvim socketu. Cili hlavni aplikace by pak mohla behem cekani na urcita data provadet i neco jineho.

Byl by tento model uz lepsim resenim, nebo je zde nejaky schovany "problem".

Mnohokrat dekuji za cenne rady!

[Semo]

Pokial vsetko co obsluhujes ma deskriptor, tak:

man select
man select_tut

terminal je deskriptor, sietove sockety tiez, ak pristupujes k ser. portu cez zariadenie z dev, tak tiez. Takze nic nestoji v ceste pouzit select. V najhorsom pripade s nejakym timeoutom, ale ak sa da, tak je lepsie bez neho.

[Bluebear]

Nekonecna smycka sama o sobe procesor nezatezuje. Zatez procesoru vznika jen tehdy, kdyz je to busy loop - tedy smycka, ktera bezi s maximalni moznou rychlosti bez cekani. Pokud ve sve smycce cekas na nejakou udalost, napriklad na to, az se na nekterem z portu objevi nejaka data, tak tvuj proces behem cekani neni nijak aktivni a procesor je volny.

[Tomáš Skočdopole]

ano to mi je jasne, ale jak jsem psal: nemuzu cekat na nejakou udalost, protoze potrebuji behem toho provadet jinou cinnost.

Takze spis by se mi hodilo neco na zpusob udalostmi rizene programovani.

Proste prijdou data na port, vygeneruje se udalost, kterou vyridim, uzivatel pohne joystickem, vygeneruje se udalost na kterou patricne zareaguji. Vyprsi casovac, provede se nejaka akce.

Kameru jsem si uz udelal ve vlastnim vlakne, takze tu neni potreba resit.

Napriklad zkousel jsem si udelat tridu pro praci se seriovym portem, ktera vytvori dve dalsi vlakna a otevre port v blokujicim rezimu. Jedno vlakno bude tedy stat na fci read na seriovy port, v pripade prijatych dat vlakno tedy pokracuje v behu, kde ulozi data do bufferu a pusti funkci, kterou uzivatel dane tridy nastavil pomoci ukazatele na ni. U odesilaciho vlakna jsem nevedel, jak predat data k odeslani. Respektive nevedel jsem jak "zastavit" odesilaci vlakno, aby cekalo az nekam poslu data. Zatim jsem to vyresil tak, ze odesilaci vlakno se vytvori v pripade ze chce uzivatel neco odeslat a hned potom skonci. Coz me prijde neefektivni.

Tomas

[JS]

No pak se musi pouzit  mezivlaknova komunikace, napr. pomoci zamku a cekani na ne. Prislusne funkce jsou bud z rodiny pthread_cond* nebo pthread_mutex* (presne to nevim, a nemam tu nainstalovane jejich manpages).

 

[Josef Kufner]

Zapomeň na vlákna. Je to zdroj zbytečných problémů, těžko se ladí a nejsou tu vůbec potřeba.

[pht]

Ja si stale myslim, ze to lze resit jednovlaknove pomoci selectu.

Ale samozrejme existuje miliarda jinych reseni, vcetne vlaken. Idealne se na toto hodi jazyk ada, ktery ma ulohy (task) a vsechny veci kolem (synchronizace, pristup k promennym) primo zabudovane v sobe.

Taky na takovouto ulohu existuji predpripravene frameworky, kde jen nacpete svoje udalosti a reakce na ne.

[trekker.dk]

Takze spis by se mi hodilo neco na zpusob udalostmi rizene programovani.

Už jsem ti to doporučoval minule - zkus si najít něco o signálech a jejich použití. Jestliže potřebuješ událostmi řízené programování, nedovedu si představit vhodnější řešení.

(Vlákna nebo dokonce IPC jsou v tomto případě neskutečný overkill.)

[Tomáš Skočdopole]

Ano, ale signaly pro uzivatelske pouziti jsou definovane jen dva SIGUSR1 a SIGUSR2. To me nestaci...

[trekker.dk]

Ach jo. Dobrá, budu se tvářit, že nemám den nahovno a místo toho, abych tě poslal RTFM, tak trochu rozvedu to, co jsem myslel pod "najít si něco o signálech a jejich použití"

V Linuxu máš nějaké signály, jejich seznam najdeš na webu, v man kill, v htopu. Ty, jak už název napovídá, signalizují, že se něco stalo.

Například si vezměme SIGTERM - tenhle signál se pošle programu, když mu dáš Ctrl-C, když se vypíná počítač (zařizuje nějaký skript, pošle SIGTERM všem) apod. Program má automaticky v sobě zabudovanou nějakou obsluhu tohoto signálu (většinou takovou, která program ukončí), ale ty ji můžeš předefinovat, například ji nechat vypsat "teď se nemůžu ukončit" a nechat program běžet dál. man sigaction

Pak tu máme signál SIGIO, který tě asi bude zajímat víc. Ten se procesu pošle může poslat ve více případech; pošle se jenom, když si nastavíš, že chceš, aby se ti poslal (tj. není to automatické.) Postup je přibližně takhle:

1. Otevře se port
2. Nastaví se, že program bude obsluhovat signál SIGIO (man sigaction)
3. dvě fcntl, jedno řekne, že otevřený popisovač souboru sériového portu bude programu posílat SIGIO, druhý přepne port do asynchronního režimu

Podrobnější info - UTFG (linux serial port programming) - můžeš "zkusit štěstí", je to první odkaz. Doporučuji prohlédnout, než tohle budeš číst dál.

Proste prijdou data na port, vygeneruje se udalost, kterou vyridim, uzivatel pohne joystickem, vygeneruje se udalost na kterou patricne zareaguji. Vyprsi casovac, provede se nejaka akce.

Výše uvedené v tomhle případě stačit nebude (možná by to šlo, ale je to pěkný hnus), proto je tu druhá varianta. Na funkce jednotlivě obsluhující signály se vykašleme (zapomeň na sigaction, místo toho se zablokují všechny signály, na které chceš reagovat (man sigemptyset, man sigaddset, man sigprocmask), nastavíš, co je potřeba nastavit (např. ty fcntl z příkladu výše) a vstoupíš do nekonečné smyčky:

(Příklad - program může přijmout data z portu, každou vteřinu vyprší časovač, pomocí Ctrl-C se to celé ukončí.)

for (;;) {
  rv = sigwaitinfo (&signaly_waitset, &signal_info);
  if (rv < 0) {
    ...
    }
  switch (signal_info.si_signo) {
    case SIGALRM: {
      printf ("Uplynula jedna vteřina, spácháme periodickou činnost\n");
      ...
      break;
      }
    case SIGTERM: {
      printf ("Program končí\n");
      ...
      exit(0)
      }
    case SIGIO: {
      printf ("Přišla nám od někoho nějaká data, zjistíme, kdo to je a co chce\n");
      ...
      break;
      }
    default: {
      printf ("Přišel signál, který jsme si neobjednali, vynadáme číšníkovi\n");
      break;
      }
    }
  }

Tohle už je lepší a dělá to víceméně to, co potřebuješ. V té smyčce mohou být další věci, ale pozor - program se ve volání sigwaitinfo zastaví a bude čekat tak dlouho, dokud nepřijde nějaký signál. (Přesněji - zastaví se vlákno, ve kterém tu funkci voláš, jiná vlákna samozřejmě poběží dál.)

Ještě pořád to má háček, že u obsluhy toho SIGIO budeš muset zjistit, odkud ta data přišla (pokud tedy nebudeš takto asynchronně přijímat jenom z jednoho souboru), což je trochu protivné. Nechá se to obejít tak, že si místo SIGIO necháš posílat nějaký real-time signál a pak ve struktuře signal_info dostaneš informaci o tom, ze kterého fd ten signál přišel.

[pht]

Jen doplnim ze ten SIGALRM se da objednat u setitimer().

Oproti tomuto "klasickemu" pristupu pak existuje jeste jiny, novy, ktery je kompletne zalozeny jen na filedescriptorech (proto furt trvam na tom ze uloha je resitelna pres select/poll :). Viz funkce signalfd a timerfd.

[Semo]

To iste je riesitelne cez pselect s timeoutom prepocitanym v kazdom kroku, nie? Jedine co som ale teraz nenasiel v manuale k pselectu je, ze ci som schopny zistit typ signalu, ktory ma vyrusil z pselectu.

[trekker.dk]

proto furt trvam na tom ze uloha je resitelna pres select/poll

Stejně tak je úloha řešitelná přes vlákna. Proč to dělat jednoduše, když to jde složitě, že?

[pht]

IMHO by to ten pristup ponekud zjednodusil - muzu cekat na timer i na filedescriptory v jednom kroku. Signaly by z toho asi vypadly uplne. Maximalne pokud bych chtel hlidat ten TERM. Tohle nove API se dost propiralo a chvalilo, tak snad k tomu nejaky duvod byl.

Teoreticky, jelikoz v teto uloze potrebuji navic jen timer, tak by se to dalo resit i bez toho timerfd, a to tak, ze bych si rucne ladil timeout pro kazdy select (nebo pselect jak radi kolega). Pribude mi tam ale kod pro vypocet timeoutu a kontrola na nej. Timerfd mi to da zadarmo.

[trekker.dk]

Signaly by z toho asi vypadly uplne.

Vypadly by jenom částečně - programátor je nevidí, ale jsou tam furt. Ale dobrá, tohle by možná o tolik složitější nebylo - asi to bude víc o zvyku. Ale ta vlákna?

[pht]

Vlakna leda v te Ade

[Semo]

Isteze je timerfd pohodlnejsie riesnie, ale funguje iba na Linuxe a aj to dost novom. Nakolko su tu preberane "techniky" a nie implementacia pre Linux, tak som navrhoval pselect ako POSIXove riesnie.

[pht]

To je pravda. Bohuzel nekdy i "POSIX" reseni se musi pak priohnout na konkretni OS.

[Michal Kubeček]

SIGTERM - tenhle signál se pošle programu, když mu dáš Ctrl-C

Ctrl-C posílá INT, ne TERM.

[trekker.dk]

Pravda, překoukl jsem se ve zdrojáku...

[peter]

AFAIK cyklus sa da v C++ nahradit pomocou sablon.

[vencas]

Jo? (nebo je to vtip?)

[default]

Ahoj!

Já teď dělám něco podobného. Sice mám místo sériového portu síť, ale nevadí. Dělám to vlákny. V mém případě je to nejelegantnější řešení. Největší "challenge" je synchronizace těch vláken. Možná ti to pomůže, možná ne.

[Josef Kufner]

Pomůže... do hrobu

[Michal Kubeček]

Chápu, máte proti threadům něco osobního. Ale nestačilo by to dát najevo jednou?

[trekker.dk]

Tam, kde lze problém vyřešit jinak, je použití vláken zbytečný kanón na vrabce. (Ospravedlnitelný možná v případě, kdy problém zahrnuje dlouhý, náročný a paralelizovatelný výpočet.)

[default]

Aha, takže odpovědí na dotaz je vlastně flame na téma vlákna, ano či ne.

[trekker.dk]

Moje odpověď na dotaz je uvedena výše.

A přesně jak bylo někým řečeno v nedávné diskuzi o root.cz, slova flame se tu zbytečně nadužívá. Zatím vidím regulérní diskuzi.

[default]

Ne, ne. V pořádku. Rád se sám poučím, jak se to má dělat. Jen jsem chtěl sdělit mé zkušenosti, protože zrovna teď dělám na "něčem podobném". Spíš jsem tím komentářem reagoval na Josefa Kufnera, který do každého vlákna zasel svůj hrob. Má aplikace funguje přes vlákna bez nejmenších potíží. Nesouhlasím tedy s výrokem, že je to cesta do pekel. Vím, že na některé úlohy nejsou vlákna vhodná, ale jsou úlohy, kde se vlákna hodí a vyndají. Zadání úlohy na mě nepůsobí, že by vlákna měla významný vliv na výkon, stabilitu či funkčnost. Toš tak. Uf.

Prostě mi to zadání přišlo strašně podobné tomu, co teď sám řeším. Tak jsem chtěl jen pomoci. :'(

[trekker.dk]

Má aplikace funguje přes vlákna bez nejmenších potíží. Nesouhlasím tedy s výrokem, že je to cesta do pekel.

Jasně. Když člověk ví, jak na to, a lepší řešení není, tak proč vlákna nepoužít...

Mě šlo spíš o to, že v jazyce, který má možnost využít nativní prostředky systému (předpokládám, že když se tazatel ptá ve vlákně, které začíná C/C++, tak má možnost tyto prostředky využít), jsou vlákna pravděpodobně zbytečná, protože existují efektivnější metody jak dělat věci naráz (přesněji jak čekat na víc věcí naráz) - efektivnější např. v tom, že v podstatě není potřeba řešit synchronizaci mezi vlákny.

O cestě do pekel s vlákny se dá mluvit, pokud člověk s programováním začíná a nemá moc zkušenosti s tím, co se děje pod pokličkou; tj. že ho vůbec nenapadne, že to či ono by se mohlo pěkně posesouvat.

[Tomáš Skočdopole]

Ahoj,

predne bych chtel vsem podekovat za posilani cennych rad a pripominek k teto problematice.  Vim ze me to neomlouva, ale chtel bych podotknut, ze nejsem informatik, studuji na elektro fakulte, takze nase kurzy programovani nebyly na takove urovni. Vse se ucim z vlastniho zajmu sam, pripadne se snazim vybirat volitelne predmety ve skole, ktere by me neco mohly dat...

Dnes jsem byl za vedoucim sve prace. Ta metoda server a klient, kterou jsem popsal zde v jednom z prispevku, se mu libila. Ale rekl mi, ze tento styl programovani, kde bezi jedna smycka, se delalo tak v dobach DOSu a ze se mam poohlednout po jinem reseni a vyuzit tak moznosti operacniho systemu - zminil prave ty vlakna. Jeho ostatni roboti na fakulte jsou postaveny na bazi Windows, takze pry moc Linux nezna. Ale i na jednocipech se tzv: force smycka nedela. (napr freescale uz v manualech maji uvedeno, ze takto se to delat nema a jsou tam tusim nejake tasky).

Takze abych splnil predstavy meho vedouciho, mel bych aplikaci navrhnout jako vicevlaknovou. Ovsem nerikam ze pak v tom konkretnim vlakne nepouziji fce select poll nebo epoll.

Jinak me jeste neni jasne, jak bych mohl udelat nasledujici: vlakno A je vytvoreno pri inicializaci programu a jeho ukolem je napriklad na zaklade prijatych dat vypocitat neco a vysledek odeslat na seriovy port. Zde nevim jakym zpusobem predat vlaknu vstupni data a jakym zpusobem toto vlakno zastavit aby na ty vstupni data cekalo...

Dekuji Tomas

[Josef Kufner]

Proti vláknům nic osobního nemám, jen je s nimi zbytečně moc práce navíc (a na první pohled to není vidět). Problém je, že jednoduchá a krásná řešení zabírají v diskusi příliš málo místa a mohla by být lehce přehlédnuta

[Michal Kubeček]

Podle toho, jak jste v rychlém sledu napsal na různá místa diskuse tři nebo čtyři příspěvky s prakticky stejným obsahem (v duchu "vlákna jsou špatně") to tak působilo.

Bohužel mám pocit, že řada linuxových programátorů (netvrdím, že je to zrovna váš případ) si za dob LinuxThreads, kdy v Linuxu nebyla vlákna implementována příliš prakticky a efektivně, začala vymýšlet argumenty, že chyba je v koncepci vláken jako takových, takže kvalitní implementace vlastně vůbec nikomu nechybí. Vzpomínám si např. na výrok jednoho (jinak velmi dobrého) programátora: "Vlákna jsou berlička pro ty, kdo neumějí správně používat fork()." Někteří bohužel ani po příchodu NPTL svůj postoj nepřehodnotili a neakceptovali, že problém byl v té původní implementaci, ne v konceptu samotném.

[mimi.vx]

 no nevim totez tvrdi o vlaknech napr ESR.

[Michal Kubeček]

Argumenty typu "říká to pan Velká Autorita" jsem nikdy nepovažoval za relevantní, pokud tvrzení pana Velké Autority nebylo podloženo nějakými argumenty.

[default]

Promiň, ale vidím to takto: hlavní aplikační vlákno vystaví vlákno s GUI, spustí vlákna obsluhy sériových portů a zamkne se, dokud tato vlákna neskončí. V případě té události, jak píše, že na ni musí reagovat UI, stačí jen sdělit vláknu, které se stará o UI, že má něco nějak překreslit, z vlákna, které obsluhuje ty porty. Vidím v tom jen bariéry a fronty (buffery událostí).

Jak jsem psal — opakuji — píšu teď něco podobného v Javě, akorát že místo UI posílám notifikace zainteresovaným JMX klientům. Mým GUI je například JConsole.

Je to jednoduché, elegantní, přehledné a hlavně — není co ladit. Zvlášť, když použije C++ — je to pár tříd. Já mám ve své proof-of-concept verzi třídy čtyři a není to žádný anti-pattern.

Takže vlákna do hrobu pomůžou tak akorát vývojáři Microsoft Wordu při implementaci kontroly pravopisu, když zrovna probíhá tisk na pozadí.

P.S.: Nemyslím si, že C++ je hloupější než Java. Naopak. Myslím si, že C++ (STL?) je na tyto věci připraven(a?) nejhůře tak, jako Java; spíš lépe. To nechť posoudí někdo, kdo ovládá Javu i C++.

[trekker.dk]

He, tak tomuhle se říká overkill. I když v Javě, kde člověk nesežene ani časovač bez toho, aby se vyrobilo vlákno navíc, se asi není čemu divit.

[default]

Jakej overkill? To mám jako všechno psát v JNI a hákovat to do native metod? Méně řádků kódu — méně chyb.

A na druhou stranu: když započítám JVM a všechen ten moloch okolo — vystavení nového vlákna operačním systémem je opravdu, z pohledu kódu v Javě, nejrychlejší operace.

Takže suma sumárum — takhle je to nejjednodušší. Krátký, čitelný a rychlý (vzhledem k business požadavkům) kód, který funguje.

[trekker.dk]

A na druhou stranu: když započítám JVM a všechen ten moloch okolo — vystavení nového vlákna operačním systémem je opravdu, z pohledu kódu v Javě, nejrychlejší operace.

No jasně, právě na to jsem narážel

[Ladicek]

Je to jednoduché, elegantní, přehledné a hlavně — není co ladit.

Jo, to říkej lidem, kteří si nechají od operačního systému diktovat, že vlákna jsou drahá, a vymýšlejí paralelismus bez paralelismu

[default]

Řeknu to asi takto: nevšimnul jsem si, že by vlákna u operačních systémů byla drahá.

[default]

Omlouvám se. Špatně jsem se vyjádřil.

Jen doplním: když už jsou vytvořena v poolu.

[Tomáš Skočdopole]

Takze napriklad pro odeslani dat na seriovy port je jednoduzsi naprogramovat to tak, ze je vytvoreno nove vlakno, odesle ty data a skonci

Nez mit konstantne vytvorene jedno vlakno a slozite pomoci mutexu ho nejak zastavovat? Vykon to nijak neohrozi?

[Michal Kubeček]

Na mutexech není nic složitého ani výkonově náročného (používají-li se rozumně).

[trekker.dk]

Nicméně odesílat data po sériovém portu v k tomu účelu vytvořeném vlákně, které se potom ukončí, je už opravdu přemrštěná pakárna. Kolik by těch dat muselo být, aby se to vyplatilo, tj. aby vytvoření vlákna a předání dat do něj bylo kratší než předání dat přímo jádru k odeslání...

[Michal Kubeček]

To v podstatě říkáme oba to samé: že je výhodnější mít tam trvale thread, který se bude starat o asynchronní odesílání dat, než vytvářet na každý blok dat nový thread. Pokud by to totiž mělo fungovat asynchronně, muselo by se tak jako tak řešit zamykání a společná fronta pro ty jednotlivé odesílající thready.

[trekker.dk]

To v podstatě říkáme oba to samé: že je výhodnější mít tam trvale thread, který se bude starat o asynchronní odesílání dat, než vytvářet na každý blok dat nový thread.

Neříkáme (ale uznávám, že jsem to nenapsal dost jasně) - já tvrdím, že na odesílání dat po sériovém portu je úplně zbytečné mít samostatný thread. Port lze v případě potřeby otevřít s O_NONBLOCK, takže zápis nebude blokovat. write() jako taková by měla být thread-safe (aspoň podle normy)

Jediné, na čem by tenhle postup mohl selhat, je zápis bloku dat většího než je jaderný buffer (u mě 4kB) najednou; to by se muselo provádět na etapy a tam už by možná stálo za to použít vlákno (osobně nicméně považuju tak velký blok dat pro řízení za nepravděpodobný, leda by se příkazy posílaly slovně)

[Michal Kubeček]

Tak jsem se dokopal udělat ty testy, orientační výsledky pro rámcovou představu:

• pthread_mutex_lock() + pthread_mutex_unock(): 26 ns
• write() (1 B): 83 ns
• select() (jeden deskriptor pro čtení, žádná data): 223 ns
• vytvoření joinable threadu (který hned skončí) a join: 15 μs
• fork procesu (který hned skončí) + waitpid(): 111 μs

(Phenom 9750 2.4 GHz, OpenSuSE 11.0 x86_64)

[trekker.dk]

Ještě mě napadlo:

Program by mel byt ciste konzolovy, takze pouziti Qt, GTK knihoven neni mozne.

Qt umožňuje napsat čistě konzolový program - knihovna QtCore nezávisí na žádném grafickém prostředí a jde používat i v řádce.

Vyhovovalo by mi neco jako udalostmi rizene programovani. Ale bohuzel jsem nikde nenasel jak na to.

Většina objektů umí v reakci na událost (časovač vypršel, přišla data po síti) vysílat signály (jde o něco jiného, než jsou linuxové signály popsané výše; linuxové signály lze nicméně na Qt signály převést), ty si nastavíš, jak na ně chceš reagovat (naprogramováním příslušné obslužné rutiny - nebo rutin - signálu) Spousta věcí, které řešíš (časovače, vlákna) je v knihovně obsažena, takže jde v podstatě jenom o to je napojit.

Pokud bys nechtěl koupit licenci, musel bys výsledek vydat pod GPL (což u školní práce nevidím jako problém)

[mikro]

Presne tak. Qt je totalne signal/event driven prostredie, tam tvoju ulohu zbuchas za 10 minut.

[vencas]

Díval jste se na knihovnu ASIO? Třeba by se vám hodila, jestli to budete dělat v c++. Je také součástí budoucího standardu c++0x.