Vadeli işlemler ve vaatler - Futures and promises

Vaat teorisi ile karıştırılmamalıdır .

Gelen bilgisayar bilimleri , gelecekte , vaat , gecikme ve ertelenmiş için kullanılan yapılara bakın senkronize programı yürütme bazılarında eşzamanlı programlama dilleri . Genellikle değerinin hesaplanması henüz tamamlanmadığından , başlangıçta bilinmeyen bir sonuç için vekil görevi gören bir nesneyi tanımlarlar .

Terimi söz tarafından 1976 yılında önerilmiştir Daniel P. Friedman ve David Wise, ve Peter Hibbard denir nihai . Biraz benzer bir gelecek kavramı 1977'de Henry Baker ve Carl Hewitt'in bir makalesinde tanıtıldı .

Terimler gelecek , vaat , gecikme ve ertelenmiş arasındaki kullanımında bazı farklılıklara rağmen sıklıkla birbirinin yerine kullanılır gelecek ve ümit vermektedir aşağıda davranılır. Spesifik olarak, kullanım ayırt edildiğinde, bir gelecek, bir değişkenin salt okunur bir yer tutucu görünümü iken, bir söz, geleceğin değerini belirleyen yazılabilir, tek bir atama kabıdır. Özellikle, bir gelecek, hangi belirli vaadin değerini belirleyeceğini belirtmeden tanımlanabilir ve farklı olası vaatler belirli bir geleceğin değerini belirleyebilir, ancak bu belirli bir gelecek için yalnızca bir kez yapılabilir. Diğer durumlarda, bir gelecek ve bir vaat birlikte yaratılır ve birbiriyle ilişkilendirilir: gelecek değerdir, vaat değeri belirleyen işlevdir - esasen eşzamansız bir işlevin (söz) dönüş değeri (gelecek). Bir geleceğin değerini belirlemek , onu çözme , yerine getirme veya bağlama olarak da adlandırılır .

Uygulamalar

Gelecekler ve vaatler, bir değeri (bir gelecek) nasıl hesaplandığından (bir vaat) ayırmak için işlevsel programlama ve ilgili paradigmalardan ( mantık programlaması gibi ) kaynaklandı ve hesaplamanın özellikle paralel hale getirilerek daha esnek bir şekilde yapılmasına izin verdi. Daha sonra, dağıtılmış bilgi işlemde , iletişim gidiş dönüşlerinden kaynaklanan gecikmeyi azaltmada kullanım buldu . Daha sonraları, sürekli-geçen stilden ziyade asenkron programların doğrudan stilde yazılmasına izin vererek daha fazla kullanım kazandı .

Örtük vs açık

Vadeli kullanımı olabilir örtülü (bir sıradan gibi gelecek herhangi bir şekilde kullanılması otomatik değerini elde referans ) ya da açık (el gibi değerinin elde edilmesi için bir işlevi çağırmak zorundadır getmetodu java.util.concurrent.Futureolarak Java ). Açık bir geleceğin değerini elde etmek, sokmak veya zorlamak olarak adlandırılabilir . Açık vadeli işlemler bir kitaplık olarak uygulanabilirken, kapalı vadeli işlemler genellikle dilin bir parçası olarak uygulanır.

Orijinal Baker ve Hewitt makalesi , hesaplamanın aktör modelinde ve Smalltalk gibi saf nesne yönelimli programlama dillerinde doğal olarak desteklenen örtük gelecekleri tanımladı . Friedman ve Wise makalesi yalnızca açık vadeli işlemleri tanımladı ve muhtemelen stok donanım üzerinde örtük vadeli işlemleri verimli bir şekilde uygulamanın zorluğunu yansıttı. Zorluk, stok donanımının tamsayılar gibi ilkel veri türleri için vadeli işlemlerle ilgilenmemesidir. Örneğin, bir ekleme talimatı ile nasıl başa çıkılacağını bilmiyor . Saf aktör veya nesne dillerinde bu sorun , geleceğin kendisine eklemesini ve sonucu döndürmesini isteyen mesajı göndererek çözülebilir . Mesaj iletme yaklaşımının, hesaplamanın ne zaman bittiğine bakılmaksızın çalıştığını ve hiçbir zorlama/zorlama gerekmediğini unutmayın. 3 + future factorial(100000)future factorial(100000)+[3]3factorial(100000)

Söz boru hattı

