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

From Vigyanwiki
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’