Dotaz: Plánovač periodických tasků v C

[MilanC]

Ahoj,

potřebuji vytvořit jakýsi jednoduchý periodický plánovač několika samostatných úloh v Cčku. Každá úloha se bude spouštět nekonečně krát v nějakém intervalu od několika sekund po hodiny. Na přesnosti až tak nezáleží. Hned jsem dostal nápad, udělat to pomocí vláken, kdy vždy 1 úloha = 1 vlákno a periodu řešit sleepem vlákna na daný čas. Trochu jsem ale narazil při ukončování programu/vláken, což mě napadlo řešit rozložením dlouhého intervalu na smyčku 1s sleepů s testem na ukončení vlákna. Má otázka zní, jestli to koncepčně nelze v Cčku udělat ještě nějak lépe?

Tady je nástřel pro 2 vlákna... https://pastebin.com/5e4KPgjR

Díky.

Odpovědi

[MilanC]

Ten problém s ukončováním jsem myslel tak, že jsem tam měl původně sleep(args->delay), což se pak samozřejmě při nastavení sRunning na 0 nevykoná bezprostředně, ale při delší periodě až po jejím uplynutí. Toto jsem tedy řešil tím for cyklem, asi je to patrné.

[MarV]

Použil bych systémový časovač https://man7.org/linux/man-pages/man2/timer_create.2.html. V hlavním vlákně čekat na ukončovací podmínku a pak časovače zabít.

[jiwopene]

Viz #2, nebo je také možné pro ukončitelné čekání použít poll(2) s timeoutem a pipe(2). (Vytvořím rouru, pollem v jednom procesu/vlákně čekám na příchozí data a ve druhém vlákně nebo třeba handleru signálu pro ukončení pošlu data.) Takové řešení se hodí, pokud už rourou (nebo soketem apod.) posíláme nějaký příkaz pro ukončení.

[MilanC]

Díky, díval jsem se na obě varianty a přijde mi to nějaké složité. Zkusím to nějak blíž nastudovat. Ta varianta s timery by mohla být schůdná.

[z_sk]

Keď si to prepíšeš do C, tak: [PHP] Program N-krát niečo vykoná a počká na dokončenie.

[Mayhem]

Kdyz uz to tedy musi byt v cecku, na vlakna se vykasli, to je overkill. Normalne naforkuj potrebny pocet procesu, v childu pouzij bud ohandlovany alarm nebo sleep a udelej, co potrebujes. V pripade potreby cekajici childy ukoncis zaslanim sigtermu. A zombie si v parentu uklidis zachycenim sigchld.

[MilanC]