Vadeli kullanımı dramatik azaltabilir gecikme içinde dağıtılmış sistemlerde . Örneğin, gelecekler , Argus dilinde çağrı akışı olarak da adlandırılan E ve Joule dillerinde uygulandığı gibi söz ardışık düzenini etkinleştirir .

Aşağıdakiler gibi geleneksel uzaktan yordam çağrılarını içeren bir ifade düşünün : 

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

hangi genişletilebilir 

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

Her ifadenin, bir sonraki ifadenin devam edebilmesi için gönderilmesi için bir mesaja ve bir yanıtın alınmasına ihtiyacı vardır. Örneğin, x, y, t1, ve t2öğelerinin aynı uzak makinede bulunduğunu varsayalım . Bu durumda, üçüncü ifadenin yürütülmeye başlayabilmesi için o makineye iki tam ağ gidiş dönüşünün gerçekleşmesi gerekir. Üçüncü ifade daha sonra aynı uzak makineye başka bir gidiş dönüşe neden olur.

Futures kullanılarak yukarıdaki ifade yazılabilir. 

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

hangi genişletilebilir 

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

Burada kullanılan sözdizimi x <- a(), mesajı a()eşzamansız olarak göndermek anlamına gelen E dilinin sözdizimidir x. Her üç değişkene de sonuçları için hemen vadeli işlemler atanır ve yürütme sonraki ifadelere ilerler. Daha sonra değerini çözme girişimleri t3gecikmeye neden olabilir; ancak, ardışık düzen, gereken gidiş-dönüş sayısını azaltabilir. Önceki örnekte olduğu gibi, x, y, t1, ve t2öğelerinin tümü aynı uzak makinede bulunuyorsa, ardışık düzendeki bir uygulama t3üç yerine bir gidiş dönüşle hesaplayabilir . Üç mesajın tümü aynı uzak makinede bulunan nesnelere yönelik olduğundan, yalnızca bir istek gönderilmesi ve sonucu içeren yalnızca bir yanıt alınması gerekir. Gönderme , farklı makinelerde t1 <- c(t2)olsa t1ve olsa bile engellenmez t2veya xveya y.

Promise ardışık düzen, paralel asenkron ileti geçişinden ayırt edilmelidir. Borulama özelliğini değil paralel mesajı geçmesini destekleyen bir sistemde ancak, mesaj gönderir x <- a()ve y <- b()yukarıdaki örnekte paralel olarak devam olabilir, ama bir gönderme t1 <- c(t2)hem kadar beklemek zorunda kalacak t1ve t2hatta, zaman alınan olmuştu x, y, t1ve t2vardır aynı uzaktan makine. Ardışık düzenin göreli gecikme avantajı, birçok iletiyi içeren daha karmaşık durumlarda daha da artar.

Promise ardışık düzen aynı zamanda , bir aktörün mevcut mesajın işlenmesini tamamlamadan bir sonraki mesaj için bir davranış belirlemesinin ve yürütmeye başlamasının mümkün olduğu, aktör sistemlerinde ardışık mesaj işleme ile karıştırılmamalıdır .

Salt okunur görünümler

Oz , E ve AmbientTalk gibi bazı programlama dillerinde , geleceğin salt okunur bir görünümünü elde etmek mümkündür; bu, çözümlendiğinde değerinin okunmasına izin verir, ancak çözülmesine izin vermez:

  • Oz'da !!operatör salt okunur bir görünüm elde etmek için kullanılır.
  • E ve AmbientTalk'ta gelecek, söz/çözücü çifti adı verilen bir çift değerle temsil edilir . Söz, salt okunur görünümü temsil eder ve geleceğin değerini ayarlamak için çözümleyiciye ihtiyaç vardır.
  • Gelen C ++ 11 bir std::futuresalt okunur bir görünüm sağlar. Değer doğrudan a kullanılarak std::promiseayarlanır std::packaged_taskveya veya kullanılarak bir işlev çağrısının sonucuna ayarlanır std::async.
  • Gelen Dojo Toolkit sürüm 1.5 itibariyle sitesindeki Ertelenmiş API, bir tüketici, sadece bir amacı söz salt okunur bir görünüşünü temsil eder.
  • In Alice ML , vadeli bir sağlamak salt okunur görünümü bir söz bir gelecek ve geleceği çözümlemek için yeteneği hem de içerir oysa
  • In .NET Framework 4.0 System.Threading.Tasks.Task<T> salt okunur bir görünüşünü temsil eder. Değerin çözümlenmesi yoluyla yapılabilir System.Threading.Tasks.TaskCompletionSource<T>.

