CSP v embedded světě

[Mirek Prýmek]

Doporučuju používat objekty jako v CoreFoundation, bude to bezpečnější.

Objekty mi do domu nesmí

[Reklama]

[Mirek Prýmek]

Na cem jedete, ja chci taky takovej caj

A ještě mi pořád nedošel!

"Migrující tasky" (kind of...) jsou na světě

https://youtu.be/GMtUod8J4GA

Zdroják: https://gist.github.com/mprymek/1b93972b71b8d3a59e143819356ea605

[Idris]

Na cem jedete, ja chci taky takovej caj

A ještě mi pořád nedošel!

"Migrující tasky" (kind of...) jsou na světě

https://youtu.be/GMtUod8J4GA

Zdroják: https://gist.github.com/mprymek/1b93972b71b8d3a59e143819356ea605

Hm, tak teď už to GCD nepřipomíná...

[Mirek Prýmek]

Hm, tak teď už to GCD nepřipomíná...

Na API CSP se nic nezměnilo

A je tam ten select, co ses na něj ptal. Nakonec jsem ho implementoval jednoduše jako skupinu tasků. Spustí se jenom jeden, ale vymažou se z tabulky všechny.

[Idris]

Hm, tak teď už to GCD nepřipomíná...

Na API CSP se nic nezměnilo

A je tam ten select, co ses na něj ptal. Nakonec jsem ho implementoval jednoduše jako skupinu tasků. Spustí se jenom jeden, ale vymažou se z tabulky všechny.

Taky správa paměti by šla řešit elegantně, když už tam je tolik struktur, klidně by mohla alokace být transparentní.

Jak se přepíná kontext?

[Reklama]

[Mirek Prýmek]

Taky správa paměti by šla řešit elegantně, když už tam je tolik struktur, klidně by mohla alokace být transparentní.

Co je transparentní alokace?

Jak se přepíná kontext?

Je to ten RTC scheduler, tj. kontext se přepne tím, že funkce doběhne. Např. can_blinker_send se spustí po tom, co jsou na kanálu k dispozici data (dostane je v chan_data_t data). Pomocí csp_send() na konci vytváří nový task, který scheduler spustí "někdy příště".

[Idris]

Taky správa paměti by šla řešit elegantně, když už tam je tolik struktur, klidně by mohla alokace být transparentní.

Co je transparentní alokace?

Bez explicitního free.

[Mirek Prýmek]

Bez explicitního free.

A jak bys to delal v cistym C?

[Idris]

Hm, tak teď už to GCD nepřipomíná...

A je tam ten select, co ses na něj ptal.

Jak na to tak koukám, tak pro čisté C by se na embedded hodilo něco jako kqueue — kanály vyžadují extra syntax (nebo hnusné workaroundy).

[Idris]

Bez explicitního free.

A jak bys to delal v cistym C?

Jako jiné knihovny v čistém C, použít cleanup a někde bokem si držet informace o strukturách (to kvůli polymorfismu při úklidu). Na embedded bych tedy především nealokoval nic na haldě, ale obecně se používají v sofistikovaných knihovnách právě ukazatele na "typy". Je to taková vyšší dívčí céčka, třeba CoreFoundation je dobrý příklad.

[Idris]

Bez explicitního free.

A jak bys to delal v cistym C?

Už nemůžu upravit tu předchozí odpověď, tak tady jako příklad:

Kód [Vybrat] Rozbalit


// nějaký kód (vytvoř třeba RSA klíče)
{
autofreed ch = channel_create();
// dej někomu kanál
// hoď klíče do kanálu
}
// kanál byl uvolněn

Takhle se dá psát v čistém C bez explicitních alokací, zrovna na embedded, kde typicky není nějaká velká standardní knihovna, to je dobrý fit. Stačí jedno makro s jedním atributem. Dost teda v GCC chybí bloky (aka uzávěry), ale ty stejně vyžadují runtime, což zabírá místo, což v embedded nemáme rádi

[Mirek Prýmek]

Tohle ale nejde pouzit (pokud ti spravne rozumim). Alokuje se v jine funkci nez dealokuje.

Kanaly se nealokuji dynamicky, to neni potreba, ty jsou alokovane staticky. Dynamicky se alokuji zpravy - prave proto, ze je potreba je na jednom miste vytvorit a na jinem pouzit. Pokud bych se moc chtel te dynamicke alokaci vyhnout, stacilo by pouzit doublebuffer (protoze kanal ma kapacitu 1). Neudelal jsem to zamerne, protoze jsem chtel, aby informace proudily striktne ve smeru channelu, ne nejakym postrannim "neviditelnym" kanalem opacne.

[Idris]

Tohle ale nejde pouzit (pokud ti spravne rozumim). Alokuje se v jine funkci nez dealokuje.

Jde to použít, když si někde držíš RC (jako třeba Rust). Případně si můžeš implementovat move, ale to už je vyšší vyšší dívčí.

[Idris]

Kanaly se nealokuji dynamicky, to neni potreba, ty jsou alokovane staticky. Dynamicky se alokuji zpravy - prave proto, ze je potreba je na jednom miste vytvorit a na jinem pouzit. Pokud bych se moc chtel te dynamicke alokaci vyhnout, stacilo by pouzit doublebuffer (protoze kanal ma kapacitu 1). Neudelal jsem to zamerne, protoze jsem chtel, aby informace proudily striktne ve smeru channelu, ne nejakym postrannim "neviditelnym" kanalem opacne.

To byl jen příklad. Zrovna u těch zpráv to dává ještě větší smysl. Teď už se bavíme o detailech, ale pro někoho, kdo si s Picem jen hraje a jinak moc vývojář není, to může být docela velký rozdíl. A v produkci je to bezpečnější.

[Mirek Prýmek]

ale pro někoho, kdo si s Picem jen hraje a jinak moc vývojář není, to může být docela velký rozdíl

Abysme si rozumeli: nesnazim se udelat to "Arduino done right". Chci udelat demo CSP na MCU. Neni to urceno lamam a jelikoz se alokuje na jednom jasne danem miste, dealokuje na jinem jasne danem miste a oboje je z definice synchronizovany, nedava mi smysl tam vymyslet jekykoli vyfikundance, ktery by kod jenom nesmyslne komplikovaly.