फ़्यूचर्स और प्रोमिस

कंप्यूटर विज्ञान में, फ़्यूचर्स, प्रोमिस, विलम्ब, और स्थगित कुछ समवर्ती प्रोग्रामिंग भाषाओं में तुल्यकालिक (कंप्यूटर विज्ञान) प्रोग्राम निष्पादन (कंप्यूटिंग) के लिए उपयोग किए जाने वाले निर्माणों को संदर्भित करता है। वे ऐसी वस्तु का वर्णन करते हैं जो परिणाम के लिए प्रॉक्सी के रूप में कार्य करती है जो प्रारंभ में अज्ञात है, क्योंकि इसके मान की गणना अभी तक पूरी नहीं हुई है।

प्रोमिस शब्द1976 में डेनियल पी. फ्रीडमैन और डेविड वाइज द्वारा प्रस्तावित किया गया था, और पीटर हिब्बार्ड ने इसे अंतिम बताया था। कुछ इसी तरह की अवधारणा फ़्यूचर्स को 1977 में हेनरी बेकर (कंप्यूटर वैज्ञानिक) और कार्ल हेविट द्वारा पेपर में पेश किया गया था।

फ़्यूचर्स, प्रोमिस, विलम्ब, और स्थगित शब्द अक्सर एक दूसरे के स्थान पर उपयोग किए जाते हैं, हालांकि फ़्यूचर्स और प्रोमिस के बीच उपयोग में कुछ अंतर नीचे दिए गए हैं। विशेष रूप से, जब उपयोग को अलग किया जाता है, तो फ़्यूचर्स चर का रीड-ओनली प्लेसहोल्डर दृश्य होता है, जबकि प्रोमिस लिखने योग्य, एकल असाइनमेंट कंटेनर होता है जो फ़्यूचर्स के मान को निर्धारित करता है। विशेष रूप से, फ़्यूचर्स को यह निर्दिष्ट किए बिना परिभाषित किया जा सकता है कि कौन सा विशिष्ट प्रोमिस अपना मान निर्धारित करेगा, और विभिन्न संभावित प्रोमिस किसी दिए गए फ़्यूचर्स का मान निर्धारित कर सकते हैं, हालांकि यह किसी दिए गए फ़्यूचर्स के लिए केवल एक बार किया जा सकता है। अन्य मामलों में फ़्यूचर्स और प्रोमिस एक साथ बनाया जाता है और एक दूसरे से जुड़ा होता है: फ़्यूचर्स मान है, प्रोमिस वह कार्य है जो मान निर्धारित करता है - अनिवार्य रूप से अतुल्यकालिक फ़ंक्शन (प्रोमिस) का वापसी मान (फ़्यूचर्स) है। किसी फ़्यूचर्स के मान को निर्धारित करना उसे विभेदन, पूरा करना या बाइंडिंग भी कहा जाता है।

अनुप्रयोग
फ़्यूचर्स और प्रोमिस कार्यात्मक प्रोग्रामिंग और संबंधित प्रतिमानों (जैसे तर्क प्रोग्रामिंग) में मान (एक फ़्यूचर्स) की गणना की गई थी ( प्रोमिस) से अलग करने के लिए, गणना को अधिक नम्य ढंग से करने की विशेष रूप से इसे समानांतर करके अनुमति देता है। बाद में, संचार राउंड ट्रिप से विलंबता को कम करने में, वितरित कंप्यूटिंग में इसका उपयोग पाया गया है। बाद में भी, निरंतरता-गुजरना वाली शैली के बजाय प्रत्यक्ष शैली में अतुल्यकालिक कार्यक्रमों को लिखने की अनुमति देकर इसे और अधिक उपयोग प्राप्त हुआ है।

अंतर्निहित बनाम स्पष्ट
फ़्यूचर्स का उपयोग अंतर्निहित हो सकता है (फ़्यूचर्स का कोई भी उपयोग स्वचालित रूप से अपना मान प्राप्त करता है, जैसे कि यह सामान्य निर्देश (प्रोग्रामिंग) था) या स्पष्ट (उपयोगकर्ता को मान प्राप्त करने के लिए फ़ंक्शन को कॉल निर्देश, जैसे कि  उसकि विधि  जावा (प्रोग्रामिंग भाषा) में)। स्पष्ट फ़्यूचर्स के मान को प्राप्त करना स्टिंगिंग या प्रेरक कहा जाता है। स्पष्ट फ़्यूचर्स को लाइब्रेरी के रूप में लागू किया जा सकता है, जबकि अंतर्निहित फ़्यूचर्स आमतौर पर भाषा के हिस्से के रूप में लागू किया जाता है।

मूल बेकर और हेविट पेपर में निहित फ़्यूचर्स का वर्णन किया गया है, जो स्वाभाविक रूप से अभिकलन के कर्ता मॉडल और स्मॉलटाक जैसी स्पष्ट ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग भाषाओं में समर्थित हैं। फ्रीडमैन एंड वाइज पेपर केवल स्पष्ट फ़्यूचर्स का वर्णन करता है, संभवतः स्टॉक हार्डवेयर पर निहित फ़्यूचर्स को कुशलता से लागू करने की कठिनाई को दर्शाता है। कठिनाई यह है कि स्टॉक हार्डवेयर आदिम डेटा प्रकारों जैसे पूर्णांकों के लिए फ़्यूचर्स से डील नहीं करता है। उदाहरण के लिए, ऐड इंस्ट्रक्शन को पता नहीं है कि कैसे डील करना है  स्पष्ट कर्ता या वस्तु भाषाओं में भेजकर इस समस्या को हल किया जा सकता है   संदेश , जो फ़्यूचर्स को जोड़ने के लिए कहता है   स्वयं के लिए और परिणाम वापस करता है। ध्यान दें कि संदेश पासिंग दृष्टिकोण कब की परवाह किए बिना काम करता है   संगणना समाप्त करता है और किसी स्टिंगिंग/प्रेरक की आवश्यकता नहीं होती है।

