Budoucnost a sliby - Futures and promises

Nesmí být zaměňována s Slibná teorie.

v počítačová věda, budoucnost, slib, zpoždění, a odložený odkazovat na konstrukty použité pro synchronizace program provedení v některých souběžné programovací jazyky. Popisují objekt, který funguje jako proxy pro výsledek, který je zpočátku neznámý, obvykle proto, že výpočet jeho hodnoty ještě není kompletní.

Termín slib bylo navrženo v roce 1976 Daniel P. Friedman a David Wise,[1]a Peter Hibbard to nazval eventuální.[2]Trochu podobný koncept budoucnost byl představen v roce 1977 v příspěvku od Henry Baker a Carl Hewitt.[3]

Podmínky budoucnost, slib, zpoždění, a odložený jsou často používány zaměnitelně, i když některé rozdíly v použití mezi budoucnost a slib jsou zpracovány níže. Konkrétně, když se rozlišuje použití, budoucnost je pouze ke čtení zástupný pohled na proměnnou, zatímco slib je zapisovatelný, jediný úkol kontejner, který nastavuje hodnotu budoucnosti. Pozoruhodně lze definovat budoucnost, aniž byste specifikovali, který konkrétní příslib nastaví jeho hodnotu, a různé možné sliby mohou nastavit hodnotu dané budoucnosti, ačkoli pro danou budoucnost to lze provést pouze jednou. V ostatních případech se budoucnost a příslib vytvářejí společně a navzájem se spojují: budoucnost je hodnota, příslib je funkce, která nastavuje hodnotu - v podstatě návratová hodnota (budoucnost) asynchronní funkce (příslib). Rovněž se nazývá nastavení hodnoty budoucnosti řešení, naplňujícínebo vazba to.

Aplikace

Futures a sliby vznikly v Funkcionální programování a související paradigmata (např logické programování ) oddělit hodnotu (budoucnost) od toho, jak byla vypočítána (příslib), což umožňuje pružnější výpočet, zejména paralelizací. Později našel použití v distribuované výpočty, při snižování latence při zpáteční komunikaci. Ještě později to získalo větší využití povolením zápisu asynchronních programů do přímý styl, spíše než v styl předávání pokračování.

Implicitní vs. explicitní

Použití futures může být implicitní (jakékoli použití budoucnosti automaticky získá svou hodnotu, jako by to bylo obyčejné odkaz ) nebo explicitní (uživatel musí pro získání hodnoty zavolat funkci, například dostat metoda java.util.concurrent.Futurev Jáva ). Lze vyvolat získání hodnoty explicitní budoucnosti bodnutí nebo nutit. Explicitní futures lze implementovat jako knihovnu, zatímco implicitní futures se obvykle implementují jako součást jazyka.

Původní práce Bakera a Hewitta popisovala implicitní futures, které jsou přirozeně podporovány v herec model výpočtu a čisté objektově orientované programování jazyky jako Pokec. Dokument Friedman a Wise popsal pouze explicitní futures, což pravděpodobně odráží obtížnost efektivní implementace implicitních futures na akciový hardware. Potíž spočívá v tom, že základní hardware se nezabývá futures na primitivní datové typy, jako jsou celá čísla. Například instrukce přidání neví, jak naložit 3 + budoucnost faktoriál (100 000). V čistých jazycích herců nebo objektů lze tento problém vyřešit odesláním budoucnost faktoriál (100 000) zpráva +[3], který žádá budoucnost o přidání 3 a vrátit výsledek. Všimněte si, že přístup k předávání zpráv funguje bez ohledu na to, kdy faktoriál (100 000) dokončí výpočet a že není nutné žádné píchání / nucení.

Slibte pipeline

Využití futures se může dramaticky snížit latence v distribuované systémy. Například futures umožňují slib potrubí,[4][5] jak je implementováno v jazycích E a Joule, který byl také nazýván stream volání[6] v jazyce Argus.

Zvažte výraz zahrnující konvenční vzdálená volání procedur, jako:

 t3: = (x.a ()) .c (y.b ())

které lze rozšířit na

 t1: = x.a (); t2: = y.b (); t3: = t1.c (t2);

