फ़्यूचर्स और प्रोमिस: Difference between revisions

Latest revision as of 16:31, 9 June 2023

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

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

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

अनुप्रयोग

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

अंतर्निहित बनाम लुसिड

फ़्यूचर्स का उपयोग अंतर्निहित हो सकता है (फ़्यूचर्स का कोई भी उपयोग स्वचालित रूप से अपना मान प्राप्त करता है, जैसे कि यह सामान्य निर्देश (प्रोग्रामिंग) था) या लुसिड (उपयोगकर्ता को मान प्राप्त करने के लिए फ़ंक्शन को कॉल निर्देश, जैसे कि get उसकि विधि java.util.concurrent.Future जावा (प्रोग्रामिंग भाषा) में)। लुसिड फ़्यूचर्स के मान को प्राप्त करना स्टिंगिंग या प्रेरक कहा जाता है। लुसिड फ़्यूचर्स को लाइब्रेरी के रूप में लागू किया जा सकता है, जबकि अंतर्निहित फ़्यूचर्स सामान्यतः भाषा के हिस्से के रूप में लागू किया जाता है।

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

प्रोमिस पाइपलाइनिंग

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

पारंपरिक दूरस्थ प्रक्रिया कॉलों से संबंधित अभिव्यक्ति पर विचार करें, जैसे:<पूर्व>

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

जिसे बढ़ाया जा सकता है

t 1: = x.a();
t 2: = y.b ();
t3t:= t1.c(t2);

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

फ्यूचर्स का उपयोग करके उपरोक्त अभिव्यक्ति लिखी जा सकती है

t 3: = (x <- a ()) <- c (y <- b ())

जिसे बढ़ाया जा सकता है

t 1: = x <- a ();
t 2: = y <- b ();
t3t:= t1 <- c(t2);

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

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

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

रीड-ओनली विचार

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

Oz में, !! ऑपरेटर का उपयोग रीड-ओनली दृश्य प्राप्त करने के लिए किया जाता है।
E और एम्बिएंटटॉक में, फ़्यूचर्स को प्रॉमिस/रिज़ॉल्वर जोड़ी कहे जाने वाले मानों के एक जोड़े द्वारा दर्शाया जाता है। प्रोमिस रीड-ओनली दृश्य का प्रतिनिधित्व करता है, और फ़्यूचर्स के मान को निर्धारित करने के लिए रिज़ॉल्वर की आवश्यकता होती है।
C ++ 11 में std::future रीड-ओनली दृश्य प्रदान करता है। मान सीधे std::प्रोमिस का उपयोग करके सेट किया गया है, या उपयोग करके फ़ंक्शन कॉल के परिणाम पर सेट करें std::packaged_task या std::async.
संस्करण 1.5 के रूप में डोजो टूलकिट के डिफर्ड एपीआई में, उपभोक्ता-मात्र प्रोमिस ऑब्जेक्ट रीड-ओनली दृश्य का प्रतिनिधित्व करती है।^[7]
ऐलिस एमएल में, फ़्यूचर्स रीड-ओनली दृश्य प्रदान करता है, जबकि प्रोमिस में फ़्यूचर्स और फ़्यूचर्स को हल करने की क्षमता दोनों सम्मिलित हैं^[8]^[9]
.NET Framework 4.0 में System.Threading.Tasks.Task<T> रीड-ओनली दृश्य का प्रतिनिधित्व करता है। मान को हल करके किया जा सकता है System.Threading.Tasks.TaskCompletionSource<T>.

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

थ्रेड-स्पेसिफिक फ्यूचर्स

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

ऐलिस एमएल भी फ़्यूचर्स का समर्थन करता है जिसे किसी भी थ्रेड से हल किया जा सकता है, और इन प्रोमिस को कॉल करता है।^[8]प्रोमिस का यह उपयोग ऊपर वर्णित E में इसके उपयोग से अलग है। ऐलिस में, प्रोमिस रीड-ओनली दृश्य नहीं है, और प्रोमिस पाइपलाइनिंग असमर्थित है। इसके अतिरिक्त, फ़्यूचर्स के लिए पाइपलाइनिंग स्वाभाविक रूप से होती है, जिसमें प्रोमिस से जुड़े हैं।

ब्लॉकिंग बनाम नॉन-ब्लॉकिंग अर्थविज्ञान

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

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

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

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

फ़्यूचर्स के विभिन्न रूपों की अभिव्यक्ति के बीच संबंध

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

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

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

मूल्यांकन रणनीति

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

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

एक्टर मॉडल में फ्यूचर्स का सिमेंटिक्स

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

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

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

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

के लिए फ़्यूचर्स के लिए स्थगित करता है factorial(n) अनुरोध का जवाब दिया है कि m स्वयं से बड़ा है या नहीं है।

इतिहास

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

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

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

लिस्कोव और श्रीरा के पेपर में वर्णित डिजाइन, और ज़ानाडू में प्रोमिस पाइपलाइनिंग के कार्यान्वयन दोनों की सीमा थी कि प्रोमिस के मान प्रथम श्रेणी के मान नहीं थे | सीधे तौर पर प्रोमिस नहीं हो सकता था (इसलिए पहले दिए गए प्रोमिस पाइपलाइनिंग का उदाहरण, जो प्रेषण के परिणाम के लिए दूसरे को लॉजिक के रूप में प्रोमिस का उपयोग करता है, कॉल-स्ट्रीम डिज़ाइन या ज़ानाडू कार्यान्वयन में सीधे अभिव्यक्त नहीं होता)। ऐसा लगता है कि लिस्कोव और श्रीरा पेपर में उपयोग की जाने वाली प्रोग्रामिंग भाषा अरगस ^[15] की किसी भी सार्वजनिक रिलीज में प्रोमिस और कॉल-स्ट्रीम कभी भी लागू नहीं किए गए थे। आर्गस का विकास 1988 के आसपास बंद हो गया था।^[16] प्रोमिस पाइपलाइनिंग का ज़ानाडू कार्यान्वयन केवल उडानैक्स गोल्ड के लिए स्रोत कोड जारी करने के साथ ही सार्वजनिक रूप से उपलब्ध हो गया^[17]था, और 1999 में, और किसी भी प्रकाशित दस्तावेज़ में कभी भी समझाया नहीं गया था।^[18] जूल और E में बाद के कार्यान्वयन पूरी तरह से प्रथम श्रेणी के प्रोमिस और रिज़ॉल्वर का समर्थन करते हैं।

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

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

कार्यान्वयन की सूची

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

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

एबीसीएल / एफ^[28]
ऐलिस (प्रोग्रामिंग भाषा)
एम्बिएंटटॉक (प्रथम श्रेणी रिज़ॉल्वर और रीड-ओनली प्रोमिस सहित)
C++, C++11: std::future और std::प्रोमिस
- रचनात्मक सी ++
क्रिस्टल (प्रोग्रामिंग भाषा)
डार्ट (प्रोग्रामिंग भाषा) (फ़्यूचर्स/पूर्ण कक्षाओं के साथ^[29] और कीवर्ड प्रतीक्षित और async हैं^[26])
एल्म (प्रोग्रामिंग भाषा) टास्क मॉड्यूल के माध्यम से^[30]
ग्लासगो हास्केल (प्रोग्रामिंग भाषा) (I-vars और M-vars केवल)
आईडी (प्रोग्रामिंग भाषा) (I-vars और M-vars केवल)
आईओ (प्रोग्रामिंग भाषा)^[31]
जावा (प्रोग्रामिंग भाषा) के माध्यम से java.util.concurrent.Future या java.util.concurrent.CompletableFuture
ईसीएमएस्क्रिप्ट 2015 के अनुसार एकमा स्क्रिप्ट,^[32] और खोजशब्दों के माध्यम से async और await ईसीएमएस्क्रिप्ट 2017 के बाद से^[33]
लुसिड (प्रोग्रामिंग भाषा) (केवल डेटा प्रवाह)
कुछ लिस्प (प्रोग्रामिंग भाषा)
- क्लोजर^[34]
- मल्टीलिस्प
.NET वाया टास्क
- सी #, .नेट फ्रेमवर्क 4.5 के बाद से,^[22]खोजशब्दों के माध्यम से async और await^[23]
  - कोटलिन (प्रोग्रामिंग भाषा), तथापि kotlin.native.concurrent.Future सामान्यतः केवल कोटलिन लिखते समय उपयोग किया जाता है जिसका ऑब्जेक्टिव मूल रूप से चलाना है^[35]
निम (प्रोग्रामिंग भाषा)
ऑक्सीजन (प्रोग्रामिंग भाषा)
Oz (प्रोग्रामिंग भाषा) संस्करण 3^[36]
पायथन (प्रोग्रामिंग भाषा) [1], 3.2 के बाद से,^[37] PEP 3148 द्वारा प्रस्तावित, और पायथन 3.5 ने async और प्रतीक्षा को जोड़ा^[38]
R (प्रोग्रामिंग भाषा) (शिथिल मूल्यांकन के लिए प्रोमिस, अभी भी सिंगल थ्रेडेड)
रैकेट (प्रोग्रामिंग भाषा)^[39]
राकू (प्रोग्रामिंग भाषा)^[40]
रस्ट (प्रोग्रामिंग भाषा) (सामान्यतः .await)^[41]
स्काला (प्रोग्रामिंग भाषा) scala.concurrent पैकेज के माध्यम से
स्कीम (प्रोग्रामिंग भाषा)
स्क्वाक स्मॉलटॉक
स्ट्रैंड(प्रोग्रामिंग भाषा)
स्विफ्ट (प्रोग्रामिंग भाषा) (केवल तीसरे पक्ष के लाइब्रेरी के माध्यम से)
विजुअल बेसिक.नेट 11 (कीवर्ड Async और Await के माध्यम से)^[23]

प्रोमिस पाइपलाइनिंग का समर्थन करने वाली लैंग्वेज में सम्मिलित हैं:

ई (प्रोग्रामिंग भाषा)
जूल (प्रोग्रामिंग भाषा)

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

सामान्य लिस्प के लिए:
- ब्लैकबर्ड^[42]
- व्यग्र फ़्यूचर्स 2^[43]
- समानांतर^[44]
- पीसी कॉल^[45]
सी ++ के लिए:
- बूस्ट (सी ++ लाइब्रेरी)^[46]
- दिलीब^[47]
- फौली^[48]
- एचपीएक्स ^[49]
- पोको C++ लाइब्रेरी (सक्रिय परिणाम)^[50]
- क्यूटी (सॉफ्टवेयर)^[51]
- सीस्टार^[52]
- छुरा^[53]
C# और अन्य .NET लैंग्वेज के लिए: समानांतर एक्सटेंशन लाइब्रेरी
ग्रोवी (प्रोग्रामिंग भाषा) के लिए: जीपार्स^[54]
जावास्क्रिप्ट के लिए:
- कुजो.जेएस'^[55] कब.जेएस^[56] प्रोमिस/A+ के अनुरूप प्रोमिस प्रदान करता है^[57] 1.1 विनिर्देश
- डोजो टूलकिट प्रोमिस की आपूर्ति करता है^[58] और मुड़ी हुई (सॉफ्टवेयर) शैली स्थगित
- मोचीकिट^[59] ट्विस्टेड (सॉफ्टवेयर) डेफेर्रेड से प्रेरित है
- jQuery's जडेफेर्रेड ऑब्जेक्ट पर आधारित है कॉमनजेएस प्रोमिस/ए डिजाइन।
- एंगुलरजेएस^[60]
- नोड.जेएस-प्रोमिस^[61]
- Q, कृष कोवल द्वारा, प्रोमिस/ए+ 1.1 के अनुरूप है^[62]
- RSVP.js, प्रोमिस/A+ 1.1 के अनुरूप है^[63]
- यूयूआई^[64] प्रोमिस वर्ग^[65] प्रोमिस/ए+ 1.0 विनिर्देश के अनुरूप है।
- ब्लूबर्ड, पेटका एंटोनोव द्वारा^[66]
- क्लोजर लाइब्रेरी का प्रोमिस पैकेज Promises/A+ विनिर्देश के अनुरूप है।
- देखें प्रोमिस/A+'s प्रोमिस/A+ डिज़ाइन के आधार पर अधिक कार्यान्वयन के लिए सूची।
जावा (प्रोग्रामिंग भाषा) के लिए:
- ओएप्रोमाइज, जडेफेर्रेड-प्रोमिस एपीआई और JQuery.Deferred ऑब्जेक्ट के समान व्यवहार प्रदान करता है^[67]
- पेयरसेक^[68] Linkedin द्वारा अनुरक्षित अतुल्यकालिक पाइपलाइनिंग और ब्रांचिंग के लिए कार्य-प्रोमिस एपीआई आदर्श प्रदान करता है
लुआ (प्रोग्रामिंग भाषा) के लिए:
- कतार [2] मॉड्यूल में एक प्रोमिस एपीआई है।
ऑब्जेक्टिव-सी के लिए: एमएफ्यूचर,^[69]^[70] आरएक्स प्रोमिस,^[71] ओबीजेसी-कोलैप्सिंग फ्यूचर्स,^[72] प्रॉमिसकिट,^[73] ओबीजेसी-प्रोमिस,^[74] ओएप्रोमाइज,^[75]
ओ कैमल के लिए: शिथिल मॉड्यूल शिथिल लुसिड फ़्यूचर्स लागू करता है^[76]
पर्ल के लिए: फ़्यूचर्स,^[77] प्रोमिस,^[78] प्रतिवर्त,^[79] प्रोमिस::ES6,^[80] और प्रोमिस :: एक्सएस^[81]
पीएचपी के लिए: प्रतिक्रिया/प्रोमिस करें^[82]
पायथन (प्रोग्रामिंग भाषा) के लिए:
- अंतर्निहित कार्यान्वयन^[83]
- पायथनफ्यूचर्स^[84]
- ट्विस्टेड (सॉफ्टवेयर) डेफर्ड्स^[85]
R (प्रोग्रामिंग भाषा) के लिए:
- फ़्यूचर्स, शिथिल और व्यग्र सिंक्रोनस और (मल्टीकोर या वितरित) अतुल्यकालिक फ्यूचर्स के साथ विस्तारणीय फ़्यूचर्स एपीआई लागू करता है^[86]^[87]
रूबी (प्रोग्रामिंग भाषा) के लिए:
- समवर्ती रूबी^[88]
- प्रॉमिस जेम^[89]
- लिबुव जेम, प्रोमिस को लागू करता है^[90]
- सेल्युलाइड जेम, फ़्यूचर्स लागू करता है^[91]
- फ़्यूचर्स-संसाधन^[92]
रस्ट (प्रोग्रामिंग भाषा) के लिए :
- फ्यूचर्स-आरएस^[93]
स्काला (प्रोग्रामिंग भाषा) के लिए:
- ट्विटर की उपयोग लाइब्रेरी^[94]
स्विफ्ट (प्रोग्रामिंग भाषा) के लिए:
- Async फ्रेमवर्क, C#-स्टाइल async/ नॉन-ब्लॉकिंग वेट await^[95]को लागू करता है
- फ्यूचरकिट,^[96] Apple GCD के लिए एक संस्करण लागू करता है^[97]
- FutureLib, प्योर स्विफ्ट 2 लाइब्रेरी स्काला-स्टाइल फ्यूचर्स को लागू करती है और टीपीएल-स्टाइल कैंसिलेशन के साथ प्रोमिस करती है^[98]
- ओकैमल के डिफर्ड से प्रेरित डिफर्ड, प्योर स्विफ्ट लाइब्रेरी^[99] ** ब्राइट फ्यूचर्स^[100] ** स्विफ्टकॉरटाइन^[101]
टीसीएल (प्रोग्रामिंग भाषा) के लिए: टीसीएल-प्रोमिस^[102]

कोरूटिन्स

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

चैनल

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

यह भी देखें

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

संदर्भ