प्रोमिस पाइपलाइनिंग
वितरित कंप्यूटिंग में फ़्यूचर्स का उपयोग प्रभावशाली रूप से विलंबता (इंजीनियरिंग) को कम कर सकता है। उदाहरण के लिए, फ़्यूचर्स पाइपलाइनिंग को सक्षम करता है, जैसा कि भाषाओं E (प्रोग्रामिंग भाषा) और जूल (प्रोग्रामिंग भाषा) में लागू किया गया था, जिसे आर्गस (प्रोग्रामिंग भाषा) भाषा में कॉल-स्ट्रीम भी कहा जाता था।

पारंपरिक दूरस्थ प्रक्रिया कॉलों से संबंधित अभिव्यक्ति पर विचार करें, जैसे:<पूर्व> t3 := (x.a .c(y.b) जिसे बढ़ाया जा सकता है t 1: = x.a; t 2: = y.b ; t3t:= t1.c(t2); प्रत्येक कथन को भेजे जाने के लिए संदेश की आवश्यकता होती है और अगले कथन के आगे बढ़ने से पहले एक उत्तर प्राप्त होता है। मान लीजिए, उदाहरण के लिए, कि,  ,  , और   सभी एक ही रिमोट मशीन पर स्थित हैं। इस मामले में, उस मशीन के लिए दो पूर्ण नेटवर्क राउंड-ट्रिप होनी चाहिए, इससे पहले कि तीसरा स्टेटमेंट निष्पादित हो सके। तीसरा कथन तब उसी रिमोट मशीन के लिए एक और राउंड-ट्रिप का कारण बनता है।

फ्यूचर्स का उपयोग करके उपरोक्त अभिव्यक्ति लिखी जा सकती है t 3: = (x <- a ) <- c (y <- b ) जिसे बढ़ाया जा सकता है t 1: = x <- a ; t 2: = y <- b ; t3t:= t1 <- c(t2); यहाँ प्रयुक्त वाक्य-विन्यास भाषा E का है, जहाँ  संदेश भेजने का मतलब है   अतुल्यकालिक रूप से. सभी तीन चरों को तुरंत उनके परिणामों के लिए फ़्यूचर्स सौंपा जाता है, और निष्पादन बाद के बयानों के लिए आगे बढ़ता है। बाद के मान को हल करने का प्रयास करता है  विलम्ब हो सकती है; हालाँकि, पाइपलाइनिंग आवश्यक राउंड-ट्रिप की संख्या को कम कर सकती है। यदि, जैसा कि पिछले उदाहरण में है, ,  ,  , और   सभी एक ही रिमोट मशीन पर स्थित हैं, पाइपलाइन कार्यान्वयन गणना   तीन के बजाय एक राउंड-ट्रिप के साथ कर सकता है। क्योंकि सभी तीन संदेश उन वस्तुओं के लिए नियत हैं जो एक ही रिमोट मशीन पर हैं, केवल एक अनुरोध भेजने की आवश्यकता है और परिणाम के साथ केवल एक प्रतिक्रिया प्राप्त करने की आवश्यकता है। भेजना   ब्लॉक भी नहीं करेंगे   और   एक दूसरे के लिए अलग-अलग मशीनों पर थे, या करने के लिए   या

प्रोमिस पाइपलाइनिंग को समानांतर एसिंक्रोनस मैसेज पासिंग से अलग किया जाना चाहिए। समांतर संदेश का समर्थन करने वाली प्रणाली में लेकिन पाइपलाइनिंग नहीं, संदेश भेजता है  और   उपरोक्त उदाहरण में समानांतर में आगे बढ़ सकता है, लेकिन प्रेषण   दोनों तक इंतजार करना होगा   और   प्राप्त किया गया था, तब भी ,  ,  , और   एक ही रिमोट मशीन पर हैं। कई संदेशों को शामिल करने वाली अधिक जटिल स्थितियों में पाइपलाइनिंग का सापेक्ष विलंबता लाभ और भी अधिक हो जाता है।

प्रोमिस पाइपलाइनिंग को कर्ता सिस्टम में पाइपलाइन संदेश प्रसंस्करण के साथ भ्रमित नहीं होना चाहिए, जहां कर्ता के लिए वर्तमान संदेश की प्रक्रिया पूरी करने से पहले अगले संदेश के लिए एक व्यवहार को निर्दिष्ट करना और निष्पादित करना संभव है।

रीड-ओनली विचार
कुछ प्रोग्रामिंग भाषाओं जैसे कि Oz (प्रोग्रामिंग भाषा), E (प्रोग्रामिंग भाषा), और एम्बिएंट टॉक में, फ़्यूचर्स का रीड-ओनली दृश्य प्राप्त करना संभव है, जो हल होने पर इसके मान को पढ़ने की अनुमति देता है, लेकिन इसे हल करने की अनुमति नहीं देता है:


 * Oz में,  ऑपरेटर का उपयोग रीड-ओनली दृश्य प्राप्त करने के लिए किया जाता है।
 * E और एम्बिएंटटॉक में, फ़्यूचर्स को प्रॉमिस/रिज़ॉल्वर जोड़ी कहे जाने वाले मानों के एक जोड़े द्वारा दर्शाया जाता है। प्रोमिस रीड-ओनली दृश्य का प्रतिनिधित्व करता है, और फ़्यूचर्स के मान को निर्धारित करने के लिए रिज़ॉल्वर की आवश्यकता होती है।
 * C ++ 11 में   रीड-ओनली दृश्य प्रदान करता है। मान सीधे    का उपयोग करके सेट किया गया है, या उपयोग करके फ़ंक्शन कॉल के परिणाम पर सेट करें   या.
 * संस्करण 1.5 के रूप में डोजो टूलकिट के डिफर्ड एपीआई में, उपभोक्ता-मात्र प्रोमिस वस्तु रीड-ओनली दृश्य का प्रतिनिधित्व करती है।
 * ऐलिस एमएल में, फ़्यूचर्स रीड-ओनली दृश्य प्रदान करता है, जबकि प्रोमिस में फ़्यूचर्स और फ़्यूचर्स को हल करने की क्षमता दोनों शामिल हैं
 * .NET Framework 4.0 में  रीड-ओनली दृश्य का प्रतिनिधित्व करता है। मान को हल करके किया जा सकता है.

रीड-ओनली दृष्टिकोण के लिए समर्थन कम से कम विशेषाधिकार के सिद्धांत के अनुरूप है, क्योंकि यह मान को सेट करने की क्षमता को विषय (अभिगम नियंत्रण) तक सीमित करने में सक्षम बनाता है जिसे इसे सेट करने की आवश्यकता होती है। ऐसी प्रणाली में जो पाइपलाइनिंग का भी समर्थन करती है, अतुल्यकालिक संदेश (परिणाम के साथ) के प्रेषक को परिणाम के लिए रीड-ओनली प्रोमिस प्राप्त होता है, और संदेश का लक्ष्य रिज़ॉल्वर प्राप्त करता है।

थ्रेड-स्पेसिफिक फ्यूचर्स
ऐलिस एमएल (प्रोग्रामिंग लैंग्वेज) जैसी कुछ भाषाएं, फ्यूचर्स को परिभाषित करती हैं जो विशिष्ट थ्रेड से जुड़े होते हैं जो फ़्यूचर्स के मान की गणना करता है। यह संगणना या तो उत्सुकता से शुरू हो सकती है जब फ़्यूचर्स बनाया जाता है, या शिथिल मूल्यांकन से जब इसके मान की पहली आवश्यकता होती है। विलंबित संगणना के अर्थ में शिथिल फ़्यूचर्स थंक (कार्यात्मक प्रोग्रामिंग) के समान है।

ऐलिस एमएल भी फ़्यूचर्स का समर्थन करता है जिसे किसी भी धागे से हल किया जा सकता है, और इन वादों को कॉल करता है। प्रोमिस का यह उपयोग ई में इसके उपयोग से अलग है जैसा कि #रीड-ओनली दृष्टिकोण में वर्णित है। ऐलिस में, एक प्रोमिस रीड-ओनली दृश्य नहीं है, और प्रोमिस पाइपलाइनिंग असमर्थित है। इसके बजाय, फ़्यूचर्स के लिए पाइपलाइनिंग स्वाभाविक रूप से होती है, जिसमें वादों से जुड़े लोग भी शामिल हैं।

ब्लॉकिंग बनाम नॉन-ब्लॉकिंग शब्दार्थ
यदि फ़्यूचर्स के मान को अतुल्यकालिक रूप से एक्सेस किया जाता है, उदाहरण के लिए इसे एक संदेश भेजकर, या स्पष्ट रूप से इसके निर्माण के लिए प्रतीक्षा करके जैसे कि  ई में, तो संदेश प्राप्त होने या प्रतीक्षा पूरी होने से पहले फ़्यूचर्स को हल करने में विलम्ब करने में कोई कठिनाई नहीं है। विशुद्ध रूप से अतुल्यकालिक प्रणालियों जैसे स्पष्ट कर्ता भाषाओं में माना जाने वाला यह एकमात्र मामला है।

हालांकि, कुछ प्रणालियों में फ़्यूचर्स के मान को तुरंत या समकालिक रूप से एक्सेस करने का प्रयास करना भी संभव हो सकता है। फिर एक डिजाइन विकल्प बनाया जाना है:


 * पहुंच वर्तमान थ्रेड या प्रक्रिया को तब तक अवरुद्ध कर सकती है जब तक कि फ़्यूचर्स हल न हो जाए (संभवतः टाइमआउट के साथ)। यह भाषा ओज़ (प्रोग्रामिंग भाषा) में डेटा प्रवाह चर का शब्दार्थ है।
 * प्रयास की गई सिंक्रोनस एक्सेस हमेशा एक त्रुटि का संकेत दे सकती है, उदाहरण के लिए एक अपवाद फेंकना (कंप्यूटर विज्ञान)। यह ई में दूरस्थ वादों का शब्दार्थ है।
 * संभावित रूप से, यदि फ़्यूचर्स पहले से ही हल हो गया है, तो पहुंच सफल हो सकती है, लेकिन यदि ऐसा नहीं है तो त्रुटि का संकेत मिलता है। यह गैर-निर्धारणवाद और दौड़ की स्थिति की संभावना को पेश करने का नुकसान होगा, और यह एक असामान्य डिजाइन विकल्प प्रतीत होता है।

पहली संभावना के उदाहरण के रूप में, सी ++ 11 में, एक थ्रेड जिसे फ़्यूचर्स के मान की आवश्यकता होती है, तब तक ब्लॉक कर सकता है जब तक कि यह कॉल करके उपलब्ध न हो  या   सदस्य कार्य। आप का उपयोग करके प्रतीक्षा पर टाइमआउट भी निर्दिष्ट कर सकते हैं   या   सदस्य कार्य अनिश्चितकालीन अवरोधन से बचने के लिए। अगर फ़्यूचर्स एक कॉल से उत्पन्न हुआ   तो एक अवरुद्ध प्रतीक्षा (बिना टाइमआउट के) प्रतीक्षा थ्रेड पर परिणाम की गणना करने के लिए फ़ंक्शन के सिंक्रोनस आमंत्रण का कारण बन सकती है।

संबंधित निर्माण
फ्यूचर्स तुल्यकालन आदिम इवेंट (तुल्यकालिक प्रिमिटिव) का एक विशेष मामला है, जिसे केवल एक बार पूरा किया जा सकता है। सामान्य तौर पर, घटनाओं को प्रारंभिक खाली स्थिति में रीसेट किया जा सकता है और इस प्रकार, आप जितनी बार चाहें उतनी बार पूरा कर सकते हैं। एक I-var (जैसा कि भाषा Id (प्रोग्रामिंग भाषा) में है) एक फ़्यूचर्स है जो ऊपर परिभाषित शब्दार्थ को अवरुद्ध करता है। I- संरचना एक डेटा संरचना है जिसमें I-var होते हैं। एक संबंधित तुल्यकालन निर्माण जिसे विभिन्न मानों के साथ कई बार सेट किया जा सकता है, उसे M-var कहा जाता है। M-vars वर्तमान मान को लेने या रखने के लिए परमाणु संचालन का समर्थन करते हैं, जहाँ मान लेने से M-var वापस अपनी प्रारंभिक खाली स्थिति में सेट हो जाता है। एक समवर्ती तर्क चर फ़्यूचर्स के समान है, लेकिन एकीकरण (कंप्यूटिंग) द्वारा अद्यतन किया जाता है, उसी तरह तर्क प्रोग्रामिंग में तर्क चर के रूप में। इस प्रकार इसे एक से अधिक बार अविवेकी मूल्यों के लिए बाध्य किया जा सकता है, लेकिन एक खाली या अनसुलझे स्थिति में वापस सेट नहीं किया जा सकता है। ओज़ के डेटाफ्लो चर समवर्ती तर्क चर के रूप में कार्य करते हैं, और उपरोक्त वर्णित शब्दार्थों को अवरुद्ध भी करते हैं।

एक समवर्ती बाधा चर, बाधा तर्क प्रोग्रामिंग का समर्थन करने के लिए समवर्ती तर्क चर का सामान्यीकरण है: बाधा को कई बार संकुचित किया जा सकता है, जो संभावित मूल्यों के छोटे सेट का संकेत देता है। आम तौर पर एक थंक निर्दिष्ट करने का एक तरीका होता है जो तब चलना चाहिए जब भी बाधा आगे संकुचित हो; बाधा प्रचार का समर्थन करने के लिए इसकी आवश्यकता है।

फ़्यूचर्स के विभिन्न रूपों की अभिव्यक्ति के बीच संबंध
उत्सुक थ्रेड-विशिष्ट फ्यूचर्स को गैर-थ्रेड-विशिष्ट फ्यूचर्स में सीधे लागू किया जा सकता है, फ़्यूचर्स बनाने के साथ ही मान की गणना करने के लिए थ्रेड बनाकर। इस मामले में क्लाइंट को रीड-ओनली दृश्य वापस करना वांछनीय है, ताकि केवल नव निर्मित धागा इस फ़्यूचर्स को हल करने में सक्षम हो।

गैर-थ्रेड-विशिष्ट फ़्यूचर्स के संदर्भ में अंतर्निहित शिथिल थ्रेड-विशिष्ट फ़्यूचर्स (उदाहरण के लिए ऐलिस एमएल द्वारा प्रदान किया गया) को लागू करने के लिए, यह निर्धारित करने के लिए एक तंत्र की आवश्यकता होती है कि फ़्यूचर्स के मान की पहली आवश्यकता कब है (उदाहरण के लिए,  Oz में निर्माण ). यदि सभी मान वस्तुएं हैं, तो पारदर्शी अग्रेषण वस्तुओं को लागू करने की क्षमता पर्याप्त है, क्योंकि फारवर्डर को भेजा गया पहला संदेश इंगित करता है कि फ़्यूचर्स के मान की आवश्यकता है।

गैर-थ्रेड-विशिष्ट फ़्यूचर्स को थ्रेड-विशिष्ट फ़्यूचर्स में लागू किया जा सकता है, यह मानते हुए कि सिस्टम संदेश पासिंग का समर्थन करता है, हल करने वाले थ्रेड को फ़्यूचर्स के अपने थ्रेड पर एक संदेश भेजकर। हालाँकि, इसे अनावश्यक जटिलता के रूप में देखा जा सकता है। थ्रेड्स पर आधारित प्रोग्रामिंग भाषाओं में, सबसे अभिव्यंजक दृष्टिकोण गैर-थ्रेड-विशिष्ट फ़्यूचर्स, रीड-ओनली व्यूज़, और या तो एक प्रतीक्षारत निर्माण, या पारदर्शी अग्रेषण के लिए समर्थन प्रदान करने के लिए प्रतीत होता है।

मूल्यांकन रणनीति
फ़्यूचर्स की मूल्यांकन रणनीति, जिसे फ़्यूचर्स की कॉल कहा जा सकता है, गैर-नियतात्मक है: फ़्यूचर्स के मान का मूल्यांकन फ़्यूचर्स के निर्माण और उसके मान के उपयोग के बीच कुछ समय में किया जाएगा, लेकिन सटीक समय निर्धारित नहीं किया गया है पहले से और रन से रन में बदल सकते हैं। जैसे ही फ़्यूचर्स बनाया जाता है (उत्सुक मूल्यांकन) या केवल जब मान वास्तव में आवश्यक होता है (शिथिल मूल्यांकन) के रूप में गणना शुरू हो सकती है, और एक रन में आंशिक रूप से निलंबित या निष्पादित किया जा सकता है। एक बार फ़्यूचर्स का मान असाइन किए जाने के बाद, फ़्यूचर्स की पहुंच पर इसकी पुन: गणना नहीं की जाती है; यह जरूरत से बुलाओ में उपयोग किए जाने वाले memoization की तरह है।

ए ' एक ऐसा फ़्यूचर्स है जो नियतात्मक रूप से शिथिल मूल्यांकन शब्दार्थ है: फ़्यूचर्स के मान की गणना तब शुरू होती है जब मान की पहली आवश्यकता होती है, जैसा कि जरूरत से कॉल में होता है। शिथिल फ़्यूचर्स उन भाषाओं में उपयोग किया जाता है जिनकी मूल्यांकन रणनीति डिफ़ॉल्ट रूप से शिथिल नहीं होती है। उदाहरण के लिए, C++11 में इस तरह के लेज़ी फ्यूचर्स को पास करके बनाया जा सकता है  लॉन्च नीति को , मान की गणना करने के लिए फ़ंक्शन के साथ।

एक्टर मॉडल में फ्यूचर्स का सिमेंटिक्स
कर्ता मॉडल में, रूप की अभिव्यक्ति  यह परिभाषित किया गया है कि यह कैसे प्रतिक्रिया करता है   पर्यावरण ई और ग्राहक सी के साथ संदेश इस प्रकार है: फ़्यूचर्स की अभिव्यक्ति इसका जवाब देती है   ग्राहक सी को नव निर्मित कर्ता एफ (मूल्यांकन की प्रतिक्रिया के लिए प्रॉक्सी) भेजकर संदेश  ) भेजने के साथ समवर्ती वापसी मान के रूप में   एक   पर्यावरण ई और ग्राहक सी के साथ संदेश। एफ का डिफ़ॉल्ट व्यवहार इस प्रकार है:


 * जब एफ एक अनुरोध आर प्राप्त करता है, तो यह देखने के लिए जांचता है कि क्या उसे मूल्यांकन से पहले ही प्रतिक्रिया मिली है (जो या तो वापसी मान या फेंकने वाला अपवाद हो सकता है)  निम्नानुसार कार्यवाही करना:
 * यदि इसकी पहले से ही प्रतिक्रिया V है, तो
 * यदि V एक वापसी मान है, तो इसे अनुरोध R भेजा जाता है।
 * यदि वी एक अपवाद है, तो अनुरोध आर के ग्राहक को फेंक दिया जाता है।
 * यदि उसके पास पहले से कोई प्रतिक्रिया नहीं है, तो R को F के अंदर अनुरोधों की कतार में संग्रहीत किया जाता है।
 * जब F मूल्यांकन से प्रतिक्रिया V प्राप्त करता है, तो V को F और में संग्रहीत किया जाता है
 * यदि V एक रिटर्न वैल्यू है, तो सभी कतारबद्ध अनुरोध V को भेजे जाते हैं।
 * यदि वी एक अपवाद है, तो यह कतारबद्ध अनुरोधों में से प्रत्येक के ग्राहक को फेंक दिया जाता है।