Než může pokračovat další výpis, je třeba odeslat zprávu a obdržet odpověď. Předpokládejme například, že X, y, t1, a t2 jsou všechny umístěny na stejném vzdáleném počítači. V takovém případě musí před uskutečněním třetího příkazu proběhnout dva úplné zpáteční lety k tomuto počítači. Třetí příkaz pak způsobí další zpáteční cestu ke stejnému vzdálenému stroji.

Pomocí futures lze výše uvedený výraz zapsat

 t3: = (x <- a ()) <- c (y <- b ())

které lze rozšířit na

 ti: = x <- a (); t2: = y <- b (); t3: = t1 <- c (t2);

Zde použitá syntaxe je syntaxe jazyka E, kde x <- a () znamená odeslat zprávu A() asynchronně na X. Všem třem proměnným jsou pro jejich výsledky okamžitě přiřazeny futures a provádění pokračuje k následným příkazům. Pozdější pokusy o vyřešení hodnoty t3 může způsobit zpoždění; pipeline však může snížit počet potřebných zpátečních letů. Pokud, jako v předchozím příkladu, X, y, t1, a t2 jsou všechny umístěny na stejném vzdáleném počítači, lze vypočítat pipeline implementaci t3 s jedním zpáteční let místo tří. Protože všechny tři zprávy jsou určeny pro objekty, které jsou na stejném vzdáleném počítači, je třeba odeslat pouze jeden požadavek a musí být přijata pouze jedna odpověď obsahující výsledek. Odeslání t1 <- c (t2) nebude blokovat, i když t1 a t2 byli na různých strojích navzájem, nebo aby X nebo y.

Promise pipelining by mělo být odlišeno od paralelního předávání asynchronních zpráv. V systému podporujícím předávání paralelních zpráv, ale nikoli zřetězení, se zpráva odešle x <- a () a y <- b () ve výše uvedeném příkladu může postupovat paralelně, ale odeslání t1 <- c (t2) bude muset počkat, až oba t1 a t2 byl přijat, i když X, y, t1, a t2 jsou na stejném vzdáleném počítači. Výhoda relativní latence zřetězení se stává ještě větší ve složitějších situacích zahrnujících mnoho zpráv.

Slibné zavádění by také nemělo být zaměňováno pipeline zpracování zpráv v systémech herec, kde je možné, aby herec určil a zahájil provádění chování pro další zprávu před dokončením zpracování aktuální zprávy.

Zobrazení jen pro čtení

V některých programovacích jazycích, jako je Oz, E, a AmbientTalk, je možné získat a jen pro čtení budoucnosti, který umožňuje čtení jeho hodnoty, když je vyřešen, ale neumožňuje jeho řešení:

  • V Oz !! operátor se používá k získání zobrazení jen pro čtení.
  • V E a AmbientTalk je budoucnost reprezentována dvojicí hodnot nazývaných a pár slib / řešitel. Příslib představuje pohled jen pro čtení a k nastavení hodnoty budoucnosti je potřebný překladač.
  • v C ++ 11 A std :: budoucnost poskytuje pohled jen pro čtení. Hodnota se nastavuje přímo pomocí a std :: slib, nebo nastaven na výsledek volání funkce pomocí std :: packaged_task nebo std :: asynchronní.
  • V Dojo Toolkit Odložené API od verze 1.5, a objekt slibu pouze pro spotřebitele představuje pohled jen pro čtení.[7]
  • v Alice ML, futures poskytují a jen pro čtenízatímco slib obsahuje budoucnost i schopnost vyřešit budoucnost[8][9]
  • v .NET 4.0 System.Threading.Tasks.Task představuje pohled jen pro čtení. Vyřešení hodnoty lze provést pomocí System.Threading.Tasks.TaskCompletionSource .

Podpora zobrazení pouze pro čtení je v souladu s zásada nejmenších privilegií, protože umožňuje nastavit omezenou hodnotu předměty to je třeba nastavit. V systému, který také podporuje zřetězení, odesílatel asynchronní zprávy (s výsledkem) obdrží slib výsledku jen pro čtení a cíl zprávy obdrží resolver.

Futures specifické pro vlákna