Ahoj, šlo by to krapet více pro lamu případně odkázat na nějaký příklad? A ano v C to musí být, bohužel. :(

[kvr]

Prostě místo pthread_create() použiješ fork() a pustíš ten child tam. Zbytek řešení by měl zůstat víceméně stejný. ... ne, že bych s tím souhlasil, pthread bude rozhodně efektivnější, na druhé straně chyba v pouštěné funkci shodí celý proces, zatímco v případě fork() jenom ten child.

Jako to původní řešení fungovat bude, pominu-li to, že nebude pouštět každých n vteřin, ale n vteřin + doba operace té funkce. A samozřejmě neefektivní využití threadů, které nejspíš budou převážnou dobu jenom spát (což bude v rámci stovek threadů asi ok). Ideální by bylo použití nějakého threadpool, nejlépe který umí rovnou schedulovat podle času, něco jako Java https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/concurrent/ScheduledExecutorService.html#scheduleAtFixedRate(java.lang.Runnable,long,long,java.util.concurrent.TimeUnit) . Letmým pohledem nedokážu nic najít pro čisté C. Něco naimplementovat asi nebude extra složité (buď timer_create nebo poll a schedulovat ručně, a k tomu normální threadpool), ale pořád složitější než původní řešení - otázkou je, stojí to za to?

[Mayhem]

ne, že bych s tím souhlasil, pthread bude rozhodně efektivnější, na druhé straně chyba v pouštěné funkci shodí celý proces, zatímco v případě fork() jenom ten child.

Efektivnejsi? Mozna ano, ale uvedom si, ze novy proces se udela jen na zacatku. Pak se stejne ceka. A v jakych poctech se vlastne pohybujeme? Myslim, ze v takovych, kde vytvoreni child procesu opravdu nebude problem s rezii.

[kvr]

Efektivnejsi? Mozna ano, ale uvedom si, ze novy proces se udela jen na zacatku. Pak se stejne ceka. A v jakych poctech se vlastne pohybujeme?

Efektivnější neznamená jen vytvoření procesu, ale celou dobu údržbu těch procesů (vlastní tabulka virtuální paměti - i když z velké části samotná paměť asi sdílená, taky, kdo ty child procesy bude sestřelovat). Pokud se pohybujeme v rámci desítek funkcí - pak je fork ok, stovky, možná nízké tisíce - threads jsou ok, u víc by to chtělo ten threadpool. Počítám, že tady půjde o jednotky až desítky, proto jsem psal, zda to stojí za ty komplikace (respektive komplikace je to, že pro čisté C takové knihovny moc nejsou, jinak by to bylo naopak jednodušší).

[Mayhem]

Efektivnější neznamená jen vytvoření procesu, ale celou dobu údržbu těch procesů (vlastní tabulka virtuální paměti - i když z velké části samotná paměť asi sdílená, taky, kdo ty child procesy bude sestřelovat).

Proc bude vetsinu dobu sveho zivota pouze spinkat, nebal bych se tedy teto rezie.

Pokud se pohybujeme v rámci desítek funkcí - pak je fork ok, stovky, možná nízké tisíce - threads jsou ok, u víc by to chtělo ten threadpool.

Jiste, ThreadPool a napsat to treba v jave by bylo nejlepsi, ale to tazatel nechtel. Pro jeho ucel naprosto postacuje model s forkem a signal. A garantuji vam, ze pro tento ucel nejsou i radove stovky na prumernem zeleze problem.

Počítám, že tady půjde o jednotky až desítky, proto jsem psal, zda to stojí za ty komplikace (respektive komplikace je to, že pro čisté C takové knihovny moc nejsou, jinak by to bylo naopak jednodušší).

+1

Take mi prijde, ze pro zacatecnika jsou veci okolo forku a signalu daleko pochopitelnejsi nez prace s pthreads, ktere v C maji vylozene hnusne api.

[Zm]

Signály jsou problematické, při jejich použítí se musí kontrolovat všechna sys. volání, zda nedošlo k přerušení signálem.

[MilanC]

Ahoj, postupně si hraji s těmi vlákny a tak mě napadlo, nebylo by snadné řešení pomocí pthread_cond_timedwait? Myslím nahradit jím ten sleep. Mělo by to řešit problém rychlým ukončením a požadovaným čekáním zároveň. Bylo by to řešení?

Nicméně se mi to nějak nedaří naimplementovat pro více vláken.

Tady jsem se pokusil o malé demo, "tasky" to periodicky spouští, ale mám tam nějaký problém s ukončením při CTRL+C. Někdy to zůstane viset na nějakém joinu, nevím proč. :(

Mmain(): sending cancellation request
Joining thread 0
main(): thread wasn't canceled (shouldn't happen!)
main(): sending cancellation request
Joining thread 1
main(): thread wasn't canceled (shouldn't happen!)
main(): sending cancellation request
Joining thread 2
main(): thread was canceled
main(): sending cancellation request
Joining thread 3
main(): thread wasn't canceled (shouldn't happen!)
main(): sending cancellation request
Joining thread 4
main(): thread wasn't canceled (shouldn't happen!)
main(): sending cancellation request
Joining thread 5
_

https://pastebin.com/BmECNELD

K čemu je tam nutný prosím ten fakeMutex? PS: Zkusil jsem i ně které zde zzmíněné další varianty, ale přišlo mi to až zbytečně složité.

[MilanC]

Tak už jsem na to asi přišel. Pokud program signalizuje ukončení, tak je třeba přerušit to čekání v jednotlivých vláknech na dané podmínce. Takže stačí poslat pthread_cond_broadcast(&fakeCond); a pak pro jistotu ještě počkat na dokončení vláken přes join().

[kvr]

Fake mutex je tam proto, že tak funguje condition:

- Producer by měl zamknout stav, nastavit indikátor a udělat broadcast na podmínku asociovanou s mutex, a odemknout mutex.

- Consumer zamkne stav, zkontroluje indikátor, rozhodne se co dál. Pouze pokud potřebuje čekat na indikátor, udělá wait na condition, který zároveň dočasně odemkne mutex, aby ho producer mohl přenastavit.

Pokud by tam ten mutex nebyl, tak přístup k indikátoru bude neizolovaný a může dojít k race condition, když producer pustí broadcast v mezičase kdy consumer kontroluje indikátor a než udělá wait na condition.

(indikátor může být cokoliv - zde asi exit, ale typicky to bývá prázdná nebo plná fronta apod)