हालांकि, कुछ फ़्यूचर्स अधिक समानता प्रदान करने के लिए विशेष तरीकों से अनुरोधों से निपट सकते हैं। उदाहरण के लिए, अभिव्यक्ति  एक नया फ़्यूचर्स बना सकते हैं जो संख्या की तरह व्यवहार करेगा. यह तरकीब हमेशा काम नहीं करती। उदाहरण के लिए, निम्नलिखित सशर्त अभिव्यक्ति:

के लिए फ़्यूचर्स के लिए स्थगित करता है  अनुरोध का जवाब दिया है कि क्या पूछ रहा है   स्वयं से बड़ा है।

इतिहास
फ़्यूचर्स और/या प्रोमिस निर्माण पहले मल्टीलिस्प और कर्ता मॉडल जैसी प्रोग्रामिंग भाषाओं में लागू किए गए थे। संगामिति (कंप्यूटर विज्ञान) तर्क प्रोग्रामिंग भाषाओं में संचार के लिए तर्क चर का उपयोग फ़्यूचर्स के समान ही था। ये फ्रीज और आईसी प्रोलॉग के साथ प्रोलॉग में शुरू हुए, और रिलेशनल लैंग्वेज, समवर्ती प्रोलॉग, गार्डेड हॉर्न क्लॉज (जीएचसी), परलॉग, किनारा (प्रोग्रामिंग भाषा),  वालकैन (प्रोग्रामिंग भाषा) , जानूस (समवर्ती बाधा प्रोग्रामिंग लैंग्वेज) के साथ एक वास्तविक समवर्ती आदिम बन गए। ), Oz (प्रोग्रामिंग भाषा) | Oz-मोजार्ट,  प्रवाह जावा , और ऐलिस (प्रोग्रामिंग भाषा)। डेटाफ्लो प्रोग्रामिंग लैंग्वेज से सिंगल-असाइनमेंट I-var, Id (प्रोग्रामिंग लैंग्वेज) में उत्पन्न होता है और Reppy's Concurrent ML में शामिल होता है, जो समवर्ती तर्क चर की तरह होता है।

