.NET: मल्टीथ्रेडिंग और अतुल्यकालिक के साथ काम करने के लिए उपकरण। भाग 1

मैं हेबर पर मूल लेख प्रकाशित करता हूं, जिसका अनुवाद कोडिंगसाइट ब्लॉग पर पोस्ट किया गया है।
दूसरा भाग यहाँ उपलब्ध है।

यहाँ और अभी के परिणाम की प्रतीक्षा किए बिना, अतुल्यकालिक रूप से कुछ करने की आवश्यकता है, या इसे निष्पादित करने वाली कई इकाइयों के बीच बहुत सारे काम साझा करने के लिए, कंप्यूटर के आगमन से पहले भी था। उनकी उपस्थिति के साथ, इस तरह की आवश्यकता बहुत मूर्त हो गई है। अब, 2019 में, 8-कोर इंटेल कोर प्रोसेसर के साथ लैपटॉप पर इस लेख को टाइप करना, जिस पर एक ही समय में एक सौ प्रक्रियाएं काम नहीं करती हैं, लेकिन इससे भी अधिक थ्रेड। इसके बगल में एक थोड़ा बैटर फोन है, जिसे कुछ साल पहले खरीदा गया था, जिसमें 8-कोर प्रोसेसर लगा था। विषयगत संसाधन लेखों और वीडियो से भरे हुए हैं जहाँ उनके लेखक इस साल के प्रमुख स्मार्टफोन की प्रशंसा करते हैं जहाँ उन्होंने 16-कोर प्रोसेसर लगाए हैं। $ 20 / घंटा से कम समय के लिए, MS Azure 128 कोर प्रोसेसर और 2 टीबी रैम के साथ एक वर्चुअल मशीन प्रदान करता है। दुर्भाग्य से, प्रवाह की बातचीत को नियंत्रित करने में सक्षम होने के बिना इस शक्ति को अधिकतम करना और उस पर अंकुश लगाना असंभव है।

शब्दावली

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

रूपक

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

