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

From Vigyanwiki
Line 3: Line 3:




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


''वादा''  शब्द1976 में डेनियल पी. फ्रीडमैन और डेविड वाइज द्वारा प्रस्तावित किया गया था,<ref>{{cite conference
''प्रोमिस''  शब्द1976 में डेनियल पी. फ्रीडमैन और डेविड वाइज द्वारा प्रस्तावित किया गया था,<ref>{{cite conference
| first= Daniel
| first= Daniel
| last= Friedman
| last= Friedman
Line 19: Line 19:
| title= Parallel Processing Facilities
| title= Parallel Processing Facilities
| conference= New Directions in Algorithmic Languages, (ed.) Stephen A. Schuman, IRIA, 1976.
| 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
| author1=Henry Baker
| author2=Carl Hewitt
| author2=Carl Hewitt
Line 34: Line 34:
}}</ref>
}}</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
|author1=Barbara Liskov |author2=Liuba Shrira | title= Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems
| year= 1988
| year= 1988
Line 52: Line 52:
| pages=260–267
| pages=260–267
| isbn=0-89791-269-1
| 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())
  t3 := (x.a() .c(y.b())
</पूर्व>
</पूर्व>जिसे बढ़ाया जा सकता है<पूर्व>
जिसे बढ़ाया जा सकता है
  t 1: = x.a();
<पूर्व>
  t 2: = y.b ();
  टी 1: = एक्सए ();
  t3t:= t1.c(t2);
  टी 2: = वाईबी ();
प्रत्येक कथन को भेजे जाने के लिए संदेश की आवश्यकता होती है और अगले कथन के आगे बढ़ने से पहले एक उत्तर प्राप्त होता है। मान लीजिए, उदाहरण के लिए, कि <code>x</code>, <code>y</code>, <code>t1</code>, और <code>t2</code> सभी एक ही रिमोट मशीन पर स्थित हैं। इस मामले में, उस मशीन के लिए दो पूर्ण नेटवर्क राउंड-ट्रिप होनी चाहिए, इससे पहले कि तीसरा स्टेटमेंट निष्पादित हो सके। तीसरा कथन तब उसी रिमोट मशीन के लिए एक और राउंड-ट्रिप का कारण बनता है।
  t3 := t1.c(t2);
</पूर्व>
प्रत्येक कथन को भेजे जाने के लिए एक संदेश की आवश्यकता होती है और अगले कथन के आगे बढ़ने से पहले एक उत्तर प्राप्त होता है। मान लीजिए, उदाहरण के लिए, कि <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> एक ही रिमोट मशीन पर हैं। कई संदेशों को शामिल करने वाली अधिक जटिल स्थितियों में पाइपलाइनिंग का सापेक्ष विलंबता लाभ और भी अधिक हो जाता है।


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


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


* ओज में, <code>!!</code> ऑपरेटर का उपयोग रीड-ओनली दृश्य प्राप्त करने के लिए किया जाता है।
* ओज में, <code>!!</code> ऑपरेटर का उपयोग रीड-ओनली दृश्य प्राप्त करने के लिए किया जाता है।
* ई और एम्बिएंटटॉक में, वायदा को मूल्यों की एक जोड़ी द्वारा दर्शाया जाता है जिसे वादा/रिज़ॉल्वर जोड़ी कहा जाता है। वादा केवल-पढ़ने के दृश्य का प्रतिनिधित्व करता है, और वायदा के मान को निर्धारित करने के लिए रिज़ॉल्वर की आवश्यकता होती है।
* ई और एम्बिएंटटॉक में, फ़्यूचर्स को मूल्यों की एक जोड़ी द्वारा दर्शाया जाता है जिसे प्रोमिस/रिज़ॉल्वर जोड़ी कहा जाता है। प्रोमिस केवल-पढ़ने के दृश्य का प्रतिनिधित्व करता है, और फ़्यूचर्स के मान को निर्धारित करने के लिए रिज़ॉल्वर की आवश्यकता होती है।
* [[सी ++ 11]] ए में <code>std::future</code> रीड-ओनली दृश्य प्रदान करता है। मान सीधे a का उपयोग करके सेट किया गया है <code>std::promise</code>, या उपयोग करके फ़ंक्शन कॉल के परिणाम पर सेट करें <code>std::packaged_task</code> या <code>std::async</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>
* संस्करण 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>
* [[ऐलिस एमएल]] में, फ़्यूचर्स केवल पढ़ने के लिए दृश्य प्रदान करता है, जबकि एक वादे में फ़्यूचर्स और फ़्यूचर्स को हल करने की क्षमता दोनों शामिल हैं<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>.
* .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 future" />यह संगणना या तो [[उत्सुक मूल्यांकन]] शुरू कर सकती है जब फ़्यूचर्स बनाया जाता है, या [[आलसी मूल्यांकन]] जब इसके मान की पहली आवश्यकता होती है। विलंबित संगणना के अर्थ में एक आलसी फ़्यूचर्स [[थंक (कार्यात्मक प्रोग्रामिंग)]] के समान है।


ऐलिस एमएल भी वायदा का समर्थन करता है जिसे किसी भी धागे से हल किया जा सकता है, और इन वादों को कॉल करता है।<ref name= "Alice ML promise" />वादा का यह उपयोग ई में इसके उपयोग से अलग है जैसा कि #रीड-ओनली व्यूज में वर्णित है। ऐलिस में, एक वादा केवल पढ़ने के लिए दृश्य नहीं है, और वादा पाइपलाइनिंग असमर्थित है। इसके बजाय, वायदा के लिए पाइपलाइनिंग स्वाभाविक रूप से होती है, जिसमें वादों से जुड़े लोग भी शामिल हैं।
ऐलिस एमएल भी फ़्यूचर्स का समर्थन करता है जिसे किसी भी धागे से हल किया जा सकता है, और इन वादों को कॉल करता है।<ref name= "Alice ML promise" />प्रोमिस का यह उपयोग ई में इसके उपयोग से अलग है जैसा कि #रीड-ओनली व्यूज में वर्णित है। ऐलिस में, एक प्रोमिस केवल पढ़ने के लिए दृश्य नहीं है, और प्रोमिस पाइपलाइनिंग असमर्थित है। इसके बजाय, फ़्यूचर्स के लिए पाइपलाइनिंग स्वाभाविक रूप से होती है, जिसमें वादों से जुड़े लोग भी शामिल हैं।


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


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


* पहुंच वर्तमान थ्रेड या प्रक्रिया को तब तक अवरुद्ध कर सकती है जब तक कि वायदा हल न हो जाए (संभवतः टाइमआउट के साथ)। यह भाषा ओज़ (प्रोग्रामिंग भाषा) में डेटा प्रवाह चर का शब्दार्थ है।
* पहुंच वर्तमान थ्रेड या प्रक्रिया को तब तक अवरुद्ध कर सकती है जब तक कि फ़्यूचर्स हल न हो जाए (संभवतः टाइमआउट के साथ)। यह भाषा ओज़ (प्रोग्रामिंग भाषा) में डेटा प्रवाह चर का शब्दार्थ है।
* प्रयास की गई सिंक्रोनस एक्सेस हमेशा एक त्रुटि का संकेत दे सकती है, उदाहरण के लिए एक अपवाद फेंकना (कंप्यूटर विज्ञान)। यह ई में दूरस्थ वादों का शब्दार्थ है।<ref>{{citation |url=http://wiki.erights.org/wiki/Promise |title= Promise |publisher= E rights}}</ref>
* प्रयास की गई सिंक्रोनस एक्सेस हमेशा एक त्रुटि का संकेत दे सकती है, उदाहरण के लिए एक अपवाद फेंकना (कंप्यूटर विज्ञान)। यह ई में दूरस्थ वादों का शब्दार्थ है।<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> तो एक अवरुद्ध प्रतीक्षा (बिना टाइमआउट के) प्रतीक्षा थ्रेड पर परिणाम की गणना करने के लिए फ़ंक्शन के सिंक्रोनस आमंत्रण का कारण बन सकती है।
पहली संभावना के उदाहरण के रूप में, सी ++ 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>
फ्यूचर्स [[तुल्यकालन आदिम]] इवेंट (तुल्यकालिक प्रिमिटिव) का एक विशेष मामला है, जिसे केवल एक बार पूरा किया जा सकता है। सामान्य तौर पर, घटनाओं को प्रारंभिक खाली स्थिति में रीसेट किया जा सकता है और इस प्रकार, आप जितनी बार चाहें उतनी बार पूरा कर सकते हैं।<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>
एक 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>
एक समवर्ती तर्क चर {{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}} वायदा के समान है, लेकिन एकीकरण (कंप्यूटिंग) द्वारा अद्यतन किया जाता है, उसी तरह तर्क प्रोग्रामिंग में तर्क चर के रूप में। इस प्रकार इसे एक से अधिक बार अविवेकी मूल्यों के लिए बाध्य किया जा सकता है, लेकिन एक खाली या अनसुलझे स्थिति में वापस सेट नहीं किया जा सकता है। ओज़ के डेटाफ्लो चर समवर्ती तर्क चर के रूप में कार्य करते हैं, और उपरोक्त वर्णित शब्दार्थों को अवरुद्ध भी करते हैं।
एक समवर्ती तर्क चर {{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> ओज में निर्माण<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|Call by future}}


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


ए '{{visible anchor|lazy future}} एक ऐसा वायदा है जो नियतात्मक रूप से आलसी मूल्यांकन शब्दार्थ है: वायदा के मान की गणना तब शुरू होती है जब मान की पहली आवश्यकता होती है, जैसा कि जरूरत से कॉल में होता है। आलसी वायदा उन भाषाओं में उपयोग किया जाता है जिनकी मूल्यांकन रणनीति डिफ़ॉल्ट रूप से आलसी नहीं होती है। उदाहरण के लिए, C++11 में इस तरह के लेज़ी फ्यूचर्स को पास करके बनाया जा सकता है <code>std::launch::deferred</code> लॉन्च नीति को <code>std::async</code>, मान की गणना करने के लिए फ़ंक्शन के साथ।
ए '{{visible anchor|lazy future}} एक ऐसा फ़्यूचर्स है जो नियतात्मक रूप से आलसी मूल्यांकन शब्दार्थ है: फ़्यूचर्स के मान की गणना तब शुरू होती है जब मान की पहली आवश्यकता होती है, जैसा कि जरूरत से कॉल में होता है। आलसी फ़्यूचर्स उन भाषाओं में उपयोग किया जाता है जिनकी मूल्यांकन रणनीति डिफ़ॉल्ट रूप से आलसी नहीं होती है। उदाहरण के लिए, C++11 में इस तरह के लेज़ी फ्यूचर्स को पास करके बनाया जा सकता है <code>std::launch::deferred</code> लॉन्च नीति को <code>std::async</code>, मान की गणना करने के लिए फ़ंक्शन के साथ।


==एक्टर मॉडल में फ्यूचर्स का सिमेंटिक्स==
==एक्टर मॉडल में फ्यूचर्स का सिमेंटिक्स==
अभिनेता मॉडल में, रूप की अभिव्यक्ति <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> पर्यावरण ई और ग्राहक सी के साथ संदेश इस प्रकार है: फ़्यूचर्स की अभिव्यक्ति इसका जवाब देती है <code>Eval</code> ग्राहक सी को नव निर्मित कर्ता एफ (मूल्यांकन की प्रतिक्रिया के लिए प्रॉक्सी) भेजकर संदेश <code><Expression></code>) भेजने के साथ समवर्ती वापसी मान के रूप में <code><Expression></code> एक <code>Eval</code> पर्यावरण ई और ग्राहक सी के साथ संदेश। एफ का डिफ़ॉल्ट व्यवहार इस प्रकार है:


* जब एफ एक अनुरोध आर प्राप्त करता है, तो यह देखने के लिए जांचता है कि क्या उसे मूल्यांकन से पहले ही प्रतिक्रिया मिली है (जो या तो वापसी मान या फेंकने वाला अपवाद हो सकता है) <code><Expression></code> निम्नानुसार कार्यवाही करना:
* जब एफ एक अनुरोध आर प्राप्त करता है, तो यह देखने के लिए जांचता है कि क्या उसे मूल्यांकन से पहले ही प्रतिक्रिया मिली है (जो या तो वापसी मान या फेंकने वाला अपवाद हो सकता है) <code><Expression></code> निम्नानुसार कार्यवाही करना:
Line 145: Line 135:
**यदि वी एक अपवाद है, तो यह कतारबद्ध अनुरोधों में से प्रत्येक के ग्राहक को फेंक दिया जाता है।
**यदि वी एक अपवाद है, तो यह कतारबद्ध अनुरोधों में से प्रत्येक के ग्राहक को फेंक दिया जाता है।


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


1988 में [[बारबरा लिस्कोव]] और [[लिउबा श्रीरा]] द्वारा वादा पाइपलाइनिंग तकनीक (विलंबता को दूर करने के लिए वायदा का उपयोग करके) का आविष्कार किया गया था।<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"/>और स्वतंत्र रूप से मार्क एस. मिलर, डीन ट्रिबल और रॉब जेलिंगहौस द्वारा परियोजना 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>
वादा शब्द लिस्कोव और श्रीरा द्वारा गढ़ा गया था, हालांकि उन्होंने पाइपलाइनिंग तंत्र को कॉल-स्ट्रीम नाम से संदर्भित किया था, जो अब शायद ही कभी उपयोग किया जाता है।
प्रोमिस शब्द लिस्कोव और श्रीरा द्वारा गढ़ा गया था, हालांकि उन्होंने पाइपलाइनिंग तंत्र को कॉल-स्ट्रीम नाम से संदर्भित किया था, जो अब शायद ही कभी उपयोग किया जाता है।


लिस्कोव और श्रीरा के पेपर में वर्णित डिजाइन, और 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> जूल और ई में बाद के कार्यान्वयन पूरी तरह से प्रथम श्रेणी के वादों और रिज़ॉल्वर का समर्थन करते हैं।
लिस्कोव और श्रीरा के पेपर में वर्णित डिजाइन, और 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>{{cite journal
| author= Henry Lieberman
| author= Henry Lieberman
| title= A Preview of Act 1
| title= A Preview of Act 1
Line 167: Line 157:
|date=June 1981
|date=June 1981
| publisher= MIT AI memo 626
| publisher= MIT AI memo 626
}}</ref> समांतर संदेश पासिंग और पाइपलाइन संदेश प्रसंस्करण दोनों का समर्थन करता है, लेकिन पाइपलाइनिंग का वादा नहीं करता है। (यद्यपि इन विशेषताओं में से अंतिम को पहले दो में लागू करना तकनीकी रूप से संभव है, इस बात का कोई प्रमाण नहीं है कि अधिनियम की भाषाओं ने ऐसा किया है।)
}}</ref> समांतर संदेश पासिंग और पाइपलाइन संदेश प्रसंस्करण दोनों का समर्थन करता है, लेकिन पाइपलाइनिंग का प्रोमिस नहीं करता है। (यद्यपि इन विशेषताओं में से अंतिम को पहले दो में लागू करना तकनीकी रूप से संभव है, इस बात का कोई प्रमाण नहीं है कि अधिनियम की भाषाओं ने ऐसा किया है।)