1988 में बारबरा लिस्कोव और लिउबा श्रीरा द्वारा प्रोमिस पाइपलाइनिंग तकनीक (विलंबता को दूर करने के लिए फ़्यूचर्स का उपयोग करके) का आविष्कार किया गया था। और स्वतंत्र रूप से मार्क एस. मिलर, डीन ट्रिबल और रॉब जेलिंगहौस द्वारा परियोजना Xanadu लगभग 1989 के संदर्भ में। प्रोमिस शब्द लिस्कोव और श्रीरा द्वारा गढ़ा गया था, हालांकि उन्होंने पाइपलाइनिंग तंत्र को कॉल-स्ट्रीम नाम से संदर्भित किया था, जो अब शायद ही कभी उपयोग किया जाता है।

लिस्कोव और श्रीरा के पेपर में वर्णित डिजाइन, और Xanadu में प्रोमिस पाइपलाइनिंग के कार्यान्वयन दोनों की सीमा थी कि प्रोमिस के मान प्रथम श्रेणी के मान नहीं थे | सीधे तौर पर एक प्रोमिस नहीं होगा (इसलिए पहले दिए गए प्रोमिस पाइपलाइनिंग का उदाहरण, जो एक तर्क के रूप में दूसरे को भेजने के परिणाम के लिए एक प्रोमिस का उपयोग करता है, कॉल-स्ट्रीम डिज़ाइन या Xanadu कार्यान्वयन में सीधे अभिव्यक्त नहीं होता)। ऐसा लगता है कि अरगस की किसी भी सार्वजनिक रिलीज में प्रोमिस और कॉल-स्ट्रीम कभी भी लागू नहीं किए गए थे, लिस्कोव और श्रीरा पेपर में प्रयुक्त प्रोग्रामिंग भाषा। आर्गस का विकास 1988 के आसपास बंद हो गया। प्रोमिस पाइपलाइनिंग का Xanadu कार्यान्वयन केवल Udanax Gold के लिए स्रोत कोड जारी करने के साथ ही सार्वजनिक रूप से उपलब्ध हो गया 1999 में, और किसी भी प्रकाशित दस्तावेज़ में कभी भी समझाया नहीं गया था। जूल और ई में बाद के कार्यान्वयन पूरी तरह से प्रथम श्रेणी के वादों और रिज़ॉल्वर का समर्थन करते हैं।

