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

From Vigyanwiki
No edit summary
 
(7 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{Short description|Computer science constructs}}
{{Short description|Computer science constructs}}
{{distinguish|वादा सिद्धांत}}
{{distinguish| फ़्यूचर्स सिद्धांत}}




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


''प्रोमिस''  शब्द1976 में डेनियल पी. फ्रीडमैन और डेविड वाइज द्वारा प्रस्तावित किया गया था,<ref>{{cite conference
''प्रोमिस''  शब्द1976 में डेनियल पी. फ्रीडमैन और डेविड वाइज द्वारा प्रस्तावित किया गया था,<ref>{{cite conference
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 68: Line 68:
  t 2: = y <- b ();
  t 2: = y <- b ();
  t3t:= t1 <- c(t2);
  t3t:= t1 <- c(t2);
यहाँ प्रयुक्त वाक्य-विन्यास भाषा E का है, जहाँ <code>x <- a()</code> संदेश भेजने का मतलब है <code>a()</code> अतुल्यकालिक रूप से <code>x</code>. सभी तीन चरों को तुरंत उनके परिणामों के लिए फ़्यूचर्स सौंपा जाता है, और निष्पादन बाद के बयानों के लिए आगे बढ़ता है। बाद के मान को हल करने का प्रयास करता है <code>t3</code> विलम्ब हो सकती है; हालाँकि, पाइपलाइनिंग आवश्यक राउंड-ट्रिप की संख्या को कम कर सकती है। यदि, जैसा कि पिछले उदाहरण में है, <code>x</code>, <code>y</code>, <code>t1</code>, और <code>t2</code> सभी एक ही रिमोट मशीन पर स्थित हैं, पाइपलाइन कार्यान्वयन गणना <code>t3</code> तीन के बजाय एक राउंड-ट्रिप के साथ कर सकता है। क्योंकि सभी तीन संदेश उन वस्तुओं के लिए नियत हैं जो एक ही रिमोट मशीन पर हैं, केवल एक अनुरोध भेजने की आवश्यकता है और परिणाम के साथ केवल एक प्रतिक्रिया प्राप्त करने की आवश्यकता है। भेजना <code>t1 <- c(t2)</code> ब्लॉक भी नहीं करेंगे <code>t1</code> और <code>t2</code> एक दूसरे के लिए अलग-अलग मशीनों पर थे, या करने के लिए <code>x</code> या <code>y</code>
यहाँ प्रयुक्त वाक्य-विन्यास भाषा E का है, जहाँ <code>x <- a()</code> संदेश भेजने का मतलब है <code>a()</code> अतुल्यकालिक रूप से <code>x</code>. सभी तीन चरों को तुरंत उनके परिणामों के लिए फ़्यूचर्स सौंपा जाता है, और निष्पादन बाद के बयानों के लिए आगे बढ़ता है। बाद के मान को हल करने का प्रयास करता है <code>t3</code> विलम्ब हो सकती है; हालाँकि, पाइपलाइनिंग आवश्यक राउंड-ट्रिप की संख्या को कम कर सकती है। यदि, जैसा कि पिछले उदाहरण में है, <code>x</code>, <code>y</code>, <code>t1</code>, और <code>t2</code> सभी एक ही रिमोट मशीन पर स्थित हैं, पाइपलाइन कार्यान्वयन गणना <code>t3</code> तीन के अतिरिक्त एक राउंड-ट्रिप के साथ कर सकता है। क्योंकि सभी तीन संदेश उन वस्तुओं के लिए नियत हैं जो एक ही रिमोट मशीन पर हैं, केवल एक अनुरोध भेजने की आवश्यकता है और परिणाम के साथ केवल एक प्रतिक्रिया प्राप्त करने की आवश्यकता है। भेजना <code>t1 <- c(t2)</code> ब्लॉक भी नहीं करेंगे <code>t1</code> और <code>t2</code> एक दूसरे के लिए अलग-अलग मशीनों पर थे, या करने के लिए <code>x</code> या <code>y</code>


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


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


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


* Oz में, <code>!!</code> ऑपरेटर का उपयोग रीड-ओनली दृश्य प्राप्त करने के लिए किया जाता है।
* Oz में, <code>!!</code> ऑपरेटर का उपयोग रीड-ओनली दृश्य प्राप्त करने के लिए किया जाता है।
Line 81: Line 81:
* [[सी ++ 11|C ++ 11]]  में <code>std::future</code> रीड-ओनली दृश्य प्रदान करता है। मान सीधे <code>std::प्रोमिस</code>  का उपयोग करके सेट किया गया है, या उपयोग करके फ़ंक्शन कॉल के परिणाम पर सेट करें <code>std::packaged_task</code> या <code>std::async</code>.
* [[सी ++ 11|C ++ 11]]  में <code>std::future</code> रीड-ओनली दृश्य प्रदान करता है। मान सीधे <code>std::प्रोमिस</code>  का उपयोग करके सेट किया गया है, या उपयोग करके फ़ंक्शन कॉल के परिणाम पर सेट करें <code>std::packaged_task</code> या <code>std::async</code>.
* संस्करण 1.5 के रूप में [[डोजो टूलकिट]] के डिफर्ड एपीआई में, उपभोक्ता-मात्र प्रोमिस ऑब्जेक्ट रीड-ओनली दृश्य का प्रतिनिधित्व करती है।<ref>{{citation |url= http://www.sitepen.com/blog/2010/05/03/robust-promises-with-dojo-deferred-1-5/ |publisher= Site Pen |date= 2010-05-03 |title= Robust promises with Dojo deferred}}</ref>
* संस्करण 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 Framework 4.0 में <code>System.Threading.Tasks.Task<T></code> रीड-ओनली दृश्य का प्रतिनिधित्व करता है। मान को हल करके किया जा सकता है <code>System.Threading.Tasks.TaskCompletionSource<T></code>.
* .NET Framework 4.0 में <code>System.Threading.Tasks.Task<T></code> रीड-ओनली दृश्य का प्रतिनिधित्व करता है। मान को हल करके किया जा सकता है <code>System.Threading.Tasks.TaskCompletionSource<T></code>.


Line 87: Line 87:


== थ्रेड-स्पेसिफिक फ्यूचर्स ==
== थ्रेड-स्पेसिफिक फ्यूचर्स ==
ऐलिस एमएल (प्रोग्रामिंग लैंग्वेज) जैसी कुछ भाषाएं, फ्यूचर्स को परिभाषित करती हैं जो विशिष्ट थ्रेड से जुड़े होते हैं जो फ़्यूचर्स के मान की गणना करता है।<ref name= "Alice ML future" />यह संगणना या तो उत्सुकता से शुरू हो सकती है जब फ़्यूचर्स बनाया जाता है, या [[आलसी मूल्यांकन|शिथिल मूल्यांकन से]] जब इसके मान की पहली आवश्यकता होती है। विलंबित संगणना के अर्थ में शिथिल फ़्यूचर्स [[थंक (कार्यात्मक प्रोग्रामिंग)]] के समान है।
ऐलिस एमएल (प्रोग्रामिंग लैंग्वेज) जैसी कुछ भाषाएं, फ्यूचर्स को परिभाषित करती हैं जो विशिष्ट थ्रेड से जुड़े होते हैं जो फ़्यूचर्स के मान की गणना करता है।<ref name= "Alice ML future" />यह संगणना या तो उत्सुकता से प्रारंभ हो सकती है जब फ़्यूचर्स बनाया जाता है, या [[आलसी मूल्यांकन|शिथिल मूल्यांकन से]] जब इसके मान की पहली आवश्यकता होती है। विलंबित संगणना के अर्थ में शिथिल फ़्यूचर्स [[थंक (कार्यात्मक प्रोग्रामिंग)]] के समान है।


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


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


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


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


पहली संभावना के उदाहरण के रूप में, C ++ 11 में, थ्रेड जिसे फ़्यूचर्स के मान की आवश्यकता होती है, तब तक ब्लॉक कर सकता है जब तक कि यह कॉल करके सदस्य कार्य  <code>wait()</code> या <code>get()</code> उपलब्ध न हो। आप अनिश्चितकालीन ब्लॉकिंग से बचने के लिए <code>wait_for()</code> या <code>wait_until()</code> सदस्य फ़ंक्शंस का उपयोग करके वेट पर एक टाइमआउट भी निर्दिष्ट कर सकते हैं। अगर फ़्यूचर्स कॉल से <code>std::async</code> के लिए उत्पन्न हुआ है तो अवरुद्ध प्रतीक्षा (बिना टाइमआउट के) प्रतीक्षा थ्रेड पर परिणाम की गणना करने के लिए फ़ंक्शन के सिंक्रोनस आह्वान का कारण बन सकता है।
पहली संभावना के उदाहरण के रूप में, C ++ 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>
एक समवर्ती तर्क चर {{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}} फ़्यूचर्स के समान है, लेकिन एकीकरण (कंप्यूटिंग) द्वारा अद्यतन किया जाता है, उसी तरह तर्क प्रोग्रामिंग में तर्क चर के रूप में। इस प्रकार इसे एक से अधिक बार अविवेकी मूल्यों के लिए बाध्य किया जा सकता है, लेकिन एक खाली या अनसुलझे स्थिति में वापस सेट नहीं किया जा सकता है। ओज़ के डेटाफ्लो चर समवर्ती तर्क चर के रूप में कार्य करते हैं, और उपरोक्त वर्णित शब्दार्थों को अवरुद्ध भी करते हैं।


एक समवर्ती बाधा चर, [[बाधा तर्क प्रोग्रामिंग]] का समर्थन करने के लिए समवर्ती तर्क चर का सामान्यीकरण है: बाधा को कई बार संकुचित किया जा सकता है, जो संभावित मूल्यों के छोटे सेट का संकेत देता है। आम तौर पर एक थंक निर्दिष्ट करने का एक तरीका होता है जो तब चलना चाहिए जब भी बाधा आगे संकुचित हो; बाधा प्रचार का समर्थन करने के लिए इसकी आवश्यकता है।
I-var (जैसा कि भाषा Id (प्रोग्रामिंग भाषा) में है) एक फ़्यूचर्स है जो ऊपर परिभाषित अर्थविज्ञान को अवरुद्ध करता है। I- संरचना [[डेटा संरचना]] है जिसमें I-var होते हैं।संबंधित तुल्यकालन निर्माण जिसे विभिन्न मानों के साथ कई बार सेट किया जा सकता है, उसे M-var कहा जाता है। M-vars वर्तमान मान को लेने या रखने के लिए परमाणु संचालन का समर्थन करते हैं, जहाँ मान लेने से M-var वापस अपनी प्रारंभिक खाली स्थिति में सेट हो जाता है।'''<ref>{{citation |url= http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent-MVar.html |publisher= Haskell |title= Control Concurrent MVar |url-status= dead |archive-url= https://web.archive.org/web/20090418025331/http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent-MVar.html |archive-date= 18 April 2009 |df= dmy-all }}</ref>'''
 
समवर्ती लॉजिक चर फ़्यूचर्स के समान है, लेकिन एकीकरण (कंप्यूटिंग) द्वारा उसी तरह लॉजिक प्रोग्रामिंग में लॉजिक चर के रूप में अद्यतन किया जाता है। इस प्रकार इसे एक से अधिक बार अविवेकी मान के लिए बाध्य किया जा सकता है, लेकिन एक खाली या अनसुलझे स्थिति में वापस सेट नहीं किया जा सकता है। Oz के डेटाफ्लो चर समवर्ती लॉजिक चर के रूप में कार्य करते हैं, और उपरोक्त वर्णित शब्दार्थों को अवरुद्ध भी करते हैं।
 
समवर्ती प्रतिबंध चर, [[बाधा तर्क प्रोग्रामिंग|प्रतिबंध लॉजिक प्रोग्रामिंग]] का समर्थन करने के लिए समवर्ती लॉजिक चर का सामान्यीकरण है: प्रतिबंध को कई बार संकुचित किया जा सकता है, जो संभावित मान के छोटे सेट का संकेत देता है। सामान्यतः थंक निर्दिष्ट करने का तरीका होता है जो तब चलना चाहिए जब भी प्रतिबंध आगे संकुचित हो; प्रतिबंध प्रचार का समर्थन करने के लिए इसकी आवश्यकता है।


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


गैर-थ्रेड-विशिष्ट फ़्यूचर्स के संदर्भ में अंतर्निहित शिथिल थ्रेड-विशिष्ट फ़्यूचर्स (उदाहरण के लिए ऐलिस एमएल द्वारा प्रदान किया गया) को लागू करने के लिए, यह निर्धारित करने के लिए एक तंत्र की आवश्यकता होती है कि फ़्यूचर्स के मान की पहली आवश्यकता कब है (उदाहरण के लिए, <code>WaitNeeded</code> Oz में निर्माण<ref>{{citation |url= http://www.mozart-oz.org/home/doc/base/node13.html |title= WaitNeeded |publisher= Mozart Oz |access-date= 21 March 2007 |archive-date= 17 May 2013 |archive-url= https://web.archive.org/web/20130517004703/http://www.mozart-oz.org/home/doc/base/node13.html |url-status= dead }}</ref>). यदि सभी मान वस्तुएं हैं, तो पारदर्शी अग्रेषण वस्तुओं को लागू करने की क्षमता पर्याप्त है, क्योंकि फारवर्डर को भेजा गया पहला संदेश इंगित करता है कि फ़्यूचर्स के मान की आवश्यकता है।
गैर-थ्रेड-विशिष्ट फ़्यूचर्स के संदर्भ में अंतर्निहित शिथिल थ्रेड-विशिष्ट फ़्यूचर्स (उदाहरण के लिए ऐलिस एमएल द्वारा प्रदान किया गया) को लागू करने के लिए, यह निर्धारित करने के लिए तंत्र की आवश्यकता होती है कि फ़्यूचर्स के मान की पहली आवश्यकता कब है (उदाहरण के लिए, <code>WaitNeeded</code> Oz में निर्माण<ref>{{citation |url= http://www.mozart-oz.org/home/doc/base/node13.html |title= WaitNeeded |publisher= Mozart Oz |access-date= 21 March 2007 |archive-date= 17 May 2013 |archive-url= https://web.archive.org/web/20130517004703/http://www.mozart-oz.org/home/doc/base/node13.html |url-status= dead }}</ref>). यदि सभी मान वस्तुएं हैं, तो पारदर्शी अग्रेषण वस्तुओं को लागू करने की क्षमता पर्याप्त है, क्योंकि फारवर्डर को भेजा गया पहला संदेश इंगित करता है कि फ़्यूचर्स के मान की आवश्यकता है।


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


== मूल्यांकन रणनीति ==
== मूल्यांकन रणनीति ==
{{further|Call by future}}
{{further|फ़्यूचर्स के अनुसार कॉल}}


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


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


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


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


हालांकि, कुछ फ़्यूचर्स अधिक समानता प्रदान करने के लिए विशेष तरीकों से अनुरोधों से निपट सकते हैं। उदाहरण के लिए, अभिव्यक्ति <code>1 + future factorial(n)</code> एक नया फ़्यूचर्स बना सकते हैं जो संख्या की तरह व्यवहार करेगा <code>1+factorial(n)</code>. यह तरकीब हमेशा काम नहीं करती। उदाहरण के लिए, निम्नलिखित सशर्त अभिव्यक्ति:
चूंकि, कुछ फ़्यूचर्स अधिक समानता प्रदान करने के लिए विशेष तरीकों से अनुरोधों से निपट सकते हैं। उदाहरण के लिए, अभिव्यक्ति <code>1 + future factorial(n)</code> नया फ़्यूचर्स बना सकते हैं जो संख्या की तरह व्यवहार करेगा <code>1+factorial(n)</code>. यह तरकीब हमेशा काम नहीं करती हैं। उदाहरण के लिए, निम्नलिखित सशर्त अभिव्यक्ति:
: <code>''if'' m>future factorial(n) ''then'' print("bigger") ''else'' print("smaller")</code>
: <code>''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> स्वयं से बड़ा है या नहीं है।


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


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"/>और स्वतंत्र रूप से मार्क एस. मिलर, डीन ट्रिबल और रॉब जेलिंगहौस द्वारा परियोजना ज़ानाडू लगभग 1989 के संदर्भ में किया गया था।<ref>{{citation |url= http://www.sunless-sea.net/Transcripts/promise.html |publisher= Sunless Sea |title= Promise |archive-url= https://web.archive.org/web/20071023111712/http://www.sunless-sea.net/Transcripts/promise.html |archive-date=23 October 2007 }}</ref>
प्रोमिस शब्द लिस्कोव और श्रीरा द्वारा गढ़ा गया था, हालांकि उन्होंने पाइपलाइनिंग तंत्र को कॉल-स्ट्रीम नाम से संदर्भित किया था, जो अब शायद ही कभी उपयोग किया जाता है।


लिस्कोव और श्रीरा के पेपर में वर्णित डिजाइन, और Xanadu में प्रोमिस पाइपलाइनिंग के कार्यान्वयन दोनों की सीमा थी कि प्रोमिस के मान प्रथम श्रेणी के मान नहीं थे | सीधे तौर पर एक प्रोमिस नहीं होगा (इसलिए पहले दिए गए प्रोमिस पाइपलाइनिंग का उदाहरण, जो एक तर्क के रूप में दूसरे को भेजने के परिणाम के लिए एक प्रोमिस का उपयोग करता है, कॉल-स्ट्रीम डिज़ाइन या Xanadu कार्यान्वयन में सीधे अभिव्यक्त नहीं होता)। ऐसा लगता है कि अरगस की किसी भी सार्वजनिक रिलीज में प्रोमिस और कॉल-स्ट्रीम कभी भी लागू नहीं किए गए थे,<ref>{{citation |url= http://www.pmg.csail.mit.edu/Argus.html |publisher= MIT |title= Argus}}</ref> लिस्कोव और श्रीरा पेपर में प्रयुक्त प्रोग्रामिंग भाषा। आर्गस का विकास 1988 के आसपास बंद हो गया।<ref>{{citation |url= http://www.ieeeghn.org/wiki/index.php/Oral-History:Barbara_Liskov#Distributed_Computing_and_Argus |publisher= IEEE GHN |series= Oral history |first= Barbara |last= Liskov |title= Distributed computing and Argus|date= 26 January 2021 }}</ref> प्रोमिस पाइपलाइनिंग का Xanadu कार्यान्वयन केवल Udanax Gold के लिए स्रोत कोड जारी करने के साथ ही सार्वजनिक रूप से उपलब्ध हो गया<ref>{{citation |url= http://www.udanax.com/gold/ |publisher= Udanax |title= Gold |url-status= dead |archive-url= https://web.archive.org/web/20081011003837/http://www.udanax.com/gold/ |archive-date= 11 October 2008 |df= dmy-all }}</ref> 1999 में, और किसी भी प्रकाशित दस्तावेज़ में कभी भी समझाया नहीं गया था।<ref>{{citation |url= http://www.erights.org/elib/distrib/pipeline.html |publisher= E rights |title= Pipeline}}</ref> जूल और ई में बाद के कार्यान्वयन पूरी तरह से प्रथम श्रेणी के प्रोमिस और रिज़ॉल्वर का समर्थन करते हैं।
प्रोमिस शब्द लिस्कोव और श्रीरा द्वारा गढ़ा गया था, चूंकि उन्होंने पाइपलाइनिंग तंत्र को कॉल-स्ट्रीम नाम से संदर्भित किया था, जो अब शायद ही कभी उपयोग किया जाता है।
 
लिस्कोव और श्रीरा के पेपर में वर्णित डिजाइन, और ज़ानाडू में प्रोमिस पाइपलाइनिंग के कार्यान्वयन दोनों की सीमा थी कि प्रोमिस के मान प्रथम श्रेणी के मान नहीं थे | सीधे तौर पर प्रोमिस नहीं हो सकता था (इसलिए पहले दिए गए प्रोमिस पाइपलाइनिंग का उदाहरण, जो प्रेषण के परिणाम के लिए दूसरे को लॉजिक के रूप में प्रोमिस का उपयोग करता है, कॉल-स्ट्रीम डिज़ाइन या ज़ानाडू कार्यान्वयन में सीधे अभिव्यक्त नहीं होता)। ऐसा लगता है कि लिस्कोव और श्रीरा पेपर में उपयोग की जाने वाली प्रोग्रामिंग भाषा अरगस <ref>{{citation |url= http://www.pmg.csail.mit.edu/Argus.html |publisher= MIT |title= Argus}}</ref> की किसी भी सार्वजनिक रिलीज में प्रोमिस और कॉल-स्ट्रीम कभी भी लागू नहीं किए गए थे। आर्गस का विकास 1988 के आसपास बंद हो गया था।<ref>{{citation |url= http://www.ieeeghn.org/wiki/index.php/Oral-History:Barbara_Liskov#Distributed_Computing_and_Argus |publisher= IEEE GHN |series= Oral history |first= Barbara |last= Liskov |title= Distributed computing and Argus|date= 26 January 2021 }}</ref> प्रोमिस पाइपलाइनिंग का ज़ानाडू कार्यान्वयन केवल उडानैक्स गोल्ड के लिए स्रोत कोड जारी करने के साथ ही सार्वजनिक रूप से उपलब्ध हो गया<ref>{{citation |url= http://www.udanax.com/gold/ |publisher= Udanax |title= Gold |url-status= dead |archive-url= https://web.archive.org/web/20081011003837/http://www.udanax.com/gold/ |archive-date= 11 October 2008 |df= dmy-all }}</ref>था, और 1999 में, और किसी भी प्रकाशित दस्तावेज़ में कभी भी समझाया नहीं गया था।<ref>{{citation |url= http://www.erights.org/elib/distrib/pipeline.html |publisher= E rights |title= Pipeline}}</ref> जूल और E में बाद के कार्यान्वयन पूरी तरह से प्रथम श्रेणी के प्रोमिस और रिज़ॉल्वर का समर्थन करते हैं।


एक्ट सीरीज़ सहित कई प्रारंभिक कर्ता भाषाएँ,<ref>{{cite journal
एक्ट सीरीज़ सहित कई प्रारंभिक कर्ता भाषाएँ,<ref>{{cite journal
Line 157: Line 160:
|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/
|date=29 October 2010
|date=29 October 2010
|author=Tomas Petricek
|author=Tomas Petricek
}}</ref> जो 2007 की है।<ref>{{cite web
}}</ref> जो 2007 तक चलता है।<ref>{{cite web
|title=The F# Asynchronous Programming Model, PADL 2011
|title=The F# Asynchronous Programming Model, PADL 2011
|url=http://blogs.msdn.com/b/dsyme/archive/2010/10/21/the-f-asynchronous-programming-model-padl-2010-pre-publication-draft.aspx
|url=http://blogs.msdn.com/b/dsyme/archive/2010/10/21/the-f-asynchronous-programming-model-padl-2010-pre-publication-draft.aspx
Line 171: Line 174:
|author2=Tomas Petricek
|author2=Tomas Petricek
|author3=Dmitry Lomov
|author3=Dmitry Lomov
}}</ref> इसे बाद में अन्य भाषाओं द्वारा अपनाया गया, विशेष रूप से डार्ट (2014),<ref name="dart"/>पायथन (2015),<ref name="python">{{cite web
}}</ref> इसे बाद में अन्य लैंग्वेज द्वारा अपनाया गया, विशेष रूप से डार्ट (2014),<ref name="dart" />पायथन (2015),<ref name="python">{{cite web
|title=PEP 0492 – Coroutines with async and await syntax
|title=PEP 0492 – Coroutines with async and await syntax
|url=https://www.python.org/dev/peps/pep-0492/
|url=https://www.python.org/dev/peps/pep-0492/
}}</ref> हैक (एचएचवीएम), और ईसीएमएस्क्रिप्ट 7 (जावास्क्रिप्ट), स्काला, और सी ++ (2011) के ड्राफ्ट।
}}</ref> हैक (एचएचवीएम), और ईसीएमएस्क्रिप्ट 7 (जावास्क्रिप्ट), स्काला, और C ++ (2011) के ड्राफ्ट द्वारा अपनाया गया है।


== कार्यान्वयन की सूची ==
== कार्यान्वयन की सूची ==
Line 192: Line 195:
* ऐलिस (प्रोग्रामिंग भाषा)
* ऐलिस (प्रोग्रामिंग भाषा)
* एम्बिएंटटॉक (प्रथम श्रेणी रिज़ॉल्वर और रीड-ओनली प्रोमिस सहित)
* एम्बिएंटटॉक (प्रथम श्रेणी रिज़ॉल्वर और रीड-ओनली प्रोमिस सहित)
* [[C++]], C++11#थ्रेडिंग सुविधाओं से शुरू होता है|C++11: std::future और std::प्रोमिस
* [[C++]], C++11: std::future और std::प्रोमिस
<!--C# is under .NET below-->
** रचनात्मक सी ++
** रचनात्मक सी ++
* [[क्रिस्टल (प्रोग्रामिंग भाषा)]]
* [[क्रिस्टल (प्रोग्रामिंग भाषा)]]
Line 229: Line 231:
| access-date=23 February 2021
| access-date=23 February 2021
}}</ref>
}}</ref>
* स्पष्ट (प्रोग्रामिंग भाषा) (केवल डेटा प्रवाह)
* लुसिड (प्रोग्रामिंग भाषा) (केवल डेटा प्रवाह)
* कुछ [[लिस्प (प्रोग्रामिंग भाषा)]]
* कुछ [[लिस्प (प्रोग्रामिंग भाषा)]]
** [[क्लोजर]]<ref>{{cite web
** [[क्लोजर]]<ref>{{cite web
Line 239: Line 241:
}}</ref>
}}</ref>
** मल्टीलिस्प
** मल्टीलिस्प
* .NET Framework|.NET वाया टास्क
* .NET वाया टास्क
** सी शार्प (प्रोग्रामिंग लैंग्वेज) | सी #, .नेट फ्रेमवर्क 4.5 के बाद से,<ref name="asyncdotnet45"/>खोजशब्दों के माध्यम से <code>async</code> और <code>await</code><ref name="dotnetasyncawait"/>* [[कोटलिन (प्रोग्रामिंग भाषा)]], तथापि <code>kotlin.native.concurrent.Future</code> आमतौर पर केवल कोटलिन लिखते समय उपयोग किया जाता है जिसका ऑब्जेक्टिव मूल रूप से चलाना है<ref>{{Cite web|url=https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.native.concurrent/-future/|title=Future - Kotlin Programming Language}}</ref>
** सी #, .नेट फ्रेमवर्क 4.5 के बाद से,<ref name="asyncdotnet45"/>खोजशब्दों के माध्यम से <code>async</code> और <code>await</code><ref name="dotnetasyncawait"/>
*** [[कोटलिन (प्रोग्रामिंग भाषा)]], तथापि <code>kotlin.native.concurrent.Future</code> सामान्यतः केवल कोटलिन लिखते समय उपयोग किया जाता है जिसका ऑब्जेक्टिव मूल रूप से चलाना है<ref>{{Cite web|url=https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.native.concurrent/-future/|title=Future - Kotlin Programming Language}}</ref>
* [[निम (प्रोग्रामिंग भाषा)]]
* [[निम (प्रोग्रामिंग भाषा)]]
* [[ऑक्सीजन (प्रोग्रामिंग भाषा)]]
* [[ऑक्सीजन (प्रोग्रामिंग भाषा)]]
* ओज़ (प्रोग्रामिंग भाषा) संस्करण 3<ref>{{cite web |url=http://www.mozart-oz.org/documentation/tutorial/node1.html |title=ओज का ट्यूटोरियल|publisher=Mozart Global User Library |access-date=12 April 2011 |author=Seif Haridi |author2=Nils Franzen |archive-date=14 May 2011 |archive-url=https://web.archive.org/web/20110514010946/http://www.mozart-oz.org/documentation/tutorial/node1.html |url-status=dead }}</ref>
* Oz (प्रोग्रामिंग भाषा) संस्करण 3<ref>{{cite web |url=http://www.mozart-oz.org/documentation/tutorial/node1.html |title=ओज का ट्यूटोरियल|publisher=Mozart Global User Library |access-date=12 April 2011 |author=Seif Haridi |author2=Nils Franzen |archive-date=14 May 2011 |archive-url=https://web.archive.org/web/20110514010946/http://www.mozart-oz.org/documentation/tutorial/node1.html |url-status=dead }}</ref>
* [[पायथन (प्रोग्रामिंग भाषा)]] [https://docs.python.org/3/library/concurrent.futures.htmlcurrent.futures], 3.2 के बाद से,<ref>[https://www.python.org/download/releases/3.2/ Python 3.2 Release]</ref> [https://www.python.org/dev/peps/pep-3148/ PEP 3148] द्वारा प्रस्तावित, और Python 3.5 ने async और प्रतीक्षा को जोड़ा<ref>[https://www.python.org/downloads/release/python-350/ Python 3.5 Release]</ref>
* [[पायथन (प्रोग्रामिंग भाषा)]] [https://docs.python.org/3/library/concurrent.futures.htmlcurrent.futures], 3.2 के बाद से,<ref>[https://www.python.org/download/releases/3.2/ Python 3.2 Release]</ref> [https://www.python.org/dev/peps/pep-3148/ PEP 3148] द्वारा प्रस्तावित, और पायथन 3.5 ने async और प्रतीक्षा को जोड़ा<ref>[https://www.python.org/downloads/release/python-350/ Python 3.5 Release]</ref>
* [[आर (प्रोग्रामिंग भाषा)]] (शिथिल मूल्यांकन के लिए प्रोमिस, अभी भी सिंगल थ्रेडेड)
* [[आर (प्रोग्रामिंग भाषा)|R (प्रोग्रामिंग भाषा)]] (शिथिल मूल्यांकन के लिए प्रोमिस, अभी भी सिंगल थ्रेडेड)
* [[रैकेट (प्रोग्रामिंग भाषा)]]<ref>{{cite web|url=http://docs.racket-lang.org/guide/performance.html#(part._effective-futures)|title=फ्यूचर्स के साथ समानता|publisher=PLT|access-date=2 March 2012}}</ref>
* [[रैकेट (प्रोग्रामिंग भाषा)]]<ref>{{cite web|url=http://docs.racket-lang.org/guide/performance.html#(part._effective-futures)|title=फ्यूचर्स के साथ समानता|publisher=PLT|access-date=2 March 2012}}</ref>
* [[राकू (प्रोग्रामिंग भाषा)]]<ref>{{cite web|url=https://docs.raku.org/type/Promise|title=कक्षा का वादा|publisher=raku.org|access-date=2022-08-19}}</ref>
* [[राकू (प्रोग्रामिंग भाषा)]]<ref>{{cite web|url=https://docs.raku.org/type/Promise|title=कक्षा का वादा|publisher=raku.org|access-date=2022-08-19}}</ref>
* [[जंग (प्रोग्रामिंग भाषा)|रस्ट (प्रोग्रामिंग भाषा)]] (आमतौर पर <code>.await</code>)<ref>{{Cite web|url=https://doc.rust-lang.org/std/future/trait.Future.html|title = Future in STD::future - Rust}}</ref>
* [[जंग (प्रोग्रामिंग भाषा)|रस्ट (प्रोग्रामिंग भाषा)]] (सामान्यतः <code>.await</code>)<ref>{{Cite web|url=https://doc.rust-lang.org/std/future/trait.Future.html|title = Future in STD::future - Rust}}</ref>
* [[स्काला (प्रोग्रामिंग भाषा)]] [http://docs.scala-lang.org/overviews/core/futures.html scala.concurrent पैकेज] के माध्यम से
* [[स्काला (प्रोग्रामिंग भाषा)]] [http://docs.scala-lang.org/overviews/core/futures.html scala.concurrent पैकेज] के माध्यम से
* [[योजना (प्रोग्रामिंग भाषा)]]
* [[योजना (प्रोग्रामिंग भाषा)|स्कीम (प्रोग्रामिंग भाषा)]]
* [[ चीख़ ]] स्मॉलटॉक
* [[ चीख़ | स्क्वाक]] स्मॉलटॉक
* किनारा (प्रोग्रामिंग भाषा)
* स्ट्रैंड(प्रोग्रामिंग भाषा)
* [[स्विफ्ट (प्रोग्रामिंग भाषा)]] (केवल तीसरे पक्ष के पुस्तकालयों के माध्यम से)
* [[स्विफ्ट (प्रोग्रामिंग भाषा)]] (केवल तीसरे पक्ष के लाइब्रेरी के माध्यम से)
* विजुअल बेसिक.नेट{{clarify|Expert needed. Which one, or both? As is, this link is a WP:NOPIPE WP:EASTEREGG|date=March 2016}} 11 (कीवर्ड Async और Await के माध्यम से)<ref name="dotnetasyncawait"/>
* विजुअल बेसिक.नेट 11 (कीवर्ड Async और Await के माध्यम से)<ref name="dotnetasyncawait"/>


प्रोमिस पाइपलाइनिंग का समर्थन करने वाली भाषाओं में शामिल हैं:
प्रोमिस पाइपलाइनिंग का समर्थन करने वाली लैंग्वेज में सम्मिलित हैं:
* ई (प्रोग्रामिंग भाषा)
* ई (प्रोग्रामिंग भाषा)
* जूल (प्रोग्रामिंग भाषा)
* जूल (प्रोग्रामिंग भाषा)
Line 263: Line 266:
* [[सामान्य लिस्प]] के लिए:
* [[सामान्य लिस्प]] के लिए:
** ब्लैकबर्ड<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>
Line 275: Line 278:
  |title=Dlib C++ Library #thread_pool
  |title=Dlib C++ Library #thread_pool
  |access-date=26 June 2013}}</ref>
  |access-date=26 June 2013}}</ref>
**मूर्खता<ref>{{cite web|url=https://github.com/facebook/folly|title=GitHub – facebook/folly: An open-source C++ library developed and used at Facebook.|website=[[GitHub]]|date=2019-01-08}}</ref>
**फौली<ref>{{cite web|url=https://github.com/facebook/folly|title=GitHub – facebook/folly: An open-source C++ library developed and used at Facebook.|website=[[GitHub]]|date=2019-01-08}}</ref>
** एचपीएक्स <ref>{{cite web|url=http://stellar-group.org/libraries/hpx/|title=एचपीएक्स|date=2019-02-10}}</ref>
** एचपीएक्स <ref>{{cite web|url=http://stellar-group.org/libraries/hpx/|title=एचपीएक्स|date=2019-02-10}}</ref>
** POCO C++ लाइब्रेरी (सक्रिय परिणाम)<ref>{{cite web|url=https://pocoproject.org/slides/130-Threads.pdf|title=Threads Slides of POCO}}</ref>
** पोको C++ लाइब्रेरी (सक्रिय परिणाम)<ref>{{cite web|url=https://pocoproject.org/slides/130-Threads.pdf|title=Threads Slides of POCO}}</ref>
** [[क्यूटी (सॉफ्टवेयर)]]<ref>{{cite web
** [[क्यूटी (सॉफ्टवेयर)]]<ref>{{cite web
  |url=https://qt-project.org/doc/qt-5.0/qtcore/qfuture.html
  |url=https://qt-project.org/doc/qt-5.0/qtcore/qfuture.html
Line 287: Line 290:
  |url-status=dead
  |url-status=dead
  }}</ref>
  }}</ref>
** खड़ा है<ref>{{cite web
** सीस्टार<ref>{{cite web
  |url=http://seastar-project.org
  |url=http://seastar-project.org
  |title=Seastar
  |title=Seastar
Line 293: Line 296:
  |access-date=22 August 2016}}</ref>
  |access-date=22 August 2016}}</ref>
** छुरा<ref>{{cite web|url=https://stlab.cc/libraries/concurrency|title=स्टैब एडोब की सॉफ्टवेयर टेक्नोलॉजी लैब का चल रहा काम है। एडोब सोर्स लाइब्रेरीज़ (एएसएल), प्लेटफ़ॉर्म लाइब्रेरीज़ और नए स्टैब लाइब्रेरीज़ को जीथब पर होस्ट किया गया है।|date=2021-01-31}}</ref>
** छुरा<ref>{{cite web|url=https://stlab.cc/libraries/concurrency|title=स्टैब एडोब की सॉफ्टवेयर टेक्नोलॉजी लैब का चल रहा काम है। एडोब सोर्स लाइब्रेरीज़ (एएसएल), प्लेटफ़ॉर्म लाइब्रेरीज़ और नए स्टैब लाइब्रेरीज़ को जीथब पर होस्ट किया गया है।|date=2021-01-31}}</ref>
* सी शार्प (प्रोग्रामिंग लैंग्वेज)|C# और अन्य .NET Framework|.NET भाषाओं के लिए: [[समानांतर एक्सटेंशन]] लाइब्रेरी
* C# और अन्य .NET लैंग्वेज के लिए: [[समानांतर एक्सटेंशन]] लाइब्रेरी
* ग्रोवी (प्रोग्रामिंग भाषा) के लिए: जीपार्स<ref>[http://gpars.codehaus.org Groovy GPars] {{webarchive|url=https://web.archive.org/web/20130112092827/http://gpars.codehaus.org/ |date=12 January 2013 }}</ref>
* ग्रोवी (प्रोग्रामिंग भाषा) के लिए: जीपार्स<ref>[http://gpars.codehaus.org Groovy GPars] {{webarchive|url=https://web.archive.org/web/20130112092827/http://gpars.codehaus.org/ |date=12 January 2013 }}</ref>
* जावास्क्रिप्ट के लिए:
* जावास्क्रिप्ट के लिए:
Line 314: Line 317:
** कतार [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> ओएप्रोमाइज,<ref>[https://github.com/oleganza/OAPromise Objective-C OAPromise]</ref>
* [[ उद्देश्य सी |ऑब्जेक्टिव-सी]]  के लिए: एमएफ्यूचर,<ref>[https://github.com/mikeash/MAFuture Objective-C MAFuture GitHub]</ref><ref>[http://www.mikeash.com/pyblog/friday-qa-2010-02-26-futures.html Objective-C MAFuture mikeash.com]</ref> आरएक्स प्रोमिस,<ref>[https://github.com/couchdeveloper/RXPromise Objective-C RXPromise]</ref> ओबीजेसी-कोलैप्सिंग फ्यूचर्स,<ref>[https://github.com/Strilanc/ObjC-CollapsingFutures ObjC-CollapsingFutures]</ref> प्रॉमिसकिट,<ref>[http://promisekit.org/ Objective-C PromiseKit]</ref> ओबीजेसी-प्रोमिस,<ref>[https://github.com/mproberts/objc-promise Objective-C objc-promise]</ref> ओएप्रोमाइज,<ref>[https://github.com/oleganza/OAPromise Objective-C OAPromise]</ref>
* [[OCaml|ओ कैमल]] के लिए: शिथिल मॉड्यूल शिथिल स्पष्ट फ़्यूचर्स लागू करता है<ref>[http://caml.inria.fr/pub/docs/manual-ocaml/libref/Lazy.html OCaml Lazy]</ref>
* [[OCaml|ओ कैमल]] के लिए: शिथिल मॉड्यूल शिथिल लुसिड फ़्यूचर्स लागू करता है<ref>[http://caml.inria.fr/pub/docs/manual-ocaml/libref/Lazy.html OCaml Lazy]</ref>
* [[पर्ल]] के लिए: फ़्यूचर्स,<ref>[http://metacpan.org/module/Future Perl Future]</ref> प्रोमिस,<ref>[https://metacpan.org/pod/Promises Perl Promises]</ref> प्रतिवर्त,<ref>[http://metacpan.org/module/Reflex/ Perl Reflex]</ref> प्रोमिस::ES6,<ref>[http://metacpan.org/module/Promise::ES6/ Perl Promise::ES6]</ref> और प्रोमिस :: एक्सएस<ref>{{Cite web|title=Promise::XS - Fast promises in Perl - metacpan.org|url=https://metacpan.org/pod/Promise::XS|access-date=2021-02-14|website=metacpan.org}}</ref>
* [[पर्ल]] के लिए: फ़्यूचर्स,<ref>[http://metacpan.org/module/Future Perl Future]</ref> प्रोमिस,<ref>[https://metacpan.org/pod/Promises Perl Promises]</ref> प्रतिवर्त,<ref>[http://metacpan.org/module/Reflex/ Perl Reflex]</ref> प्रोमिस::ES6,<ref>[http://metacpan.org/module/Promise::ES6/ Perl Promise::ES6]</ref> और प्रोमिस :: एक्सएस<ref>{{Cite web|title=Promise::XS - Fast promises in Perl - metacpan.org|url=https://metacpan.org/pod/Promise::XS|access-date=2021-02-14|website=metacpan.org}}</ref>
* [[PHP|पीएचपी]] के लिए: प्रतिक्रिया/प्रोमिस करें<ref>[https://github.com/reactphp/promise PHP React/Promise]</ref>
* [[PHP|पीएचपी]] के लिए: प्रतिक्रिया/प्रोमिस करें<ref>[https://github.com/reactphp/promise PHP React/Promise]</ref>
Line 322: Line 325:
** ट्विस्टेड (सॉफ्टवेयर) डेफर्ड्स<ref>{{Cite web |url=http://twistedmatrix.com/documents/current/core/howto/defer.html |title=मुड़ आस्थगित|access-date=29 April 2010 |archive-date=6 August 2020 |archive-url=https://web.archive.org/web/20200806202718/https://twistedmatrix.com/documents/current/core/howto/defer.html |url-status=dead }}</ref>
** ट्विस्टेड (सॉफ्टवेयर) डेफर्ड्स<ref>{{Cite web |url=http://twistedmatrix.com/documents/current/core/howto/defer.html |title=मुड़ आस्थगित|access-date=29 April 2010 |archive-date=6 August 2020 |archive-url=https://web.archive.org/web/20200806202718/https://twistedmatrix.com/documents/current/core/howto/defer.html |url-status=dead }}</ref>
* R (प्रोग्रामिंग भाषा) के लिए:
* R (प्रोग्रामिंग भाषा) के लिए:
** फ़्यूचर्स, शिथिल और उत्सुक सिंक्रोनस और (मल्टीकोर या वितरित) अतुल्यकालिक फ्यूचर्स के साथ विस्तारणीय फ़्यूचर्स एपीआई लागू करता है<ref>[https://cran.r-project.org/package=future R package future]</ref><ref>[https://cran.r-project.org/package=future future]</ref>
** फ़्यूचर्स, शिथिल और व्यग्र सिंक्रोनस और (मल्टीकोर या वितरित) अतुल्यकालिक फ्यूचर्स के साथ विस्तारणीय फ़्यूचर्स एपीआई लागू करता है<ref>[https://cran.r-project.org/package=future R package future]</ref><ref>[https://cran.r-project.org/package=future future]</ref>
* [[रूबी (प्रोग्रामिंग भाषा)]] के लिए:
* [[रूबी (प्रोग्रामिंग भाषा)]] के लिए:
** समवर्ती रूबी<ref>[https://github.com/ruby-concurrency/concurrent-ruby Concurrent Ruby]</ref>
** समवर्ती रूबी<ref>[https://github.com/ruby-concurrency/concurrent-ruby Concurrent Ruby]</ref>
Line 344: Line 347:
=== चैनल ===
=== चैनल ===
{{main|चैनल (प्रोग्रामिंग)}}
{{main|चैनल (प्रोग्रामिंग)}}
फ़्यूचर्स को [[चैनल (प्रोग्रामिंग)]] में आसानी से कार्यान्वित किया जा सकता है: फ़्यूचर्स एकल-तत्व चैनल है, और प्रोमिस एक प्रक्रिया है जो चैनल को भेजता है, फ़्यूचर्स को पूरा करता है।<ref>[https://sites.google.com/site/gopatterns/concurrency/futures Go language patterns Futures]</ref><ref>[https://sites.google.com/site/gopatterns Go Language Patterns]</ref> यह सीएसपी और Go (प्रोग्रामिंग भाषा) जैसे चैनलों के समर्थन के साथ समवर्ती प्रोग्रामिंग भाषाओं में फ्यूचर्स को लागू करने की अनुमति देता है। परिणामी फ़्यूचर्स स्पष्ट हैं, क्योंकि उन्हें केवल मूल्यांकन के बजाय चैनल से पढ़कर एक्सेस किया जाना चाहिए।
फ़्यूचर्स को [[चैनल (प्रोग्रामिंग)]] में आसानी से कार्यान्वित किया जा सकता है: फ़्यूचर्स एकल-तत्व चैनल है, और प्रोमिस एक प्रक्रिया है जो चैनल को भेजता है, फ़्यूचर्स को पूरा करता है।<ref>[https://sites.google.com/site/gopatterns/concurrency/futures Go language patterns Futures]</ref><ref>[https://sites.google.com/site/gopatterns Go Language Patterns]</ref> यह सीएसपी और Go (प्रोग्रामिंग भाषा) जैसे चैनलों के समर्थन के साथ समवर्ती प्रोग्रामिंग लैंग्वेज में फ्यूचर्स को लागू करने की अनुमति देता है। परिणामी फ़्यूचर्स लुसिड हैं, क्योंकि उन्हें केवल मूल्यांकन के अतिरिक्त चैनल से पढ़कर एक्सेस किया जाना चाहिए।


== यह भी देखें ==
== यह भी देखें ==
Line 358: Line 361:
*[http://shairosenfeld.com/concurrency.html Concurrency patterns presentation] given at [http://scaleconf.org scaleconf]
*[http://shairosenfeld.com/concurrency.html Concurrency patterns presentation] given at [http://scaleconf.org scaleconf]
* [http://c2.com/cgi/wiki?FutureValue Future Value] and [[wiki:PromisePipelining|प्रोमिस Pipelining]] at the [[Portland Pattern Repository]]
* [http://c2.com/cgi/wiki?FutureValue Future Value] and [[wiki:PromisePipelining|प्रोमिस Pipelining]] at the [[Portland Pattern Repository]]
* [http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/84317 Easy Threading with Futures] in [[Python (language)|Python]]
* [http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/84317 Easy Threading with Futures] in [[Python (language)|पायथन]]
 
{{DEFAULTSORT:Futures and promises}}[[Category: अंतःप्रक्रम संचार]] [[Category: अभिनेता मॉडल (कंप्यूटर विज्ञान)]]
 


{{DEFAULTSORT:Futures and promises}}


[[Category: Machine Translated Page]]
[[Category:Articles with hatnote templates targeting a nonexistent page|Futures and promises]]
[[Category:Created On 26/05/2023]]
[[Category:CS1 errors]]
[[Category:Created On 26/05/2023|Futures and promises]]
[[Category:Lua-based templates|Futures and promises]]
[[Category:Machine Translated Page|Futures and promises]]
[[Category:Pages with script errors|Futures and promises]]
[[Category:Templates Vigyan Ready|Futures and promises]]
[[Category:Templates that add a tracking category|Futures and promises]]
[[Category:Templates that generate short descriptions|Futures and promises]]
[[Category:Templates using TemplateData|Futures and promises]]
[[Category:Webarchive template wayback links]]
[[Category:अंतःप्रक्रम संचार|Futures and promises]]
[[Category:अभिनेता मॉडल (कंप्यूटर विज्ञान)|Futures and promises]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

फ्यूचर्स तुल्यकालन आदिम "इवेंट्स" (तुल्यकालिक प्रिमिटिव) का विशेष मामला है, जिसे केवल एक बार पूरा किया जा सकता है। सामान्यतः, घटनाओं को प्रारंभिक खाली स्थिति में रीसेट किया जा सकता है और इस प्रकार, आप जितनी बार चाहें उतनी बार पूरा कर सकते हैं।[11]

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

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

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

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

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

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

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

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

Further information: फ़्यूचर्स के अनुसार कॉल

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

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

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

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

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

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

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

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

इतिहास

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

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

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

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

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

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

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

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

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

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

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

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

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

कोरूटिन्स

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

चैनल

Main article: चैनल (प्रोग्रामिंग)

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

यह भी देखें

संदर्भ

  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=179295’