CSP v embedded světě

[Idris]

Na cem jedete, ja chci taky takovej caj

Tyhle látky začne mozek produkovat přirozeně sám, stačí par let programovat v Elixiru

Nejen Elixiru. Spíš stačí v praxi narazit na zajímavé problémy a po letech pokusů a omylů dokonvergovat k best practices (např. CSP).

[Reklama]

[Ondrej Nemecek]

Nádhera, nad CSP se pak dají udělat semafory, generátory, promises apod. Třešničkou by byly kanály mezi dvěma MCU (něco jako netchan v Go).

Bingo! To jsem právě naťukl v tom původním vláknu s tím PRU na Beaglebone. To jsou dva oddělený procesory. A jakmile by bylo CSP rozchozený, je to už jenom kousek k dalším srandám.

Takže co třeba dvě Blue Pills za padesátikorunu jedno, propojené přes CAN bus a tasky migrují z jednoho na druhý podle zatížení CPU? Proč ne A když jsme u toho CAN busu, co třeba deset propojených Blue Pills a jeden blink task migruje z jednoho na druhý, takže každou chvilku blikne s LEDkou jinde? To jako motivace nestačí? Tak to už fakt nevím co teda

Tento příklad mne motivoval se zapojit do diskuze 

Představujete si to tak, že ten task nasadím jen na jednom node a on se sám distribuuje (tedy musí se přenést spustitelná podoba) anebo tak, že jsou nasazené na všech nodech (už tam je spustitelná podoba) a distribuuje se jen to vykonání? A zrovna u toho blikání jak synchronizovat čas (asi bychom chtěli, aby to blikalo alespoň přibližně ve správném itervalu)?

Přiznám se, že CSP neznám, ale podle popisu na wikipedii je to přesně to, co by se mi líbilo. IMHO divné že to už neexistuje (nebo existuje?).

[Idris]

Nádhera, nad CSP se pak dají udělat semafory, generátory, promises apod. Třešničkou by byly kanály mezi dvěma MCU (něco jako netchan v Go).

Bingo! To jsem právě naťukl v tom původním vláknu s tím PRU na Beaglebone. To jsou dva oddělený procesory. A jakmile by bylo CSP rozchozený, je to už jenom kousek k dalším srandám.

Takže co třeba dvě Blue Pills za padesátikorunu jedno, propojené přes CAN bus a tasky migrují z jednoho na druhý podle zatížení CPU? Proč ne A když jsme u toho CAN busu, co třeba deset propojených Blue Pills a jeden blink task migruje z jednoho na druhý, takže každou chvilku blikne s LEDkou jinde? To jako motivace nestačí? Tak to už fakt nevím co teda

Tento příklad mne motivoval se zapojit do diskuze 

Představujete si to tak, že ten task nasadím jen na jednom node a on se sám distribuuje (tedy musí se přenést spustitelná podoba) anebo tak, že jsou nasazené na všech nodech (už tam je spustitelná podoba) a distribuuje se jen to vykonání? A zrovna u toho blikání jak synchronizovat čas (asi bychom chtěli, aby to blikalo alespoň přibližně ve správném itervalu)?

Přiznám se, že CSP neznám, ale podle popisu na wikipedii je to přesně to, co by se mi líbilo. IMHO divné že to už neexistuje (nebo existuje?).

To druhé, ale přenášet přes kanály spustitelný kód by bylo taky zajímavé (zvlášť na MCU)

CSP existuje v mnoha podobách, jen na MCU moc ne. Třeba Pico má kanály pro komunikaci mezi vlákny (je dvoujádrové), tady se ale bavíme spíše o "userspacu" (kooperativní scheduler s podporou kanálů). Ve skutečnosti se vlastně bavíme o Go v pár kilobajtech paměti...

[Mirek Prýmek]

Představujete si to tak, že ten task nasadím jen na jednom node a on se sám distribuuje (tedy musí se přenést spustitelná podoba) anebo tak, že jsou nasazené na všech nodech (už tam je spustitelná podoba) a distribuuje se jen to vykonání?

Tak predstavit si umim ledasco