एक्ट सीरीज़ सहित कई प्रारंभिक कर्ता भाषाएँ, समांतर संदेश पासिंग और पाइपलाइन संदेश प्रसंस्करण दोनों का समर्थन करता है, लेकिन पाइपलाइनिंग का प्रोमिस नहीं करता है। (यद्यपि इन विशेषताओं में से अंतिम को पहले दो में लागू करना तकनीकी रूप से संभव है, इस बात का कोई प्रमाण नहीं है कि अधिनियम की भाषाओं ने ऐसा किया है।)

2000 के बाद, उपयोगकर्ता इंटरफेस की जवाबदेही में उनके उपयोग के कारण, और वेब विकास में, संदेश-पासिंग के अनुरोध-प्रतिक्रिया मॉडल के कारण फ़्यूचर्स और वादों में रुचि का एक बड़ा पुनरुद्धार हुआ। कई मुख्यधारा की भाषाओं में अब फ़्यूचर्स और वादों के लिए भाषा का समर्थन है, जो विशेष रूप से लोकप्रिय हैं  जावा 5 में (घोषणा 2004) और .NET 4.5 में async/प्रतीक्षा निर्माण (घोषित 2010, रिलीज़ 2012)  काफी हद तक F# के एसिंक्रोनस वर्कफ्लो से प्रेरित है, जो 2007 की है। इसे बाद में अन्य भाषाओं द्वारा अपनाया गया, विशेष रूप से डार्ट (2014), पायथन (2015), हैक (एचएचवीएम), और ईसीएमएस्क्रिप्ट 7 (जावास्क्रिप्ट), स्काला, और सी ++ (2011) के ड्राफ्ट।