सुबह का नाश्ता मैं ( सीपीयू ) रसोई ( कंप्यूटर ) पर करता हूं। मेरे 2 हाथ ( कोरे ) हैं। रसोई में कई उपकरण ( IO ) हैं: ओवन, केतली, टोस्टर, रेफ्रिजरेटर। मैं गैस चालू करता हूं, उस पर एक फ्राइंग पैन डालता हूं और वहां तेल डालता हूं, जब तक वह गर्म नहीं होता है ( asynchronously, Non-Blocking-IO-Wait ), मैं अंडे को रेफ्रिजरेटर से बाहर निकालता हूं और उन्हें एक प्लेट में तोड़ता हूं, और फिर उन्हें एक हाथ से हराता हूं ( थ्रेड # 1 # ), और दूसरा ( थ्रेड # 2 ) मैं प्लेट (साझा संसाधन) रखता हूं। अब मैं केतली चालू करूंगा, लेकिन पर्याप्त हाथ नहीं हैं ( थ्रेड भुखमरी ) इस समय के दौरान, फ्राइंग पैन को गर्म किया जाता है (परिणाम को संसाधित करता है) जहां मैं वही डालता हूं जो मैंने व्हीप्ड किया था। मैं केतली के लिए पहुंचता हूं और इसे चालू करता हूं और बेवकूफी से देखता हूं कि इसमें पानी कैसे उबलता है ( ब्लॉकिंग-आईओ-रुको ), हालांकि मैं इस समय के दौरान प्लेट धो सकता था, जहां मैंने आमलेट को हराया।

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

रूपक जारी रखना:

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

.NET उपकरण

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

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

स्ट्रीम प्रारंभ करें

थ्रेड क्लास, थ्रेड के साथ काम करने के लिए .NET में सबसे बेसिक क्लास। निर्माणकर्ता दो प्रतिनिधियों में से एक को स्वीकार करता है:

• थ्रेडस्टार्ट - कोई पैरामीटर नहीं
• ParametrizedThreadStart - प्रकार ऑब्जेक्ट के एक पैरामीटर के साथ।

स्टार्ट विधि को कॉल करने के बाद, नए बनाए गए थ्रेड में प्रतिनिधि को निष्पादित किया जाएगा, यदि पैरामीटर के एक प्रतिनिधि को कंस्ट्रक्टर को पारित किया गया था, तो एक ऑब्जेक्ट को स्टार्ट विधि में पारित किया जाना चाहिए। किसी भी स्थानीय जानकारी को स्ट्रीम में स्थानांतरित करने के लिए इस तंत्र की आवश्यकता होती है। यह ध्यान देने योग्य है कि एक स्ट्रीम बनाना एक महंगा ऑपरेशन है, और स्ट्रीम ही एक भारी वस्तु है, कम से कम क्योंकि 1MB मेमोरी स्टैक को आवंटित की जाती है, और ओएस एपीआई के साथ बातचीत की आवश्यकता होती है।

new Thread(...).Start(...); 

थ्रेडपूल वर्ग एक पूल की अवधारणा का प्रतिनिधित्व करता है। .NET में, थ्रेड पूल कला का एक काम है और Microsoft के डेवलपर्स ने इसे विभिन्न प्रकार के परिदृश्यों में उत्कृष्ट रूप से काम करने में बहुत प्रयास किया है।

सामान्य अवधारणा:

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

पूल से एक थ्रेड का उपयोग करने के लिए, एक क्वेयूसेवरवर्क इटेम विधि है जो एक WaitCallback प्रतिनिधि को स्वीकार करती है, जो ParametrizedThreadStart के समान हस्ताक्षर है, और इसके लिए दिया गया पैरामीटर समान फ़ंक्शन करता है।

 ThreadPool.QueueUserWorkItem(...); 

कम ज्ञात थ्रेड पूल विधि RegisterWaitForSingleObject का उपयोग गैर-अवरुद्ध IO संचालन को व्यवस्थित करने के लिए किया जाता है। इस विधि में पारित प्रतिनिधि को तब बुलाया जाएगा जब वेटहैंडल विधि को पारित किया गया "जारी"।

 ThreadPool.RegisterWaitForSingleObject(...) 

.NET में एक स्ट्रीम टाइमर है और यह WinForms / WPF टाइमर से अलग है कि इसके हैंडलर को पूल से ली गई स्ट्रीम में बुलाया जाएगा।

 System.Threading.Timer 

पूल से थ्रेड के लिए एक प्रतिनिधि भेजने के लिए एक बल्कि विदेशी तरीका भी है - बिगिनॉक विधि।

 DelegateInstance.BeginInvoke 

मैं एक ऐसे फ़ंक्शन को पारित करने में भी ध्यान देना चाहता हूं जो उपरोक्त कई विधियों को कॉल करता है - CreateThread from Kernel32.dll Win32 API एक तरीका है, इस फ़ंक्शन को कॉल करने के लिए बाहरी तरीकों के तंत्र के लिए धन्यवाद। मैंने इस तरह की चुनौती को केवल एक बार विरासत कोड के एक भयानक उदाहरण में देखा, और लेखक की प्रेरणा सिर्फ ऐसा करने के लिए जो अभी भी मेरे लिए एक रहस्य है।

 Kernel32.dll CreateThread 

धागे देखें और डीबग करें

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

टास्क समानांतर पुस्तकालय

टास्क पैरेलल लाइब्रेरी (TPL) .NET 4.0 में दिखाई दिया। अब यह अतुल्यकालिक के साथ काम करने के लिए मानक और मुख्य उपकरण है। पुराने दृष्टिकोण का उपयोग करने वाले किसी भी कोड को विरासत माना जाता है। TPL की मूल इकाई System.Threading.Tasks नाम स्थान से कार्य वर्ग है। टास्क एक थ्रेड पर एक अमूर्तता है। C # के नए संस्करण के साथ, हमें टास्क के साथ काम करने का एक सुंदर तरीका मिल गया - async / प्रतीक्षा ऑपरेटर। इन अवधारणाओं ने अतुल्यकालिक कोड लिखना संभव बना दिया जैसे कि यह सरल और तुल्यकालिक था, इससे उन लोगों के लिए भी संभव हो गया है, जो थ्रेड्स की आंतरिक रसोई के बारे में बहुत कम समझ रखते हैं, ऐसे अनुप्रयोगों को लिखने के लिए जो उनका उपयोग करते हैं, ऐसे अनुप्रयोग जो लंबे ऑपरेशन के दौरान फ्रीज नहीं करते हैं। एसिंक्स / वेट का उपयोग करना एक या कई लेखों के लिए एक विषय है, लेकिन मैं कुछ वाक्यों का उल्लेख प्राप्त करने की कोशिश करूंगा:

• async टास्क या शून्य को वापस करने की विधि का एक संशोधक है
• और प्रतीक्षारत टास्क नॉन-ब्लॉकिंग प्रतीक्षा विवरण है।

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

टास्क को लॉन्च करने और उपयोग करने के विकल्पों पर विचार करें। नीचे दिए गए कोड उदाहरण का उपयोग करके, हम एक नया कार्य बनाते हैं जो कुछ भी उपयोगी नहीं होता है ( थ्रेड। सोलेप (10000) ), लेकिन वास्तविक जीवन में यह किसी प्रकार का जटिल CPU-युक्त कार्य होना चाहिए।

 using TCO = System.Threading.Tasks.TaskCreationOptions; public static async void VoidAsyncMethod() { var cancellationSource = new CancellationTokenSource(); await Task.Factory.StartNew( // Code of action will be executed on other context () => Thread.Sleep(10000), cancellationSource.Token, TCO.LongRunning | TCO.AttachedToParent | TCO.PreferFairness, scheduler ); // Code after await will be executed on captured context } 

कार्य कई विकल्पों के साथ बनाया गया है:

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

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

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

प्रतीक्षित ऑपरेटर को बनाई गई टास्क पर लागू किया जाता है, जिसका अर्थ है कि उसके बाद लिखे गए कोड, यदि कोई हो, को उसी संदर्भ में निष्पादित किया जाएगा (अक्सर इसका मतलब यह है कि यह उसी थ्रेड पर है) प्रतीक्षा से पहले कोड के रूप में।

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

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

आइए थोड़ा और ध्यान दें कि कैसे आप टास्क पूरा होने तक इंतजार कर सकते हैं। नीचे एक नमूना कोड है, टिप्पणियों के साथ, जब प्रतीक्षा सशर्त रूप से अच्छी की जाती है और जब सशर्त रूप से खराब होती है।

 public static async void AnotherMethod() { int result = await AsyncMethod(); // good result = AsyncMethod().Result; // bad AsyncMethod().Wait(); // bad IEnumerable<Task> tasks = new Task[] { AsyncMethod(), OtherAsyncMethod() }; await Task.WhenAll(tasks); // good await Task.WhenAny(tasks); // good Task.WaitAll(tasks.ToArray()); // bad } 

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

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

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

तीसरे और अंतिम उदाहरण को भी उसी कारण से खराब चिह्नित किया गया है और सभी समान समस्याएं हैं।

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

प्रवाह बंद करो

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

इंटरप्ट विधि अधिक अनुमानित रूप से काम करती है। यह केवल थ्रेड निष्क्रिय स्थिति में थ्रेडइंटरनेटेड अपवाद के अपवाद के साथ किसी थ्रेड को बाधित कर सकता है। इस स्थिति में, यह वेटहैंडल, लॉक की प्रतीक्षा करते समय, या थ्रेड को सो जाने के बाद निलंबन में चला जाता है।

ऊपर वर्णित दोनों विकल्प उनकी अप्रत्याशितता के लिए खराब हैं। समाधान रद्दीकरण टोकेन संरचना और रद्दीकरण टोकेनसोर्स स्रोत का उपयोग करना है । लब्बोलुआब यह है: रद्दीकरण श्रेणी का एक उदाहरण कैंसिलेशन टोकेनसोर्स बनाया गया है और केवल वह व्यक्ति जो इसका मालिक है वह रद्द पद्धति को कॉल करके ऑपरेशन को रोक सकता है। केवल कैंसिलेशनटोकन को ऑपरेशन के लिए ही पास किया जाता है। रद्दीकरण के मालिकों को ऑपरेशन को रद्द नहीं किया जा सकता है, लेकिन केवल यह जांच कर सकता है कि ऑपरेशन रद्द कर दिया गया है या नहीं। ऐसा करने के लिए, एक बूलियन संपत्ति IsCancellationRequested और ThrowIfCancelRequested विधि है। यदि रद्द विधि को रद्द कर दिया गया है रद्द करने के लिए रद्द कर दिया जाता है, तो बाद वाला टास्ककैन्डल एक्सेप्शन बढ़ाएगा । और यह इस पद्धति का उपयोग करने की सलाह देता है। यह पिछले विकल्पों से बेहतर है कि अपवाद संचालन में किन बिंदुओं पर पूर्ण नियंत्रण प्राप्त किया जा सकता है।

थ्रेड को रोकने के लिए सबसे क्रूर विकल्प Win32 API टर्मिनेटह्रेड फ़ंक्शन को कॉल करना है। इस फ़ंक्शन को कॉल करने के बाद सीएलआर का व्यवहार अप्रत्याशित हो सकता है। MSDN पर, इस फ़ंक्शन के बारे में निम्नलिखित लिखा गया है: "टर्मिनेटह्रेड एक खतरनाक फ़ंक्शन है जिसका उपयोग केवल सबसे चरम मामलों में किया जाना चाहिए। "

FromAsync विधि का उपयोग करके विरासत-एपीआई को टास्क में परिवर्तित करें

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

 object state = null; WebRequest wr = WebRequest.CreateHttp("http://github.com"); await Task.Factory.FromAsync( wr.BeginGetResponse, we.EndGetResponse ); 

यह केवल एक उदाहरण है और आप बिल्ट-इन प्रकारों के साथ ऐसा करने की संभावना नहीं रखते हैं, लेकिन किसी भी पुराने प्रोजेक्ट को शुरुआती तरीके से शुरू करना है जो IAsyncResult और EndDoSomething तरीकों को वापस करता है जो इसे स्वीकार करते हैं।

टास्क कॉमप्लेक्शन सोर्स क्लास का उपयोग करके टास्क के आधार पर लीगेसी-एपीआई को कन्वर्ट करें

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

आप कहेंगे कि मैंने पहले से ही इन उद्देश्यों के लिए इच्छित टास्कफैक्टरी वर्ग के FromAsync विधि के बारे में बात की थी। यहां हमें .net में अतुल्यकालिक मॉडल के विकास के पूरे इतिहास को याद करना होगा जो Microsoft पिछले 15 वर्षों से पेश कर रहा है: टास्क-आधारित अतुल्यकालिक पैटर्न (TAP) से पहले असिंक्रोनस प्रोग्रामिंग पैटर्न (एपीपी) था, जो शुरुआती DoSomething तरीकों के बारे में था जो IAsyncResult और End DoSomething तरीकों को स्वीकार करते हैं। और FromAsync विधि इन वर्षों की विरासत के लिए ठीक है, लेकिन समय के साथ, इसे इवेंट आधारित अतुल्यकालिक पैटर्न ( EAP ) द्वारा बदल दिया गया, जिसने यह मान लिया कि एक घटना को अतुल्यकालिक ऑपरेशन पूरा होने पर बुलाया जाएगा।

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

 public static Task<Result> DoAsync(this SomeApiInstance someApiObj) { var completionSource = new TaskCompletionSource<Result>(); someApiObj.Done += result => completionSource.SetResult(result); someApiObj.Do(); result completionSource.Task; } 

TaskCompletionSource टिप्स और ट्रिक्स

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

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

 while(!eventOccures && !timeoutExceeded) { CheckTimout(); CheckEvent(); Thread.Sleep(1); } 

लेकिन इस तरह के एक समाधान के रूप में ही घटना के इंतजार कर रहे ग्राहकों की संख्या बढ़ जाती है, क्योंकि बहुत ही दिखाई देगा इस तरह के प्रत्येक ग्राहक, घटना की प्रत्याशा में, एक संपूर्ण स्ट्रीम लेता है। हां, और हमें घटना के ट्रिगर पर 1ms की अतिरिक्त देरी मिलती है, सबसे अधिक बार यह महत्वपूर्ण नहीं है, लेकिन सॉफ़्टवेयर को इससे भी बदतर क्यों बनाया जा सकता है? यदि आप Thread.Sleep (1) को हटा देते हैं, तो व्यर्थ में हम एक प्रोसेसर कोर को 100% बेकार में लोड करेंगे, एक बेकार चक्र में कताई करेंगे। TaskCompletionSource का उपयोग करके, आप आसानी से इस कोड को फिर से कर सकते हैं और ऊपर बताई गई सभी समस्याओं को हल कर सकते हैं:

 class LongPollingApi { private Dictionary<int, TaskCompletionSource<Msg>> tasks; public async Task<Msg> AcceptMessageAsync(int userId, int duration) { var cs = new TaskCompletionSource<Msg>(); tasks[userId] = cs; await Task.WhenAny(Task.Delay(duration), cs.Task); return cs.Task.IsCompleted ? cs.Task.Result : null; } public void SendMessage(int userId, Msg m) { if (tasks.TryGetValue(userId, out var completionSource)) completionSource.SetResult(m); } } 

यह कोड उत्पादन-तैयार नहीं है, लेकिन सिर्फ एक डेमो है। वास्तविक मामलों में इसका उपयोग करने के लिए, आपको कम से कम उस स्थिति को संभालने की आवश्यकता होती है जब कोई संदेश उस समय आता है जब कोई इसकी उम्मीद नहीं कर रहा होता है: इस मामले में, AsseptMessageAsync विधि को पहले से ही पूर्ण टास्क को वापस करना चाहिए। यदि यह मामला सबसे अधिक बार होता है, तो आप ValueTask का उपयोग करने के बारे में सोच सकते हैं।

संदेश के लिए अनुरोध प्राप्त होने पर, हम शब्दकोश में टास्क कॉमप्लेक्शन स्रोत बनाते हैं, और फिर हम प्रतीक्षा करते हैं कि पहले क्या होता है: निर्दिष्ट समय अंतराल समाप्त हो जाता है या एक संदेश प्राप्त होता है।

ValueTask: क्यों और कैसे

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

 public async Task<string> GetById(int id) { if (cache.TryGetValue(id, out string val)) return val; return await RequestById(id); } 

इस कोड को संकलित करके रोजलिन जो कुछ उत्पन्न करेगा, उसके बारे में थोड़ा सा अनुकूलन करने की इच्छा के कारण, हम इस उदाहरण को फिर से लिख सकते हैं:

 public Task<string> GetById(int id) { if (cache.TryGetValue(id, out string val)) return Task.FromResult(val); return RequestById(id); } 

वास्तव में, इस मामले में इष्टतम समाधान गर्म-पथ का अनुकूलन करना है, अर्थात्, बिना किसी अतिरिक्त आवंटन के शब्दकोश से मूल्य प्राप्त करना और जीसी पर लोड करना, जबकि उन दुर्लभ मामलों में जब हमें अभी भी आईओ में जाने की आवश्यकता है, तो सब कुछ प्लस रहेगा / माइनस पुराना:

 public ValueTask<string> GetById(int id) { if (cache.TryGetValue(id, out string val)) return new ValueTask<string>(val); return new ValueTask<string>(RequestById(id)); } 

आइए इस कोड के टुकड़े पर करीब से नज़र डालें: यदि कैश में कोई मूल्य है, तो हम एक संरचना बनाते हैं, अन्यथा वास्तविक कार्य एक महत्वपूर्ण में लपेटा जाएगा। कॉलिंग कोड इस बात पर ध्यान नहीं देता है कि इस कोड को किस तरह से निष्पादित किया गया है: C # सिंटैक्स के दृष्टिकोण से ValueTask इस मामले में सामान्य कार्य की तरह ही व्यवहार करेगा।

TaskSchedulers: कार्य लॉन्च रणनीतियाँ

अगला एपीआई जिस पर मैं विचार करना चाहूंगा, वह है टास्कसिड्यूलर क्लास और उसका डेरिवेटिव। मैंने पहले ही ऊपर उल्लेख किया है कि टीपीएल में थ्रेड द्वारा टास्कव को वितरित करने के लिए रणनीतियों को नियंत्रित करने की क्षमता है। ऐसी रणनीतियों को टास्कस्क्राइडर क्लास के वंशजों में परिभाषित किया गया है। लगभग किसी भी रणनीति की आवश्यकता हो सकती है जो कि ParallelExtensionsExtras लाइब्रेरी में मिलेगी , जिसे Microsoft द्वारा विकसित किया गया है, लेकिन .NET का हिस्सा नहीं है, लेकिन एक Nuget पैकेज के रूप में दिया गया है। आइए संक्षेप में उनमें से कुछ पर विचार करें:

• CurrentThreadTaskScheduler - वर्तमान थ्रेड पर कार्य करता है
• LimitedConcurrencyLevelTaskScheduler - एन पैरामीटर में एक साथ निष्पादित कार्यों की संख्या को सीमित करता है, जिसे कंस्ट्रक्टर में स्वीकार किया जाता है
• OrderedTaskScheduler — LimitedConcurrencyLevelTaskScheduler(1), .
• WorkStealingTaskScheduler — work-stealing . ThreadPool. , .NET ThreadPool , , . . .. WorkStealingTaskScheduler' , ThreadPool .
• QueuedTaskScheduler - आप प्राथमिकताओं के साथ कतार नियमों के अनुसार कार्य करने की अनुमति देता है
• ThreadPerTaskScheduler - उस पर चलने वाले प्रत्येक टास्क के लिए एक अलग थ्रेड बनाता है। यह उन कार्यों के लिए उपयोगी हो सकता है जो अप्रत्याशित रूप से लंबे समय तक चलते हैं।

Microsoft ब्लॉग पर TaskSchedulers पर एक अच्छा विस्तृत लेख है ।

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

PLinq और समानांतर वर्ग

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

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

निष्कर्ष

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

निष्कर्ष:

• आधुनिक पीसी के संसाधनों का उपयोग करने के लिए आपको थ्रेड्स, अतुल्यकालिकता और समानता के साथ काम करने के लिए उपकरणों को जानना होगा।
• .NET के पास इस उद्देश्य के लिए कई अलग-अलग उपकरण हैं।
• उनमें से सभी एक ही बार में दिखाई नहीं दिए, क्योंकि विरासत अक्सर मिल सकती है, हालांकि बहुत प्रयास के बिना पुराने एपीआई को परिवर्तित करने के तरीके हैं।
• .NET में थ्रेड के साथ कार्य थ्रेड और थ्रेडपूल कक्षाओं द्वारा दर्शाया गया है
• Thread.Abort, Thread.Interrupt, Win32 API TerminateThread . CancellationToken'
• — , . , . TaskCompletionSource
• .NET Task'.
• c# async/await
• Task' TaskScheduler'
• ValueTask hot-paths memory-traffic
• Tasks Threads Visual Studio
• PLinq , , partitioning
• ...