Postavil jsem robota nad ESP32 a stvalo me, jak dlouho trva OTA uprage firmwaru. Tak jsem tam udelal uplne jednoduchoucky virtualni stroj s par instrukcemi a upgrade timpadem prenasel jenom par desitek bytu. Tady by se to dalo udelat stejne, kdyby clovek chtel. Minimalisticka implementace CSP by vyzadovala jenom par instrukci, takze "virtualni stroj" by byl jeden switch s nekolika malo kejsy

A zrovna u toho blikání jak synchronizovat čas (asi bychom chtěli, aby to blikalo alespoň přibližně ve správném itervalu)?

Tak pokud mam vyreseny komunikacni kanal, je synchronizace casu (s nejakou rozumnou presnosti) uz jenom snadna skolni uloha

Přiznám se, že CSP neznám, ale podle popisu na wikipedii je to přesně to, co by se mi líbilo. IMHO divné že to už neexistuje (nebo existuje?).

Tak on ma RDa v principu pravdu, ze to striktne vzato neni potreba. Synchronizaci blikani po CAN busu si muzu napsat i natvrdo v C a bude to efektivnejsi, zejo...

Mne to prijde zajimavy ciste z "vyzkumnych", sebevzdelavacich a sebe-potesujicich duvodu

[Idris]

To CSP je to zajímavé, scheduler je tam prostě z nutnosti

Presne! Scheduler je tam jenom technikalie, kterou je proste potreba nejak vyresit, aby to "svítilo a hřálo", jak říká klasik

Tak mě napadá, jak tam hodláš řešit select?

[Reklama]

[Mirek Prýmek]

Tak mě napadá, jak tam hodláš řešit select?

Takhle nízko ještě nejsem, zatím mám jenom mlhavou, high-level představu.

Nad tímhle jsou ještě jiná zajímavá rozhodnutí - jestli pojmenovávat kanály nebo procesy, jestli si vystačit s nebufferovanými kanály nebo přidat nějakou kapacitu, jestli kanál pojmout jako frontu nebo mailbox, jestli umožnit selektivní výběr zpráv...

Jestli má jít o srandu na jedno dvě odpoledne, tak to vidím na pojmenované kanály bez kapacity a tímpádem bez selektivního výběru. V takovým jednoduchým případě by select neměl být nic, nad čím by bylo potřeba dumat (?). Prostě z množiny kanálu náhodně vybereš jeden připravený ke čtení. Pokud by tam byl ten run to complete scheduler, tak by select vůbec nemusel být potřeba se mi intuitivně zdá.

[Idris]

Tak mě napadá, jak tam hodláš řešit select?

Takhle nízko ještě nejsem, zatím mám jenom mlhavou, high-level představu.

Nad tímhle jsou ještě jiná zajímavá rozhodnutí - jestli pojmenovávat kanály nebo procesy, jestli si vystačit s nebufferovanými kanály nebo přidat nějakou kapacitu, jestli kanál pojmout jako frontu nebo mailbox, jestli umožnit selektivní výběr zpráv...

Jestli má jít o srandu na jedno dvě odpoledne, tak to vidím na pojmenované kanály bez kapacity a tímpádem bez selektivního výběru. V takovým jednoduchým případě by select neměl být nic, nad čím by bylo potřeba dumat (?). Prostě z množiny kanálu náhodně vybereš jeden připravený ke čtení. Pokud by tam byl ten run to complete scheduler, tak by select vůbec nemusel být potřeba se mi intuitivně zdá.

Nad tím bufferem jsem taky přemýšlel a klidně bych to vypustil, tj. mít jen blokující kanály na zápis i čtení. Co je důležité (aby to k něčemu bylo) je zavírání kanálů, ani ne tak kvůli čtení ve smyčce, jako spíš signalizaci v kontextu (korutina, která čeká na čtení, se probudí, když se příslušný kanál zavře).

[Mirek Prýmek]

Nad tím bufferem jsem taky přemýšlel a klidně bych to vypustil, tj. mít jen blokující kanály na zápis i čtení. Co je důležité (aby to k něčemu bylo) je zavírání kanálů, ani ne tak kvůli čtení ve smyčce, jako spíš signalizaci v kontextu (korutina, která čeká na čtení, se probudí, když se příslušný kanál zavře).