कार्यान्वयन की सूची
कुछ प्रोग्रामिंग लैंग्वेज फ्यूचर्स, प्रोमिस, समवर्ती लॉजिक वेरिएबल्स, डेटाफ्लो वेरिएबल्स या I-vars को डायरेक्ट लैंग्वेज सपोर्ट या स्टैंडर्ड लाइब्रेरी में सपोर्ट कर रही हैं।

प्रोग्रामिंग लैंग्वेज द्वारा फ्यूचर्स और वादों से संबंधित अवधारणाओं की सूची

 * एबीसीएल / एफ
 * ऐलिस (प्रोग्रामिंग भाषा)
 * एम्बिएंटटॉक (प्रथम श्रेणी रिज़ॉल्वर और रीड-ओनली वादों सहित)
 * C++, C++11#थ्रेडिंग सुविधाओं से शुरू होता है|C++11: std::future और std::promise


 * रचनात्मक सी ++
 * क्रिस्टल (प्रोग्रामिंग भाषा)
 * डार्ट (प्रोग्रामिंग भाषा) (फ़्यूचर्स/पूर्ण कक्षाओं के साथ और कीवर्ड प्रतीक्षित और async हैं )
 * एल्म (प्रोग्रामिंग भाषा) टास्क मॉड्यूल के माध्यम से
 * ग्लासगो हास्केल (प्रोग्रामिंग भाषा) (I-vars और M-vars केवल)
 * आईडी (प्रोग्रामिंग भाषा) (I-vars और M-vars केवल)
 * आईओ (प्रोग्रामिंग भाषा)
 * जावा (प्रोग्रामिंग भाषा) के माध्यम से या
 * ईसीएमएस्क्रिप्ट 2015 के अनुसार एकमा स्क्रिप्ट, और खोजशब्दों के माध्यम से  और   ईसीएमएस्क्रिप्ट 2017 के बाद से
 * स्पष्ट (प्रोग्रामिंग भाषा) (केवल डेटा प्रवाह)
 * कुछ लिस्प (प्रोग्रामिंग भाषा)
 * क्लोजर
 * मल्टीलिस्प
 * .NET Framework|.NET वाया टास्क
 * सी शार्प (प्रोग्रामिंग लैंग्वेज) | सी #, .नेट फ्रेमवर्क 4.5 के बाद से, खोजशब्दों के माध्यम से  और  * कोटलिन (प्रोग्रामिंग भाषा), तथापि   आमतौर पर केवल कोटलिन लिखते समय उपयोग किया जाता है जिसका उद्देश्य मूल रूप से चलाना है
 * निम (प्रोग्रामिंग भाषा)
 * ऑक्सीजन (प्रोग्रामिंग भाषा)
 * ओज़ (प्रोग्रामिंग भाषा) संस्करण 3
 * पायथन (प्रोग्रामिंग भाषा), 3.2 के बाद से, PEP 3148 द्वारा प्रस्तावित, और Python 3.5 ने async और प्रतीक्षा को जोड़ा
 * आर (प्रोग्रामिंग भाषा) (शिथिल मूल्यांकन के लिए प्रोमिस, अभी भी सिंगल थ्रेडेड)
 * रैकेट (प्रोग्रामिंग भाषा)
 * राकू (प्रोग्रामिंग भाषा)
 * जंग (प्रोग्रामिंग भाषा) (आमतौर पर )
 * स्काला (प्रोग्रामिंग भाषा) scala.concurrent पैकेज के माध्यम से
 * योजना (प्रोग्रामिंग भाषा)
 * चीख़ स्मॉलटॉक
 * किनारा (प्रोग्रामिंग भाषा)
 * स्विफ्ट (प्रोग्रामिंग भाषा) (केवल तीसरे पक्ष के पुस्तकालयों के माध्यम से)
 * विजुअल बेसिक.नेट 11 (कीवर्ड Async और Await के माध्यम से)

