अतुल्यकालिक प्रोग्रामिंग सिर्फ एक अन्य प्रोग्रामिंग चाल की तुलना में एक दर्शन का अधिक है। हालांकि, आपके अंतिम प्रश्न ने प्रोग्रामिंग पहलुओं के बारे में मुख्य रूप से उत्तर आकर्षित किए हैं और मेरा उत्तर ज्यादातर सैद्धांतिक होने के लिए डिस्कनेक्ट किया गया अकेला था, मैं आपको केवल संदर्भों के बजाय उसी लाइन पर एक नया परिप्रेक्ष्य निर्माण देने की कोशिश कर रहा हूं।
यह अतुल्यकालिक प्रोग्रामिंग के क्यों और कैसे के कुछ बुनियादी बातों के बारे में है।
मान लीजिए कि आप एक बेकरी की दुकान पर जाते हैं (और यह मानते हुए कि केक ऑर्डर के बाद तैयार किया जाएगा) - आपके पास दो विकल्प हैं, या तो आप तब तक इंतजार करें जब तक कि केक तैयार न हो जाए और आप ऑर्डर दें और घर वापस जाएं और पिकअप करें बाद में जब यह तैयार है। पहले एक (प्रतीक्षा) एक तुल्यकालिक विधि है और बाद में अतुल्यकालिक विधि है । यह कहने की आवश्यकता नहीं है कि यह उदाहरण एक अच्छा संदर्भ प्रदान करता है कि आपको सिंक्रोनस पर अतुल्यकालिक तरीकों का उपयोग क्यों करना चाहिए।
इवेंट आधारित प्रोग्रामिंग केवल एक तरीका है जिससे एसिंक्रोनस सिस्टम का निर्माण किया जा सकता है और यह सिर्फ एक उपयोगी डिज़ाइन पैटर्न नहीं है, बल्कि यह एक वास्तुशिल्प पैटर्न है। मैं उन मामलों को सूचीबद्ध कर रहा हूं जहां इस सिद्धांत का व्यावहारिक रूप से उपयोगी तरीके से उपयोग किया जाता है - उम्मीद है कि यह कुछ स्पष्टता लाएगा
अतुल्यकालिक प्रणालियों के पहले उदाहरण में से एक यूनिक्स सिस्टम आईओ हैं। जब हम जानते हैं read(), write()और यहां तक कि select()कॉल भी प्रोग्राम फ्लो को ब्लॉक करते हैं, लेकिन ओएस के अंदर, वे एसिंक्रोनस होते हैं, यानी कर्नेल आमतौर पर जानता है कि ब्लॉक डिवाइस (उर्फ हार्ड डिस्क) बफर को भरने में कुछ समय लगेगा, जब तक कि सीपीयू मुफ्त नहीं होता उस संबंधित धागे से और इसलिए धागे को (तैयार नहीं) के रूप में पार्क किया गया है। देखें 1. मोरिस बाख "यूनिक्स ऑपरेटिंग सिस्टम का डिज़ाइन"
एक और सबसे आम उदाहरण UI फ्रेमवर्क का बहुमत है। यहां, सभी उपयोगकर्ता क्लिक पहले एक नियंत्रक के माध्यम से भेजे जाते हैं जो बदले में संबंधित एप्लिकेशन को कॉल बैक करते हैं। महत्वपूर्ण बात यह है कि इस तरह के कॉल बैक को कॉल-बैक का इंतजार नहीं करना चाहिए अन्यथा सिस्टम फ्रीज हो जाएगा। यूआई नियंत्रक से बैक-एंड पर कॉल बैक आमतौर पर अतुल्यकालिक होते हैं यदि वे भारी प्रसंस्करण को शामिल करते हैं।
अतुल्यकालिक प्रोग्रामिंग (एक शुद्ध डिजाइन पैटर्न के रूप में) का एक और अच्छा उदाहरण एक्टिव ऑब्जेक्ट है। एक सक्रिय वस्तु वह है जिसके पास अपना निजी धागा है जैसे कि एक कतार में कई अनुरोध रख सकते हैं और एक-एक करके निष्पादित कर सकते हैं। इस पत्र का संदर्भ लें: सक्रिय वस्तु । यह पैटर्न एंटरप्राइज़ सॉफ़्टवेयर से मोबाइल फ़्रेमवर्क में सही उपयोग किया जाता है। लोकप्रिय प्लेटफार्मों जावा / ईजेबी और .NET स्थानीय या दूरस्थ अतुल्यकालिक विधि मंगलाचरण की अनुमति देता है जो अनिवार्य रूप से सामान्य वस्तुओं को सक्रिय ऑब्जेक्ट बनने की अनुमति देता है। सिम्बियन OS में सक्रिय ऑब्जेक्ट वापस आ रहे थे: Aapo Haapanen द्वारा सिम्बियन OS में सक्रिय ऑब्जेक्ट्स (इसे भी देखें: सिम्बियन में सक्रिय ऑब्जेक्ट्स )। यह भी अब मौजूद हैAndroid )।
सक्रिय ऑब्जेक्ट के अलावा, एक ही लेखक डगलस सी। श्मिट ने अन्य कार्यों की संख्या का उत्पादन किया है जो सक्रिय ऑब्जेक्ट के लिए अन्य समानताएं हैं और अतुल्यकालिक पैटर्न भी हैं। इस ईवेंट हैंडलिंग पैटर्न को देखें और एक पूरा खाता उनकी पुस्तक पैटर्न-ओरिएंटेड सॉफ्टवेयर आर्किटेक्चर पर उपलब्ध है : पैटर्न समवर्ती और नेटवर्क ऑब्जेक्ट्स - V2
जब किसी दिए गए ऑब्जेक्ट को एपीआई को वापस करने की आवश्यकता होती है, तो वास्तव में काम पूरा करने के लिए पृष्ठभूमि में काम करते हुए, सामान्य कार्यप्रणाली को इसे प्राप्त करने के लिए एक बहु-थ्रेडेड सिस्टम होना चाहिए। थ्रेडेड सिस्टम C (पॉज़िक्स), C ++ ( बूस्ट ) से लेकर जावा, C # और हर जगह मौजूद हैं । सक्रिय वस्तु अनिवार्य रूप से केवल एक अमूर्त है जो इसे छिपा सकती है। देखें कि सक्रिय वस्तु कार्यान्वयन नग्न धागे पर बेहतर क्यों हैं। एक और अच्छा पढ़ा ।
लेकिन यह अवधारणा अतुल्यकालिक बनने के लिए किसी एप्लिकेशन के अंदर थ्रेड्स या ऑब्जेक्ट्स से परे जाती है। सबसे अच्छे उपयोग में से एक डिस्ट्रीब्यूटेड सिस्टम में है जहां दो अनुप्रयोगों के लिए एक-दूसरे के लिए तालमेल की जरूरत नहीं है। अच्छा पुराना (या इतना अच्छा नहीं कि आप इसे जिस भी तरीके से देखें) आरपीसी तुल्यकालिक था। [बेशक, अन्य अतुल्यकालिक आरपीसी भी हैं]। लेकिन मैसेज ओरिएंटेड मिडलवेयर जैसे आधुनिक विकल्प वास्तव में अच्छे कारणों के लिए अतुल्यकालिक हैं।
अंतिम लेकिन सबसे दिलचस्प एक हो सकता है, एजेंट प्रोग्रामिंग है जो संचार के अतुल्यकालिक मॉडल से लाभ उठा सकता है ।
जबकि अतुल्यकालिक प्रोग्रामिंग सेक्सी दिखती है, लेकिन यह अपनी खुद की जटिलता बनाता है:
- रिटर्न वैल्यू पास करने की रूपरेखा
- संचार के अतिरिक्त उपरि
- निर्माण को सिंक्रनाइज़ करने के लिए अतिरिक्त आवश्यकता है
- गतिरोधों, रेसिंग आदि की संभावना अगर चीजें सही नहीं हुईं।
... और इसी तरह।
इसका उपयोग हमेशा वास्तविक कारणों से ही किया जाना चाहिए।
तो अतुल्यकालिक मॉडल का उपयोग कब करना चाहिए? आपको बैकग्राउंड थ्रेड कब लगाना चाहिए और कॉलर को एसिंक्रोनस जाने की अनुमति देनी चाहिए? यहां कुछ अच्छे अंगूठे नियम हैं जब यह लागू होता है (लेकिन नहीं)
जब सिस्टम सख्त गंभीर संसाधन बातचीत को लागू करना चाहता है: उदाहरण के लिए, आप थ्रेड की एक निश्चित निश्चित संख्या रखना चाहते हैं। अतुल्यकालिक पैटर्न सिस्टम को कतार को लागू करने के लिए मजबूर करता है।
जब कॉल करने वाले को वास्तव में " वास्तविक करने के लिए अन्य उपयोगी चीजें" करने की आवश्यकता होती है । इसलिए कई बार, दूसरा थ्रेड भले ही अनब्लॉकिंग से बना हो, कुछ भी उपयोगी नहीं होगा और परिणामों के लिए मतदान के आसपास लटका रहता है। यह वास्तव में बुनियादी तुल्यकालिक मॉडल की तुलना में अधिक सीपीयू खपत कर सकता है।
जब आपको वितरित सिस्टम में विश्वसनीयता के उच्च स्तर की आवश्यकता होती है। ( मैसेज ओरिएंटेड मिडलवेयर देखें )।