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

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

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

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

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

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

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

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

फ्यूचर्स का उपयोग करके उपरोक्त अभिव्यक्ति लिखी जा सकती है  टी 3: = (एक्स <- ए ) <- सी (वाई <- बी ) 

जिसे बढ़ाया जा सकता है  टी 1: = एक्स <- ए ; टी 2: = वाई <- बी ; t3 := t1 <- c(t2); 

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

इतिहास
भविष्य और/या वादा निर्माण पहले मल्टीलिस्प और अभिनेता मॉडल जैसी प्रोग्रामिंग भाषाओं में लागू किए गए थे। संगामिति (कंप्यूटर विज्ञान) तर्क प्रोग्रामिंग भाषाओं में संचार के लिए तर्क चर का उपयोग वायदा के समान ही था। ये फ्रीज और आईसी प्रोलॉग के साथ प्रोलॉग में शुरू हुए, और रिलेशनल लैंग्वेज, समवर्ती प्रोलॉग, गार्डेड हॉर्न क्लॉज (जीएचसी), परलॉग, किनारा (प्रोग्रामिंग भाषा),  वालकैन (प्रोग्रामिंग भाषा) , जानूस (समवर्ती बाधा प्रोग्रामिंग लैंग्वेज) के साथ एक वास्तविक समवर्ती आदिम बन गए। ), ओज (प्रोग्रामिंग भाषा) | ओज-मोजार्ट,  प्रवाह जावा , और ऐलिस (प्रोग्रामिंग भाषा)। डेटाफ्लो प्रोग्रामिंग लैंग्वेज से सिंगल-असाइनमेंट 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