प्रोमिस पाइपलाइनिंग का समर्थन करने वाली भाषाओं में शामिल हैं:
 * ई (प्रोग्रामिंग भाषा)
 * जूल (प्रोग्रामिंग भाषा)

फ्यूचर्स के गैर-मानक, लाइब्रेरी आधारित कार्यान्वयनों की सूची

 * सामान्य लिस्प के लिए:
 * ब्लैकबर्ड
 * उत्सुक फ़्यूचर्स 2
 * समानांतर
 * पीसी कॉल
 * सी ++ के लिए:
 * बूस्ट (सी ++ लाइब्रेरी)
 * दिलीब
 * मूर्खता
 * एचपीएक्स
 * POCO C++ लाइब्रेरी (सक्रिय परिणाम)
 * क्यूटी (सॉफ्टवेयर)
 * खड़ा है
 * छुरा
 * C Sharp (प्रोग्रामिंग लैंग्वेज)|C# और अन्य .NET Framework|.NET भाषाओं के लिए: समानांतर एक्सटेंशन लाइब्रेरी
 * ग्रोवी (प्रोग्रामिंग भाषा) के लिए: GPars
 * जावास्क्रिप्ट के लिए:
 * कुजो.जेएस' कब.जेएस वादों/A+ के अनुरूप प्रोमिस प्रदान करता है 1.1 विनिर्देश
 * डोजो टूलकिट वादों की आपूर्ति करता है और मुड़ी हुई (सॉफ्टवेयर) शैली स्थगित
 * मोचीकिट ट्विस्टेड (सॉफ्टवेयर)#Deferreds|Twisted's Deferreds से प्रेरित है
 * jQuery's [//api.jquery.com/category/deferred-object/ आस्थगित वस्तु] पर आधारित है एक कॉमनजेएस प्रोमिस/ए डिजाइन।
 * एंगुलरजेएस
 * नोड.जेएस-प्रोमिस
 * क्यू, कृष कोवल द्वारा, वादों/ए+ 1.1 के अनुरूप है
 * RSVP.js, वादों/A+ 1.1 के अनुरूप है
 * यूयूआई प्रोमिस वर्ग प्रोमिस/ए+ 1.0 विनिर्देश के अनुरूप है।
 * ब्लूबर्ड, पेटका एंटोनोव द्वारा
 * Google क्लोजर टूल्स # क्लोजर लाइब्रेरी का Promise पैकेज Promises/A+ विनिर्देश के अनुरूप है।
 * देखें Promise/A+'s Promise/A+ डिज़ाइन के आधार पर अधिक कार्यान्वयन के लिए सूची।
 * जावा (प्रोग्रामिंग भाषा) के लिए:
 * JDeferred, आस्थगित-प्रोमिस API और JQuery.Deferred वस्तु के समान व्यवहार प्रदान करता है
 * पेयरसेक Linkedin  द्वारा अनुरक्षित एसिंक्रोनस पाइपलाइनिंग और ब्रांचिंग के लिए कार्य-प्रोमिस एपीआई आदर्श प्रदान करता है
 * लुआ (प्रोग्रामिंग भाषा) के लिए:
 * कतार मॉड्यूल में एक प्रोमिस एपीआई है।
 * उद्देश्य सी के लिए: एमएफ्यूचर,  आरएक्स प्रोमिस, ओबीजेसी-कोलैप्सिंग फ्यूचर्स, प्रॉमिसकिट, ओबीजेसी-प्रोमिस, OAPromise,
 * OCaml के लिए: शिथिल मॉड्यूल शिथिल स्पष्ट फ़्यूचर्स लागू करता है
 * पर्ल के लिए: फ़्यूचर्स, प्रोमिस, प्रतिवर्त, प्रोमिस::ES6, और प्रोमिस :: एक्सएस
 * PHP के लिए: प्रतिक्रिया/प्रोमिस करें
 * पायथन (प्रोग्रामिंग भाषा) के लिए:
 * अंतर्निहित कार्यान्वयन
 * पायथनफ्यूचर्स
 * ट्विस्टेड (सॉफ्टवेयर) | ट्विस्टेड्स डेफर्ड्स
 * आर (प्रोग्रामिंग भाषा) के लिए:
 * फ़्यूचर्स, शिथिल और उत्सुक सिंक्रोनस और (मल्टीकोर या वितरित) एसिंक्रोनस फ्यूचर्स के साथ एक विस्तारणीय फ़्यूचर्स एपीआई लागू करता है
 * रूबी (प्रोग्रामिंग भाषा) के लिए:
 * समवर्ती रूबी
 * वचन रत्न
 * लिबुव रत्न, वादों को लागू करता है
 * सेल्युलाइड रत्न, फ़्यूचर्स लागू करता है
 * फ़्यूचर्स-संसाधन
 * जंग के लिए (प्रोग्रामिंग भाषा):
 * फ्यूचर्स-आरएस
 * स्काला (प्रोग्रामिंग भाषा) के लिए:
 * ट्विटर की उपयोग लाइब्रेरी
 * स्विफ्ट (प्रोग्रामिंग भाषा) के लिए:
 * Async फ्रेमवर्क, C#-शैली को लागू करता है / गैर-अवरुद्ध
 * फ्यूचरकिट, Apple GCD के लिए एक संस्करण लागू करता है
 * FutureLib, प्योर स्विफ्ट 2 लाइब्रेरी स्काला-स्टाइल फ्यूचर्स को लागू करती है और TPL- स्टाइल कैंसलेशन के साथ प्रोमिस करती है
 * आस्थगित, स्पष्ट स्विफ्ट लाइब्रेरी OCaml के आस्थगित से प्रेरित है ** ब्राइट फ्यूचर्स ** स्विफ्टकॉरटाइन
 * टीसीएल (प्रोग्रामिंग भाषा) के लिए: टीसीएल-प्रोमिस