Některé jazyky, například Alice ML, definujte futures, které jsou spojeny s konkrétním vláknem, které počítá hodnotu budoucnosti.[9] Tento výpočet může začít buď dychtivě když je vytvořena budoucnost, nebo líně když je nejprve potřeba jeho hodnota. Líná budoucnost je podobná a thunk ve smyslu opožděného výpočtu.

Alice ML také podporuje futures, které lze vyřešit jakýmkoli vláknem, a volá je sliby.[8] Toto použití slib se liší od jeho použití v E, jak je popsáno výše. V Alice není slib pohledem jen pro čtení a pipelining slibů není podporován. Místo toho se pipeline přirozeně děje pro futures, včetně těch, které jsou spojeny se sliby.

Blokovací vs neblokující sémantika

Pokud je k hodnotě budoucnosti přistupováno asynchronně, například odesláním zprávy nebo explicitně čekáním na ni pomocí konstrukce, jako je když v E pak není problém se zpožděním, dokud nebude vyřešena budoucnost, než bude možné přijmout zprávu nebo dokončit čekání. Toto je jediný případ, který je třeba vzít v úvahu v čistě asynchronních systémech, jako jsou jazyky čistých aktérů.

V některých systémech je však také možné se o to pokusit ihned nebo synchronně získat přístup k hodnotě budoucnosti. Pak je třeba provést výběr designu:

  • přístup by mohl blokovat aktuální vlákno nebo proces, dokud nebude vyřešena budoucnost (pravděpodobně s časovým limitem). To je sémantika proměnné toku dat v jazyce Oz.
  • pokus o synchronní přístup mohl vždy signalizovat chybu, například hod výjimka. Toto je sémantika vzdálených slibů v E.[10]
  • potenciálně by přístup mohl uspět, pokud je budoucnost již vyřešena, ale signalizovat chybu, pokud není. To by mělo tu nevýhodu, že by vneslo nedeterminismus a potenciál pro podmínky závodu, a zdá se být neobvyklou volbou designu.

Jako příklad první možnosti v C ++ 11, vlákno, které potřebuje hodnotu budoucnosti, může blokovat, dokud nebude dostupné voláním Počkejte() nebo dostat() členské funkce. Můžete také určit časový limit čekání pomocí čekat na() nebo Počkej do() členské funkce, aby se zabránilo neomezenému blokování. Pokud budoucnost vznikla z volání na std :: asynchronní pak blokování čekání (bez časového limitu) může způsobit synchronní vyvolání funkce k výpočtu výsledku na vláknu čekání.

Související konstrukty

Budoucnost je zvláštní případ Událost (synchronizační primitiv), kterou lze dokončit pouze jednou. Obecně lze události resetovat do počátečního prázdného stavu, a tedy dokončit tolikrát, kolikrát chcete.[11]

An I-var (jako v jazyce Id ) je budoucnost s blokující sémantikou, jak je definována výše. An I-struktura je datová struktura obsahující I-vars. Související synchronizační konstrukt, který lze nastavit vícekrát s různými hodnotami, se nazývá an M-var. M-vars podporuje atomové operace vzít nebo dát aktuální hodnota, kde převzetí hodnoty také nastaví M-var zpět na počáteční hodnotu prázdný Stát.[12]

A souběžná logická proměnná[Citace je zapotřebí ] je podobná budoucnosti, ale je aktualizována o unifikace stejným způsobem jako logické proměnné v logické programování. Může tedy být vázán více než jednou na unifiable hodnoty, ale nemůže být nastaven zpět do prázdného nebo nevyřešeného stavu. Proměnné toku dat Oz fungují jako souběžné logické proměnné a mají také blokovací sémantiku, jak je uvedeno výše.

A proměnná souběžného omezení je zobecnění souběžných logických proměnných na podporu logické programování omezení: omezení může být zúžil několikrát, což označuje menší sady možných hodnot. Obvykle existuje způsob, jak určit thunk, který by se měl spustit, kdykoli se omezení zúží dále; to je nutné k podpoře šíření omezení.

Vztahy mezi expresivitou různých forem budoucnosti

Eager futures specifické pro podprocesy lze přímo implementovat do futures specifických pro jiné podprocesy vytvořením podprocesu pro výpočet hodnoty současně s vytvářením budoucnosti. V tomto případě je žádoucí vrátit klientovi pohled jen pro čtení, aby tuto budoucnost mohl vyřešit pouze nově vytvořený podproces.