↑ Friedman, Daniel; David Wise (1976). The Impact of Applicative Programming on Multiprocessing. International Conference on Parallel Processing. pp. 263–272.
Preliminary version of: Friedman, Daniel; Wise, David (April 1978). "समानांतर प्रसंस्करण के लिए एप्लीकेटिव प्रोग्रामिंग के पहलू". IEEE Transactions on Computers. C-27 (4): 289–296. CiteSeerX 10.1.1.295.9692. doi:10.1109/tc.1978.1675100. S2CID 16333366.
↑ Hibbard, Peter (1976). Parallel Processing Facilities. New Directions in Algorithmic Languages, (ed.) Stephen A. Schuman, IRIA, 1976.
↑ Henry Baker; Carl Hewitt (August 1977). The Incremental Garbage Collection of Processes. Proceedings of the Symposium on Artificial Intelligence Programming Languages. ACM SIGPLAN Notices 12, 8. pp. 55–59. Archived from the original on 4 July 2008. Retrieved 13 February 2015.
↑ Promise Pipelining at erights.org
↑ Promise Pipelining on the C2 wiki
↑ ^6.0 ^6.1 Barbara Liskov; Liuba Shrira (1988). "Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems". Proceedings of the SIGPLAN '88 Conference on Programming Language Design and Implementation; Atlanta, Georgia, United States. ACM. pp. 260–267. doi:10.1145/53990.54016. ISBN 0-89791-269-1. Also published in ACM SIGPLAN Notices 23(7).
↑ Robust promises with Dojo deferred, Site Pen, 2010-05-03
↑ ^8.0 ^8.1 "Promise", Alice Manual, DE: Uni-SB, archived from the original on 8 October 2008, retrieved 21 March 2007
↑ ^9.0 ^9.1 "Future", Alice manual, DE: Uni-SB, archived from the original on 6 October 2008, retrieved 21 March 2007
↑ Promise, E rights
↑ 500 lines or less, "A Web Crawler With asyncio Coroutines" by A. Jesse Jiryu Davis and Guido van Rossum says "implementation uses an asyncio.Event in place of the Future shown here. The difference is an Event can be reset, whereas a Future cannot transition from resolved back to pending."
↑ Control Concurrent MVar, Haskell, archived from the original on 18 April 2009
↑ WaitNeeded, Mozart Oz, archived from the original on 17 May 2013, retrieved 21 March 2007
↑ Promise, Sunless Sea, archived from the original on 23 October 2007
↑ Argus, MIT
↑ Liskov, Barbara (26 January 2021), Distributed computing and Argus, Oral history, IEEE GHN
↑ Gold, Udanax, archived from the original on 11 October 2008
↑ Pipeline, E rights
↑ Henry Lieberman (June 1981). "A Preview of Act 1". MIT AI memo 625. {{cite journal}}: Cite journal requires |journal= (help)
↑ Henry Lieberman (June 1981). "Thinking About Lots of Things at Once without Getting Confused: Parallelism in Act 1". MIT AI memo 626. {{cite journal}}: Cite journal requires |journal= (help)
↑ Goetz, Brian (November 23, 2004). "Concurrency in JDK 5.0". IBM.
↑ ^22.0 ^22.1 "Async in 4.5: Worth the Await – .NET Blog – Site Home – MSDN Blogs". Blogs.msdn.com. Retrieved 2014-05-13.
↑ ^23.0 ^23.1 ^23.2 "Async और Await (C# और Visual Basic) के साथ एसिंक्रोनस प्रोग्रामिंग". Msdn.microsoft.com. Retrieved 2014-05-13.
↑ Tomas Petricek (29 October 2010). "Asynchronous C# and F# (I.): Simultaneous introduction".
↑ Don Syme; Tomas Petricek; Dmitry Lomov (21 Oct 2010). "The F# Asynchronous Programming Model, PADL 2011".
↑ ^26.0 ^26.1 Gilad Bracha (October 2014). "Dart Language Asynchrony Support: Phase 1".
↑ ^27.0 ^27.1 "PEP 0492 – Coroutines with async and await syntax".
↑ Kenjiro Taura; Satoshi Matsuoka; Akinori Yonezawa (1994). "ABCL/f: A Future-Based Polymorphic Typed Concurrent Object-Oriented Language – Its Design and Implementation.". In Proceedings of the DIMACS workshop on Specification of Parallel Algorithms, number 18 in Dimacs Series in Discrete Mathematics and Theoretical Computer Science. American Mathematical Society. pp. 275–292. CiteSeerX 10.1.1.23.1161.
↑ "Dart SDK dart async Completer".
↑ "Task".
↑ Steve Dekorte (2005). "Io, The Programming Language".
↑ "Using promises". Mozilla Developer Network. Retrieved 23 February 2021.
↑ "Making asynchronous programming easier with async and await". Mozilla Developer Network. Retrieved 23 February 2021.
↑ Rich Hickey (2009). "changes.txt at 1.1.x from richhickey's clojure". GitHub.
↑ "Future - Kotlin Programming Language".
↑ Seif Haridi; Nils Franzen. "ओज का ट्यूटोरियल". Mozart Global User Library. Archived from the original on 14 May 2011. Retrieved 12 April 2011.
↑ Python 3.2 Release
↑ Python 3.5 Release
↑ "फ्यूचर्स के साथ समानता". PLT. Retrieved 2 March 2012.
↑ "कक्षा का वादा". raku.org. Retrieved 2022-08-19.
↑ "Future in STD::future - Rust".
↑ Common Lisp Blackbird
↑ Common Lisp Eager Future2
↑ Lisp in parallel – A parallel programming library for Common Lisp
↑ Common Lisp PCall
↑ "Chapter 30. Thread 4.0.0". Retrieved 26 June 2013.
↑ "Dlib C++ Library #thread_pool". Retrieved 26 June 2013.
↑ "GitHub – facebook/folly: An open-source C++ library developed and used at Facebook". GitHub. 2019-01-08.
↑ "एचपीएक्स". 2019-02-10.
↑ "Threads Slides of POCO" (PDF).
↑ "QtCore 5.0: QFuture Class". Qt Project. Archived from the original on 1 June 2013. Retrieved 26 June 2013.
↑ "Seastar". Seastar project. Retrieved 22 August 2016.
↑ "स्टैब एडोब की सॉफ्टवेयर टेक्नोलॉजी लैब का चल रहा काम है। एडोब सोर्स लाइब्रेरीज़ (एएसएल), प्लेटफ़ॉर्म लाइब्रेरीज़ और नए स्टैब लाइब्रेरीज़ को जीथब पर होस्ट किया गया है।". 2021-01-31.
↑ Groovy GPars Archived 12 January 2013 at the Wayback Machine
↑ Cujo.js
↑ JavaScript when.js
↑ Promises/A+ specification
↑ promises
↑ JavaScript MochKit.Async
↑ JavaScript Angularjs
↑ JavaScript node-promise
↑ "जावास्क्रिप्ट क्यू". Archived from the original on 31 December 2018. Retrieved 8 April 2013.
↑ JavaScript RSVP.js
↑ YUI JavaScript class library
↑ YUI JavaScript promise class
↑ JavaScript Bluebird
↑ Java JDeferred
↑ Java ParSeq
↑ Objective-C MAFuture GitHub
↑ Objective-C MAFuture mikeash.com
↑ Objective-C RXPromise
↑ ObjC-CollapsingFutures
↑ Objective-C PromiseKit
↑ Objective-C objc-promise
↑ Objective-C OAPromise
↑ OCaml Lazy
↑ Perl Future
↑ Perl Promises
↑ Perl Reflex
↑ Perl Promise::ES6
↑ "Promise::XS - Fast promises in Perl - metacpan.org". metacpan.org. Retrieved 2021-02-14.
↑ PHP React/Promise
↑ Python built-in implementation
↑ pythonfutures
↑ "मुड़ आस्थगित". Archived from the original on 6 August 2020. Retrieved 29 April 2010.
↑ R package future
↑ future
↑ Concurrent Ruby
↑ Ruby Promise gem
↑ Ruby libuv
↑ "रूबी सेल्युलाइड रत्न". Archived from the original on 8 May 2013. Retrieved 19 February 2022.
↑ Ruby future-resource
↑ futures-rs crate
↑ Twitter's util library
↑ "स्विफ्ट एसिंक्स". Archived from the original on 31 December 2018. Retrieved 23 June 2014.
↑ Swift FutureKit
↑ Swift Apple GCD
↑ Swift FutureLib
↑ bignerdranch/Deferred
↑ Thomvis/BrightFutures
↑ belozierov/SwiftCoroutine
↑ tcl-promise
↑ Does async/await solve a real problem?
↑ Go language patterns Futures
↑ Go Language Patterns

बाहरी संबंध

Concurrency patterns presentation given at scaleconf
Future Value and प्रोमिस Pipelining at the Portland Pattern Repository
Easy Threading with Futures in पायथन

[1] Friedman, Daniel; David Wise (1976). The Impact of Applicative Programming on Multiprocessing. International Conference on Parallel Processing. pp. 263–272.
Preliminary version of: Friedman, Daniel; Wise, David (April 1978). "समानांतर प्रसंस्करण के लिए एप्लीकेटिव प्रोग्रामिंग के पहलू". IEEE Transactions on Computers. C-27 (4): 289–296. CiteSeerX 10.1.1.295.9692. doi:10.1109/tc.1978.1675100. S2CID 16333366.

[2] Hibbard, Peter (1976). Parallel Processing Facilities. New Directions in Algorithmic Languages, (ed.) Stephen A. Schuman, IRIA, 1976.

[3] Henry Baker; Carl Hewitt (August 1977). The Incremental Garbage Collection of Processes. Proceedings of the Symposium on Artificial Intelligence Programming Languages. ACM SIGPLAN Notices 12, 8. pp. 55–59. Archived from the original on 4 July 2008. Retrieved 13 February 2015.

[4] Promise Pipelining at erights.org

[5] Promise Pipelining on the C2 wiki

[SIGPLAN_pp._260-6] 6.0 ^6.1 Barbara Liskov; Liuba Shrira (1988). "Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems". Proceedings of the SIGPLAN '88 Conference on Programming Language Design and Implementation; Atlanta, Georgia, United States. ACM. pp. 260–267. doi:10.1145/53990.54016. ISBN 0-89791-269-1. Also published in ACM SIGPLAN Notices 23(7).

[7] Robust promises with Dojo deferred, Site Pen, 2010-05-03

[Alice_ML_promise-8] 8.0 ^8.1 "Promise", Alice Manual, DE: Uni-SB, archived from the original on 8 October 2008, retrieved 21 March 2007

[Alice_ML_future-9] 9.0 ^9.1 "Future", Alice manual, DE: Uni-SB, archived from the original on 6 October 2008, retrieved 21 March 2007

[10] Promise, E rights

[11] 500 lines or less, "A Web Crawler With asyncio Coroutines" by A. Jesse Jiryu Davis and Guido van Rossum says "implementation uses an asyncio.Event in place of the Future shown here. The difference is an Event can be reset, whereas a Future cannot transition from resolved back to pending."

[12] Control Concurrent MVar, Haskell, archived from the original on 18 April 2009

[13] WaitNeeded, Mozart Oz, archived from the original on 17 May 2013, retrieved 21 March 2007

[14] Promise, Sunless Sea, archived from the original on 23 October 2007

[15] Argus, MIT

[16] Liskov, Barbara (26 January 2021), Distributed computing and Argus, Oral history, IEEE GHN

[17] Gold, Udanax, archived from the original on 11 October 2008

[18] Pipeline, E rights

[19] Henry Lieberman (June 1981). "A Preview of Act 1". MIT AI memo 625. {{cite journal}}: Cite journal requires |journal= (help)

[20] Henry Lieberman (June 1981). "Thinking About Lots of Things at Once without Getting Confused: Parallelism in Act 1". MIT AI memo 626. {{cite journal}}: Cite journal requires |journal= (help)

[21] Goetz, Brian (November 23, 2004). "Concurrency in JDK 5.0". IBM.

[asyncdotnet45-22] 22.0 ^22.1 "Async in 4.5: Worth the Await – .NET Blog – Site Home – MSDN Blogs". Blogs.msdn.com. Retrieved 2014-05-13.

[dotnetasyncawait-23] 23.0 ^23.1 ^23.2 "Async और Await (C# और Visual Basic) के साथ एसिंक्रोनस प्रोग्रामिंग". Msdn.microsoft.com. Retrieved 2014-05-13.

[24] Tomas Petricek (29 October 2010). "Asynchronous C# and F# (I.): Simultaneous introduction".

[25] Don Syme; Tomas Petricek; Dmitry Lomov (21 Oct 2010). "The F# Asynchronous Programming Model, PADL 2011".

[dart-26] 26.0 ^26.1 Gilad Bracha (October 2014). "Dart Language Asynchrony Support: Phase 1".

[python-27] 27.0 ^27.1 "PEP 0492 – Coroutines with async and await syntax".

[28] Kenjiro Taura; Satoshi Matsuoka; Akinori Yonezawa (1994). "ABCL/f: A Future-Based Polymorphic Typed Concurrent Object-Oriented Language – Its Design and Implementation.". In Proceedings of the DIMACS workshop on Specification of Parallel Algorithms, number 18 in Dimacs Series in Discrete Mathematics and Theoretical Computer Science. American Mathematical Society. pp. 275–292. CiteSeerX 10.1.1.23.1161.

[dartCompleter-29] "Dart SDK dart async Completer".

[elmTask-30] "Task".

[31] Steve Dekorte (2005). "Io, The Programming Language".

[32] "Using promises". Mozilla Developer Network. Retrieved 23 February 2021.

[33] "Making asynchronous programming easier with async and await". Mozilla Developer Network. Retrieved 23 February 2021.

[34] Rich Hickey (2009). "changes.txt at 1.1.x from richhickey's clojure". GitHub.

[35] "Future - Kotlin Programming Language".

[36] Seif Haridi; Nils Franzen. "ओज का ट्यूटोरियल". Mozart Global User Library. Archived from the original on 14 May 2011. Retrieved 12 April 2011.

[37] Python 3.2 Release

[38] Python 3.5 Release

[39] "फ्यूचर्स के साथ समानता". PLT. Retrieved 2 March 2012.

[40] "कक्षा का वादा". raku.org. Retrieved 2022-08-19.

[41] "Future in STD::future - Rust".

[42] Common Lisp Blackbird

[43] Common Lisp Eager Future2

[44] Lisp in parallel – A parallel programming library for Common Lisp

[45] Common Lisp PCall

[46] "Chapter 30. Thread 4.0.0". Retrieved 26 June 2013.

[47] "Dlib C++ Library #thread_pool". Retrieved 26 June 2013.

[48] "GitHub – facebook/folly: An open-source C++ library developed and used at Facebook". GitHub. 2019-01-08.

[49] "एचपीएक्स". 2019-02-10.

[50] "Threads Slides of POCO" (PDF).

[51] "QtCore 5.0: QFuture Class". Qt Project. Archived from the original on 1 June 2013. Retrieved 26 June 2013.

[52] "Seastar". Seastar project. Retrieved 22 August 2016.

[53] "स्टैब एडोब की सॉफ्टवेयर टेक्नोलॉजी लैब का चल रहा काम है। एडोब सोर्स लाइब्रेरीज़ (एएसएल), प्लेटफ़ॉर्म लाइब्रेरीज़ और नए स्टैब लाइब्रेरीज़ को जीथब पर होस्ट किया गया है।". 2021-01-31.

[54] Groovy GPars Archived 12 January 2013 at the Wayback Machine

[55] Cujo.js

[56] JavaScript when.js

[57] Promises/A+ specification

[58] romises

[59] JavaScript MochKit.Async

[60] JavaScript Angularjs

[61] JavaScript node-promise

[62] "जावास्क्रिप्ट क्यू". Archived from the original on 31 December 2018. Retrieved 8 April 2013.

[63] JavaScript RSVP.js

[64] YUI JavaScript class library

[65] YUI JavaScript promise class

[66] JavaScript Bluebird

[67] Java JDeferred

[68] Java ParSeq

[69] Objective-C MAFuture GitHub

[70] Objective-C MAFuture mikeash.com

[71] Objective-C RXPromise

[72] ObjC-CollapsingFutures

[73] Objective-C PromiseKit

[74] Objective-C objc-promise

[75] Objective-C OAPromise

[76] OCaml Lazy

[77] Perl Future

[78] Perl Promises

[79] Perl Reflex

[80] Perl Promise::ES6

[81] "Promise::XS - Fast promises in Perl - metacpan.org". metacpan.org. Retrieved 2021-02-14.

[82] PHP React/Promise

[83] Python built-in implementation

[84] ythonfutures

[85] "मुड़ आस्थगित". Archived from the original on 6 August 2020. Retrieved 29 April 2010.

[86] R package future

[87] uture

[88] Concurrent Ruby

[89] Ruby Promise gem

[90] Ruby libuv

[91] "रूबी सेल्युलाइड रत्न". Archived from the original on 8 May 2013. Retrieved 19 February 2022.

[92] Ruby future-resource

[93] utures-rs crate

[94] Twitter's util library

[95] "स्विफ्ट एसिंक्स". Archived from the original on 31 December 2018. Retrieved 23 June 2014.

[96] Swift FutureKit

[97] Swift Apple GCD

[98] Swift FutureLib

[99] rdranch/Deferred

[100] Thomvis/BrightFutures

[101] zierov/SwiftCoroutine

[102] tcl-promise

[103] Does async/await solve a real problem?

[104] Go language patterns Futures

[105] Go Language Patterns

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43]

[44]

[45]

[46]

[47]

[48]

[49]

[50]

[51]

[52]

[53]

[54]

[55]

[56]

[57]

[58]

[59]

[60]

[61]

[62]

[63]

[64]

[65]

[66]

[67]

[68]

[69]

[70]

[71]

[72]

[73]

[74]

[75]

[76]

[77]

[78]

[79]

[80]

[81]

[82]

[83]

[84]

[85]

[86]

[87]

[88]

[89]

[90]

[91]

[92]

[93]

[94]

[95]

[96]

[97]

[98]

[99]

[100]

Anonymous

Search

फ़्यूचर्स और प्रोमिस: Difference between revisions

Namespaces

More

Page actions

Latest revision as of 16:31, 9 June 2023

Contents

अनुप्रयोग

अंतर्निहित बनाम लुसिड

प्रोमिस पाइपलाइनिंग

रीड-ओनली विचार

थ्रेड-स्पेसिफिक फ्यूचर्स

ब्लॉकिंग बनाम नॉन-ब्लॉकिंग अर्थविज्ञान

संबंधित निर्माण

फ़्यूचर्स के विभिन्न रूपों की अभिव्यक्ति के बीच संबंध

मूल्यांकन रणनीति

एक्टर मॉडल में फ्यूचर्स का सिमेंटिक्स

इतिहास

कार्यान्वयन की सूची

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

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

कोरूटिन्स

चैनल

यह भी देखें

संदर्भ

बाहरी संबंध

Navigation

Navigation

Wiki tools

Wiki tools

@@ Line 1: / Line 1: @@
 {{Short description|Computer science constructs}}