Já si (po zkušenosti s Elixirem) pořád myslím, že mailbox se selektivním výběrem je daleko mocnější nástroj, ale pro jednoduchou implementaci by nebufferované kanály imho měly stačit.

Bufferovaný kanál by se z nebufferovaného dal udělat, pokud by byla k dispozici operace testu, jestli je kanál prázdný. Pak můžu v případě potřeby ukládat do lokálního bufferu. Nenapadá mě teď případ, ve kterém by to nebylo funkčně ekvivalentní k "nativnímu" bufferu.

Kromě toho, nevybavuju si, že bych se někdy setkal se situací, kde by buffer na kanálu byl nutně potřeba pro korektnost algoritmu a nedalo by se to napsat jinak.

[Idris]

Nad tím bufferem jsem taky přemýšlel a klidně bych to vypustil, tj. mít jen blokující kanály na zápis i čtení. Co je důležité (aby to k něčemu bylo) je zavírání kanálů, ani ne tak kvůli čtení ve smyčce, jako spíš signalizaci v kontextu (korutina, která čeká na čtení, se probudí, když se příslušný kanál zavře).

Já si (po zkušenosti s Elixirem) pořád myslím, že mailbox se selektivním výběrem je daleko mocnější nástroj, ale pro jednoduchou implementaci by nebufferované kanály imho měly stačit.

Bufferovaný kanál by se z nebufferovaného dal udělat, pokud by byla k dispozici operace testu, jestli je kanál prázdný. Pak můžu v případě potřeby ukládat do lokálního bufferu. Nenapadá mě teď případ, ve kterém by to nebylo funkčně ekvivalentní k "nativnímu" bufferu.

Kromě toho, nevybavuju si, že bych se někdy setkal se situací, kde by buffer na kanálu byl nutně potřeba pro korektnost algoritmu a nedalo by se to napsat jinak.

Mocnější to bude, ale já na to právě koukám stylem "jak mít za málo peněz hodně muziky," tj. použít nejméně mocné (nejjednodušší) prostředky k dosazení cíle.

Ten "lokální buffer" mě napadl včera, když jsem psal předchozí příspěvek, ale IMHO žádný buffer není vůbec potřeba. Spíš se zaměřuju na zdánlivě nepodstatné, ale veledůležité detaily, třeba to zavírání kanálů, aby šel udělat fan in/out s kontextem apod.

[Mirek Prýmek]

Ten "lokální buffer" mě napadl včera, když jsem psal předchozí příspěvek, ale IMHO žádný buffer není vůbec potřeba.

Prisne vzato neni, protoze kanal s konecnou kapacitou ma stejny potencialni dusledky jako kanal s kapacitou 1. Nekdy se proste muze zablokovat. A to je asi tak vsechno Jiny by to bylo s kanalem s neohranicenou kapacitou, ale nad tim predpokladam nepremyslis.

Spíš se zaměřuju na zdánlivě nepodstatné, ale veledůležité detaily, třeba to zavírání kanálů, aby šel udělat fan in/out s kontextem apod.

Nejsem si uplne stoprocentne jistej, jestli je zavirani kanalu nutny. Muzes zkusit trochu detailneji popsat, proc si pripadne myslis, ze jo?

Idealni by byl nejakej protipriklad - priklad konkretni situace, ktera bez zavirani kanalu nepujde vyresit.

[Idris]

Ten "lokální buffer" mě napadl včera, když jsem psal předchozí příspěvek, ale IMHO žádný buffer není vůbec potřeba.

Prisne vzato neni, protoze kanal s konecnou kapacitou ma stejny potencialni dusledky jako kanal s kapacitou 1. Nekdy se proste muze zablokovat. A to je asi tak vsechno Jiny by to bylo s kanalem s neohranicenou kapacitou, ale nad tim predpokladam nepremyslis.

Ne, to dost dobře nejde a ani mě teď nenapadá, k čemu by to bylo.

[Idris]

Nejsem si uplne stoprocentne jistej, jestli je zavirani kanalu nutny. Muzes zkusit trochu detailneji popsat, proc si pripadne myslis, ze jo?