Salt okunur görünümler için destek , en az ayrıcalık ilkesiyle tutarlıdır , çünkü değeri ayarlama yeteneğinin, onu ayarlaması gereken konularla sınırlandırılmasını sağlar . Ardışık düzeni de destekleyen bir sistemde, zaman uyumsuz bir iletinin (sonuçla birlikte) göndericisi, sonuç için salt okunur taahhüdü alır ve iletinin hedefi çözümleyiciyi alır.

Konuya özel gelecekler

Alice ML gibi bazı diller, geleceğin değerini hesaplayan belirli bir iş parçacığıyla ilişkili gelecekleri tanımlar. Bu hesaplama , gelecek yaratıldığında hevesle veya değerine ilk ihtiyaç duyulduğunda tembelce başlayabilir . Tembel bir gelecek, gecikmeli bir hesaplama anlamında bir thunk'a benzer .

Alice ML ayrıca herhangi bir iş parçacığı tarafından çözülebilen vadeli işlemleri destekler ve bu vaatleri çağırır . Bu kullanımı söz tarif edildiği gibi E kullanımı farklıdır , yukarıda . Alice'de bir söz salt okunur bir görünüm değildir ve söz ardışık düzeni desteklenmez. Bunun yerine, vaatlerle ilişkili olanlar da dahil olmak üzere gelecekler için doğal olarak ardışık düzen oluşur.

Engelleme ve engelleyici olmayan anlambilim

Bir geleceğin değerine asenkron olarak erişilirse, örneğin ona bir mesaj gönderilerek veya whenE'deki gibi bir yapı kullanılarak açıkça beklenerek , o zaman, mesaj çözülmeden önce geleceğin çözülmesini geciktirmekte hiçbir zorluk yoktur. alındı ​​veya bekleme tamamlandı. Saf aktör dilleri gibi tamamen asenkron sistemlerde dikkate alınması gereken tek durum budur.

Ancak bazı sistemlerde bir geleceğin değerine anında veya eşzamanlı olarak erişmeye çalışmak da mümkün olabilir . Sonra yapılacak bir tasarım seçimi var:

  • erişim, gelecek çözümlenene kadar (muhtemelen bir zaman aşımıyla) mevcut iş parçacığını veya işlemi engelleyebilir. Bu, Oz dilindeki veri akışı değişkenlerinin anlamıdır .
  • denenen eşzamanlı erişim her zaman bir hata sinyali verebilir, örneğin bir istisna atmak . Bu, E'deki uzak vaatlerin semantiğidir.
  • potansiyel olarak, gelecek zaten çözülmüşse erişim başarılı olabilir, ancak çözülmediyse bir hata sinyali verir. Bu, nondeterminizm ve yarış koşulları için potansiyel getirme dezavantajına sahip olacaktır ve sıra dışı bir tasarım seçimi gibi görünmektedir.

İlk olasılığa örnek olarak, C++11'de geleceğin değerine ihtiyaç duyan bir iş parçacığı wait()veya get()üye işlevleri çağrılarak kullanılabilir olana kadar engellenebilir . Belirsiz engellemeyi önlemek için wait_for()veya wait_until()üye işlevlerini kullanarak beklemede bir zaman aşımı da belirleyebilirsiniz . Gelecek, bir çağrıdan kaynaklanıyorsa, std::asyncbloke edici bir bekleme (zaman aşımı olmadan), bekleyen iş parçacığındaki sonucu hesaplamak için işlevin senkronize çağrılmasına neden olabilir.

İlgili yapılar

Future , yalnızca bir kez tamamlanabilen belirli bir Event (senkronizasyon ilkel) durumudur . Genel olarak, olaylar ilk boş durumuna sıfırlanabilir ve böylece istediğiniz kadar tamamlanabilir.

Bir I-var ( Id dilinde olduğu gibi ), yukarıda tanımlandığı gibi bloklama semantiğine sahip bir gelecek. Bir I-yapı a, veri yapısı içeren, I-değişkenler. Farklı değerlerle birden çok kez ayarlanabilen ilgili bir senkronizasyon yapısına M-var adı verilir . M-vars , mevcut değeri almak veya koymak için atomik işlemleri destekler ; burada değer almak aynı zamanda M-var'ı ilk boş durumuna geri döndürür.

