Bariéra vs opakované volání – C / C++ – Fórum – Programujte.com

Ahoj, zajímá mě váš názor ohledně následujícího problému - jazyk C.

Mám aplikaci, která je poměrně kritická na co nejrychlejší odezvu (čti reakci) na událost řekněme stisk klávesy. Reakce bude obsloužena vláknem. A otázka zní: 

1) Je lepší vlákno pustit hned na začátku app. a zaseknout ho na nějakém synchro. primitivu (mutex/bariéra), a tehdy až příjde událost tak to odblokuju, vlákno provede to co má, vrátí se na začátek a znovu zasekne?

2) Nebo jako reakce na událost vytvořit vždy nové vlákno, které provede požadovanou funkcionalitu?

Dle mého názoru je asi lepší to první, ale kdyžtak mě opravte kdybych se mýlil, popř to bylo uplně jedno :)

#1 host
Aj podľa mňa by bolo lepšie použiť prvú alternatívu, nemusíš písať viac vlákien = menej chýb. Taktiež viac vlákien vyžaduje viac operačnej pamäte.

vytvareni vlaken je zdlouhave - pro neco kratsiho bys travil daleko vice casu na tom...

lepsi je mit pracovni vlakno (nebo i vice) zavesenejch nad semaforem (wait a notify v posix threads) - musis pak akorat nejak predat co a cim se ma zpracovat... (pokud nemas jednoucelove vlakno)

samozrejme lepe se to pak jeste dela v c++ - tam jde udelat i virtualni trida s metodou process a kazda akce, kterou tam chces zpracovat pak tu metodu musi implementovat... (a tady uz muzes predat cokoliv odvozeneho od base class)

+ neco, co ma reagovat rychle na stisk klavesy se zase neda nazyvat "kriticka" aplikace... kriticka je, az kdyz musis reagovat vzdy stejne rychle a jeste v daleko mensich radech casu/poctu instrukci (Real Time aplikace)

#3 KIIV
Ahoj, nechci se s tebou hádat, protože si tě vážím a vím že víš (  ) ale s tím posledním co jsi napsal nesouhlasím. Slovo časově kritická znamená, že je na časovou odezvu kladen důraz a to nemusí nutně znamenat určitý čas (hard RTOS), stačí co nejmenší čas (můj případ) a proto jsem se z hlediska optimalizace ptal na to co je lepší :)

#4 host
jo mas pravdu .. s RTOS sem nikdy poradne nedelal a jako "kriticka aplikace" mi utkvela v pameti ta definice hard RTOS... takhle mirneji vylozene se to opravdu pouzit da

u odezvy na klávesu je jedno, jestli to bude 5 ms nebo 20 ms - uživatel se stejně bude rozmýšlet několik desetin sekundy (to je oprvdu "kritický"). Za kritický považuji např. odezvu na přerušení od ADC u rychlých měření (už při 1ksps je každou 1 ms nová hodnota) nebo obsluhy přerušení při fázovém řízení triaku.

hu

#6 hlucheucho
No a kde víš že ta klávesa neovládá nukleární reaktor?? Kde je psáno že klávesa = klávesnice = není nutno rychle? 

#7 host
V takovém případě je nejvíce kritický lidský faktor - reakční doba (čas který člověk potřebuje k reakci na podnět) se pohybuje v řádu desetin sekundy. Kromě toho, v MaR bývá zvykem nouzové signály netahat do řídícího počítače a vyřizovat je co nejkratší a nejspolehlivější cestou. Na spuštění řídících tyčí reaktoru počítač nepotřebuji, stačí stykač + pohon (nebo to dělá závaží?).

U malých vodních elektráren se nouzové odstavení dělalo gravitačně - bezp. ventil bez napětí vypustil tlak z hydrauliky a závaží zavřelo přívod vody do turbíny (buď rozváděcí kolo turbíny nebo klapku před ní).

hu

#8 hlucheucho
tak to přirovnání neber doslova s reaktorem, může to být cokoli .. spíš mi přijde že tomu nechceš rozumět, než že nerozumíš :)

Ještě k reaktoru: přehřát reaktor do stavu, kdy ho nelze řídit a roztaví se jádro, trvá docela dlouho. Pokud se to "podaří" tak už zbývá pouze evakuace širokého okolí, ta se pro nedostatek času nedá stihnout. Pak to dopadne jak v Černobylu. Tam zařvali jen 2 lidi: první "vypni to" a druhý "nejde to"   

hu

Všimni si: odstavovací pochody zařízení často trvají dlouho - spustit řídící tyče do reaktoru, zavřít přívod vody do turbíny. Proti tomu je odezva systému (počítač, relé) v řádu desítek ms zanedbatelná.

Pro běžného uživatele je odezva na klávesu pod 0,2 s nepostřehnutelné zdržení.

hu