Přidat otázku mezi oblíbenéZasílat nové odpovědi e-mailem Vicevlaknova aplikace pro hlidani vice vstupu najednou, nebo jine reseni

Ahoj,

jak se tak prokousávam postupně do Céčka narazil jsem na věc, kterou jsem nikdy předtím (kdysi dávno ve škole) nemusel řešit a to je hlídání více vstupů najednou.

Vezměme si situaci, kdy hlídám vstup z klávesnice a zároveň třeba seriový port.
Když nechám program čekat na string z klávesnice ( scanf() ), program stojí a logicky neobsluhuje seriový port. Když by mi na něj dorazila nějaká data, nevěděl bych o tom, dokud bych si nepřečetl vstupní buffer. To není úplně ideální situace.
Dovedu si představit řešení u mikrokontroleru, kde pomocí přerušení vyruším jeden proces, zpracuji příchozí data a proces nechám pokračovat v čekání. U PC netuším, jestli jsem schopen přijmat přerušení například při stisku klávesy.

Takže mě napadla dvě možná řešení:

1) nečekat na vstup z klávesnice, ale pouze v cyklech kontrolovat vstupní buffer a v případě, že se v něm něco objeví, tak to zpracovat

2) udělat aplikaci vícevláknovou, kde jedno vlákno obsluhuje uživatele a druhé hlídá seriový port.

Které řešení je častější, případně efektivnější?

Jak se takové věci řeší obecně? Jedno vlákno na GUI, jiné například na výpočetní engine a třetí například na obsluhu periferií?

Pokud jsou mé otázky naivní, tak mě prosím uveďte na pravou míru. Rovnou se přiznám, že netuším, jestli momentálně programuju v C nebo v C++, protože netbeans mi nabízejí jako možnost "C/C++ application" a gcc mi přeloží oboje. Takže nemám tušení, podle čeho bych to mohl poznat ;-).

Díky

Jsou zobrazeny jen nové odpovědi. Zobrazit všechny
Předmět Autor Datum
Obecne sa to riesi napojenim aplikacie na odoberanie sprav zo systemovych (a inych) front (queue) a…
KiloViktor 28.02.2012 17:35
KiloViktor
Uh, to dokonce zni sloziteji, nez mnou navrhovany vicevlaknovy proces.
JR_Ewing 28.02.2012 19:14
JR_Ewing
To co navrhujes, je programovanie ake sa aplikovalo v dobach minulych pri jednotaskovych ulohach. V…
KiloViktor 28.02.2012 21:17
KiloViktor
Diky, podivam se na to, jestli k tomu neco najdu. Jeste otazecka. Pro komunikaci se zarizenim pres s…
JR_Ewing 28.02.2012 22:55
JR_Ewing
Pokial to ide, tak je vzdy lepsie pouzit uz hotove API, ktore system obsahuje. API sa obchadza len v…
KiloViktor 29.02.2012 18:50
KiloViktor
Ja si s Ceckem hraju teprve necely mesic, tak jsi na tom o dost lepe ;-). Diky za rady, podivam se p… nový
JR_Ewing 01.03.2012 08:37
JR_Ewing
Tak se k tématu snažím něco vygooglit a nějak stále nemůžu narazit na správná klíčová slova, protože… poslední
JR_Ewing 01.03.2012 15:53
JR_Ewing

Obecne sa to riesi napojenim aplikacie na odoberanie sprav zo systemovych (a inych) front (queue) a ich filtraciou. Ak chces vyvijat uz vyvinute trebars za ucelom studia, daju sa na uvod pouzit jaderne spravy, ktore vychadzaju na ABC Linuxu. Budes musiet zalistovat mozno aj hodne rokov dozadu.
Mozes sa pripadne orientovat podla klucovych slov ako:
procesy, priority, scheduler, VM (Virtual Machine), VMM (Virtual machine manager), pipeling, synchronizacia, event, mutex, futex, thread, LPC (Local Procedure Call), RPC (Remote Procedure Call), DCE (Distributed Computing Environment)...
Ak by sa ti podarilo zahnat casopis Bajt 1993 (najdes v kniznici), tak tam je popisana architektura threadingoveho spracovania velmi detailne pod nazvom "Windows NT story" na pokracovanie. Pripadne tiez casopis CHIP 10/1996 nazov clanku "Crack 95".

To co navrhujes, je programovanie ake sa aplikovalo v dobach minulych pri jednotaskovych ulohach. V zasade sa to robilo ako Main_loop v ktorej sa testovali priznaky od preruseni (alebo inych udalosti) a robili sa patricne akcie. To boli casy ZX Spectrum a starsie kedy sa to robilo takto. V sucastnosti sa na udalosti hojne vyuzivaju API, ktore tie spravy zbieraju z jadra a predavaju ich aplikaciam.
Kukni si akykolvek open source ovladac, napriklad pre NET v ktorom najdes minimalne riesenie fronty pre Tx/Rx a jej obsluhy. Casto sa na to vyuziva tzv.kruhovy buffer.

Diky, podivam se na to, jestli k tomu neco najdu.
Jeste otazecka. Pro komunikaci se zarizenim pres seriovy port, myslis ze je lepsi vyuzit funkce primo pro cteni/zapis na seriovy port (a tedy udelat vicevlaknovou aplikaci, kde jedno vlakno by melo na starosti seriovy port), nebo k tomu ucelu vyuzit (pokud to jde) API OS?

Pokial to ide, tak je vzdy lepsie pouzit uz hotove API, ktore system obsahuje. API sa obchadza len vtedy, ak je treba riesit nieco inak napr. vzhladom na rychlost, odozvu, usporu pamete a pod. Aj z Cecka je mozne volat API. Pre Linux najdes hodne veci v jadernych spravach. Su tam priklady ako pouzivat niektore API z jadra, parametre volania, navratove hodnoty a pod. Ak by si chcel spravit viacvlaknovu aplikaciu tak ako ty myslis, musel by si zajst do velkej hlbky a riesit take veci ako napr. semafory, priority, udalosti, synchronizaciu a pod. Vsetky tieto veci jadro uz obsahuje.
Hned prvy prispevok od MaSo o tom hovori tiez. Vo vyssich prog.jazykoch sa to vola eventy a v C++ sa to vola signaly a sloty.
Inak ja niesom nejaky programator, len niekolko rokov fusujem do programovania. Da sa povedat, ze som si napisal ovladac pre wifi kartu kde tiez momentalne stojim nad riesenim obsluhy viac-frontoveho spracovania QoS.

Tak se k tématu snažím něco vygooglit a nějak stále nemůžu narazit na správná klíčová slova, protože jsem zatím nic kloudného nevymyslel. Jako by neexistovala jiná možnost vstupu než cin nebo scanf (kdy program stojí na místě a čeká až něco zmáčknu).

Rozumím tomu správně, že navěšení na API (hook?) mi bude fungovat jako přerušení? Tedy že kdykoli v běhu programu, když někdo zmáčkne klávesu, provede se příslušná rutina a program pokračuje vesele dál z místa, kde byl vyrušen?

Omlouvám se, ale jsem poněkud ovlivněn světem jednočipů, kde toho mám ze své bídné programátorské kariéry zdaleka natočeno nejvíc.

Zpět do poradny Odpovědět na původní otázku Nahoru