Chcete-li implementovat implicitní líné vlákno specifické futures (například poskytované Alice ML), pokud jde o futures jiné než vlákno, potřebuje mechanismus k určení, kdy je nejprve potřeba hodnota budoucnosti (například WaitNeeded postavit v Oz[13]). Pokud jsou všechny hodnoty objekty, pak je schopnost implementovat transparentní objekty pro předávání dostatečná, protože první zpráva odeslaná předávajícímu naznačuje, že je potřeba budoucí hodnota.

Futures, které nejsou specifické pro vlákna, lze implementovat ve futures na konkrétní vlákna, za předpokladu, že systém podporuje předávání zpráv, tím, že řešení vlákno odešle zprávu do vlastního vlákna budoucnosti. Lze to však považovat za nepotřebnou složitost. V programovacích jazycích založených na vláknech se nejexpresivnějším přístupem zdá být poskytnutí kombinace futures jiných než vlákna, pohledů jen pro čtení a buď WaitNeeded konstrukce nebo podpora transparentního předávání.

Strategie hodnocení

Další informace: Volejte do budoucnosti

The strategie hodnocení futures, které lze nazvat volání do budoucnosti, je nedeterministická: hodnota budoucnosti bude hodnocena v určitém čase mezi vytvořením budoucnosti a jejím použitím, ale přesný čas není předem určen a může se měnit od běhu k běhu. Výpočet může začít, jakmile se vytvoří budoucnost (nedočkavé hodnocení ) nebo pouze v případě, že je hodnota skutečně potřebná (líné hodnocení ) a mohou být částečně pozastaveny nebo provedeny v jednom běhu. Jakmile je přiřazena hodnota budoucnosti, není při dalších přístupech přepočítávána; to je jako memorování použito v volejte podle potřeby.

A líná budoucnost je budoucnost, která má deterministicky sémantiku líného hodnocení: výpočet hodnoty budoucnosti začíná, když je hodnota nejprve potřeba, jako v případě volání podle potřeby. Líné futures se používají v jazycích, jejichž strategie hodnocení není ve výchozím nastavení líná. Například v C ++ 11 takové líné budoucnosti lze vytvořit předáním std :: launch :: odloženo spustit politiku do std :: asynchronní, spolu s funkcí pro výpočet hodnoty.

Sémantika futures v modelu herce

V modelu herce výraz formy budoucnost <Expression> je definována tím, jak reaguje na Eval zpráva s prostředím E a zákazník C takto: Budoucí výraz reaguje na Eval zpráva zasláním zákazníka C nově vytvořený herec F (zástupce odpovědi na hodnocení <Expression>) jako návratová hodnota současně s odesláním <Expression> an Eval zpráva s prostředím E a zákazník C. Výchozí chování F je následující:

  • Když F obdrží požadavek R, poté zkontroluje, zda již obdržel odpověď (která může být buď návratovou hodnotou nebo vyvolanou výjimkou) z vyhodnocení <Expression> postupuje takto:
    1. Pokud již má odpověď PROTI, pak
      • Li PROTI je návratová hodnota, pak se odešle požadavek R.
      • Li PROTI je výjimka, pak je vyvolána zákazníkovi požadavku R.
    2. Pokud ještě nemá odpověď, pak R je uložen ve frontě požadavků uvnitř F.
  • Když F obdrží odpověď PROTI z hodnocení <Expression>, pak PROTI je uložen v F a
    • Li PROTI je návratová hodnota, pak se odešlou všechny žádosti ve frontě PROTI.
    • Li PROTI je výjimka, pak je vyvolána zákazníkovi každého z požadavků ve frontě.

Některé futures však mohou vyřizovat žádosti zvláštními způsoby, aby zajistily větší paralelismus. Například výraz 1 + budoucí faktoriál (n) může vytvořit novou budoucnost, která se bude chovat jako číslo 1 + faktoriál (n). Tento trik nefunguje vždy. Například následující podmíněný výraz:

-li m> budoucí faktoriál (n) pak tisk ("větší") jiný tisk ("menší")

pozastaví do budoucnosti pro faktoriál (n) odpověděl na žádost s dotazem, zda m je větší než on sám.