2000 के बाद, उपयोगकर्ता इंटरफेस की [[जवाबदेही]] में उनके उपयोग के कारण, और [[वेब विकास]] में, संदेश-पासिंग के अनुरोध-प्रतिक्रिया मॉडल के कारण वायदा और वादों में रुचि का एक बड़ा पुनरुद्धार हुआ। कई मुख्यधारा की भाषाओं में अब वायदा और वादों के लिए भाषा का समर्थन है, जो विशेष रूप से लोकप्रिय हैं <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
2000 के बाद, उपयोगकर्ता इंटरफेस की [[जवाबदेही]] में उनके उपयोग के कारण, और [[वेब विकास]] में, संदेश-पासिंग के अनुरोध-प्रतिक्रिया मॉडल के कारण फ़्यूचर्स और वादों में रुचि का एक बड़ा पुनरुद्धार हुआ। कई मुख्यधारा की भाषाओं में अब फ़्यूचर्स और वादों के लिए भाषा का समर्थन है, जो विशेष रूप से लोकप्रिय हैं <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
|title=Asynchronous C# and F# (I.): Simultaneous introduction
|url=http://tomasp.net/blog/csharp-fsharp-async-intro.aspx/
|url=http://tomasp.net/blog/csharp-fsharp-async-intro.aspx/
Line 188: Line 178:
== कार्यान्वयन की सूची ==
== कार्यान्वयन की सूची ==


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