Idealni by byl nejakej protipriklad - priklad konkretni situace, ktera bez zavirani kanalu nepujde vyresit.

Je nutné (pro obecné praktické CSP). Představ se, že chci mít kanál pro rušení operací čtení z nějakého datového kanálu. Tento kanál (říkejme mu třeba "dropdead") může být použit v mnoha selectech zároveň. Když chci všechny tyto selecty přerušit naráz, nemůžu jen poslat hodnotu, protože tu přečte jen jeden (náhodně vybraný), to je ostatně princip použití kanálů pro load balancing. Proto se to řeší tak, že se tento kanál zavře, pročež se všechny příslušné selecty odblokují a vyskočí se z nich. Všechny implementace CSP, co znám, to takto mají. Nejspíš to ani jinak (bez nárůstu složitosti) nejde. A je to elegantní.

[Mirek Prýmek]

Je nutné (pro obecné praktické CSP). Představ se, že chci mít kanál pro rušení operací čtení z nějakého datového kanálu. Tento kanál (říkejme mu třeba "dropdead") může být použit v mnoha selectech zároveň. Když chci všechny tyto selecty přerušit naráz, nemůžu jen poslat hodnotu, protože tu přečte jen jeden (náhodně vybraný), to je ostatně princip použití kanálů pro load balancing. Proto se to řeší tak, že se tento kanál zavře, pročež se všechny příslušné selecty odblokují a vyskočí se z nich. Všechny implementace CSP, co znám, to takto mají. Nejspíš to ani jinak (bez nárůstu složitosti) nejde. A je to elegantní.

Jasný, prostě context.Context. Nutný to není, dá se to udělat jinak. A dokonce i elegantněji V Erlangu jsou to linky (viz spawn_link). To je daleko robustnější řešení, protože nezávisí na kooperaci konsumenta. Mně tohle zavírání kanálů přijde spíš jako jejich zneužití. Z jistého pohledu to elegantní je, z jiného nikoli

Shodou okolností jsem přesně na tohle právě teď pěkně nasranej, protože píšu server, který musí obsluhovat net.Conn a zároveň kanály. Právě proto (!), že context.Context funguje přes kanály, není s net.Conn.Read kompatibilní a musí se kolem toho dělat opičky. Nevede to k elegantnímu kódu, ale přesně naopak...

[Idris]

Je nutné (pro obecné praktické CSP). Představ se, že chci mít kanál pro rušení operací čtení z nějakého datového kanálu. Tento kanál (říkejme mu třeba "dropdead") může být použit v mnoha selectech zároveň. Když chci všechny tyto selecty přerušit naráz, nemůžu jen poslat hodnotu, protože tu přečte jen jeden (náhodně vybraný), to je ostatně princip použití kanálů pro load balancing. Proto se to řeší tak, že se tento kanál zavře, pročež se všechny příslušné selecty odblokují a vyskočí se z nich. Všechny implementace CSP, co znám, to takto mají. Nejspíš to ani jinak (bez nárůstu složitosti) nejde. A je to elegantní.

Jasný, prostě context.Context. Nutný to není, dá se to udělat jinak. A dokonce i elegantněji V Erlangu jsou to linky (viz spawn_link). To je daleko robustnější řešení, protože nezávisí na kooperaci konsumenta. Mně tohle zavírání kanálů přijde spíš jako jejich zneužití. Z jistého pohledu to elegantní je, z jiného nikoli

Shodou okolností jsem přesně na tohle právě teď pěkně nasranej, protože píšu server, který musí obsluhovat net.Conn a zároveň kanály. Právě proto (!), že context.Context funguje přes kanály, není s net.Conn.Read kompatibilní a musí se kolem toho dělat opičky. Nevede to k elegantnímu kódu, ale přesně naopak...

Context není dělaný pro net.Conn. Jistě by to šlo přes síťové kanály, které ovšem zatím nikdo nenapsal (vlastně napsal a pak zahodil, to vyjde nastejno).

[Idris]

Mně tohle zavírání kanálů přijde spíš jako jejich zneužití.

Je to využití scheduleru. Pro embedded se mi to nezdá špatné, můžeš si tam sice přidat linky, ale proč, když už to scheduler umí jinak a šetříš každý bajt.