Dějiny

The budoucnost a / nebo slib konstrukce byly poprvé implementovány v programovacích jazycích, jako je MultiLisp a 1. dějství. Využití logických proměnných pro komunikaci v systému Windows souběžně logické programování jazyky byly docela podobné futures. Ty začaly v roce Prolog s Freeze a IC Prolog, a stal se skutečným primitivem souběžnosti s Relational Language, Concurrent Prolog hlídané Horn klauzule (GHC), Parlog, Pramen, Vulcan, Janus, Oz-Mozart, Flow Java, a Alice ML. Jediný úkol I-var z programování toku dat jazycích pocházejících z Id a je součástí Reppy's Souběžné ML, je hodně jako souběžná logická proměnná.

Techniku ​​slibného pipeline (použití futures k překonání latence) vynalezl Barbara Liskov a Liuba Shrira v roce 1988,[6] a nezávisle na Mark S. Miller, Dean Tribble a Rob Jellinghaus v kontextu Projekt Xanadu cca 1989.[14]

Termín slib byl vytvořen Liskovem a Shrirou, ačkoli odkazovali na pipeliningový mechanismus jménem stream volání, který se nyní používá jen zřídka.

Jak design popsaný v Liskovově a Shrirově práci, tak implementace pipelingu slibů v Xanadu měly limit, že hodnoty slibů nebyly první třída: argument do nebo hodnota vrácená voláním nebo odesláním nemohla být přímo slibem (takže dříve uvedený příklad slibného pipeline, který používá slib pro výsledek jednoho odeslání jako argument pro jiný, by nebyl přímo vyjádřitelný v designu streamování hovorů nebo v implementaci Xanadu). Zdá se, že sliby a streamování hovorů nebyly nikdy implementovány v žádném veřejném vydání Argusu,[15] programovací jazyk použitý v Liskovově a Shriraově práci. Vývoj společnosti Argus se zastavil kolem roku 1988.[16] Implementace Xanadu slibného pipeline byla veřejně dostupná až po vydání zdrojového kódu pro Udanax Gold[17] v roce 1999 a nikdy nebyl vysvětlen v žádném publikovaném dokumentu.[18] Pozdější implementace v Joule a E plně podporují prvotřídní sliby a řešitele.

Několik jazyků raných herců, včetně série Act,[19][20] podporováno jak paralelní předávání zpráv, tak pipeline zpracování zpráv, ale neslibuji pipeline. (I když je technicky možné implementovat poslední z těchto funkcí do prvních dvou, neexistují žádné důkazy o tom, že tak učinily jazyky zákona.)

Po roce 2000 došlo k výraznému oživení zájmu o futures a sliby, a to kvůli jejich použití v roce 2006 citlivost uživatelských rozhraní a v vývoj webových aplikací, v důsledku vyžádat odpověď model předávání zpráv. Několik běžných jazyků má nyní jazykovou podporu pro budoucnost a sliby, zejména popularizované FutureTask v Javě 5 (oznámeno 2004)[21] a asynchronní a čekat konstrukce v .NET 4.5 (oznámeno 2010, vydané 2012)[22][23] do značné míry inspirován asynchronní pracovní toky vypnuto#,[24] který se datuje do roku 2007.[25] Toto bylo následně přijato dalšími jazyky, zejména Dartem (2014),[26] Python (2015),[27] Hack (HHVM) a návrhy ECMAScript 7 (JavaScript), Scala a C ++.

Seznam implementací

Některé programovací jazyky podporují futures, sliby, souběžné logické proměnné, proměnné toku dat nebo I-vary, a to buď přímou podporou jazyků, nebo ve standardní knihovně.

Seznam konceptů souvisejících s futures a sliby programovacím jazykem

Mezi jazyky, které také podporují pipelining slibů, patří:

Seznam nestandardních implementací futures založených na knihovnách

Běžné

Futures lze implementovat v coutiny[27] nebo generátory,[95] což vede ke stejné strategii hodnocení (např. kooperativní multitasking nebo líné hodnocení).

Kanály

Hlavní článek: Kanál (programování)

