सिंक्रोनसिटी एक मिथक है

सभी को नमस्कार!

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

ऐसे विषयों को छूने वाली पुस्तक लिखने के इच्छुक या सोचने वाले व्यक्ति - व्यक्तिगत रूप से लिखते हैं।

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

भौतिक दुनिया में इस तरह की जड़ता का मतलब है कि कुछ पहलू नई प्रौद्योगिकियों के आगमन के साथ भी अपनी प्रासंगिकता नहीं खोते हैं जो उत्पादकता के नए मोर्चे पर नए अवसर और पहुंच प्रदान करते हैं। वे वैध बने रहते हैं क्योंकि वे "डिजाइन के दौरान चुने गए विकल्प" नहीं हैं, लेकिन भौतिक ब्रह्मांड की अंतर्निहित वास्तविकता है।

भाषा और सिस्टम के निर्माण में समकालिकता और अतुल्यकालिकता के बीच का अंतर केवल डिजाइन का ऐसा पहलू है जिसमें गहरी भौतिक नींव है। अधिकांश प्रोग्रामर तुरंत ऐसे कार्यक्रमों और भाषाओं के साथ काम करना शुरू कर देते हैं, जहां तुल्यकालिक निष्पादन निहित है। वास्तव में, यह इतना स्वाभाविक है कि कोई भी इसके बारे में उल्लेख या बात नहीं करता है। इस संदर्भ में "सिंक्रोनस" शब्द का अर्थ है कि गणना तुरंत होती है, क्रमिक चरणों की एक श्रृंखला की तरह, और इसके पूरा होने से पहले और कुछ नहीं होता है। मैं “c = a + b” “x = f(y)” निष्पादित करता हूं - और इस निर्देश के पूरा होने तक और कुछ नहीं होगा।

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

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

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

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

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

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

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

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

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

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

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

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

स्वाभाविक रूप से, स्थानीय पैकेजिंग को एक सिंक्रोनस इंटरफ़ेस पर भी लागू किया जा सकता है, लेकिन इसके लिए आपको इंटरफ़ेस की एक विशेष विशेषता के रूप में एक बड़ी सीमा तक या प्रोग्राम पैकेज को "सच्चाई को छुपाना" पड़ेगा, जो पूरे क्लाइंट को जटिल बना सकता है। सच को छिपाने का एक क्लासिक उदाहरण आई / ओ है। एप्लिकेशन “write(byte)” कहता है, और इंटरफ़ेस success लौटाता है, लेकिन, वास्तव में, रिकॉर्ड स्वयं (साथ ही यह जानकारी कि क्या यह सफलतापूर्वक पारित हुआ) तब तक नहीं होगा जब तक कि बफर स्पष्ट रूप से भरा या खाली न हो, और यह तब होता है जब फ़ाइल बंद हो जाती है । कई एप्लिकेशन ऐसे विवरणों को अनदेखा कर सकते हैं - केवल एक गड़बड़ी तब होती है जब आवेदन को संचालन के कुछ अंतःक्रियात्मक अनुक्रमों की गारंटी देने की आवश्यकता होती है, साथ ही निचले स्तर पर क्या हो रहा है, इसका एक सच्चा विचार।

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

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

तुल्यकालिक मॉडल में, घटक और उनके प्रसंस्करण मॉडल आमतौर पर निकटता से संबंधित होते हैं।
अतुल्यकालिक बातचीत एक तंत्र है जिसे अक्सर बाध्यकारी ढीला करने के लिए उपयोग किया जाता है ।

लागत में कमी और प्रबंधन। जैसा कि ऊपर उल्लेख किया गया है, अतुल्यकालिक को छिपाने के लिए किसी भी तंत्र में कुछ संसाधन आवंटन और ओवरहेड शामिल हैं। किसी विशेष एप्लिकेशन के लिए, ऐसा ओवरहेड स्वीकार्य नहीं हो सकता है, और उस एप्लिकेशन के डिजाइनर को प्राकृतिक अतुल्यकालिक को नियंत्रित करने का एक तरीका खोजना होगा।

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

बैकएंड डेवलपमेंट में NodeJS की सफलता को न केवल कई जावास्क्रिप्ट डेवलपर्स के पक्ष से इस इंजन के समर्थन से समझाया गया है जो क्लाइंट वेब इंटरफेस बनाते हुए बड़े हुए हैं। NodeJS में, ब्राउज़र स्क्रिप्टिंग के रूप में, अतुल्यकालिक तरीके से डिजाइन करने पर बहुत ध्यान दिया जाता है, जो विशिष्ट सर्वर लोड विकल्पों के साथ अच्छी तरह से चला जाता है: सर्वर संसाधनों का प्रबंधन मुख्य रूप से I / O पर निर्भर करता है, और प्रसंस्करण पर नहीं।

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

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

अन्य विषय

रद्द करना

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

थ्रॉटलिंग / संसाधन प्रबंधन

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

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

अच्छा इंटरएक्टिव प्रदर्शन सुनिश्चित करने के लिए, हमारे एप्लिकेशन को कुछ रेंडरिंग प्रदान करनी चाहिए (यह सुनिश्चित करें कि वह लाइन जहां कर्सर अब अपडेट और रेंडर किया गया है), और फिर जांचें कि क्या कोई अन्य कीबोर्ड इनपुट है जिसे पढ़ने की आवश्यकता है। , ( , ), , . API. , , - . , . UI , .

, 30 (-, Facebook iPhone ). – ( , ), , . , , .



, . , Microsoft, , API – , , . , , – : «, !» , , .

, . – , . , : , , , . , - . , , async/await . «» , , , JavaScript. : , . Async/await , , . . , , , .

. , , . , , , . , , ( !). () , , .

, . , . async/await, , , , .

, , , – . , . – , , , ( , – Word Excel). , , - , , , .
, , , , .
, – . .

निष्कर्ष

. – , , . , , , . , ; , .