कोरूटिन्स
फ्यूचर्स को कोरआउट्स में लागू किया जा सकता है या जनरेटर (कंप्यूटर प्रोग्रामिंग), परिणामस्वरूप एक ही मूल्यांकन रणनीति (जैसे, सहकारी मल्टीटास्किंग या शिथिल मूल्यांकन)।

चैनल
फ़्यूचर्स को चैनल (प्रोग्रामिंग) में आसानी से कार्यान्वित किया जा सकता है: फ़्यूचर्स एक एकल-तत्व चैनल है, और प्रोमिस एक प्रक्रिया है जो चैनल को भेजता है, फ़्यूचर्स को पूरा करता है। यह सीएसपी और गो (प्रोग्रामिंग भाषा) जैसे चैनलों के समर्थन के साथ समवर्ती प्रोग्रामिंग भाषाओं में फ्यूचर्स को लागू करने की अनुमति देता है। परिणामी वायदे स्पष्ट हैं, क्योंकि उन्हें केवल मूल्यांकन के बजाय चैनल से पढ़कर एक्सेस किया जाना चाहिए।

यह भी देखें

 * फाइबर (कंप्यूटर विज्ञान)
 * Futex
 * कयामत का पिरामिड (प्रोग्रामिंग), वादों से बचने वाला एक डिज़ाइन एंटीपैटर्न

बाहरी संबंध

 * Concurrency patterns presentation given at scaleconf
 * Future Value and Promise Pipelining at the Portland Pattern Repository
 * Easy Threading with Futures in Python