Futures lze snadno implementovat v kanály: budoucnost je jednoprvkový kanál a slib je proces, který do kanálu odešle a naplní budoucnost.[96][97] To umožňuje implementaci futures v souběžných programovacích jazycích s podporou kanálů, jako jsou CSP a Jít. Výsledné futures jsou explicitní, protože k nim je třeba přistupovat čtením z kanálu, nikoli pouze vyhodnocením.

Viz také

Reference

  1. ^ Friedman, Daniel; David Wise (1976). Dopad aplikačního programování na multiprocesing. Mezinárodní konference o paralelním zpracování. 263–272.
  2. ^ Hibbard, Peter (1976). Zařízení pro paralelní zpracování. New Directions in Algorithmic Languages, (ed.) Stephen A. Schuman, IRIA, 1976.
  3. ^ Henry Baker; Carl Hewitt (srpen 1977). Inkrementální sběr odpadků procesů. Sborník ze sympozia o programovacích jazycích umělé inteligence. Oznámení ACM SIGPLAN 12, 8. str. 55–59.
  4. ^ Promise Pipelining na erights.org
  5. ^ Slib Pipelining na C2 wiki
  6. ^ A b Barbara Liskov; Liuba Shrira (1988). "Sliby: Jazyková podpora pro efektivní volání asynchronních procedur v distribuovaných systémech". Sborník konference SIGPLAN '88 o programování a implementaci programovacích jazyků; Atlanta, Georgia, Spojené státy. ACM. str. 260–267. doi:10.1145/53990.54016. ISBN  0-89791-269-1. Publikováno také v Oznámení ACM SIGPLAN 23(7).
  7. ^ Robustní sliby s odložením Dojo, Site Pen, 3. května 2010
  8. ^ A b "Slib", Alice Manual, DE: Uni-SB
  9. ^ A b "Budoucnost", Alice manuál, DE: Uni-SB
  10. ^ Slib Práva E.
  11. ^ 500 řádků nebo méně, „Webový prohledávač s asyncio Coroutines“ od A. Jesse Jiryu Davise a Guida van Rossuma říká "implementace používá asyncio.Event namísto zde zobrazené budoucnosti. Rozdíl spočívá v tom, že událost může být resetována, zatímco budoucnost nemůže přejít z vyřešeného zpět na nevyřízenou."
  12. ^ Řízení souběžného MVar, Haskell, archivovány z originál dne 18. dubna 2009
  13. ^ WaitNeeded, Mozart Oz
  14. ^ Slib, Moře bez slunce, archivovány z originál dne 23. října 2007
  15. ^ Argus, MIT
  16. ^ Liskov, Barbara, Distribuované výpočty a Argus, Orální historie, IEEE GHN
  17. ^ Zlato, Udanax, archivovány z originál dne 11. října 2008
  18. ^ Potrubí Práva E.
  19. ^ Henry Lieberman (červen 1981). "Náhled zákona 1". Memo AI MIT 625. Citovat deník vyžaduje | deník = (Pomoc)
  20. ^ Henry Lieberman (červen 1981). „Přemýšlíte o spoustě věcí najednou, aniž byste se nechali zmást: Rovnoběžnost v 1. dějství“. Memo AI MIT 626. Citovat deník vyžaduje | deník = (Pomoc)
  21. ^ Goetz, Brian (23. listopadu 2004). „Souběžnost v JDK 5.0“.
  22. ^ A b „Async in 4.5: Worth the Await - .NET Blog - Site Home - MSDN Blogs“. Blogs.msdn.com. Citováno 13. května 2014.
  23. ^ A b C "Asynchronous Programming with Async and Await (C # and Visual Basic)". Msdn.microsoft.com. Citováno 13. května 2014.
  24. ^ Tomáš Petříček (29. října 2010). „Asynchronous C # and F # (I.): Sim obecný úvod“.
  25. ^ Don Syme; Tomáš Petříček; Dmitrij Lomov (21. října 2010). „F # asynchronní programovací model, PADL 2011“.
  26. ^ A b Gilad Bracha (říjen 2014). "Dart Language Asynchrony Support: Phase 1".
  27. ^ A b „PEP 0492 - Coroutines s asynchronní a čekající na syntaxi“.
  28. ^ Kenjiro Taura; Satoshi matsuoka; Akinori Yonezawa (1994). „ABCL / f: Budoucí polymorfní typovaný souběžný objektově orientovaný jazyk - jeho design a implementace.“. V Proceedings of the DIMACS workshop on Specification of Parallel Algorithms, number 18 in Dimacs Series in Discrete Mathematics and Theoretical Computer Science. Americká matematická společnost. str. 275–292. CiteSeerX  10.1.1.23.1161.
  29. ^ "Dart SDK dart async Completer".
  30. ^ "Úkol".
  31. ^ Steve Dekorte (2005). „Io, programovací jazyk“.
  32. ^ Rich Hickey (2009). "changes.txt v 1.1.x od Richhickeyho clojure".
  33. ^ Seif Haridi; Nils Franzen. "Tutorial of Oz". Globální knihovna uživatelů Mozarta. Citováno 12. dubna 2011.
  34. ^ Vydání Pythonu 3.2
  35. ^ Vydání Pythonu 3.5
  36. ^ „Rovnoběžnost s budoucností“. PLT. Citováno 2. března 2012.
  37. ^ Slibná třída v Perlu 6
  38. ^ Společný kos Lisp
  39. ^ Společná budoucnost Lisp Eager2
  40. ^ Lisp paralelně - Knihovna paralelního programování pro Common Lisp
  41. ^ Společný Lisp PCall
  42. ^ „Kapitola 30. Vlákno 4.0.0“. Citováno 26. června 2013.
  43. ^ „Knihovna Dlib C ++ #thread_pool“. Citováno 26. června 2013.
  44. ^ „QtCore 5.0: QFuture Class“. Projekt Qt. Archivovány od originál dne 1. června 2013. Citováno 26. června 2013.
  45. ^ "Mořská hvězda". Projekt Seastar. Citováno 22. srpna 2016.
  46. ^ „GitHub - facebook / bláznovství: Otevřená knihovna C ++ vyvinutá a používaná na Facebooku“. 8. ledna 2019.
  47. ^ „Threads Slides of POCO“ (PDF).
  48. ^ „HPX“. 10. února 2019.
  49. ^ Groovy GPars Archivováno 12. ledna 2013 v Wayback Machine
  50. ^ Cujo.js
  51. ^ JavaScript when.js
  52. ^ Sliby / specifikace A +
  53. ^ sliby
  54. ^ JavaScript MochKit.Async
  55. ^ JavaScript Angularjs
  56. ^ Slib uzlu JavaScriptu
  57. ^ JavaScript Q
  58. ^ JavaScript RSVP.js
  59. ^ Knihovna tříd YUI JavaScript
  60. ^ YUI třída slibů JavaScriptu
  61. ^ JavaScript Bluebird
  62. ^ Java JDeferred
  63. ^ Java ParSeq
  64. ^ Objective-C MAFuture GitHub
  65. ^ Objective-C MAFuture mikeash.com
  66. ^ Objective-C RXPromise
  67. ^ ObjC-CollapsingFutures
  68. ^ Objective-C PromiseKit
  69. ^ Objective-C objc-příslib
  70. ^ Objective-C OAPromise
  71. ^ OCaml Lazy
  72. ^ Perl Future
  73. ^ Perl Promises
  74. ^ Perl Reflex
  75. ^ Perl Promise :: ES6
  76. ^ Reakce / příslib PHP
  77. ^ Integrovaná implementace Pythonu
  78. ^ pythonfutures
  79. ^ Twisted Deferreds
  80. ^ Budoucí balíček R.
  81. ^ budoucnost
  82. ^ Ruby Promise klenot
  83. ^ Ruby libuv
  84. ^ Ruby Celluloid drahokam
  85. ^ Ruby budoucí zdroj
  86. ^ bedna futures-rs
  87. ^ Knihovna util na Twitteru
  88. ^ Swift Async
  89. ^ Swift FutureKit
  90. ^ Swift Apple GCD
  91. ^ Swift FutureLib
  92. ^ bignerdranch / Odloženo
  93. ^ Thomvis / BrightFutures
  94. ^ tcl-příslib
  95. ^ Vyřeší async / await skutečný problém?
  96. ^ Přejít na jazykové vzory Futures
  97. ^ Přejít na jazykové vzory

externí odkazy