Bir eşzamanlı mantık değişken bir geleceğe benzer, ancak tarafından güncellenen birleşmesi ile aynı şekilde, mantık değişkenleri de mantık programlama . Bu nedenle, birleştirilebilir değerlere birden fazla kez bağlanabilir, ancak boş veya çözülmemiş bir duruma geri döndürülemez. Oz'un veri akışı değişkenleri, eşzamanlı mantık değişkenleri olarak hareket eder ve ayrıca yukarıda bahsedildiği gibi bloklama semantiğine sahiptir.

Bir eşzamanlı kısıt değişken eşzamanlı mantık değişkenlerin bir genelleme desteklemektir kısıtlama mantık programlama : kısıt olabilir daralmış olası değerler daha küçük setleri gösteren birden çok kez. Tipik olarak, kısıtlama daha da daraltıldığında çalışması gereken bir thunk belirtmenin bir yolu vardır; bu kısıtlama yayılımını desteklemek için gereklidir .

Geleceğin farklı biçimlerinin dışavurumculuğu arasındaki ilişkiler

Hevesli iş parçacığına özgü gelecekler, geleceği yaratırken aynı zamanda değeri hesaplamak için bir iş parçacığı oluşturarak, iş parçacığına özel olmayan geleceklerde doğrudan uygulanabilir. Bu durumda, istemciye salt okunur bir görünüm döndürmek istenir, böylece yalnızca yeni oluşturulan iş parçacığı bu geleceği çözebilir.

Örtük tembel iş parçacığına özgü gelecekleri (örneğin, Alice ML tarafından sağlanan) iş parçacığına özgü olmayan gelecekler açısından uygulamak için, geleceğin değerine ilk ne zaman ihtiyaç duyulacağını (örneğin, WaitNeededOz'daki yapı) belirlemek için bir mekanizmaya ihtiyaç vardır . Tüm değerler nesne ise, ileticiye gönderilen ilk mesaj geleceğin değerine ihtiyaç olduğunu gösterdiğinden, şeffaf iletme nesnelerini uygulama yeteneği yeterlidir.

Konuya özgü olmayan gelecekler, çözümleme iş parçacığının geleceğin kendi iş parçacığına bir mesaj göndermesini sağlayarak, sistemin mesaj geçişini desteklediğini varsayarak, iş parçacığına özel geleceklerde uygulanabilir. Ancak, bu gereksiz karmaşıklık olarak görülebilir. İş parçacıklarına dayalı programlama dillerinde, en etkileyici yaklaşım, iş parçacığına özgü olmayan gelecekler, salt okunur görünümler ve bir WaitNeeded yapısı veya şeffaf iletme desteğinin bir karışımını sağlamak gibi görünmektedir .

Değerlendirme stratejisi

Daha fazla bilgi: Geleceğe göre arayın

Değerlendirme stratejisi olarak adlandırılabilir geleceklerin, geleceğe çağrıyı , belirli olmayan geçerli: bir gelecek değer gelecek oluşturulduğunda ve değeri kullanıldığında arasındaki bir zamanda değerlendirilecektir fakat kesin zaman belli değil önceden ve çalıştırmadan çalıştırmaya değişebilir. Hesaplama, gelecek oluşturulur oluşturulmaz ( istekli değerlendirme ) veya yalnızca değere gerçekten ihtiyaç duyulduğunda ( tembel değerlendirme ) başlayabilir ve yarı yolda askıya alınabilir veya tek seferde yürütülebilir. Bir geleceğin değeri atandıktan sonra, gelecekteki erişimlerde yeniden hesaplanmaz; bu, call by ihtiyaçta kullanılan nota benzer .

A tembel gelecek , deterministik olarak tembel değerlendirme semantiğine sahip bir gelecek: geleceğin değerinin hesaplanması, call by need'da olduğu gibi, değere ilk ihtiyaç duyulduğunda başlar. Tembel vadeli işlemler, değerlendirme stratejisinin varsayılan olarak tembel olmadığı dillerde kullanılır. Örneğin,C++ 11'de, değeri hesaplama işleviyle birliktestd::launch::deferredbaşlatma ilkesiniileterek bu tür tembel vadeli işlemler oluşturulabilirstd::async.

Aktör modelinde geleceklerin semantiği

Aktör modelinde, formun bir ifadesi, E ortamı ve müşteri C ile future <Expression>bir Evalmesaja nasıl yanıt verdiğine göre aşağıdaki gibi tanımlanır: Gelecekteki ifade , müşteri C'ye yeni oluşturulan bir aktör F'yi (vekil için proxy) göndererek mesaja yanıt verir . değerlendirme yanıtı ) E ortamı ve müşteri C ile bir mesaj gönderme ile aynı anda bir dönüş değeri olarak . F'nin varsayılan davranışı aşağıdaki gibidir: Eval<Expression><Expression>Eval

  • Tüm F bir talep aldığında Ar daha önce değerlendirme ile (ya bir geri dönüş değeri ya da atılmış bir durum olabilir) bir yanıt varsa, o zaman kontrol eder <Expression>şu şekilde geçmeden:
    1. Zaten bir yanıtı varsa V , o zaman
      • Eğer V , bir geri dönüş değeri, o zaman talep gönderilir R .
      • Eğer V bir istisnadır, o zaman istek ve müşteriye atılır Ar .
    2. Zaten bir yanıtı yoksa, R , F içindeki istekler sırasında saklanır .
  • Tüm F yanıtı alır V değerlendirme ile <Expression>, daha sonra V depolanan F ve
    • Eğer V bir dönüş değeri, sonra bütün sıraya isteklerin gönderilir V .
    • Eğer V bir istisnadır, o zaman sıraya istekleri her birinin müşteriye atılır.

