Koprogram
Koprogramy (anglicky coroutine) jsou v informatice programové komponenty, které umožňují na rozdíl od podprogramů (procedur, funkcí, metod) více vstupních bodů, pozastavení a obnovení výpočtu v jejich různých místech. Koprogramy jsou vhodné pro implementaci kooperativního multitaskingu, iterátorů, proudů (stream) a trubek (pipe).
Termín koprogram poprvé použil Melvin Conway ve své seminární práci v roce 1963.[1]
Srovnání s podprogramy
Koprogramy jsou obecnější než podprogramy. Životní cyklus podprogramů je řízen zásobníkem (LIFO) (tj. poslední volaný podprogram provede návrat jako první). Naproti tomu životní cyklus koprogramů závisí výhradně na jejich použití a aktuální potřebě.
Podprogram má pouze jeden vstupní bod (svůj začátek) a můžeme se z něj vrátit jen jednou. Naproti tomu koprogramy se mohou vracet několikrát (příkazem yield). Začátek koprogramu je první vstupní bod a následující vstupní body označuje příkaz yield. V praxi příkaz yield vrací výsledek a předává řízení do volajícího koprogramu podobně, jako u klasických podprogramů. Avšak při dalším volání koprogramu nezačne provádění na jeho začátku, ale následujícím příkazem za posledním provedeným příkazem yield.
V následujícím příkladu si ukážeme, jak mohou být koprogramy užitečné. Předpokládejme, že máme vazbu producent-konzument, kde jedna rutina vytváří položky a přidává je do fronty a druhá odebírá položky z fronty a zpracovává je. Z úsporných důvodů chceme přidávat a odebírat několik položek najednou. Zápis programu by mohl vypadat takto:
var q := new queue coroutine produce loop while q is not full create some new items add the items to q yield to consume coroutine consume loop while q is not empty remove some items from q use the items yield to produce
Fronta je zde kompletně naplněna nebo vyprázdněna před voláním příkazu yield a předáním řízení druhému koprogramu. Vnitřní koprogramová smyčka zajišťuje další volání koprogramů přímo za příkazem yield.
Přestože je tento příklad obvykle uváděn jako úvod do multithreadingu, není nutné, abychom kvůli tomu vytvářeli dva thready. Příkaz yield může být implementován jako přímý odskok z jedné rutiny do druhé.
Srovnání s generátory
Generátory jsou také zobecněním podprogramů, ale jsou více limitovány než koprogramy. Oba přístupy umožňují více návratů, což zastaví jejich vykonávání s tím, že je možné později pokračovat ve vykonávání z více vstupních bodů. Liší se však v tom, že koprogramy mohou kontrolovat místo, ve kterém bude vykonávání programu pokračovat po zavolání yield. Toto generátory nemohou ovlivnit, neboť pouze vrací kontrolu zpět na místo kde byly zavolány.[2]
Nicméně je stále možné implementovat koprogramy za pomocí více generátorů s vrchní rozhodující funkcí, která předává kontrolu explicitně svým generátorům identifikovatelným pomocí tokenů, které jsou z nich předány zpět:
var q := new queue
generator produce loop while q is not full create some new items add the items to q yield consume
generator consume loop while q is not empty remove some items from q use the items yield produce
subroutine dispatcher var d := new dictionary(generator → iterator) d[produce] := start produce d[consume] := start consume var current := produce loop current := next d[current]
Mnoho implementací koprogramů pro jazyky s podporou generátorů, avšak bez nativních koprogramů (e.g. Python[3] před 2.5), využívá tento přístup.
Srovnání se vzájemnou rekurzí
Používání koprogramů pro stavové stroje nebo souběžnost je podobné jako používání vzájemné rekurze s návratem. V obou případech řízení mění různé druhy úloh. Nicméně koprogramy jsou více flexibilní a obvykle výhodnější. Koprogramy jsou uzpůsobené spíše k obnovení provádění než k restartování, a proto jsou schopné udržet stav, obě proměnné (jako uzávěry), bod vykonávání a výsledky nemusí nutně být na konci kódu. Vzájemné rekurzivní podprogramy musí používat sdílené proměnné, a nebo odesílat stav jako parametr. Předávání řízení mezi koprogramy probíhá pomocí existujícího kontextu a může být jednoduše implementováno jako instrukce skoku.
Častá použití
Koprogramy jsou užitečné při implementaci:
- Stavových automatů v jediném podprogramu, kde stav je určen aktuálním vstupním/výstupním bodem procedury; takto může vzniknout více čitelný kód v porovnání s použitím goto a může být také implementován pomocí vzájemné rekurze s koncovým voláním.
- Aktorový model souběhu, například v počítačových hrách. Každý aktor má své vlastní procedury (logicky odděluje kód), ale dobrovolně předává kontrolu hlavnímu plánovači, který je vykonává sekvenčně (určitá forma kooperativního multitaskingu).
- Generátory jsou užitečné pro proudy – zejména vstupní/výstupní – a pro obecné procházení datových struktur.
- Komunikace mezi sekvenčními procesy, kde každý podproces je koprogram. Vstupně-výstupní kanály a blokující operace volají yield v koprogramu a plánovač je následně odblokuje při dokončení.
Programovací jazyky s nativní podporou koprogramů
- Aikido
- AngelScript
- BCPL
- Pascal (Borland Turbo Pascal 7.0 s uThreads modulem)
- BETA
- BLISS
- C#
- ChucK
- D
- Dynamic C
- Erlang
- F#
- Factor
- GameMonkey Script
- Go
- Haskell
- High Level Assembly
- Icon
- Io
- JavaScript (od verze 1.7)
- Julia
- Kotlin (od verze 1.3)
- Limbo
- Lua
- Lucid
- µC++
- MiniD
- Modula-2
- Nemerle
- Perl (Perl5 s Coro, nativně od Perl 6)
- PHP (s Hiphop, nativně od PHP 5.5)
- Picolisp
- Prolog
- Python (od verze 2.5, s vylepšenou podporou od verze 3.3)
- Ruby
- Rust
- Sather
- Scheme
- Self
- Simula 67
- Squirrel
- Stackless Python
- SuperCollider
- Tcl (od verze 8.6)
- Urbiscript
Alternativy
Použití koprogramů nemusí být vždy dostupné řešení pro přirozenou implementaci mechanismu. Typickou reakcí na tento problém je použití uzávěr – podprogramů se stavovými proměnnými (statické proměnné, často booleovské příznaky). Tyto proměnné se používají k udržení vnitřních stavů mezi voláními a k řízení transferu do správného bodu. Podmínky uvnitř kódu určují, která část kódu se vykoná na základě hodnot stavových proměnných. Další typickou reakcí je implementace explicitního stavového stroje ve formě rozsáhlých a komplexních switch nebo „goto“ příkazů, zvláště vypočítaných „goto“ příkazů. Všechny tyto implementace jsou považovány za složité k pochopení a údržbě. Jsou tedy motivací pro podporu koprogramů.
Vlákna jsou dnes v oboru programování také alternativou koprogramů. Vlákna poskytují v reálném čase možnosti pro řízení spolupráce mezi souběžně vykonávanými kusy kódu. Vlákna jsou široce rozšířena v prostředích, která podporují jazyk C (a jsou podporovány nativně ve spoustě ostatních moderních jazycích) a programátoři jsou s nimi obeznámeni. Jsou obvykle velmi dobře implementovány, dokumentovány a podporovány. Jakmile vlákna řeší rozsáhlý a obtížný problém obsahují mnoho mocných a komplexních možností a mají tomu odpovídající složitost na porozumění. V případě, že je snadnější použít koprogram, je vláknování velmi nadbytečné.
Jedním důležitým rozdílem mezi vlákny a koprogramy je ten, že vlákna jsou typicky preemptivně plánována, zatímco koprogramy nejsou. Programy používající vlákna musí být chráněny proti uzamčení, protože vlákna mohou být přeplánována v jakýkoliv moment a mohou být spuštěna současně. Koprogramy, které mohou být přeplánovány pouze v určitých bodech v programu a nespouští se současně, často předchází uzamčení úplně. Tato vlastnost je často citována jako výhoda událostmi řízeného nebo asynchronního programování.
Reference
V tomto článku byl použit překlad textu z článku Coroutine na anglické Wikipedii.
- ↑ M.E. Conway, Design of a separable transition-diagram compiler, Communications of the ACM, Vol. 6, No. 7, July 1963
- ↑ Příklad The Python Language Reference "http://docs.python.org/reference/expressions.html#yieldexpr 5.2.10. Yield expressions]":
"All of this makes generator functions quite similar to coroutines; they yield multiple times, they have more than one entry point and their execution can be suspended. The only difference is that a generator function cannot control where should the execution continue after it yields; the control is always transferred to the generator's caller." - ↑ MERTZ, David. Generator-based State Machines [online]. IBM developerWorks, July 1, 2002 [cit. 2011-02-02]. Dostupné v archivu pořízeném dne 2009-02-28. (anglicky)