-{{distinguish|वादा सिद्धांत}}
+{{distinguish| फ़्यूचर्स सिद्धांत}}
-[[कंप्यूटर विज्ञान]] में, '''वायदा, वादा, विलम्ब''', और '''स्थगित''' कुछ [[समवर्ती प्रोग्रामिंग भाषा]]ओं में तुल्यकालिक (कंप्यूटर विज्ञान) प्रोग्राम [[निष्पादन (कंप्यूटिंग)]] के लिए उपयोग किए जाने वाले निर्माणों को संदर्भित करता है। वे ऐसी वस्तु का वर्णन करते हैं जो परिणाम के लिए प्रॉक्सी के रूप में कार्य करती है जो प्रारंभ में अज्ञात है,  क्योंकि इसके मान की [[गणना]] अभी तक पूरी नहीं हुई है।
+[[कंप्यूटर विज्ञान]] में, '''फ़्यूचर्स, प्रोमिस, विलम्ब''', और '''स्थगित''' कुछ [[समवर्ती प्रोग्रामिंग भाषा|समवर्ती प्रोग्रामिंग]] लैंग्वेज में तुल्यकालिक (कंप्यूटर विज्ञान) प्रोग्राम [[निष्पादन (कंप्यूटिंग)]] के लिए उपयोग किए जाने वाले निर्माणों को संदर्भित करता है। वे ऐसी ऑब्जेक्ट का वर्णन करते हैं जो परिणाम के लिए प्रॉक्सी के रूप में कार्य करती है जो प्रारंभ में अज्ञात है,  क्योंकि इसके मान की [[गणना]] अभी तक पूरी नहीं हुई है।
-''वादा''  शब्द1976 में डेनियल पी. फ्रीडमैन और डेविड वाइज द्वारा प्रस्तावित किया गया था,<ref>{{cite conference
+''प्रोमिस''  शब्द1976 में डेनियल पी. फ्रीडमैन और डेविड वाइज द्वारा प्रस्तावित किया गया था,<ref>{{cite conference
 | first= Daniel
 | last= Friedman
@@ Line 19: / Line 19: @@
 | title= Parallel Processing Facilities
 | conference= New Directions in Algorithmic Languages, (ed.) Stephen A. Schuman, IRIA, 1976.
-}}</ref>कुछ इसी तरह की अवधारणा वायदा को 1977 में [[हेनरी बेकर (कंप्यूटर वैज्ञानिक)]] और [[कार्ल हेविट]] द्वारा पेपर में पेश किया गया था।<ref>{{cite conference
+}}</ref>कुछ इसी तरह की अवधारणा फ़्यूचर्स को 1977 में [[हेनरी बेकर (कंप्यूटर वैज्ञानिक)]] और [[कार्ल हेविट]] द्वारा पेपर में पेश किया गया था।<ref>{{cite conference
 | author1=Henry Baker
 | author2=Carl Hewitt
@@ Line 34: / Line 34: @@
 }}</ref>
-''वायदा, वादा, विलम्ब,'' और ''स्थगित'' शब्द अक्सर एक दूसरे के स्थान पर उपयोग किए जाते हैं, हालांकि वायदा और वादा के बीच उपयोग में कुछ अंतर नीचे दिए गए हैं। विशेष रूप से, जब उपयोग को अलग किया जाता है, तो वायदा चर का रीड-ओनली प्लेसहोल्डर दृश्य होता है, जबकि वादा लिखने योग्य, [[एकल असाइनमेंट]] कंटेनर होता है जो वायदा के मान को निर्धारित करता है। विशेष रूप से, वायदा को यह निर्दिष्ट किए बिना परिभाषित किया जा सकता है कि कौन सा विशिष्ट वादा अपना मान निर्धारित करेगा, और विभिन्न संभावित वादे किसी दिए गए वायदा का मान निर्धारित कर सकते हैं, हालांकि यह किसी दिए गए वायदा के लिए केवल एक बार किया जा सकता है। अन्य मामलों में वायदा और वादा एक साथ बनाया जाता है और एक दूसरे से जुड़ा होता है: वायदा मान है, वादा वह कार्य है जो मान निर्धारित करता है - अनिवार्य रूप से अतुल्यकालिक फ़ंक्शन (वादे) का वापसी मान (वायदा) है। किसी वायदा के मान को निर्धारित करना उसे विभेदन, पूरा करना या बाइंडिंग भी कहा जाता है।
+''फ़्यूचर्स, प्रोमिस, विलम्ब,'' और ''स्थगित'' शब्द अधिकांशतः एक दूसरे के स्थान पर उपयोग किए जाते हैं, चूंकि फ़्यूचर्स और प्रोमिस के बीच उपयोग में कुछ अंतर नीचे दिए गए हैं। विशेष रूप से, जब उपयोग को अलग किया जाता है, तो फ़्यूचर्स चर का रीड-ओनली प्लेसहोल्डर दृश्य होता है, जबकि प्रोमिस लिखने योग्य, [[एकल असाइनमेंट]] कंटेनर होता है जो फ़्यूचर्स के मान को निर्धारित करता है। विशेष रूप से, फ़्यूचर्स को यह निर्दिष्ट किए बिना परिभाषित किया जा सकता है कि कौन सा विशिष्ट प्रोमिस अपना मान निर्धारित करेगा, और विभिन्न संभावित प्रोमिस किसी दिए गए फ़्यूचर्स का मान निर्धारित कर सकते हैं, चूंकि यह किसी दिए गए फ़्यूचर्स के लिए केवल एक बार किया जा सकता है। अन्य मामलों में फ़्यूचर्स और प्रोमिस एक साथ बनाया जाता है और एक दूसरे से जुड़ा होता है: फ़्यूचर्स मान है, प्रोमिस वह कार्य है जो मान निर्धारित करता है - अनिवार्य रूप से अतुल्यकालिक फ़ंक्शन (प्रोमिस) का वापसी मान (फ़्यूचर्स) है। किसी फ़्यूचर्स के मान को निर्धारित करना उसे विभेदन, पूरा करना या बाइंडिंग भी कहा जाता है।
 == अनुप्रयोग ==
-वायदा और वादे [[कार्यात्मक प्रोग्रामिंग]] और संबंधित प्रतिमानों (जैसे [[तर्क प्रोग्रामिंग]]) में मान (एक वायदा) की गणना की गई थी ( वादा) से अलग करने के लिए, गणना को अधिक नम्य ढंग से करने की विशेष रूप से इसे समानांतर करके अनुमति देता है। बाद में, संचार राउंड ट्रिप से विलंबता को कम करने में, वितरित कंप्यूटिंग में इसका उपयोग पाया गया है। बाद में भी,  [[निरंतरता-गुजरने वाली शैली|निरंतरता-गुजरना वाली शैली]] के बजाय [[प्रत्यक्ष शैली]] में अतुल्यकालिक कार्यक्रमों को लिखने की अनुमति देकर इसे और अधिक उपयोग प्राप्त हुआ है।
+फ़्यूचर्स और प्रोमिस [[कार्यात्मक प्रोग्रामिंग]] और संबंधित प्रतिमानों (जैसे [[तर्क प्रोग्रामिंग|लॉजिक प्रोग्रामिंग]]) में मान (एक फ़्यूचर्स) की गणना की गई थी ( प्रोमिस) से अलग करने के लिए, गणना को अधिक नम्य ढंग से करने की विशेष रूप से इसे समानांतर करके अनुमति देता है। बाद में, संचार राउंड ट्रिप से विलंबता को कम करने में, वितरित कंप्यूटिंग में इसका उपयोग पाया गया है। बाद में भी,  [[निरंतरता-गुजरने वाली शैली|निरंतरता-गुजरना वाली शैली]] के अतिरिक्त [[प्रत्यक्ष शैली]] में अतुल्यकालिक कार्यक्रमों को लिखने की अनुमति देकर इसे और अधिक उपयोग प्राप्त हुआ है।
-== अंतर्निहित बनाम स्पष्ट ==
+== अंतर्निहित बनाम लुसिड ==
-वायदा का उपयोग अंतर्निहित हो सकता है (वायदा का कोई भी उपयोग स्वचालित रूप से अपना मान प्राप्त करता है, जैसे कि यह एक सामान्य [[संदर्भ (प्रोग्रामिंग)]] था) या स्पष्ट (उपयोगकर्ता को मान प्राप्त करने के लिए फ़ंक्शन को कॉल करना चाहिए, जैसे कि <code>get</code> उसकि विधि {{Javadoc:SE|package=java.util.concurrent|java/util/concurrent|Future}} [[जावा (प्रोग्रामिंग भाषा)]] में)। एक स्पष्ट वायदा के मान को प्राप्त करना स्टिंगिंग या जबरदस्ती कहा जा सकता है। स्पष्ट वायदा को पुस्तकालय के रूप में लागू किया जा सकता है, जबकि अंतर्निहित वायदा आमतौर पर भाषा के हिस्से के रूप में लागू किया जाता है।
+फ़्यूचर्स का उपयोग अंतर्निहित हो सकता है (फ़्यूचर्स का कोई भी उपयोग स्वचालित रूप से अपना मान प्राप्त करता है, जैसे कि यह सामान्य [[संदर्भ (प्रोग्रामिंग)|निर्देश (प्रोग्रामिंग)]] था) या लुसिड (उपयोगकर्ता को मान प्राप्त करने के लिए फ़ंक्शन को कॉल निर्देश, जैसे कि <code>get</code> उसकि विधि {{Javadoc:SE|package=java.util.concurrent|java/util/concurrent|Future}} [[जावा (प्रोग्रामिंग भाषा)]] में)। लुसिड फ़्यूचर्स के मान को प्राप्त करना स्टिंगिंग या प्रेरक कहा जाता है। लुसिड फ़्यूचर्स को लाइब्रेरी के रूप में लागू किया जा सकता है, जबकि अंतर्निहित फ़्यूचर्स सामान्यतः भाषा के हिस्से के रूप में लागू किया जाता है।
-मूल बेकर और हेविट पेपर में निहित वायदा का वर्णन किया गया है, जो स्वाभाविक रूप से अभिकलन के [[अभिनेता मॉडल]] और स्मॉलटाक जैसी शुद्ध वस्तु-उन्मुख प्रोग्रामिंग भाषाओं में समर्थित हैं। फ्रीडमैन एंड वाइज पेपर केवल स्पष्ट वायदा का वर्णन करता है, संभवतः स्टॉक हार्डवेयर पर निहित वायदा को कुशलता से लागू करने की कठिनाई को दर्शाता है। कठिनाई यह है कि स्टॉक हार्डवेयर आदिम डेटा प्रकारों जैसे पूर्णांकों के लिए वायदा से नहीं निपटता है। उदाहरण के लिए, एक ऐड इंस्ट्रक्शन को पता नहीं है कि कैसे डील करना है <code>3 + ''future '' factorial(100000)</code>. शुद्ध अभिनेता या वस्तु भाषाओं में भेजकर इस समस्या को हल किया जा सकता है <code>''future '' factorial(100000)</code> संदेश <code>+[3]</code>, जो वायदा को जोड़ने के लिए कहता है <code>3</code> स्वयं के लिए और परिणाम वापस करें। ध्यान दें कि संदेश पासिंग दृष्टिकोण कब की परवाह किए बिना काम करता है <code>factorial(100000)</code> संगणना समाप्त करता है और किसी चुभने/जबरदस्ती की आवश्यकता नहीं होती है।
+मूल बेकर और हेविट पेपर में निहित फ़्यूचर्स का वर्णन किया गया है, जो स्वाभाविक रूप से अभिकलन के [[अभिनेता मॉडल|कर्ता मॉडल]] और स्मॉलटाक जैसी लुसिड ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग लैंग्वेज में समर्थित हैं। फ्रीडमैन एंड वाइज पेपर केवल लुसिड फ़्यूचर्स का वर्णन करता है, संभवतः स्टॉक हार्डवेयर पर निहित फ़्यूचर्स को कुशलता से लागू करने की कठिनाई को दर्शाता है। कठिनाई यह है कि स्टॉक हार्डवेयर आदिम डेटा प्रकारों जैसे पूर्णांकों के लिए फ़्यूचर्स से डील नहीं करता है। उदाहरण के लिए, ऐड इंस्ट्रक्शन को पता नहीं है कि कैसे डील करना है <code>3 + ''future '' factorial(100000),</code> लुसिड कर्ता या ऑब्जेक्ट लैंग्वेज में भेजकर इस समस्या को हल किया जा सकता है <code>''future '' factorial(100000)</code> संदेश <code>+[3]</code>, जो फ़्यूचर्स को जोड़ने के लिए कहता है <code>3</code> स्वयं के लिए और परिणाम वापस करता है। ध्यान दें कि संदेश पासिंग दृष्टिकोण कब की परवाह किए बिना काम करता है <code>factorial(100000)</code> संगणना समाप्त करता है और किसी स्टिंगिंग/प्रेरक की आवश्यकता नहीं होती है।
-== वादा पाइपलाइनिंग ==
+== प्रोमिस पाइपलाइनिंग ==
-वितरित कंप्यूटिंग में वायदा का उपयोग नाटकीय रूप से [[विलंबता (इंजीनियरिंग)]] को कम कर सकता है। उदाहरण के लिए, वायदा पाइपलाइनिंग को सक्षम करता है,<ref>[http://www.erights.org/elib/distrib/pipeline.html Promise Pipelining at erights.org]</ref><ref>[http://c2.com/cgi/wiki?PromisePipelining Promise Pipelining on the C2 wiki]</ref> जैसा कि भाषाओं E (प्रोग्रामिंग भाषा) और [[जूल (प्रोग्रामिंग भाषा)]] में लागू किया गया था, जिसे कॉल-स्ट्रीम भी कहा जाता था<ref name="SIGPLAN pp. 260">{{cite conference
+वितरित कंप्यूटिंग में फ़्यूचर्स का उपयोग प्रभावशाली रूप से [[विलंबता (इंजीनियरिंग)]] को कम कर सकता है। उदाहरण के लिए, फ़्यूचर्स पाइपलाइनिंग को सक्षम करता है,<ref>[http://www.erights.org/elib/distrib/pipeline.html Promise Pipelining at erights.org]</ref><ref>[http://c2.com/cgi/wiki?PromisePipelining Promise Pipelining on the C2 wiki]</ref> जैसा कि लैंग्वेज E (प्रोग्रामिंग भाषा) और [[जूल (प्रोग्रामिंग भाषा)]] में लागू किया गया था, जिसे <ref name="SIGPLAN pp. 260">{{cite conference
 |author1=Barbara Liskov |author2=Liuba Shrira | title= Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems
 | year= 1988
@@ Line 52: / Line 52: @@
 | pages=260–267
 | isbn=0-89791-269-1
-| publisher = ACM}} Also published in ''ACM SIGPLAN Notices'' '''23'''(7).</ref> [[आर्गस (प्रोग्रामिंग भाषा)]] भाषा में।
+| publisher = ACM}} Also published in ''ACM SIGPLAN Notices'' '''23'''(7).</ref> [[आर्गस (प्रोग्रामिंग भाषा)]] भाषा में कॉल-स्ट्रीम भी कहा जाता था।
-पारंपरिक दूरस्थ प्रक्रिया कॉलों से संबंधित एक अभिव्यक्ति पर विचार करें, जैसे:
+पारंपरिक दूरस्थ प्रक्रिया कॉलों से संबंधित अभिव्यक्ति पर विचार करें, जैसे:<पूर्व>
-<पूर्व>
   t3 := (x.a() .c(y.b())
-</पूर्व>
 जिसे बढ़ाया जा सकता है
-<पूर्व>
+  t 1: = x.a();
-  टी 1: = एक्सए ();
+  t 2: = y.b ();
-  टी 2: = वाईबी ();
+  t3t:= t1.c(t2);
-  t3 := t1.c(t2);
+प्रत्येक कथन को भेजे जाने के लिए संदेश की आवश्यकता होती है और अगले कथन के आगे बढ़ने से पहले एक उत्तर प्राप्त होता है। मान लीजिए, उदाहरण के लिए, कि <code>x</code>, <code>y</code>, <code>t1</code>, और <code>t2</code> सभी एक ही रिमोट मशीन पर स्थित हैं। इस मामले में, उस मशीन के लिए दो पूर्ण नेटवर्क राउंड-ट्रिप होनी चाहिए, इससे पहले कि तीसरा स्टेटमेंट निष्पादित हो सके। तीसरा कथन तब उसी रिमोट मशीन के लिए एक और राउंड-ट्रिप का कारण बनता है।
-</पूर्व>
-प्रत्येक कथन को भेजे जाने के लिए एक संदेश की आवश्यकता होती है और अगले कथन के आगे बढ़ने से पहले एक उत्तर प्राप्त होता है। मान लीजिए, उदाहरण के लिए, कि <code>x</code>, <code>y</code>, <code>t1</code>, और <code>t2</code> सभी एक ही रिमोट मशीन पर स्थित हैं। इस मामले में, उस मशीन के लिए दो पूर्ण नेटवर्क राउंड-ट्रिप होनी चाहिए, इससे पहले कि तीसरा स्टेटमेंट निष्पादित हो सके। तीसरा कथन तब उसी रिमोट मशीन के लिए एक और राउंड-ट्रिप का कारण बनेगा।
 फ्यूचर्स का उपयोग करके उपरोक्त अभिव्यक्ति लिखी जा सकती है
-<पूर्व>
+  t 3: = (x <- a ()) <- c (y <- b ())
-  टी 3: = (एक्स <- ए ()) <- सी (वाई <- बी ())
-</पूर्व>
 जिसे बढ़ाया जा सकता है
-<पूर्व>
+  t 1: = x <- a ();
-  टी 1: = एक्स <- ए ();
+  t 2: = y <- b ();
-  टी 2: = वाई <- बी ();
+  t3t:= t1 <- c(t2);
-  t3 := t1 <- c(t2);
+यहाँ प्रयुक्त वाक्य-विन्यास भाषा E का है, जहाँ <code>x <- a()</code> संदेश भेजने का मतलब है <code>a()</code> अतुल्यकालिक रूप से <code>x</code>. सभी तीन चरों को तुरंत उनके परिणामों के लिए फ़्यूचर्स सौंपा जाता है, और निष्पादन बाद के बयानों के लिए आगे बढ़ता है। बाद के मान को हल करने का प्रयास करता है <code>t3</code> विलम्ब हो सकती है; हालाँकि, पाइपलाइनिंग आवश्यक राउंड-ट्रिप की संख्या को कम कर सकती है। यदि, जैसा कि पिछले उदाहरण में है, <code>x</code>, <code>y</code>, <code>t1</code>, और <code>t2</code> सभी एक ही रिमोट मशीन पर स्थित हैं, पाइपलाइन कार्यान्वयन गणना <code>t3</code> तीन के अतिरिक्त एक राउंड-ट्रिप के साथ कर सकता है। क्योंकि सभी तीन संदेश उन वस्तुओं के लिए नियत हैं जो एक ही रिमोट मशीन पर हैं, केवल एक अनुरोध भेजने की आवश्यकता है और परिणाम के साथ केवल एक प्रतिक्रिया प्राप्त करने की आवश्यकता है। भेजना <code>t1 <- c(t2)</code> ब्लॉक भी नहीं करेंगे <code>t1</code> और <code>t2</code> एक दूसरे के लिए अलग-अलग मशीनों पर थे, या करने के लिए <code>x</code> या <code>y</code>
-</पूर्व>
-यहाँ प्रयुक्त वाक्य-विन्यास भाषा E का है, जहाँ <code>x <- a()</code> संदेश भेजने का मतलब है <code>a()</code> अतुल्यकालिक रूप से <code>x</code>. सभी तीन चरों को तुरंत उनके परिणामों के लिए वायदा सौंपा जाता है, और निष्पादन बाद के बयानों के लिए आगे बढ़ता है। बाद में के मान को हल करने का प्रयास करता है <code>t3</code> विलम्ब हो सकती है; हालाँकि, पाइपलाइनिंग आवश्यक राउंड-ट्रिप की संख्या को कम कर सकती है। यदि, जैसा कि पिछले उदाहरण में है, <code>x</code>, <code>y</code>, <code>t1</code>, और <code>t2</code> सभी एक ही रिमोट मशीन पर स्थित हैं, एक पाइपलाइन कार्यान्वयन गणना कर सकता है <code>t3</code> तीन के बजाय एक राउंड-ट्रिप के साथ। क्योंकि सभी तीन संदेश उन वस्तुओं के लिए नियत हैं जो एक ही रिमोट मशीन पर हैं, केवल एक अनुरोध भेजने की आवश्यकता है और परिणाम के साथ केवल एक प्रतिक्रिया प्राप्त करने की आवश्यकता है। भेजना <code>t1 <- c(t2)</code> ब्लॉक भी नहीं करेंगे <code>t1</code> और <code>t2</code> एक दूसरे के लिए अलग-अलग मशीनों पर थे, या करने के लिए <code>x</code> या <code>y</code>.
+प्रोमिस पाइपलाइनिंग को समानांतर अतुल्यकालिक मैसेज पासिंग से अलग किया जाना चाहिए। समांतर संदेश का समर्थन करने वाली प्रणाली में लेकिन पाइपलाइनिंग नहीं, संदेश भेजता है <code>x <- a()</code> और <code>y <- b()</code> उपरोक्त उदाहरण में समानांतर में आगे बढ़ सकता है, लेकिन प्रेषण <code>t1 <- c(t2)</code> दोनों तक इंतजार करना होगा <code>t1</code> और <code>t2</code> प्राप्त किया गया था, तब भी <code>x</code>, <code>y</code>, <code>t1</code>, और <code>t2</code> एक ही रिमोट मशीन पर हैं। कई संदेशों को सम्मिलित करने वाली अधिक जटिल स्थितियों में पाइपलाइनिंग का सापेक्ष विलंबता लाभ और भी अधिक हो जाता है।
-वादा पाइपलाइनिंग को समानांतर एसिंक्रोनस मैसेज पासिंग से अलग किया जाना चाहिए। समांतर संदेश का समर्थन करने वाली प्रणाली में लेकिन पाइपलाइनिंग नहीं, संदेश भेजता है <code>x <- a()</code> और <code>y <- b()</code> उपरोक्त उदाहरण में समानांतर में आगे बढ़ सकता है, लेकिन का प्रेषण <code>t1 <- c(t2)</code> दोनों तक इंतजार करना होगा <code>t1</code> और <code>t2</code> प्राप्त किया गया था, तब भी <code>x</code>, <code>y</code>, <code>t1</code>, और <code>t2</code> एक ही रिमोट मशीन पर हैं। कई संदेशों को शामिल करने वाली अधिक जटिल स्थितियों में पाइपलाइनिंग का सापेक्ष विलंबता लाभ और भी अधिक हो जाता है।
+प्रोमिस पाइपलाइनिंग को कर्ता सिस्टम में पाइपलाइन संदेश प्रसंस्करण के साथ भ्रमित नहीं होना चाहिए, जहां कर्ता के लिए वर्तमान संदेश की प्रक्रिया पूरी करने से पहले अगले संदेश के लिए एक व्यवहार को निर्दिष्ट करना और निष्पादित करना संभव है।
-वादा पाइपलाइनिंग को अभिनेता मॉडल के साथ भ्रमित नहीं किया जाना चाहिए # अभिनेता सिस्टम में संदेश आगमन के आदेश पर कोई आवश्यकता नहीं है, जहां एक अभिनेता के लिए वर्तमान संदेश की प्रक्रिया पूरी करने से पहले अगले संदेश के लिए व्यवहार को निर्दिष्ट करना और निष्पादित करना संभव है।
+== रीड-ओनली विचार ==
+कुछ प्रोग्रामिंग लैंग्वेज जैसे कि Oz (प्रोग्रामिंग भाषा), E (प्रोग्रामिंग भाषा), और [[एम्बिएंट टॉक]] में, फ़्यूचर्स का रीड-ओनली दृश्य प्राप्त करना संभव है, जो हल होने पर इसके मान को पढ़ने की अनुमति देता है, लेकिन इसे हल करने की अनुमति नहीं देता है:
-== केवल-पढ़ने के विचार ==
+* Oz में, <code>!!</code> ऑपरेटर का उपयोग रीड-ओनली दृश्य प्राप्त करने के लिए किया जाता है।
-कुछ प्रोग्रामिंग भाषाओं जैसे कि ओज़ (प्रोग्रामिंग भाषा), ई (प्रोग्रामिंग भाषा), और [[एम्बिएंट टॉक]] में, वायदा का रीड-ओनली दृश्य प्राप्त करना संभव है, जो हल होने पर इसके मान को पढ़ने की अनुमति देता है, लेकिन इसे हल करने की अनुमति नहीं देता है:
+* E और एम्बिएंटटॉक में, फ़्यूचर्स को प्रॉमिस/रिज़ॉल्वर जोड़ी कहे जाने वाले मानों के एक जोड़े द्वारा दर्शाया जाता है। प्रोमिस रीड-ओनली दृश्य का प्रतिनिधित्व करता है, और फ़्यूचर्स के मान को निर्धारित करने के लिए रिज़ॉल्वर की आवश्यकता होती है।
+* [[सी ++ 11|C ++ 11]]  में <code>std::future</code> रीड-ओनली दृश्य प्रदान करता है। मान सीधे <code>std::प्रोमिस</code>  का उपयोग करके सेट किया गया है, या उपयोग करके फ़ंक्शन कॉल के परिणाम पर सेट करें <code>std::packaged_task</code> या <code>std::async</code>.
+* संस्करण 1.5 के रूप में [[डोजो टूलकिट]] के डिफर्ड एपीआई में, उपभोक्ता-मात्र प्रोमिस ऑब्जेक्ट रीड-ओनली दृश्य का प्रतिनिधित्व करती है।<ref>{{citation |url= http://www.sitepen.com/blog/2010/05/03/robust-promises-with-dojo-deferred-1-5/ |publisher= Site Pen |date= 2010-05-03 |title= Robust promises with Dojo deferred}}</ref>
+* [[ऐलिस एमएल]] में, फ़्यूचर्स रीड-ओनली दृश्य प्रदान करता है, जबकि प्रोमिस में फ़्यूचर्स और फ़्यूचर्स को हल करने की क्षमता दोनों सम्मिलित हैं<ref name= "Alice ML promise">{{citation |chapter-url= http://www.ps.uni-sb.de/alice/manual/library/promise.html |title= Alice Manual |chapter= Promise |publisher= Uni-SB |place= DE |access-date= 21 March 2007 |archive-date= 8 October 2008 |archive-url= https://web.archive.org/web/20081008005201/http://www.ps.uni-sb.de/alice/manual/library/promise.html |url-status= dead }}</ref><ref name= "Alice ML future">{{citation |chapter-url= http://www.ps.uni-sb.de/alice/manual/library/future.html |title= Alice manual |chapter= Future |publisher= Uni-SB |place= DE |access-date= 21 March 2007 |archive-date= 6 October 2008 |archive-url= https://web.archive.org/web/20081006231223/http://www.ps.uni-sb.de/alice/manual/library/future.html |url-status= dead }}</ref>
+* .NET Framework 4.0 में <code>System.Threading.Tasks.Task<T></code> रीड-ओनली दृश्य का प्रतिनिधित्व करता है। मान को हल करके किया जा सकता है <code>System.Threading.Tasks.TaskCompletionSource<T></code>.
-* ओज में, <code>!!</code> ऑपरेटर का उपयोग रीड-ओनली दृश्य प्राप्त करने के लिए किया जाता है।
+रीड-ओनली दृष्टिकोण के लिए समर्थन कम से कम विशेषाधिकार के सिद्धांत के अनुरूप है, क्योंकि यह मान को सेट करने की क्षमता को [[ विषय (अभिगम नियंत्रण) |विषय (अभिगम नियंत्रण)]] तक सीमित करने में सक्षम बनाता है जिसे इसे सेट करने की आवश्यकता होती है। ऐसी प्रणाली में जो पाइपलाइनिंग का भी समर्थन करती है, अतुल्यकालिक संदेश (परिणाम के साथ) के प्रेषक को परिणाम के लिए रीड-ओनली प्रोमिस प्राप्त होता है, और संदेश का लक्ष्य रिज़ॉल्वर प्राप्त करता है।
-* ई और एम्बिएंटटॉक में, वायदा को मूल्यों की एक जोड़ी द्वारा दर्शाया जाता है जिसे वादा/रिज़ॉल्वर जोड़ी कहा जाता है। वादा केवल-पढ़ने के दृश्य का प्रतिनिधित्व करता है, और वायदा के मान को निर्धारित करने के लिए रिज़ॉल्वर की आवश्यकता होती है।
-* [[सी ++ 11]] ए में <code>std::future</code> रीड-ओनली दृश्य प्रदान करता है। मान सीधे a का उपयोग करके सेट किया गया है <code>std::promise</code>, या उपयोग करके फ़ंक्शन कॉल के परिणाम पर सेट करें <code>std::packaged_task</code> या <code>std::async</code>.
-* संस्करण 1.5 के रूप में [[डोजो टूलकिट]] के डिफर्ड एपीआई में, एक उपभोक्ता-मात्र वादा वस्तु केवल-पढ़ने के दृश्य का प्रतिनिधित्व करती है।<ref>{{citation |url= http://www.sitepen.com/blog/2010/05/03/robust-promises-with-dojo-deferred-1-5/ |publisher= Site Pen |date= 2010-05-03 |title= Robust promises with Dojo deferred}}</ref>
-* [[ऐलिस एमएल]] में, वायदा केवल पढ़ने के लिए दृश्य प्रदान करता है, जबकि एक वादे में वायदा और वायदा को हल करने की क्षमता दोनों शामिल हैं<ref name= "Alice ML promise">{{citation |chapter-url= http://www.ps.uni-sb.de/alice/manual/library/promise.html |title= Alice Manual |chapter= Promise |publisher= Uni-SB |place= DE |access-date= 21 March 2007 |archive-date= 8 October 2008 |archive-url= https://web.archive.org/web/20081008005201/http://www.ps.uni-sb.de/alice/manual/library/promise.html |url-status= dead }}</ref><ref name= "Alice ML future">{{citation |chapter-url= http://www.ps.uni-sb.de/alice/manual/library/future.html |title= Alice manual |chapter= Future |publisher= Uni-SB |place= DE |access-date= 21 March 2007 |archive-date= 6 October 2008 |archive-url= https://web.archive.org/web/20081006231223/http://www.ps.uni-sb.de/alice/manual/library/future.html |url-status= dead }}</ref>
-* .NET फ्रेमवर्क 4.0 में <code>System.Threading.Tasks.Task<T></code> केवल-पढ़ने के दृश्य का प्रतिनिधित्व करता है। मान को हल करके किया जा सकता है <code>System.Threading.Tasks.TaskCompletionSource<T></code>.
-रीड-ओनली व्यूज के लिए समर्थन कम से कम विशेषाधिकार के सिद्धांत के अनुरूप है, क्योंकि यह मान को सेट करने की क्षमता को [[ विषय (अभिगम नियंत्रण) ]] तक सीमित करने में सक्षम बनाता है जिसे इसे सेट करने की आवश्यकता होती है। ऐसी प्रणाली में जो पाइपलाइनिंग का भी समर्थन करती है, एक अतुल्यकालिक संदेश (परिणाम के साथ) के प्रेषक को परिणाम के लिए केवल-पढ़ने का वादा प्राप्त होता है, और संदेश का लक्ष्य रिज़ॉल्वर प्राप्त करता है।
+== थ्रेड-स्पेसिफिक फ्यूचर्स ==
+ऐलिस एमएल (प्रोग्रामिंग लैंग्वेज) जैसी कुछ भाषाएं, फ्यूचर्स को परिभाषित करती हैं जो विशिष्ट थ्रेड से जुड़े होते हैं जो फ़्यूचर्स के मान की गणना करता है।<ref name= "Alice ML future" />यह संगणना या तो उत्सुकता से प्रारंभ हो सकती है जब फ़्यूचर्स बनाया जाता है, या [[आलसी मूल्यांकन|शिथिल मूल्यांकन से]] जब इसके मान की पहली आवश्यकता होती है। विलंबित संगणना के अर्थ में शिथिल फ़्यूचर्स [[थंक (कार्यात्मक प्रोग्रामिंग)]] के समान है।
-== थ्रेड-विशिष्ट फ्यूचर्स ==
+ऐलिस एमएल भी फ़्यूचर्स का समर्थन करता है जिसे किसी भी थ्रेड से हल किया जा सकता है, और इन प्रोमिस को कॉल करता है।<ref name= "Alice ML promise" />प्रोमिस का यह उपयोग ऊपर वर्णित E में इसके उपयोग से अलग है। ऐलिस में, प्रोमिस रीड-ओनली दृश्य नहीं है, और प्रोमिस पाइपलाइनिंग असमर्थित है। इसके अतिरिक्त, फ़्यूचर्स के लिए पाइपलाइनिंग स्वाभाविक रूप से होती है, जिसमें प्रोमिस से जुड़े हैं।
-ऐलिस (प्रोग्रामिंग लैंग्वेज) जैसी कुछ भाषाएं, फ्यूचर्स को परिभाषित करती हैं जो एक विशिष्ट थ्रेड से जुड़े होते हैं जो वायदा के मान की गणना करता है।<ref name= "Alice ML future" />यह संगणना या तो [[उत्सुक मूल्यांकन]] शुरू कर सकती है जब वायदा बनाया जाता है, या [[आलसी मूल्यांकन]] जब इसके मान की पहली आवश्यकता होती है। विलंबित संगणना के अर्थ में एक आलसी वायदा [[थंक (कार्यात्मक प्रोग्रामिंग)]] के समान है।
-ऐलिस एमएल भी वायदा का समर्थन करता है जिसे किसी भी धागे से हल किया जा सकता है, और इन वादों को कॉल करता है।<ref name= "Alice ML promise" />वादा का यह उपयोग ई में इसके उपयोग से अलग है जैसा कि #रीड-ओनली व्यूज में वर्णित है। ऐलिस में, एक वादा केवल पढ़ने के लिए दृश्य नहीं है, और वादा पाइपलाइनिंग असमर्थित है। इसके बजाय, वायदा के लिए पाइपलाइनिंग स्वाभाविक रूप से होती है, जिसमें वादों से जुड़े लोग भी शामिल हैं।
+== ब्लॉकिंग बनाम नॉन-ब्लॉकिंग अर्थविज्ञान ==
+यदि फ़्यूचर्स के मान को अतुल्यकालिक रूप से एक्सेस किया जाता है, उदाहरण के लिए इसे एक संदेश भेजकर, या लुसिड रूप से इसके निर्माण के लिए प्रतीक्षा करके जैसे कि <code>when</code>E में, तो संदेश प्राप्त होने या प्रतीक्षा पूरी होने से पहले फ़्यूचर्स को हल करने में विलम्ब करने में कोई कठिनाई नहीं है। विशुद्ध रूप से अतुल्यकालिक प्रणालियों जैसे लुसिड कर्ता लैंग्वेज में माना जाने वाला यह एकमात्र मामला है।
-== ब्लॉकिंग बनाम नॉन-ब्लॉकिंग शब्दार्थ ==
+चूंकि, कुछ प्रणालियों में फ़्यूचर्स के मान को तुरंत या समकालिक रूप से एक्सेस करने का प्रयास करना भी संभव हो सकता है। फिर डिजाइन विकल्प बनाया जाना है:
-यदि वायदा के मान को अतुल्यकालिक रूप से एक्सेस किया जाता है, उदाहरण के लिए इसे एक संदेश भेजकर, या स्पष्ट रूप से इसके निर्माण के लिए प्रतीक्षा करके जैसे कि <code>when</code> ई में, तो संदेश प्राप्त होने या प्रतीक्षा पूरी होने से पहले वायदा को हल करने में विलम्ब करने में कोई कठिनाई नहीं है। विशुद्ध रूप से अतुल्यकालिक प्रणालियों जैसे शुद्ध अभिनेता भाषाओं में माना जाने वाला यह एकमात्र मामला है।
-हालांकि, कुछ प्रणालियों में वायदा के मान को तुरंत या समकालिक रूप से एक्सेस करने का प्रयास करना भी संभव हो सकता है। फिर एक डिजाइन विकल्प बनाया जाना है:
+* पहुंच वर्तमान थ्रेड या प्रक्रिया को तब तक अवरुद्ध कर सकती है जब तक कि फ़्यूचर्स हल न हो जाए (संभवतः टाइमआउट के साथ)। यह भाषा Oz (प्रोग्रामिंग भाषा) में डेटा प्रवाह चर का अर्थविज्ञान है।
+* प्रयास की गई सिंक्रोनस एक्सेस हमेशा त्रुटि का संकेत देती है, उदाहरण के लिए एक अपवाद संचालन (कंप्यूटर विज्ञान) है। यह E में दूरस्थ प्रोमिस का अर्थविज्ञान है।<ref>{{citation |url=http://wiki.erights.org/wiki/Promise |title= Promise |publisher= E rights}}</ref>
+* संभावित रूप से, यदि फ़्यूचर्स पहले से ही हल हो गया है, तो पहुंच सफल हो सकती है, लेकिन यदि ऐसा नहीं है तो त्रुटि का संकेत मिलता है। यह गैर-निर्धारणवाद और [[दौड़ की स्थिति|रेस स्थिति]] की संभावना को पेश करने का नुकसान होगा, और यह असामान्य डिजाइन विकल्प प्रतीत होता है।
-* पहुंच वर्तमान थ्रेड या प्रक्रिया को तब तक अवरुद्ध कर सकती है जब तक कि वायदा हल न हो जाए (संभवतः टाइमआउट के साथ)। यह भाषा ओज़ (प्रोग्रामिंग भाषा) में डेटा प्रवाह चर का शब्दार्थ है।
+पहली संभावना के उदाहरण के रूप में, C ++ 11 में, थ्रेड जिसे फ़्यूचर्स के मान की आवश्यकता होती है, तब तक ब्लॉक कर सकता है जब तक कि यह कॉल करके सदस्य कार्य  <code>wait()</code> या <code>get()</code> उपलब्ध न हो। आप अनिश्चितकालीन ब्लॉकिंग से बचने के लिए <code>wait_for()</code> या <code>wait_until()</code> सदस्य फ़ंक्शंस का उपयोग करके वेट पर एक टाइमआउट भी निर्दिष्ट कर सकते हैं। यदि फ़्यूचर्स कॉल से <code>std::async</code> के लिए उत्पन्न हुआ है तो अवरुद्ध प्रतीक्षा (बिना टाइमआउट के) प्रतीक्षा थ्रेड पर परिणाम की गणना करने के लिए फ़ंक्शन के सिंक्रोनस आह्वान का कारण बन सकता है।
-* प्रयास की गई सिंक्रोनस एक्सेस हमेशा एक त्रुटि का संकेत दे सकती है, उदाहरण के लिए एक अपवाद फेंकना (कंप्यूटर विज्ञान)। यह ई में दूरस्थ वादों का शब्दार्थ है।<ref>{{citation |url=http://wiki.erights.org/wiki/Promise |title= Promise |publisher= E rights}}</ref>
-* संभावित रूप से, यदि वायदा पहले से ही हल हो गया है, तो पहुंच सफल हो सकती है, लेकिन यदि ऐसा नहीं है तो त्रुटि का संकेत मिलता है। यह गैर-निर्धारणवाद और [[दौड़ की स्थिति]] की संभावना को पेश करने का नुकसान होगा, और यह एक असामान्य डिजाइन विकल्प प्रतीत होता है।
-पहली संभावना के उदाहरण के रूप में, सी ++ 11 में, एक थ्रेड जिसे वायदा के मान की आवश्यकता होती है, तब तक ब्लॉक कर सकता है जब तक कि यह कॉल करके उपलब्ध न हो <code>wait()</code> या <code>get()</code> सदस्य कार्य। आप का उपयोग करके प्रतीक्षा पर टाइमआउट भी निर्दिष्ट कर सकते हैं <code>wait_for()</code> या <code>wait_until()</code> सदस्य कार्य अनिश्चितकालीन अवरोधन से बचने के लिए। अगर वायदा एक कॉल से उत्पन्न हुआ <code>std::async</code> तो एक अवरुद्ध प्रतीक्षा (बिना टाइमआउट के) प्रतीक्षा थ्रेड पर परिणाम की गणना करने के लिए फ़ंक्शन के सिंक्रोनस आमंत्रण का कारण बन सकती है।
+== संबंधित निर्माण ==
+फ्यूचर्स [[तुल्यकालन आदिम]] "इवेंट्स" (तुल्यकालिक प्रिमिटिव) का विशेष मामला है, जिसे केवल एक बार पूरा किया जा सकता है। सामान्यतः, घटनाओं को प्रारंभिक खाली स्थिति में रीसेट किया जा सकता है और इस प्रकार, आप जितनी बार चाहें उतनी बार पूरा कर सकते हैं।<ref>[http://aosabook.org/en/500L/a-web-crawler-with-asyncio-coroutines.html#fn13 500 lines or less, "A Web Crawler With asyncio Coroutines" by A. Jesse Jiryu Davis and Guido van Rossum] says "implementation uses an asyncio.Event in place of the Future shown here. The difference is an Event can be reset, whereas a Future cannot transition from resolved back to pending."</ref>
-== संबंधित निर्माण ==
+I-var (जैसा कि भाषा Id (प्रोग्रामिंग भाषा) में है) एक फ़्यूचर्स है जो ऊपर परिभाषित अर्थविज्ञान को अवरुद्ध करता है। I- संरचना [[डेटा संरचना]] है जिसमें I-var होते हैं।संबंधित तुल्यकालन निर्माण जिसे विभिन्न मानों के साथ कई बार सेट किया जा सकता है, उसे M-var कहा जाता है। M-vars वर्तमान मान को लेने या रखने के लिए परमाणु संचालन का समर्थन करते हैं, जहाँ मान लेने से M-var वापस अपनी प्रारंभिक खाली स्थिति में सेट हो जाता है।'''<ref>{{citation |url= http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent-MVar.html |publisher= Haskell |title= Control Concurrent MVar |url-status= dead |archive-url= https://web.archive.org/web/20090418025331/http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent-MVar.html |archive-date= 18 April 2009 |df= dmy-all }}</ref>'''
-फ्यूचर्स [[तुल्यकालन आदिम]] इवेंट (तुल्यकालिक प्रिमिटिव) का एक विशेष मामला है, जिसे केवल एक बार पूरा किया जा सकता है। सामान्य तौर पर, घटनाओं को प्रारंभिक खाली स्थिति में रीसेट किया जा सकता है और इस प्रकार, आप जितनी बार चाहें उतनी बार पूरा कर सकते हैं।<ref>[http://aosabook.org/en/500L/a-web-crawler-with-asyncio-coroutines.html#fn13 500 lines or less, "A Web Crawler With asyncio Coroutines" by A. Jesse Jiryu Davis and Guido van Rossum] says "implementation uses an asyncio.Event in place of the Future shown here. The difference is an Event can be reset, whereas a Future cannot transition from resolved back to pending."</ref>
-एक I-var (जैसा कि भाषा Id (प्रोग्रामिंग भाषा) में है) एक वायदा है जो ऊपर परिभाषित शब्दार्थ को अवरुद्ध करता है। I- संरचना एक [[डेटा संरचना]] है जिसमें I-var होते हैं। एक संबंधित तुल्यकालन निर्माण जिसे विभिन्न मानों के साथ कई बार सेट किया जा सकता है, उसे M-var कहा जाता है। M-vars वर्तमान मान को लेने या रखने के लिए परमाणु संचालन का समर्थन करते हैं, जहाँ मान लेने से M-var वापस अपनी प्रारंभिक खाली स्थिति में सेट हो जाता है।<ref>{{citation |url= http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent-MVar.html |publisher= Haskell |title= Control Concurrent MVar |url-status= dead |archive-url= https://web.archive.org/web/20090418025331/http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent-MVar.html |archive-date= 18 April 2009 |df= dmy-all }}</ref>
+समवर्ती लॉजिक चर फ़्यूचर्स के समान है, लेकिन एकीकरण (कंप्यूटिंग) द्वारा उसी तरह लॉजिक प्रोग्रामिंग में लॉजिक चर के रूप में अद्यतन किया जाता है। इस प्रकार इसे एक से अधिक बार अविवेकी मान के लिए बाध्य किया जा सकता है, लेकिन एक खाली या अनसुलझे स्थिति में वापस सेट नहीं किया जा सकता है। Oz के डेटाफ्लो चर समवर्ती लॉजिक चर के रूप में कार्य करते हैं, और उपरोक्त वर्णित शब्दार्थों को अवरुद्ध भी करते हैं।
-एक समवर्ती तर्क चर {{Citation needed|reason=It is not obvious to the reader where a definition and description of a concurrent logic variable can be found.|date=March 2018}} वायदा के समान है, लेकिन एकीकरण (कंप्यूटिंग) द्वारा अद्यतन किया जाता है, उसी तरह तर्क प्रोग्रामिंग में तर्क चर के रूप में। इस प्रकार इसे एक से अधिक बार अविवेकी मूल्यों के लिए बाध्य किया जा सकता है, लेकिन एक खाली या अनसुलझे स्थिति में वापस सेट नहीं किया जा सकता है। ओज़ के डेटाफ्लो चर समवर्ती तर्क चर के रूप में कार्य करते हैं, और उपरोक्त वर्णित शब्दार्थों को अवरुद्ध भी करते हैं।
-एक समवर्ती बाधा चर, [[बाधा तर्क प्रोग्रामिंग]] का समर्थन करने के लिए समवर्ती तर्क चर का सामान्यीकरण है: बाधा को कई बार संकुचित किया जा सकता है, जो संभावित मूल्यों के छोटे सेट का संकेत देता है। आम तौर पर एक थंक निर्दिष्ट करने का एक तरीका होता है जो तब चलना चाहिए जब भी बाधा आगे संकुचित हो; बाधा प्रचार का समर्थन करने के लिए इसकी आवश्यकता है।
+समवर्ती प्रतिबंध चर, [[बाधा तर्क प्रोग्रामिंग|प्रतिबंध लॉजिक प्रोग्रामिंग]] का समर्थन करने के लिए समवर्ती लॉजिक चर का सामान्यीकरण है: प्रतिबंध को कई बार संकुचित किया जा सकता है, जो संभावित मान के छोटे सेट का संकेत देता है। सामान्यतः थंक निर्दिष्ट करने का तरीका होता है जो तब चलना चाहिए जब भी प्रतिबंध आगे संकुचित हो; प्रतिबंध प्रचार का समर्थन करने के लिए इसकी आवश्यकता है।
-== वायदा के विभिन्न रूपों की अभिव्यक्ति के बीच संबंध ==
+== फ़्यूचर्स के विभिन्न रूपों की अभिव्यक्ति के बीच संबंध ==
-उत्सुक थ्रेड-विशिष्ट फ्यूचर्स को गैर-थ्रेड-विशिष्ट फ्यूचर्स में सीधे लागू किया जा सकता है, वायदा बनाने के साथ ही मान की गणना करने के लिए थ्रेड बनाकर। इस मामले में क्लाइंट को रीड-ओनली दृश्य वापस करना वांछनीय है, ताकि केवल नव निर्मित धागा इस वायदा को हल करने में सक्षम हो।
+व्यग्र थ्रेड-विशिष्ट फ्यूचर्स को गैर-थ्रेड-विशिष्ट फ्यूचर्स में फ़्यूचर्स बनाने के साथ ही मान की गणना करने के लिए थ्रेड बनाकर सीधे लागू किया जा सकता है। इस मामले में क्लाइंट को रीड-ओनली दृश्य वापस करना वांछनीय है, जिससे कि केवल नव निर्मित थ्रेड इस फ़्यूचर्स को हल करने में सक्षम हो।
-गैर-थ्रेड-विशिष्ट वायदा के संदर्भ में अंतर्निहित आलसी थ्रेड-विशिष्ट वायदा (उदाहरण के लिए ऐलिस एमएल द्वारा प्रदान किया गया) को लागू करने के लिए, यह निर्धारित करने के लिए एक तंत्र की आवश्यकता होती है कि वायदा के मान की पहली आवश्यकता कब है (उदाहरण के लिए, <code>WaitNeeded</code> ओज में निर्माण<ref>{{citation |url= http://www.mozart-oz.org/home/doc/base/node13.html |title= WaitNeeded |publisher= Mozart Oz |access-date= 21 March 2007 |archive-date= 17 May 2013 |archive-url= https://web.archive.org/web/20130517004703/http://www.mozart-oz.org/home/doc/base/node13.html |url-status= dead }}</ref>). यदि सभी मान वस्तुएं हैं, तो पारदर्शी अग्रेषण वस्तुओं को लागू करने की क्षमता पर्याप्त है, क्योंकि फारवर्डर को भेजा गया पहला संदेश इंगित करता है कि वायदा के मान की आवश्यकता है।
+गैर-थ्रेड-विशिष्ट फ़्यूचर्स के संदर्भ में अंतर्निहित शिथिल थ्रेड-विशिष्ट फ़्यूचर्स (उदाहरण के लिए ऐलिस एमएल द्वारा प्रदान किया गया) को लागू करने के लिए, यह निर्धारित करने के लिए तंत्र की आवश्यकता होती है कि फ़्यूचर्स के मान की पहली आवश्यकता कब है (उदाहरण के लिए, <code>WaitNeeded</code> Oz में निर्माण<ref>{{citation |url= http://www.mozart-oz.org/home/doc/base/node13.html |title= WaitNeeded |publisher= Mozart Oz |access-date= 21 March 2007 |archive-date= 17 May 2013 |archive-url= https://web.archive.org/web/20130517004703/http://www.mozart-oz.org/home/doc/base/node13.html |url-status= dead }}</ref>). यदि सभी मान वस्तुएं हैं, तो पारदर्शी अग्रेषण वस्तुओं को लागू करने की क्षमता पर्याप्त है, क्योंकि फारवर्डर को भेजा गया पहला संदेश इंगित करता है कि फ़्यूचर्स के मान की आवश्यकता है।
-गैर-थ्रेड-विशिष्ट वायदा को थ्रेड-विशिष्ट वायदा में लागू किया जा सकता है, यह मानते हुए कि सिस्टम संदेश पासिंग का समर्थन करता है, हल करने वाले थ्रेड को वायदा के अपने थ्रेड पर एक संदेश भेजकर। हालाँकि, इसे अनावश्यक जटिलता के रूप में देखा जा सकता है। थ्रेड्स पर आधारित प्रोग्रामिंग भाषाओं में, सबसे अभिव्यंजक दृष्टिकोण गैर-थ्रेड-विशिष्ट वायदा, रीड-ओनली व्यूज़, और या तो एक प्रतीक्षारत निर्माण, या पारदर्शी अग्रेषण के लिए समर्थन प्रदान करने के लिए प्रतीत होता है।
+गैर-थ्रेड-विशिष्ट फ़्यूचर्स को थ्रेड-विशिष्ट फ़्यूचर्स में लागू किया जा सकता है, यह मानते हुए कि सिस्टम संदेश पासिंग का हल करने वाले थ्रेड को फ़्यूचर्स के अपने थ्रेड पर एक संदेश भेजकर समर्थन करता है। हालाँकि, इसे अनावश्यक जटिलता के रूप में देखा जा सकता है। थ्रेड्स पर आधारित प्रोग्रामिंग लैंग्वेज में, सबसे अभिव्यंजक दृष्टिकोण गैर-थ्रेड-विशिष्ट फ़्यूचर्स, रीड-ओनली व्यूज़, और या तो प्रतीक्षारत निर्माण, या पारदर्शी अग्रेषण के लिए समर्थन प्रदान करने के लिए प्रतीत होता है।
 == मूल्यांकन रणनीति ==
-{{further|Call by future}}
+{{further|फ़्यूचर्स के अनुसार कॉल}}
-वायदा की [[मूल्यांकन रणनीति]], जिसे वायदा की कॉल कहा जा सकता है, गैर-नियतात्मक है: वायदा के मान का मूल्यांकन वायदा के निर्माण और उसके मान के उपयोग के बीच कुछ समय में किया जाएगा, लेकिन सटीक समय निर्धारित नहीं किया गया है पहले से और रन से रन में बदल सकते हैं। जैसे ही वायदा बनाया जाता है (उत्सुक मूल्यांकन) या केवल जब मान वास्तव में आवश्यक होता है (आलसी मूल्यांकन) के रूप में गणना शुरू हो सकती है, और एक रन में आंशिक रूप से निलंबित या निष्पादित किया जा सकता है। एक बार वायदा का मान असाइन किए जाने के बाद, वायदा की पहुंच पर इसकी पुन: गणना नहीं की जाती है; यह [[जरूरत से बुलाओ]] में उपयोग किए जाने वाले [[memoization]] की तरह है।
+फ़्यूचर्स की [[मूल्यांकन रणनीति]], जिसे फ़्यूचर्स की कॉल कहा जा सकता है, गैर-नियतात्मक है: फ़्यूचर्स के मान का मूल्यांकन फ़्यूचर्स के निर्माण और उसके मान के उपयोग के बीच कुछ समय में किया जाएगा, लेकिन सटीक समय निर्धारित नहीं किया गया है पहले से और रन से रन में बदल सकते हैं। जैसे ही फ़्यूचर्स बनाया जाता है (व्यग्र मूल्यांकन) या केवल जब मान वास्तव में आवश्यक होता है (शिथिल मूल्यांकन) के रूप में गणना प्रारंभ हो सकती है, और रन में आंशिक रूप से निलंबित या निष्पादित किया जाता है। एक बार फ़्यूचर्स का मान असाइन किए जाने के बाद, फ़्यूचर्स की पहुंच पर इसकी पुन: गणना नहीं की जाती है; यह [[जरूरत से बुलाओ|कॉल बाय नीड]] में उपयोग किए जाने वाले [[memoization|मेमोइज़ेशन]] की तरह है।
-ए '{{visible anchor|lazy future}} एक ऐसा वायदा है जो नियतात्मक रूप से आलसी मूल्यांकन शब्दार्थ है: वायदा के मान की गणना तब शुरू होती है जब मान की पहली आवश्यकता होती है, जैसा कि जरूरत से कॉल में होता है। आलसी वायदा उन भाषाओं में उपयोग किया जाता है जिनकी मूल्यांकन रणनीति डिफ़ॉल्ट रूप से आलसी नहीं होती है। उदाहरण के लिए, C++11 में इस तरह के लेज़ी फ्यूचर्स को पास करके बनाया जा सकता है <code>std::launch::deferred</code> लॉन्च नीति को <code>std::async</code>, मान की गणना करने के लिए फ़ंक्शन के साथ।
+'{{visible anchor|शिथिल फ़्यूचर्स}} एक ऐसा फ़्यूचर्स है जो नियतात्मक रूप से शिथिल मूल्यांकन अर्थविज्ञान है: फ़्यूचर्स के मान की गणना तब प्रारंभ होती है जब मान की पहली आवश्यकता होती है, जैसा कि जरूरत से कॉल में होता है। शिथिल फ़्यूचर्स उन लैंग्वेज में उपयोग किया जाता है जिनकी मूल्यांकन रणनीति डिफ़ॉल्ट रूप से शिथिल नहीं होती है। उदाहरण के लिए, C++11 में मान की गणना करने के लिए फ़ंक्शन के साथ, <code>std::launch::deferred</code> लॉन्च पॉलिसी को<code>std::async</code>,पर पास करके इस तरह के {{visible anchor|शिथिल फ़्यूचर्स}} बनाए जा सकते हैं।
 ==एक्टर मॉडल में फ्यूचर्स का सिमेंटिक्स==
-अभिनेता मॉडल में, रूप की अभिव्यक्ति <code>''future'' <Expression></code> यह परिभाषित किया गया है कि यह कैसे प्रतिक्रिया करता है <code>Eval</code> पर्यावरण ई और ग्राहक सी के साथ संदेश इस प्रकार है: वायदा की अभिव्यक्ति इसका जवाब देती है <code>Eval</code> ग्राहक सी को नव निर्मित अभिनेता एफ (मूल्यांकन की प्रतिक्रिया के लिए प्रॉक्सी) भेजकर संदेश <code><Expression></code>) भेजने के साथ समवर्ती वापसी मान के रूप में <code><Expression></code> एक <code>Eval</code> पर्यावरण ई और ग्राहक सी के साथ संदेश। एफ का डिफ़ॉल्ट व्यवहार इस प्रकार है:
+कर्ता मॉडल में, <code>''future'' <Expression></code> की अभिव्यक्ति यह परिभाषित किया गया है कि यह कैसे प्रतिक्रिया करता है <code>Eval</code> परिवेश E और ग्राहक C के साथ संदेश इस प्रकार है: फ़्यूचर्स की अभिव्यक्ति ग्राहक C को नव निर्मित कर्ता <code>Eval</code> संदेश का जवाब देती है। ''F'' ( <code><Expression></code> के मूल्यांकन की प्रतिक्रिया के लिए प्रॉक्सी) परिवेश ई और ग्राहक सी के साथ <code><Expression></code> एक <code>Eval</code> संदेश भेजने के साथ-साथ वापसी मान के रूप में है। ''F'' का डिफ़ॉल्ट व्यवहार इस प्रकार है:
-* जब एफ एक अनुरोध आर प्राप्त करता है, तो यह देखने के लिए जांचता है कि क्या उसे मूल्यांकन से पहले ही प्रतिक्रिया मिली है (जो या तो वापसी मान या फेंकने वाला अपवाद हो सकता है) <code><Expression></code> निम्नानुसार कार्यवाही करना:
+* जब ''F'' अनुरोध ''R'' प्राप्त करता है, तो यह देखने के लिए जांचता है कि क्या उसे मूल्यांकन से पहले ही प्रतिक्रिया मिली है (जो या तो वापसी मान या फेंकने वाला अपवाद हो सकता है) <code><Expression></code> निम्नानुसार कार्यवाही करना:
-*# यदि इसकी पहले से ही प्रतिक्रिया V है, तो
+*# यदि इसकी पहले से ही प्रतिक्रिया ''V'' है, तो
-*#*यदि V एक वापसी मान है, तो इसे अनुरोध R भेजा जाता है।
+*#*यदि ''V'' वापसी मान है, तो इसे अनुरोध ''R'' भेजा जाता है।
-*#*यदि वी एक अपवाद है, तो अनुरोध आर के ग्राहक को फेंक दिया जाता है।
+*#*यदि ''V'' एक अपवाद है, तो अनुरोध ''R'' के ग्राहक को छोड दिया जाता है।
-*# यदि उसके पास पहले से कोई प्रतिक्रिया नहीं है, तो R को F के अंदर अनुरोधों की कतार में संग्रहीत किया जाता है।
+*# यदि उसके पास पहले से कोई प्रतिक्रिया नहीं है, तो ''R'' को ''F'' के अंदर अनुरोधों की कतार में संग्रहीत किया जाता है।
-* जब F मूल्यांकन से प्रतिक्रिया V प्राप्त करता है <code><Expression></code>, तो V को F और में संग्रहीत किया जाता है
+* जब ''F'' मूल्यांकन से प्रतिक्रिया ''V'' प्राप्त करता है <code><Expression></code>, तो ''V'' को ''F'' और में संग्रहीत किया जाता है
-**यदि V एक रिटर्न वैल्यू है, तो सभी कतारबद्ध अनुरोध V को भेजे जाते हैं।
+**यदि ''V'' एक रिटर्न वैल्यू है, तो सभी कतारबद्ध अनुरोध ''V'' को भेजे जाते हैं।
-**यदि वी एक अपवाद है, तो यह कतारबद्ध अनुरोधों में से प्रत्येक के ग्राहक को फेंक दिया जाता है।
+**यदि ''V'' अपवाद है, तो यह कतारबद्ध अनुरोधों में से प्रत्येक के ग्राहक को छोड दिया जाता है।
-हालांकि, कुछ वायदा अधिक समानता प्रदान करने के लिए विशेष तरीकों से अनुरोधों से निपट सकते हैं। उदाहरण के लिए, अभिव्यक्ति <code>1 + future factorial(n)</code> एक नया वायदा बना सकते हैं जो संख्या की तरह व्यवहार करेगा <code>1+factorial(n)</code>. यह तरकीब हमेशा काम नहीं करती। उदाहरण के लिए, निम्नलिखित सशर्त अभिव्यक्ति:
+चूंकि, कुछ फ़्यूचर्स अधिक समानता प्रदान करने के लिए विशेष तरीकों से अनुरोधों से निपट सकते हैं। उदाहरण के लिए, अभिव्यक्ति <code>1 + future factorial(n)</code> नया फ़्यूचर्स बना सकते हैं जो संख्या की तरह व्यवहार करेगा <code>1+factorial(n)</code>. यह तरकीब हमेशा काम नहीं करती हैं। उदाहरण के लिए, निम्नलिखित सशर्त अभिव्यक्ति:
 : <code>''if'' m>future factorial(n) ''then'' print("bigger") ''else'' print("smaller")</code>
-के लिए वायदा के लिए स्थगित करता है <code>factorial(n)</code> अनुरोध का जवाब दिया है कि क्या पूछ रहा है <code>m</code> स्वयं से बड़ा है।
+के लिए फ़्यूचर्स के लिए स्थगित करता है <code>factorial(n)</code> अनुरोध का जवाब दिया है कि  <code>m</code> स्वयं से बड़ा है या नहीं है।
 == इतिहास ==
-वायदा और/या वादा निर्माण पहले [[मल्टीलिस्प]] और अभिनेता मॉडल जैसी प्रोग्रामिंग भाषाओं में लागू किए गए थे। संगामिति (कंप्यूटर विज्ञान) तर्क प्रोग्रामिंग भाषाओं में संचार के लिए तर्क चर का उपयोग वायदा के समान ही था। ये फ्रीज और आईसी [[प्रोलॉग]] के साथ प्रोलॉग में शुरू हुए, और रिलेशनल लैंग्वेज, समवर्ती प्रोलॉग, गार्डेड [[हॉर्न क्लॉज]] (जीएचसी), [[परलॉग]], [[ किनारा (प्रोग्रामिंग भाषा) ]], [[ वालकैन (प्रोग्रामिंग भाषा) ]], जानूस (समवर्ती बाधा प्रोग्रामिंग लैंग्वेज) के साथ एक वास्तविक समवर्ती आदिम बन गए। ), ओज (प्रोग्रामिंग भाषा) | ओज-मोजार्ट, [[ प्रवाह जावा ]], और ऐलिस (प्रोग्रामिंग भाषा)। [[डेटाफ्लो प्रोग्रामिंग]] लैंग्वेज से सिंगल-असाइनमेंट I-var, Id (प्रोग्रामिंग लैंग्वेज) में उत्पन्न होता है और Reppy's [[Concurrent ML]] में शामिल होता है, जो समवर्ती तर्क चर की तरह होता है।
+फ़्यूचर्स और/या प्रोमिस कंस्ट्रक्शंस को सबसे पहले [[मल्टीलिस्प]] और एक्ट 1 जैसी प्रोग्रामिंग लैंग्वेज में लागू किए गए थे। संगामिति (कंप्यूटर विज्ञान) लॉजिक प्रोग्रामिंग लैंग्वेज में संचार के लिए लॉजिक चर का उपयोग फ़्यूचर्स के समान ही था। ये फ्रीज और आईसी [[प्रोलॉग]] के साथ प्रोलॉग में प्रारंभ हुए, और रिलेशनल लैंग्वेज, समवर्ती प्रोलॉग, गार्डेड [[हॉर्न क्लॉज]] (जीएचसी), [[परलॉग]], [[ किनारा (प्रोग्रामिंग भाषा) | स्ट्रैंड(प्रोग्रामिंग भाषा)]], [[ वालकैन (प्रोग्रामिंग भाषा) |वालकैन (प्रोग्रामिंग भाषा)]] , जानूस (समवर्ती प्रतिबंध प्रोग्रामिंग लैंग्वेज) Oz-मोजार्ट, [[ प्रवाह जावा ]], और ऐलिस (प्रोग्रामिंग भाषा) के साथ वास्तविक समवर्ती आदिम बन गए। [[डेटाफ्लो प्रोग्रामिंग]] लैंग्वेज से सिंगल-असाइनमेंट I-var, Id (प्रोग्रामिंग लैंग्वेज) में उत्पन्न होता है औररेपी के समवर्ती एमएल में सम्मिलित होता है, जो समवर्ती लॉजिक चर की तरह होता है।
-में [[बारबरा लिस्कोव]] और [[लिउबा श्रीरा]] द्वारा वादा पाइपलाइनिंग तकनीक (विलंबता को दूर करने के लिए वायदा का उपयोग करके) का आविष्कार किया गया था।<ref name="SIGPLAN pp. 260"/>और स्वतंत्र रूप से मार्क एस. मिलर, डीन ट्रिबल और रॉब जेलिंगहौस द्वारा परियोजना Xanadu लगभग 1989 के संदर्भ में।<ref>{{citation |url= http://www.sunless-sea.net/Transcripts/promise.html |publisher= Sunless Sea |title= Promise |archive-url= https://web.archive.org/web/20071023111712/http://www.sunless-sea.net/Transcripts/promise.html |archive-date=23 October 2007 }}</ref>
+प्रोमिस पाइपलाइनिंग तकनीक (विलंबता को दूर करने के लिए फ़्यूचर्स का उपयोग करके) का आविष्कार 1988 में [[बारबरा लिस्कोव]] और [[लिउबा श्रीरा]] द्वारा किया गया था।<ref name="SIGPLAN pp. 260"/>और स्वतंत्र रूप से मार्क एस. मिलर, डीन ट्रिबल और रॉब जेलिंगहौस द्वारा परियोजना ज़ानाडू लगभग 1989 के संदर्भ में किया गया था।<ref>{{citation |url= http://www.sunless-sea.net/Transcripts/promise.html |publisher= Sunless Sea |title= Promise |archive-url= https://web.archive.org/web/20071023111712/http://www.sunless-sea.net/Transcripts/promise.html |archive-date=23 October 2007 }}</ref>
-वादा शब्द लिस्कोव और श्रीरा द्वारा गढ़ा गया था, हालांकि उन्होंने पाइपलाइनिंग तंत्र को कॉल-स्ट्रीम नाम से संदर्भित किया था, जो अब शायद ही कभी उपयोग किया जाता है।
-लिस्कोव और श्रीरा के पेपर में वर्णित डिजाइन, और Xanadu में वादा पाइपलाइनिंग के कार्यान्वयन दोनों की सीमा थी कि वादे के मान प्रथम श्रेणी के मान नहीं थे | सीधे तौर पर एक वादा नहीं होगा (इसलिए पहले दिए गए वादे पाइपलाइनिंग का उदाहरण, जो एक तर्क के रूप में दूसरे को भेजने के परिणाम के लिए एक वादे का उपयोग करता है, कॉल-स्ट्रीम डिज़ाइन या Xanadu कार्यान्वयन में सीधे अभिव्यक्त नहीं होता)। ऐसा लगता है कि अरगस की किसी भी सार्वजनिक रिलीज में वादे और कॉल-स्ट्रीम कभी भी लागू नहीं किए गए थे,<ref>{{citation |url= http://www.pmg.csail.mit.edu/Argus.html |publisher= MIT |title= Argus}}</ref> लिस्कोव और श्रीरा पेपर में प्रयुक्त प्रोग्रामिंग भाषा। आर्गस का विकास 1988 के आसपास बंद हो गया।<ref>{{citation |url= http://www.ieeeghn.org/wiki/index.php/Oral-History:Barbara_Liskov#Distributed_Computing_and_Argus |publisher= IEEE GHN |series= Oral history |first= Barbara |last= Liskov |title= Distributed computing and Argus|date= 26 January 2021 }}</ref> वादा पाइपलाइनिंग का Xanadu कार्यान्वयन केवल Udanax Gold के लिए स्रोत कोड जारी करने के साथ ही सार्वजनिक रूप से उपलब्ध हो गया<ref>{{citation |url= http://www.udanax.com/gold/ |publisher= Udanax |title= Gold |url-status= dead |archive-url= https://web.archive.org/web/20081011003837/http://www.udanax.com/gold/ |archive-date= 11 October 2008 |df= dmy-all }}</ref> 1999 में, और किसी भी प्रकाशित दस्तावेज़ में कभी भी समझाया नहीं गया था।<ref>{{citation |url= http://www.erights.org/elib/distrib/pipeline.html |publisher= E rights |title= Pipeline}}</ref> जूल और ई में बाद के कार्यान्वयन पूरी तरह से प्रथम श्रेणी के वादों और रिज़ॉल्वर का समर्थन करते हैं।
+प्रोमिस शब्द लिस्कोव और श्रीरा द्वारा गढ़ा गया था, चूंकि उन्होंने पाइपलाइनिंग तंत्र को कॉल-स्ट्रीम नाम से संदर्भित किया था, जो अब शायद ही कभी उपयोग किया जाता है।
-एक्ट सीरीज़ सहित कई प्रारंभिक अभिनेता भाषाएँ,<ref>{{cite journal
+लिस्कोव और श्रीरा के पेपर में वर्णित डिजाइन, और ज़ानाडू में प्रोमिस पाइपलाइनिंग के कार्यान्वयन दोनों की सीमा थी कि प्रोमिस के मान प्रथम श्रेणी के मान नहीं थे | सीधे तौर पर प्रोमिस नहीं हो सकता था (इसलिए पहले दिए गए प्रोमिस पाइपलाइनिंग का उदाहरण, जो प्रेषण के परिणाम के लिए दूसरे को लॉजिक के रूप में प्रोमिस का उपयोग करता है, कॉल-स्ट्रीम डिज़ाइन या ज़ानाडू कार्यान्वयन में सीधे अभिव्यक्त नहीं होता)। ऐसा लगता है कि लिस्कोव और श्रीरा पेपर में उपयोग की जाने वाली प्रोग्रामिंग भाषा अरगस <ref>{{citation |url= http://www.pmg.csail.mit.edu/Argus.html |publisher= MIT |title= Argus}}</ref> की किसी भी सार्वजनिक रिलीज में प्रोमिस और कॉल-स्ट्रीम कभी भी लागू नहीं किए गए थे। आर्गस का विकास 1988 के आसपास बंद हो गया था।<ref>{{citation |url= http://www.ieeeghn.org/wiki/index.php/Oral-History:Barbara_Liskov#Distributed_Computing_and_Argus |publisher= IEEE GHN |series= Oral history |first= Barbara |last= Liskov |title= Distributed computing and Argus|date= 26 January 2021 }}</ref> प्रोमिस पाइपलाइनिंग का ज़ानाडू कार्यान्वयन केवल उडानैक्स गोल्ड के लिए स्रोत कोड जारी करने के साथ ही सार्वजनिक रूप से उपलब्ध हो गया<ref>{{citation |url= http://www.udanax.com/gold/ |publisher= Udanax |title= Gold |url-status= dead |archive-url= https://web.archive.org/web/20081011003837/http://www.udanax.com/gold/ |archive-date= 11 October 2008 |df= dmy-all }}</ref>था, और 1999 में, और किसी भी प्रकाशित दस्तावेज़ में कभी भी समझाया नहीं गया था।<ref>{{citation |url= http://www.erights.org/elib/distrib/pipeline.html |publisher= E rights |title= Pipeline}}</ref> जूल और E में बाद के कार्यान्वयन पूरी तरह से प्रथम श्रेणी के प्रोमिस और रिज़ॉल्वर का समर्थन करते हैं।
+एक्ट सीरीज़ सहित कई प्रारंभिक कर्ता भाषाएँ,<ref>{{cite journal
 | author= Henry Lieberman
 | title= A Preview of Act 1
@@ Line 167: / Line 160: @@
 |date=June 1981
 | publisher= MIT AI memo 626
-}}</ref> समांतर संदेश पासिंग और पाइपलाइन संदेश प्रसंस्करण दोनों का समर्थन करता है, लेकिन पाइपलाइनिंग का वादा नहीं करता है। (यद्यपि इन विशेषताओं में से अंतिम को पहले दो में लागू करना तकनीकी रूप से संभव है, इस बात का कोई प्रमाण नहीं है कि अधिनियम की भाषाओं ने ऐसा किया है।)
+}}</ref> समांतर संदेश पासिंग और पाइपलाइन संदेश प्रसंस्करण दोनों का समर्थन करता है, लेकिन पाइपलाइनिंग का प्रोमिस नहीं करता है। (यद्यपि इन विशेषताओं में से अंतिम को पहले दो में लागू करना तकनीकी रूप से संभव है, इस बात का कोई प्रमाण नहीं है कि अधिनियम की लैंग्वेज ने ऐसा किया है।)
-के बाद, उपयोगकर्ता इंटरफेस की [[जवाबदेही]] में उनके उपयोग के कारण, और [[वेब विकास]] में, संदेश-पासिंग के अनुरोध-प्रतिक्रिया मॉडल के कारण वायदा और वादों में रुचि का एक बड़ा पुनरुद्धार हुआ। कई मुख्यधारा की भाषाओं में अब वायदा और वादों के लिए भाषा का समर्थन है, जो विशेष रूप से लोकप्रिय हैं <code>FutureTask</code> जावा 5 में (घोषणा 2004)<ref>{{Cite web|url=https://www.ibm.com/developerworks/java/tutorials/j-concur/j-concur.html|title=Concurrency in JDK 5.0|last=Goetz|first=Brian|website=[[IBM]] |date=November 23, 2004}}</ref> और .NET 4.5 में async/प्रतीक्षा निर्माण (घोषित 2010, रिलीज़ 2012)<ref name="asyncdotnet45">{{cite web|url=http://blogs.msdn.com/b/dotnet/archive/2012/04/03/async-in-4-5-worth-the-await.aspx |title=Async in 4.5: Worth the Await – .NET Blog – Site Home – MSDN Blogs |publisher=Blogs.msdn.com |access-date=2014-05-13}}</ref><ref name="dotnetasyncawait">{{cite web|url=http://msdn.microsoft.com/en-us/library/hh191443.aspx |title=Async और Await (C# और Visual Basic) के साथ एसिंक्रोनस प्रोग्रामिंग|publisher=Msdn.microsoft.com |access-date=2014-05-13}}</ref> काफी हद तक F# के एसिंक्रोनस वर्कफ्लो से प्रेरित है,<ref>{{cite web
+के बाद, उपयोगकर्ता इंटरफेस की [[जवाबदेही]] में उनके उपयोग के कारण, और [[वेब विकास]] में, संदेश-पासिंग के अनुरोध-प्रतिक्रिया मॉडल के कारण फ़्यूचर्स और प्रोमिस में रुचि का बड़ा पुनरुद्धार हुआ था। कई मुख्यधारा की लैंग्वेज में अब फ़्यूचर्स और प्रोमिस के लिए भाषा का समर्थन है, जो विशेष रूप से लोकप्रिय हैं <code>FutureTask</code> जावा 5 में (घोषणा 2004)<ref>{{Cite web|url=https://www.ibm.com/developerworks/java/tutorials/j-concur/j-concur.html|title=Concurrency in JDK 5.0|last=Goetz|first=Brian|website=[[IBM]] |date=November 23, 2004}}</ref> और .NET 4.5 में async/प्रतीक्षा निर्माण (घोषित 2010, रिलीज़ 2012)<ref name="asyncdotnet45">{{cite web|url=http://blogs.msdn.com/b/dotnet/archive/2012/04/03/async-in-4-5-worth-the-await.aspx |title=Async in 4.5: Worth the Await – .NET Blog – Site Home – MSDN Blogs |publisher=Blogs.msdn.com |access-date=2014-05-13}}</ref><ref name="dotnetasyncawait">{{cite web|url=http://msdn.microsoft.com/en-us/library/hh191443.aspx |title=Async और Await (C# और Visual Basic) के साथ एसिंक्रोनस प्रोग्रामिंग|publisher=Msdn.microsoft.com |access-date=2014-05-13}}</ref> काफी हद तक F# के अतुल्यकालिक वर्कफ्लो से प्रेरित है,<ref>{{cite web
 |title=Asynchronous C# and F# (I.): Simultaneous introduction
 |url=http://tomasp.net/blog/csharp-fsharp-async-intro.aspx/
 |date=29 October 2010
 |author=Tomas Petricek
-}}</ref> जो 2007 की है।<ref>{{cite web
+}}</ref> जो 2007 तक चलता है।<ref>{{cite web
 |title=The F# Asynchronous Programming Model, PADL 2011
 |url=http://blogs.msdn.com/b/dsyme/archive/2010/10/21/the-f-asynchronous-programming-model-padl-2010-pre-publication-draft.aspx
@@ Line 181: / Line 174: @@
 |author2=Tomas Petricek
 |author3=Dmitry Lomov
-}}</ref> इसे बाद में अन्य भाषाओं द्वारा अपनाया गया, विशेष रूप से डार्ट (2014),<ref name="dart"/>पायथन (2015),<ref name="python">{{cite web
+}}</ref> इसे बाद में अन्य लैंग्वेज द्वारा अपनाया गया, विशेष रूप से डार्ट (2014),<ref name="dart" />पायथन (2015),<ref name="python">{{cite web
 |title=PEP 0492 – Coroutines with async and await syntax
 |url=https://www.python.org/dev/peps/pep-0492/
-}}</ref> हैक (एचएचवीएम), और ईसीएमएस्क्रिप्ट 7 (जावास्क्रिप्ट), स्काला, और सी ++ (2011) के ड्राफ्ट।
+}}</ref> हैक (एचएचवीएम), और ईसीएमएस्क्रिप्ट 7 (जावास्क्रिप्ट), स्काला, और C ++ (2011) के ड्राफ्ट द्वारा अपनाया गया है।
 == कार्यान्वयन की सूची ==
-कुछ प्रोग्रामिंग लैंग्वेज फ्यूचर्स, वादा, समवर्ती लॉजिक वेरिएबल्स, डेटाफ्लो वेरिएबल्स या I-vars को डायरेक्ट लैंग्वेज सपोर्ट या स्टैंडर्ड लाइब्रेरी में सपोर्ट कर रही हैं।
+कुछ प्रोग्रामिंग लैंग्वेज फ्यूचर्स, प्रोमिस, समवर्ती लॉजिक वेरिएबल्स, डेटाफ्लो वेरिएबल्स या I-vars को डायरेक्ट लैंग्वेज सपोर्ट या स्टैंडर्ड लाइब्रेरी में सपोर्ट कर रही हैं।
-=== प्रोग्रामिंग लैंग्वेज द्वारा फ्यूचर्स और वादों से संबंधित अवधारणाओं की सूची ===
+=== प्रोग्रामिंग लैंग्वेज द्वारा फ्यूचर्स और प्रोमिस से संबंधित अवधारणाओं की सूची ===
 * एबीसीएल / एफ<ref>{{cite conference
@@ Line 201: / Line 194: @@
 }}</ref>
 * ऐलिस (प्रोग्रामिंग भाषा)
-* एम्बिएंटटॉक (प्रथम श्रेणी रिज़ॉल्वर और रीड-ओनली वादों सहित)
+* एम्बिएंटटॉक (प्रथम श्रेणी रिज़ॉल्वर और रीड-ओनली प्रोमिस सहित)
-* [[C++]], C++11#थ्रेडिंग सुविधाओं से शुरू होता है|C++11: std::future और std::promise
+* [[C++]], C++11: std::future और std::प्रोमिस
-<!--C# is under .NET below-->
 ** रचनात्मक सी ++
 * [[क्रिस्टल (प्रोग्रामिंग भाषा)]]
-* [[डार्ट (प्रोग्रामिंग भाषा)]] (वायदा/पूर्ण कक्षाओं के साथ<ref name="dartCompleter">{{cite web
+* [[डार्ट (प्रोग्रामिंग भाषा)]] (फ़्यूचर्स/पूर्ण कक्षाओं के साथ<ref name="dartCompleter">{{cite web
 |url=https://api.dartlang.org/1.12.1/dart-async/Completer-class.html
 |title=Dart SDK dart async Completer
@@ Line 239: / Line 231: @@
 | access-date=23 February 2021
 }}</ref>
-* स्पष्ट (प्रोग्रामिंग भाषा) (केवल डेटा प्रवाह)
+* लुसिड (प्रोग्रामिंग भाषा) (केवल डेटा प्रवाह)
 * कुछ [[लिस्प (प्रोग्रामिंग भाषा)]]
 ** [[क्लोजर]]<ref>{{cite web
@@ Line 249: / Line 241: @@
 }}</ref>
 ** मल्टीलिस्प
-* .NET Framework|.NET वाया टास्क
+* .NET वाया टास्क
-** सी शार्प (प्रोग्रामिंग लैंग्वेज) | सी #, .नेट फ्रेमवर्क 4.5 के बाद से,<ref name="asyncdotnet45"/>खोजशब्दों के माध्यम से <code>async</code> और <code>await</code><ref name="dotnetasyncawait"/>* [[कोटलिन (प्रोग्रामिंग भाषा)]], तथापि <code>kotlin.native.concurrent.Future</code> आमतौर पर केवल कोटलिन लिखते समय उपयोग किया जाता है जिसका उद्देश्य मूल रूप से चलाना है<ref>{{Cite web|url=https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.native.concurrent/-future/|title=Future - Kotlin Programming Language}}</ref>
+** सी #, .नेट फ्रेमवर्क 4.5 के बाद से,<ref name="asyncdotnet45"/>खोजशब्दों के माध्यम से <code>async</code> और <code>await</code><ref name="dotnetasyncawait"/>
+*** [[कोटलिन (प्रोग्रामिंग भाषा)]], तथापि <code>kotlin.native.concurrent.Future</code> सामान्यतः केवल कोटलिन लिखते समय उपयोग किया जाता है जिसका ऑब्जेक्टिव मूल रूप से चलाना है<ref>{{Cite web|url=https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.native.concurrent/-future/|title=Future - Kotlin Programming Language}}</ref>
 * [[निम (प्रोग्रामिंग भाषा)]]
 * [[ऑक्सीजन (प्रोग्रामिंग भाषा)]]
-* ओज़ (प्रोग्रामिंग भाषा) संस्करण 3<ref>{{cite web |url=http://www.mozart-oz.org/documentation/tutorial/node1.html |title=ओज का ट्यूटोरियल|publisher=Mozart Global User Library |access-date=12 April 2011 |author=Seif Haridi |author2=Nils Franzen |archive-date=14 May 2011 |archive-url=https://web.archive.org/web/20110514010946/http://www.mozart-oz.org/documentation/tutorial/node1.html |url-status=dead }}</ref>
+* Oz (प्रोग्रामिंग भाषा) संस्करण 3<ref>{{cite web |url=http://www.mozart-oz.org/documentation/tutorial/node1.html |title=ओज का ट्यूटोरियल|publisher=Mozart Global User Library |access-date=12 April 2011 |author=Seif Haridi |author2=Nils Franzen |archive-date=14 May 2011 |archive-url=https://web.archive.org/web/20110514010946/http://www.mozart-oz.org/documentation/tutorial/node1.html |url-status=dead }}</ref>
-* [[पायथन (प्रोग्रामिंग भाषा)]] [https://docs.python.org/3/library/concurrent.futures.htmlcurrent.futures], 3.2 के बाद से,<ref>[https://www.python.org/download/releases/3.2/ Python 3.2 Release]</ref> [https://www.python.org/dev/peps/pep-3148/ PEP 3148] द्वारा प्रस्तावित, और Python 3.5 ने async और प्रतीक्षा को जोड़ा<ref>[https://www.python.org/downloads/release/python-350/ Python 3.5 Release]</ref>
+* [[पायथन (प्रोग्रामिंग भाषा)]] [https://docs.python.org/3/library/concurrent.futures.htmlcurrent.futures], 3.2 के बाद से,<ref>[https://www.python.org/download/releases/3.2/ Python 3.2 Release]</ref> [https://www.python.org/dev/peps/pep-3148/ PEP 3148] द्वारा प्रस्तावित, और पायथन 3.5 ने async और प्रतीक्षा को जोड़ा<ref>[https://www.python.org/downloads/release/python-350/ Python 3.5 Release]</ref>
-* [[आर (प्रोग्रामिंग भाषा)]] (आलसी मूल्यांकन के लिए वादे, अभी भी सिंगल थ्रेडेड)
+* [[आर (प्रोग्रामिंग भाषा)|R (प्रोग्रामिंग भाषा)]] (शिथिल मूल्यांकन के लिए प्रोमिस, अभी भी सिंगल थ्रेडेड)
 * [[रैकेट (प्रोग्रामिंग भाषा)]]<ref>{{cite web|url=http://docs.racket-lang.org/guide/performance.html#(part._effective-futures)|title=फ्यूचर्स के साथ समानता|publisher=PLT|access-date=2 March 2012}}</ref>
 * [[राकू (प्रोग्रामिंग भाषा)]]<ref>{{cite web|url=https://docs.raku.org/type/Promise|title=कक्षा का वादा|publisher=raku.org|access-date=2022-08-19}}</ref>
-* [[जंग (प्रोग्रामिंग भाषा)]] (आमतौर पर <code>.await</code>)<ref>{{Cite web|url=https://doc.rust-lang.org/std/future/trait.Future.html|title = Future in STD::future - Rust}}</ref>
+* [[जंग (प्रोग्रामिंग भाषा)|रस्ट (प्रोग्रामिंग भाषा)]] (सामान्यतः <code>.await</code>)<ref>{{Cite web|url=https://doc.rust-lang.org/std/future/trait.Future.html|title = Future in STD::future - Rust}}</ref>
 * [[स्काला (प्रोग्रामिंग भाषा)]] [http://docs.scala-lang.org/overviews/core/futures.html scala.concurrent पैकेज] के माध्यम से
-* [[योजना (प्रोग्रामिंग भाषा)]]
+* [[योजना (प्रोग्रामिंग भाषा)|स्कीम (प्रोग्रामिंग भाषा)]]
-* [[ चीख़ ]] स्मॉलटॉक
+* [[ चीख़ | स्क्वाक]]  स्मॉलटॉक
-* किनारा (प्रोग्रामिंग भाषा)
+* स्ट्रैंड(प्रोग्रामिंग भाषा)
-* [[स्विफ्ट (प्रोग्रामिंग भाषा)]] (केवल तीसरे पक्ष के पुस्तकालयों के माध्यम से)
+* [[स्विफ्ट (प्रोग्रामिंग भाषा)]] (केवल तीसरे पक्ष के लाइब्रेरी के माध्यम से)
-* विजुअल बेसिक.नेट{{clarify|Expert needed. Which one, or both? As is, this link is a WP:NOPIPE WP:EASTEREGG|date=March 2016}} 11 (कीवर्ड Async और Await के माध्यम से)<ref name="dotnetasyncawait"/>
+* विजुअल बेसिक.नेट 11 (कीवर्ड Async और Await के माध्यम से)<ref name="dotnetasyncawait"/>
-वादा पाइपलाइनिंग का समर्थन करने वाली भाषाओं में शामिल हैं:
+प्रोमिस पाइपलाइनिंग का समर्थन करने वाली लैंग्वेज में सम्मिलित हैं:
 * ई (प्रोग्रामिंग भाषा)
 * जूल (प्रोग्रामिंग भाषा)
-=== फ्यूचर्स के गैर-मानक, पुस्तकालय आधारित कार्यान्वयनों की सूची ===
+=== फ्यूचर्स के गैर-मानक, लाइब्रेरी आधारित कार्यान्वयनों की सूची ===
 * [[सामान्य लिस्प]] के लिए:
 ** ब्लैकबर्ड<ref>[https://orthecreedence.github.io/blackbird/ Common Lisp Blackbird]</ref>
-** उत्सुक वायदा 2<ref>[http://common-lisp.net/project/eager-future/ Common Lisp Eager Future2]</ref>
+** व्यग्र फ़्यूचर्स 2<ref>[http://common-lisp.net/project/eager-future/ Common Lisp Eager Future2]</ref>
 ** समानांतर<ref>[https://lparallel.org Lisp in parallel – A parallel programming library for Common Lisp]</ref>
 ** पीसी कॉल<ref>[http://marijnhaverbeke.nl/pcall/ Common Lisp PCall]</ref>
 * सी ++ के लिए:
-** [[बूस्ट (सी ++ पुस्तकालय)]]<ref>{{cite web
+** [[बूस्ट (सी ++ पुस्तकालय)|बूस्ट (सी ++ लाइब्रेरी)]]<ref>{{cite web
   |url=http://www.boost.org/doc/libs/release/doc/html/thread.html
   |title=Chapter 30. Thread 4.0.0
@@ Line 285: / Line 278: @@
   |title=Dlib C++ Library #thread_pool
   |access-date=26 June 2013}}</ref>
-**मूर्खता<ref>{{cite web|url=https://github.com/facebook/folly|title=GitHub – facebook/folly: An open-source C++ library developed and used at Facebook.|website=[[GitHub]]|date=2019-01-08}}</ref>
+**फौली<ref>{{cite web|url=https://github.com/facebook/folly|title=GitHub – facebook/folly: An open-source C++ library developed and used at Facebook.|website=[[GitHub]]|date=2019-01-08}}</ref>
 ** एचपीएक्स <ref>{{cite web|url=http://stellar-group.org/libraries/hpx/|title=एचपीएक्स|date=2019-02-10}}</ref>
-** POCO C++ लाइब्रेरी (सक्रिय परिणाम)<ref>{{cite web|url=https://pocoproject.org/slides/130-Threads.pdf|title=Threads Slides of POCO}}</ref>
+** पोको C++ लाइब्रेरी (सक्रिय परिणाम)<ref>{{cite web|url=https://pocoproject.org/slides/130-Threads.pdf|title=Threads Slides of POCO}}</ref>
 ** [[क्यूटी (सॉफ्टवेयर)]]<ref>{{cite web
   |url=https://qt-project.org/doc/qt-5.0/qtcore/qfuture.html
@@ Line 297: / Line 290: @@
   |url-status=dead
   }}</ref>
-** खड़ा है<ref>{{cite web
+** सीस्टार<ref>{{cite web
   |url=http://seastar-project.org
   |title=Seastar
@@ Line 303: / Line 296: @@
   |access-date=22 August 2016}}</ref>
 ** छुरा<ref>{{cite web|url=https://stlab.cc/libraries/concurrency|title=स्टैब एडोब की सॉफ्टवेयर टेक्नोलॉजी लैब का चल रहा काम है। एडोब सोर्स लाइब्रेरीज़ (एएसएल), प्लेटफ़ॉर्म लाइब्रेरीज़ और नए स्टैब लाइब्रेरीज़ को जीथब पर होस्ट किया गया है।|date=2021-01-31}}</ref>
-* C Sharp (प्रोग्रामिंग लैंग्वेज)|C# और अन्य .NET Framework|.NET भाषाओं के लिए: [[समानांतर एक्सटेंशन]] लाइब्रेरी
+* C# और अन्य .NET लैंग्वेज के लिए: [[समानांतर एक्सटेंशन]] लाइब्रेरी
-* ग्रोवी (प्रोग्रामिंग भाषा) के लिए: GPars<ref>[http://gpars.codehaus.org Groovy GPars] {{webarchive|url=https://web.archive.org/web/20130112092827/http://gpars.codehaus.org/ |date=12 January 2013 }}</ref>
+* ग्रोवी (प्रोग्रामिंग भाषा) के लिए: जीपार्स<ref>[http://gpars.codehaus.org Groovy GPars] {{webarchive|url=https://web.archive.org/web/20130112092827/http://gpars.codehaus.org/ |date=12 January 2013 }}</ref>
 * जावास्क्रिप्ट के लिए:
-** कुजो.जेएस'<ref>[http://cujojs.com Cujo.js]</ref> कब.जेएस<ref>[https://github.com/cujojs/when JavaScript when.js]</ref> वादों/A+ के अनुरूप वादे प्रदान करता है<ref>[http://promisesaplus.com Promises/A+ specification]</ref> 1.1 विनिर्देश
+** कुजो.जेएस'<ref>[http://cujojs.com Cujo.js]</ref> कब.जेएस<ref>[https://github.com/cujojs/when JavaScript when.js]</ref> प्रोमिस/A+ के अनुरूप प्रोमिस प्रदान करता है<ref>[http://promisesaplus.com Promises/A+ specification]</ref> 1.1 विनिर्देश
-** डोजो टूलकिट वादों की आपूर्ति करता है<ref>[http://dojotoolkit.org/documentation/tutorials/1.6/promises/ promises]</ref> और मुड़ी हुई (सॉफ्टवेयर) शैली स्थगित
+** डोजो टूलकिट प्रोमिस की आपूर्ति करता है<ref>[http://dojotoolkit.org/documentation/tutorials/1.6/promises/ promises]</ref> और मुड़ी हुई (सॉफ्टवेयर) शैली स्थगित
-** मोचीकिट<ref>[https://mochi.github.io/mochikit/doc/html/MochiKit/Async.html JavaScript MochKit.Async]</ref> ट्विस्टेड (सॉफ्टवेयर)#Deferreds|Twisted's Deferreds से प्रेरित है
+** मोचीकिट<ref>[https://mochi.github.io/mochikit/doc/html/MochiKit/Async.html JavaScript MochKit.Async]</ref> ट्विस्टेड (सॉफ्टवेयर) डेफेर्रेड से प्रेरित है
-** [http://jquery.com/ jQuery's] [//api.jquery.com/category/deferred-object/ आस्थगित वस्तु] [http://wiki.commonjs.org/wiki/Promises/ पर आधारित है एक कॉमनजेएस वादा/ए] डिजाइन।
+** [http://jquery.com/ jQuery's] [//api.jquery.com/category/deferred-object/ जडेफेर्रेड ऑब्जेक्ट] [http://wiki.commonjs.org/wiki/Promises/ पर आधारित है कॉमनजेएस प्रोमिस/ए] डिजाइन।
 ** एंगुलरजेएस<ref>[https://angularjs.org/ JavaScript Angularjs]</ref>
-** नोड.जेएस-वादा<ref>[https://github.com/kriszyp/node-promise JavaScript node-promise]</ref>
+** नोड.जेएस-प्रोमिस<ref>[https://github.com/kriszyp/node-promise JavaScript node-promise]</ref>
-** क्यू, कृष कोवल द्वारा, वादों/ए+ 1.1 के अनुरूप है<ref>{{Cite web |url=http://documentup.com/kriskowal/q |title=जावास्क्रिप्ट क्यू|access-date=8 April 2013 |archive-date=31 December 2018 |archive-url=https://web.archive.org/web/20181231093236/http://documentup.com/kriskowal/q |url-status=dead }}</ref>
+** Q, कृष कोवल द्वारा, प्रोमिस/ए+ 1.1 के अनुरूप है<ref>{{Cite web |url=http://documentup.com/kriskowal/q |title=जावास्क्रिप्ट क्यू|access-date=8 April 2013 |archive-date=31 December 2018 |archive-url=https://web.archive.org/web/20181231093236/http://documentup.com/kriskowal/q |url-status=dead }}</ref>
-** RSVP.js, वादों/A+ 1.1 के अनुरूप है<ref>[https://github.com/tildeio/rsvp.js JavaScript RSVP.js]</ref>
+** RSVP.js, प्रोमिस/A+ 1.1 के अनुरूप है<ref>[https://github.com/tildeio/rsvp.js JavaScript RSVP.js]</ref>
-** यूयूआई<ref>[http://yuilibrary.com/ YUI JavaScript class library]</ref> वादा वर्ग<ref>[http://yuilibrary.com/yui/docs/promise/ YUI JavaScript promise class]</ref> वादे/ए+ 1.0 विनिर्देश के अनुरूप है।
+** यूयूआई<ref>[http://yuilibrary.com/ YUI JavaScript class library]</ref> प्रोमिस वर्ग<ref>[http://yuilibrary.com/yui/docs/promise/ YUI JavaScript promise class]</ref> प्रोमिस/ए+ 1.0 विनिर्देश के अनुरूप है।
 ** ब्लूबर्ड, पेटका एंटोनोव द्वारा<ref>[https://github.com/petkaantonov/bluebird JavaScript Bluebird]</ref>
-** Google क्लोजर टूल्स # क्लोजर लाइब्रेरी का [https://github.com/google/closure-library/tree/master/closure/goog/promise Promise] पैकेज Promises/A+ विनिर्देश के अनुरूप है।
+** क्लोजर लाइब्रेरी का [https://github.com/google/closure-library/tree/master/closure/goog/promise प्रोमिस] पैकेज Promises/A+ विनिर्देश के अनुरूप है।
-** देखें [http://promisesaplus.com/implementations Promise/A+'s] Promise/A+ डिज़ाइन के आधार पर अधिक कार्यान्वयन के लिए सूची।
+** देखें [http://promisesaplus.com/implementations प्रोमिस/A+'s] प्रोमिस/A+ डिज़ाइन के आधार पर अधिक कार्यान्वयन के लिए सूची।
 * जावा (प्रोग्रामिंग भाषा) के लिए:
-** JDeferred, आस्थगित-वादा API और [[JQuery]].Deferred वस्तु के समान व्यवहार प्रदान करता है<ref>[http://jdeferred.org Java JDeferred]</ref>
+** ओएप्रोमाइज, जडेफेर्रेड-प्रोमिस एपीआई और [[JQuery]].Deferred ऑब्जेक्ट के समान व्यवहार प्रदान करता है<ref>[http://jdeferred.org Java JDeferred]</ref>
-** पेयरसेक<ref>[https://github.com/linkedin/parseq/wiki Java ParSeq]</ref> [[ Linkedin ]] द्वारा अनुरक्षित एसिंक्रोनस पाइपलाइनिंग और ब्रांचिंग के लिए कार्य-वादा एपीआई आदर्श प्रदान करता है
+** पेयरसेक<ref>[https://github.com/linkedin/parseq/wiki Java ParSeq]</ref> [[ Linkedin ]] द्वारा अनुरक्षित अतुल्यकालिक पाइपलाइनिंग और ब्रांचिंग के लिए कार्य-प्रोमिस एपीआई आदर्श प्रदान करता है
 * [[लुआ (प्रोग्रामिंग भाषा)]] के लिए:
-** कतार [https://www.25thandclement.com/~william/projects/cqueues.html] मॉड्यूल में एक वादा एपीआई है।
+** कतार [https://www.25thandclement.com/~william/projects/cqueues.html] मॉड्यूल में एक प्रोमिस एपीआई है।
-* [[ उद्देश्य सी ]] के लिए: एमएफ्यूचर,<ref>[https://github.com/mikeash/MAFuture Objective-C MAFuture GitHub]</ref><ref>[http://www.mikeash.com/pyblog/friday-qa-2010-02-26-futures.html Objective-C MAFuture mikeash.com]</ref> आरएक्स वादा,<ref>[https://github.com/couchdeveloper/RXPromise Objective-C RXPromise]</ref> ओबीजेसी-कोलैप्सिंग फ्यूचर्स,<ref>[https://github.com/Strilanc/ObjC-CollapsingFutures ObjC-CollapsingFutures]</ref> प्रॉमिसकिट,<ref>[http://promisekit.org/ Objective-C PromiseKit]</ref> ओबीजेसी-वादा,<ref>[https://github.com/mproberts/objc-promise Objective-C objc-promise]</ref> OAPromise,<ref>[https://github.com/oleganza/OAPromise Objective-C OAPromise]</ref>
+* [[ उद्देश्य सी |ऑब्जेक्टिव-सी]]  के लिए: एमएफ्यूचर,<ref>[https://github.com/mikeash/MAFuture Objective-C MAFuture GitHub]</ref><ref>[http://www.mikeash.com/pyblog/friday-qa-2010-02-26-futures.html Objective-C MAFuture mikeash.com]</ref> आरएक्स प्रोमिस,<ref>[https://github.com/couchdeveloper/RXPromise Objective-C RXPromise]</ref> ओबीजेसी-कोलैप्सिंग फ्यूचर्स,<ref>[https://github.com/Strilanc/ObjC-CollapsingFutures ObjC-CollapsingFutures]</ref> प्रॉमिसकिट,<ref>[http://promisekit.org/ Objective-C PromiseKit]</ref> ओबीजेसी-प्रोमिस,<ref>[https://github.com/mproberts/objc-promise Objective-C objc-promise]</ref> ओएप्रोमाइज,<ref>[https://github.com/oleganza/OAPromise Objective-C OAPromise]</ref>
-* [[OCaml]] के लिए: आलसी मॉड्यूल आलसी स्पष्ट वायदा लागू करता है<ref>[http://caml.inria.fr/pub/docs/manual-ocaml/libref/Lazy.html OCaml Lazy]</ref>
+* [[OCaml|ओ कैमल]] के लिए: शिथिल मॉड्यूल शिथिल लुसिड फ़्यूचर्स लागू करता है<ref>[http://caml.inria.fr/pub/docs/manual-ocaml/libref/Lazy.html OCaml Lazy]</ref>
-* [[पर्ल]] के लिए: वायदा,<ref>[http://metacpan.org/module/Future Perl Future]</ref> वादे,<ref>[https://metacpan.org/pod/Promises Perl Promises]</ref> प्रतिवर्त,<ref>[http://metacpan.org/module/Reflex/ Perl Reflex]</ref> वादा::ES6,<ref>[http://metacpan.org/module/Promise::ES6/ Perl Promise::ES6]</ref> और वादा :: एक्सएस<ref>{{Cite web|title=Promise::XS - Fast promises in Perl - metacpan.org|url=https://metacpan.org/pod/Promise::XS|access-date=2021-02-14|website=metacpan.org}}</ref>
+* [[पर्ल]] के लिए: फ़्यूचर्स,<ref>[http://metacpan.org/module/Future Perl Future]</ref> प्रोमिस,<ref>[https://metacpan.org/pod/Promises Perl Promises]</ref> प्रतिवर्त,<ref>[http://metacpan.org/module/Reflex/ Perl Reflex]</ref> प्रोमिस::ES6,<ref>[http://metacpan.org/module/Promise::ES6/ Perl Promise::ES6]</ref> और प्रोमिस :: एक्सएस<ref>{{Cite web|title=Promise::XS - Fast promises in Perl - metacpan.org|url=https://metacpan.org/pod/Promise::XS|access-date=2021-02-14|website=metacpan.org}}</ref>
-* [[PHP]] के लिए: प्रतिक्रिया/वादा करें<ref>[https://github.com/reactphp/promise PHP React/Promise]</ref>
+* [[PHP|पीएचपी]] के लिए: प्रतिक्रिया/प्रोमिस करें<ref>[https://github.com/reactphp/promise PHP React/Promise]</ref>
 * पायथन (प्रोग्रामिंग भाषा) के लिए:
 ** अंतर्निहित कार्यान्वयन<ref>[https://docs.python.org/3/library/asyncio-task.html#future Python built-in implementation]</ref>
 ** पायथनफ्यूचर्स<ref>[http://code.google.com/p/pythonfutures/ pythonfutures]</ref>
-** ट्विस्टेड (सॉफ्टवेयर) | ट्विस्टेड्स डेफर्ड्स<ref>{{Cite web |url=http://twistedmatrix.com/documents/current/core/howto/defer.html |title=मुड़ आस्थगित|access-date=29 April 2010 |archive-date=6 August 2020 |archive-url=https://web.archive.org/web/20200806202718/https://twistedmatrix.com/documents/current/core/howto/defer.html |url-status=dead }}</ref>
+** ट्विस्टेड (सॉफ्टवेयर) डेफर्ड्स<ref>{{Cite web |url=http://twistedmatrix.com/documents/current/core/howto/defer.html |title=मुड़ आस्थगित|access-date=29 April 2010 |archive-date=6 August 2020 |archive-url=https://web.archive.org/web/20200806202718/https://twistedmatrix.com/documents/current/core/howto/defer.html |url-status=dead }}</ref>
-* आर (प्रोग्रामिंग भाषा) के लिए:
+* R (प्रोग्रामिंग भाषा) के लिए:
-** वायदा, आलसी और उत्सुक सिंक्रोनस और (मल्टीकोर या वितरित) एसिंक्रोनस फ्यूचर्स के साथ एक विस्तारणीय वायदा एपीआई लागू करता है<ref>[https://cran.r-project.org/package=future R package future]</ref><ref>[https://cran.r-project.org/package=future future]</ref>
+** फ़्यूचर्स, शिथिल और व्यग्र सिंक्रोनस और (मल्टीकोर या वितरित) अतुल्यकालिक फ्यूचर्स के साथ विस्तारणीय फ़्यूचर्स एपीआई लागू करता है<ref>[https://cran.r-project.org/package=future R package future]</ref><ref>[https://cran.r-project.org/package=future future]</ref>
 * [[रूबी (प्रोग्रामिंग भाषा)]] के लिए:
 ** समवर्ती रूबी<ref>[https://github.com/ruby-concurrency/concurrent-ruby Concurrent Ruby]</ref>
-**वचन रत्न<ref>[http://rubygems.org/gems/promise Ruby Promise gem]</ref>
+**प्रॉमिस जेम<ref>[http://rubygems.org/gems/promise Ruby Promise gem]</ref>
-** लिबुव रत्न, वादों को लागू करता है<ref>[https://github.com/cotag/libuv Ruby libuv]</ref>
+** लिबुव जेम, प्रोमिस को लागू करता है<ref>[https://github.com/cotag/libuv Ruby libuv]</ref>
-** सेल्युलाइड रत्न, वायदा लागू करता है<ref>{{Cite web |url=http://celluloid.io/ |title=रूबी सेल्युलाइड रत्न|access-date=19 February 2022 |archive-date=8 May 2013 |archive-url=https://web.archive.org/web/20130508122056/http://celluloid.io/ |url-status=dead }}</ref>
+** सेल्युलाइड जेम, फ़्यूचर्स लागू करता है<ref>{{Cite web |url=http://celluloid.io/ |title=रूबी सेल्युलाइड रत्न|access-date=19 February 2022 |archive-date=8 May 2013 |archive-url=https://web.archive.org/web/20130508122056/http://celluloid.io/ |url-status=dead }}</ref>
-**वायदा-संसाधन<ref>[https://github.com/adhearsion/future-resource Ruby future-resource]</ref>
+**फ़्यूचर्स-संसाधन<ref>[https://github.com/adhearsion/future-resource Ruby future-resource]</ref>
-* जंग के लिए (प्रोग्रामिंग भाषा):
+* रस्ट (प्रोग्रामिंग भाषा) के लिए :
 ** फ्यूचर्स-आरएस<ref>[https://github.com/alexcrichton/futures-rs futures-rs crate]</ref>
 * स्काला (प्रोग्रामिंग भाषा) के लिए:
 ** ट्विटर की उपयोग लाइब्रेरी<ref>[https://twitter.github.io/util/ Twitter's util library]</ref>
 * स्विफ्ट (प्रोग्रामिंग भाषा) के लिए:
-** Async फ्रेमवर्क, C#-शैली को लागू करता है <code>async</code>/ गैर-अवरुद्ध <code>await</code><ref>{{Cite web |url=https://bitbucket.org/al45tair/async |title=स्विफ्ट एसिंक्स|access-date=23 June 2014 |archive-date=31 December 2018 |archive-url=https://web.archive.org/web/20181231092935/https://bitbucket.org/al45tair/async |url-status=dead }}</ref>
+** Async फ्रेमवर्क, C#-स्टाइल <code>async</code>/ नॉन-ब्लॉकिंग वेट <code>await</code><ref>{{Cite web |url=https://bitbucket.org/al45tair/async |title=स्विफ्ट एसिंक्स|access-date=23 June 2014 |archive-date=31 December 2018 |archive-url=https://web.archive.org/web/20181231092935/https://bitbucket.org/al45tair/async |url-status=dead }}</ref>को लागू करता है
 ** फ्यूचरकिट,<ref>[https://github.com/FutureKit/FutureKit Swift FutureKit]</ref> Apple GCD के लिए एक संस्करण लागू करता है<ref>[https://developer.apple.com/library/prerelease/mac/documentation/Performance/Reference/GCD_libdispatch_Ref/ Swift Apple GCD]</ref>
-** FutureLib, प्योर स्विफ्ट 2 लाइब्रेरी स्काला-स्टाइल फ्यूचर्स को लागू करती है और TPL- स्टाइल कैंसलेशन के साथ वादा करती है<ref>[https://github.com/couchdeveloper/FutureLib Swift FutureLib]</ref>
+** FutureLib, प्योर स्विफ्ट 2 लाइब्रेरी स्काला-स्टाइल फ्यूचर्स को लागू करती है और टीपीएल-स्टाइल कैंसिलेशन के साथ प्रोमिस करती है<ref>[https://github.com/couchdeveloper/FutureLib Swift FutureLib]</ref>
-** आस्थगित, शुद्ध स्विफ्ट पुस्तकालय OCaml के आस्थगित से प्रेरित है<ref>[https://github.com/bignerdranch/deferred bignerdranch/Deferred]</ref> ** ब्राइट फ्यूचर्स<ref>[https://github.com/Thomvis/BrightFutures Thomvis/BrightFutures]</ref> ** स्विफ्टकॉरटाइन<ref>[https://github.com/belozierov/SwiftCoroutine belozierov/SwiftCoroutine]</ref>
+** ओकैमल के डिफर्ड से प्रेरित डिफर्ड, प्योर स्विफ्ट लाइब्रेरी<ref>[https://github.com/bignerdranch/deferred bignerdranch/Deferred]</ref> ** ब्राइट फ्यूचर्स<ref>[https://github.com/Thomvis/BrightFutures Thomvis/BrightFutures]</ref> ** स्विफ्टकॉरटाइन<ref>[https://github.com/belozierov/SwiftCoroutine belozierov/SwiftCoroutine]</ref>
-* [[टीसीएल (प्रोग्रामिंग भाषा)]] के लिए: टीसीएल-वादा<ref>[https://sourceforge.net/projects/tcl-promise/ tcl-promise]</ref>
+* [[टीसीएल (प्रोग्रामिंग भाषा)]] के लिए: टीसीएल-प्रोमिस<ref>[https://sourceforge.net/projects/tcl-promise/ tcl-promise]</ref>
 === कोरूटिन्स ===
-फ्यूचर्स को कोरआउट्स में लागू किया जा सकता है<ref name="python"/>या [[जनरेटर (कंप्यूटर प्रोग्रामिंग)]],<ref>[https://esdiscuss.org/topic/does-async-await-solve-a-real-problem#content-2 Does async/await solve a real problem?]</ref> परिणामस्वरूप एक ही मूल्यांकन रणनीति (जैसे, सहकारी मल्टीटास्किंग या आलसी मूल्यांकन)।
+फ्यूचर्स को कोरूटिन<ref name="python"/>या [[जनरेटर (कंप्यूटर प्रोग्रामिंग)]],<ref>[https://esdiscuss.org/topic/does-async-await-solve-a-real-problem#content-2 Does async/await solve a real problem?]</ref> में लागू किया जा सकता है, जिसके परिणामस्वरूप एक ही मूल्यांकन रणनीति (जैसे, सहकारी मल्टीटास्किंग या शिथिल मूल्यांकन) होती है।
 === चैनल ===
-{{main|Channel (programming)}}
+{{main|चैनल (प्रोग्रामिंग)}}
-वायदा को [[चैनल (प्रोग्रामिंग)]] में आसानी से कार्यान्वित किया जा सकता है: वायदा एक एकल-तत्व चैनल है, और वादा एक प्रक्रिया है जो चैनल को भेजता है, वायदा को पूरा करता है।<ref>[https://sites.google.com/site/gopatterns/concurrency/futures Go language patterns Futures]</ref><ref>[https://sites.google.com/site/gopatterns Go Language Patterns]</ref> यह सीएसपी और गो (प्रोग्रामिंग भाषा) जैसे चैनलों के समर्थन के साथ समवर्ती प्रोग्रामिंग भाषाओं में फ्यूचर्स को लागू करने की अनुमति देता है। परिणामी वायदे स्पष्ट हैं, क्योंकि उन्हें केवल मूल्यांकन के बजाय चैनल से पढ़कर एक्सेस किया जाना चाहिए।
+फ़्यूचर्स को [[चैनल (प्रोग्रामिंग)]] में आसानी से कार्यान्वित किया जा सकता है: फ़्यूचर्स एकल-तत्व चैनल है, और प्रोमिस एक प्रक्रिया है जो चैनल को भेजता है, फ़्यूचर्स को पूरा करता है।<ref>[https://sites.google.com/site/gopatterns/concurrency/futures Go language patterns Futures]</ref><ref>[https://sites.google.com/site/gopatterns Go Language Patterns]</ref> यह सीएसपी और Go (प्रोग्रामिंग भाषा) जैसे चैनलों के समर्थन के साथ समवर्ती प्रोग्रामिंग लैंग्वेज में फ्यूचर्स को लागू करने की अनुमति देता है। परिणामी फ़्यूचर्स लुसिड हैं, क्योंकि उन्हें केवल मूल्यांकन के अतिरिक्त चैनल से पढ़कर एक्सेस किया जाना चाहिए।
 == यह भी देखें ==
 * [[फाइबर (कंप्यूटर विज्ञान)]]
 * [[ Futex ]]
-* [[कयामत का पिरामिड (प्रोग्रामिंग)]], वादों से बचने वाला एक डिज़ाइन एंटीपैटर्न
+* [[कयामत का पिरामिड (प्रोग्रामिंग)]], प्रोमिस से बचने वाला एक डिज़ाइन एंटीपैटर्न
 == संदर्भ ==
@@ Line 369: / Line 360: @@
 == बाहरी संबंध ==
 *[http://shairosenfeld.com/concurrency.html Concurrency patterns presentation] given at [http://scaleconf.org scaleconf]
-* [http://c2.com/cgi/wiki?FutureValue Future Value] and [http://c2.com/cgi/wiki?PromisePipelining Promise Pipelining] at the [[Portland Pattern Repository]]
+* [http://c2.com/cgi/wiki?FutureValue Future Value] and [[wiki:PromisePipelining|प्रोमिस Pipelining]] at the [[Portland Pattern Repository]]
-* [http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/84317 Easy Threading with Futures] in [[Python (language)|Python]]
+* [http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/84317 Easy Threading with Futures] in [[Python (language)|पायथन]]
-{{DEFAULTSORT:Futures and promises}}[[Category: अंतःप्रक्रम संचार]] [[Category: अभिनेता मॉडल (कंप्यूटर विज्ञान)]]
+{{DEFAULTSORT:Futures and promises}}
-[[Category: Machine Translated Page]]
+[[Category:Articles with hatnote templates targeting a nonexistent page|Futures and promises]]
-[[Category:Created On 26/05/2023]]
+[[Category:CS1 errors]]
+[[Category:Created On 26/05/2023|Futures and promises]]
+[[Category:Lua-based templates|Futures and promises]]
+[[Category:Machine Translated Page|Futures and promises]]
+[[Category:Pages with script errors|Futures and promises]]
+[[Category:Templates Vigyan Ready|Futures and promises]]
+[[Category:Templates that add a tracking category|Futures and promises]]
+[[Category:Templates that generate short descriptions|Futures and promises]]
+[[Category:Templates using TemplateData|Futures and promises]]
+[[Category:Webarchive template wayback links]]
+[[Category:अंतःप्रक्रम संचार|Futures and promises]]
+[[Category:अभिनेता मॉडल (कंप्यूटर विज्ञान)|Futures and promises]]

Anonymous

Search

फ़्यूचर्स और प्रोमिस: Difference between revisions

Latest revision as of 16:31, 9 June 2023

अनुप्रयोग

अंतर्निहित बनाम लुसिड

प्रोमिस पाइपलाइनिंग

रीड-ओनली विचार

थ्रेड-स्पेसिफिक फ्यूचर्स

ब्लॉकिंग बनाम नॉन-ब्लॉकिंग अर्थविज्ञान

संबंधित निर्माण

फ़्यूचर्स के विभिन्न रूपों की अभिव्यक्ति के बीच संबंध

मूल्यांकन रणनीति

एक्टर मॉडल में फ्यूचर्स का सिमेंटिक्स

इतिहास

कार्यान्वयन की सूची

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

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

कोरूटिन्स

चैनल

यह भी देखें

संदर्भ

बाहरी संबंध

Navigation

Wiki tools

Page tools

Other projects

Categories