Bununla birlikte, bazı vadeli işlemler, daha fazla paralellik sağlamak için talepleri özel yollarla ele alabilir. Örneğin, ifade 1 + future factorial(n), sayı gibi davranacak yeni bir gelecek yaratabilir 1+factorial(n). Bu hile her zaman işe yaramaz. Örneğin, aşağıdaki koşullu ifade:

if m>future factorial(n) then print("bigger") else print("smaller")

geleceği için askıya alınıp alınmadığını factorial(n)soran talebe mkendisinden büyük olup olmadığını sorar .

Tarih

Gelecekteki ve / veya söz yapılar bu tür ilk olarak programlama dillerinde uygulanmıştır MultiLisp ve Kanunun 1 . Eşzamanlı mantık programlama dillerinde iletişim için mantık değişkenlerinin kullanımı, geleceklere oldukça benziyordu. Bunlar Prolog'da Freeze ve IC Prolog ile başladı ve Relational Language, Concurrent Prolog , guarded Horn cümlecikleri (GHC), Parlog , Strand , Vulcan , Janus , Oz-Mozart , Flow Java ve Alice ML ile gerçek bir eşzamanlılık ilkeli oldu . Tek atama I-var gelen veri akışı programlama dilleri, orjinli Id ve Reppy en dahil Eşzamanlı ML , çok eşzamanlı mantık değişkeni gibidir.

Vaat ardışık düzen tekniği (gecikmenin üstesinden gelmek için gelecekleri kullanarak), 1988'de Barbara Liskov ve Liuba Shrira tarafından ve 1989 dolaylarında Xanadu Projesi bağlamında bağımsız olarak Mark S. Miller , Dean Tribble ve Rob Jellinghaus tarafından icat edildi .

Terimi söz bunların isim tarafından ardışık düzen mekanizmasına atıfta rağmen, Liskov ve Shrira tarafından ortaya konmuştur çağrı-stream artık nadiren kullanılır.

Hem Liskov hem de Shrira'nın makalesinde açıklanan tasarım ve Xanadu'da söz ardışık düzeninin uygulanması, vaat değerlerinin birinci sınıf olmadığı sınırına sahipti : bir argüman veya bir çağrı veya gönderme tarafından döndürülen değer doğrudan bir söz olamaz (bu nedenle, daha önce verilen, bir gönderimin sonucu için bir diğerine argüman olarak bir söz kullanan söz ardışık düzeni örneği, çağrı akışı tasarımında veya Xanadu uygulamasında doğrudan ifade edilemezdi). Görünüşe göre sözler ve çağrı akışları, Liskov ve Shrira gazetesinde kullanılan programlama dili olan Argus'un herhangi bir kamuya açık yayınında asla uygulanmadı. Argus geliştirmesi 1988'de durdu. Xanadu'nun vaat edilen ardışık düzen uygulaması, 1999'da Udanax Gold'un kaynak kodunun yayınlanmasıyla birlikte kamuya açık hale geldi ve hiçbir yayınlanmış belgede açıklanmadı. Joule ve E'deki sonraki uygulamalar, tamamen birinci sınıf vaatleri ve çözümleyicileri destekler.

Act serisi de dahil olmak üzere birçok erken aktör dili, hem paralel ileti geçişini hem de ardışık düzen ileti işlemeyi destekledi, ancak ardışık düzen sağlama sözü vermedi. (Bu özelliklerin sonuncusunu ilk ikisinde uygulamak teknik olarak mümkün olsa da, Act dillerinin bunu yaptığına dair bir kanıt yoktur.)