=== प्रोग्रामिंग लैंग्वेज द्वारा फ्यूचर्स और वादों से संबंधित अवधारणाओं की सूची ===
=== प्रोग्रामिंग लैंग्वेज द्वारा फ्यूचर्स और वादों से संबंधित अवधारणाओं की सूची ===
Line 206: Line 196:
** रचनात्मक सी ++
** रचनात्मक सी ++
* [[क्रिस्टल (प्रोग्रामिंग भाषा)]]
* [[क्रिस्टल (प्रोग्रामिंग भाषा)]]
* [[डार्ट (प्रोग्रामिंग भाषा)]] (वायदा/पूर्ण कक्षाओं के साथ<ref name="dartCompleter">{{cite web
* [[डार्ट (प्रोग्रामिंग भाषा)]] (फ़्यूचर्स/पूर्ण कक्षाओं के साथ<ref name="dartCompleter">{{cite web
|url=https://api.dartlang.org/1.12.1/dart-async/Completer-class.html
|url=https://api.dartlang.org/1.12.1/dart-async/Completer-class.html
|title=Dart SDK dart async Completer
|title=Dart SDK dart async Completer
Line 266: Line 256:
* विजुअल बेसिक.नेट{{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"/>
* विजुअल बेसिक.नेट{{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"/>


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


=== फ्यूचर्स के गैर-मानक, पुस्तकालय आधारित कार्यान्वयनों की सूची ===
=== फ्यूचर्स के गैर-मानक, लाइब्रेरी आधारित कार्यान्वयनों की सूची ===
* [[सामान्य लिस्प]] के लिए:
* [[सामान्य लिस्प]] के लिए:
** ब्लैकबर्ड<ref>[https://orthecreedence.github.io/blackbird/ Common Lisp Blackbird]</ref>
** ब्लैकबर्ड<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>[https://lparallel.org Lisp in parallel – A parallel programming library for Common Lisp]</ref>
** पीसी कॉल<ref>[http://marijnhaverbeke.nl/pcall/ Common Lisp PCall]</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
  |url=http://www.boost.org/doc/libs/release/doc/html/thread.html
  |title=Chapter 30. Thread 4.0.0
  |title=Chapter 30. Thread 4.0.0
Line 309: Line 299:
** डोजो टूलकिट वादों की आपूर्ति करता है<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> ट्विस्टेड (सॉफ्टवेयर)#Deferreds|Twisted's Deferreds से प्रेरित है
** [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://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>
** क्यू, कृष कोवल द्वारा, वादों/ए+ 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>
** ब्लूबर्ड, पेटका एंटोनोव द्वारा<ref>[https://github.com/petkaantonov/bluebird JavaScript Bluebird]</ref>
** Google क्लोजर टूल्स # क्लोजर लाइब्रेरी का [https://github.com/google/closure-library/tree/master/closure/goog/promise Promise] पैकेज Promises/A+ विनिर्देश के अनुरूप है।
** Google क्लोजर टूल्स # क्लोजर लाइब्रेरी का [https://github.com/google/closure-library/tree/master/closure/goog/promise Promise] पैकेज Promises/A+ विनिर्देश के अनुरूप है।
** देखें [http://promisesaplus.com/implementations Promise/A+'s] Promise/A+ डिज़ाइन के आधार पर अधिक कार्यान्वयन के लिए सूची।
** देखें [http://promisesaplus.com/implementations Promise/A+'s] Promise/A+ डिज़ाइन के आधार पर अधिक कार्यान्वयन के लिए सूची।
* जावा (प्रोग्रामिंग भाषा) के लिए:
* जावा (प्रोग्रामिंग भाषा) के लिए:
** JDeferred, आस्थगित-वादा API और [[JQuery]].Deferred वस्तु के समान व्यवहार प्रदान करता है<ref>[http://jdeferred.org Java JDeferred]</ref>
** JDeferred, आस्थगित-प्रोमिस API और [[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> OAPromise,<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>[https://docs.python.org/3/library/asyncio-task.html#future Python built-in implementation]</ref>
Line 332: Line 322:
** ट्विस्टेड (सॉफ्टवेयर) | ट्विस्टेड्स डेफर्ड्स<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>
* आर (प्रोग्रामिंग भाषा) के लिए:
* आर (प्रोग्रामिंग भाषा) के लिए:
** वायदा, आलसी और उत्सुक सिंक्रोनस और (मल्टीकोर या वितरित) एसिंक्रोनस फ्यूचर्स के साथ एक विस्तारणीय वायदा एपीआई लागू करता है<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>[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://github.com/alexcrichton/futures-rs futures-rs crate]</ref>
Line 346: Line 336:
** 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>
** फ्यूचरकिट,<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 लाइब्रेरी स्काला-स्टाइल फ्यूचर्स को लागू करती है और TPL- स्टाइल कैंसलेशन के साथ प्रोमिस करती है<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>
** आस्थगित, स्पष्ट स्विफ्ट लाइब्रेरी 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://sourceforge.net/projects/tcl-promise/ tcl-promise]</ref>
* [[टीसीएल (प्रोग्रामिंग भाषा)]] के लिए: टीसीएल-प्रोमिस<ref>[https://sourceforge.net/projects/tcl-promise/ tcl-promise]</ref>




Line 356: Line 346:
=== चैनल ===
=== चैनल ===
{{main|Channel (programming)}}
{{main|Channel (programming)}}
वायदा को [[चैनल (प्रोग्रामिंग)]] में आसानी से कार्यान्वित किया जा सकता है: वायदा एक एकल-तत्व चैनल है, और वादा एक प्रक्रिया है जो चैनल को भेजता है, वायदा को पूरा करता है।<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> यह सीएसपी और गो (प्रोग्रामिंग भाषा) जैसे चैनलों के समर्थन के साथ समवर्ती प्रोग्रामिंग भाषाओं में फ्यूचर्स को लागू करने की अनुमति देता है। परिणामी वायदे स्पष्ट हैं, क्योंकि उन्हें केवल मूल्यांकन के बजाय चैनल से पढ़कर एक्सेस किया जाना चाहिए।


== यह भी देखें ==
== यह भी देखें ==

Revision as of 11:44, 5 June 2023

Not to be confused with वादा सिद्धांत.


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

प्रोमिस शब्द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 एक ही रिमोट मशीन पर हैं। कई संदेशों को शामिल करने वाली अधिक जटिल स्थितियों में पाइपलाइनिंग का सापेक्ष विलंबता लाभ और भी अधिक हो जाता है।

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

केवल-पढ़ने के विचार

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

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

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

थ्रेड-विशिष्ट फ्यूचर्स

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

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

ब्लॉकिंग बनाम नॉन-ब्लॉकिंग शब्दार्थ

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

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

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

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

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

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

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

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

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

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

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

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

Further information: Call by future

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

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

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

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

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

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

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

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

इतिहास

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

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

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

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

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

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

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

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

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

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

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

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


कोरूटिन्स

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

चैनल

Main article: Channel (programming)

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

यह भी देखें

संदर्भ

  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
  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
  8. ↑ 8.0 8.1 "Promise", Alice Manual, DE: Uni-SB, archived from the original on 8 October 2008, retrieved 21 March 2007
  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.
  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.
  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".
  26. ↑ 26.0 26.1 Gilad Bracha (October 2014). "Dart Language Asynchrony Support: Phase 1".
  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.
  29. ↑ "Dart SDK dart async Completer".
  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. ↑ promises
  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. ↑ pythonfutures
  85. ↑ "मुड़ आस्थगित". Archived from the original on 6 August 2020. Retrieved 29 April 2010.
  86. ↑ R package future
  87. ↑ future
  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. ↑ futures-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. ↑ bignerdranch/Deferred
  100. ↑ Thomvis/BrightFutures
  101. ↑ belozierov/SwiftCoroutine
  102. ↑ tcl-promise
  103. ↑ Does async/await solve a real problem?
  104. ↑ Go language patterns Futures
  105. ↑ Go Language Patterns


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=फ़्यूचर्स_और_प्रोमिस&oldid=177637’