2000 yılından sonra, futures ve vaatler ilgi büyük canlanma nedeniyle kullanımları ile oluştu yanıt kullanıcı arayüzlerinin ve içinde web geliştirme nedeniyle, istek-yanıt ileti geçişi modeline. Birçok ana dilde artık gelecekler ve vaatler için dil desteği var, bunların en önemlisi FutureTaskJava 5'te (2004 duyurulmuştu) ve .NET 4.5'te (2010'da duyurulmuştu, 2012'de yayınlanmıştı) büyük ölçüde F#' ın eşzamansız iş akışlarından esinlenen async/await yapıları tarafından popüler hale getirilmiştir. Bu daha sonra diğer diller, özellikle Dart (2014), Python (2015), Hack (HHVM) ve ECMAScript 7 (JavaScript), Scala ve C++ taslakları tarafından benimsenmiştir.

Uygulamaların listesi

Bazı programlama dilleri, doğrudan dil desteği veya standart kitaplıkta gelecekleri, vaatleri, eşzamanlı mantık değişkenlerini, veri akışı değişkenlerini veya I değişkenlerini destekler.

Programlama diline göre gelecek ve vaatlerle ilgili kavramların listesi

Söz ardışık düzenini de destekleyen diller şunları içerir:

Geleceklerin standart olmayan, kütüphane tabanlı uygulamalarının listesi

  • For Common Lisp :
    • kara kuş
    • hevesli gelecek2
    • paralel
    • PCall
  • C++ için:
  • İçin C # ve diğer .NET : diller Paralel Uzantıları kütüphanesinde
  • For Groovy : GPars
  • For JavaScript :
  • İçin Java :
    • JDeferred, ertelenmiş söz API'si ve JQuery .Deferred nesnesine benzer davranış sağlar
    • ParSeq, LinkedIn tarafından sağlanan asenkron boru hattı ve dallandırma için ideal olan görev vaadi API'sini sağlar
  • İçin Lua :
    • Sıralar [1] modülü bir Promise API içerir.
  • İçin Objective-C : MAFuture, RXPromise, objc-CollapsingFutures, PromiseKit, objc-söz, OAPromise,
  • İçin OCaml Tembel modül uygular tembel açık gelecekleri:
  • İçin Perl Future, Promises, Refleks, Promise :: ES6 ve Promise :: XS:
  • For PHP : Tepki / Promise
  • İçin Python :
    • Yerleşik uygulama
    • pitonfutürler
    • Twisted'ın Ertelenenleri
  • İçin R :
    • gelecek, tembel ve istekli zaman uyumlu ve (çok çekirdekli veya dağıtılmış) zaman uyumsuz vadeli işlemlerle genişletilebilir bir gelecek API'si uygular
  • İçin Ruby :
    • söz mücevher
    • libuv gem, vaatlerini yerine getirir
    • Selüloit mücevher, vadeli işlemleri uygular
    • gelecek-kaynak
  • İçin Rust :
    • vadeli işlemler
  • İçin Scala :
    • Twitter'ın kullanım kütüphanesi
  • İçin Swift :
    • Zaman uyumsuz çerçeve, C# stilini uygular async/engellemezawait
    • FutureKit, Apple GCD için bir sürüm uygular
    • FutureLib, Scala tarzı vadeli işlemler uygulayan saf Swift 2 kitaplığı ve TPL tarzı iptal ile vaatler
    • OCaml's Deferred'den ilham alan ertelenmiş, saf Swift kitaplığı
    • BrightFutures
    • SwiftCooutine
  • İçin Tcl tcl-vaadi:

eşyordamlar

Vadeli uygulanabilir değiş tokuş eden kavramlar veya jeneratörler aynı değerlendirme stratejisi (örneğin, ortak çoklu görev veya yavaş değerlendirme) ile sonuçlanır.

Kanallar

Ana madde: Kanal (programlama)

Vadeli işlemler kanallarda kolayca uygulanabilir : gelecek tek öğeli bir kanaldır ve vaat, kanala gönderen ve geleceği gerçekleştiren bir süreçtir. Bu, geleceklerin CSP ve Go gibi kanalları destekleyen eşzamanlı programlama dillerinde uygulanmasına olanak tanır . Ortaya çıkan gelecekler, yalnızca değerlendirmeden ziyade kanaldan okunarak erişilmesi gerektiği için açıktır.

Ayrıca bakınız

Referanslar

Dış bağlantılar