👃🏽 🤼 🔧 .NET: बहु सूत्रण और अतुल्यकालिक के साथ काम करने के लिए उपकरण

मैंने मूल रूप से इस लेख को कोडिंगसाइट ब्लॉग में पोस्ट किया है
लेख का दूसरा भाग यहाँ उपलब्ध है

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

अंतर्वस्तु

शब्दावली

प्रक्रिया - एक ओएस ऑब्जेक्ट जो थ्रेड्स वाले एक अलग पते वाले स्थान का प्रतिनिधित्व करता है।

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

मल्टीटास्किंग - एक ओएस सुविधा जो एक साथ कई प्रक्रियाओं को निष्पादित करने की क्षमता का प्रतिनिधित्व करती है।

मल्टी-कोर - एक सीपीयू सुविधा जो डेटा प्रोसेसिंग के लिए कई कोर का उपयोग करने की क्षमता का प्रतिनिधित्व करती है

मल्टीप्रोसेसिंग - एक कंप्यूटर की विशेषता जो कई सीपीयू के साथ शारीरिक रूप से काम करने की क्षमता का प्रतिनिधित्व करती है।

मल्टी-थ्रेडिंग - एक प्रक्रिया की विशेषता जो कई थ्रेड्स के बीच डेटा प्रोसेसिंग को विभाजित करने और फैलाने की क्षमता का प्रतिनिधित्व करती है।

समानता - समय की एक इकाई में कई क्रियाओं का एक साथ भौतिक निष्पादन

अतुल्यकालिक - बाद में समय के लिए परिणाम की गणना छोड़कर पूरी तरह से संसाधित होने की प्रतीक्षा किए बिना एक ऑपरेशन को निष्पादित करना।

एक रूपक

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

नाश्ता बनाना इस रूपक में एक प्रक्रिया का प्रतिनिधित्व करता है।

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

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

रूपक का विस्तार करने के लिए:

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

.NET उपकरण

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

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

एक धागा शुरू करना

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

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

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

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

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

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

QueueUserWorkItem विधि पूल से थ्रेड का उपयोग करने की अनुमति देती है। यह विधि WaitCallback -type प्रतिनिधि लेती है। इसका हस्ताक्षर ParametrizedThreadStart के हस्ताक्षर के साथ मेल खाता है, और जो पैरामीटर इसे पास करता है, वही भूमिका निभाता है।

 ThreadPool.QueueUserWorkItem(...);

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

 ThreadPool.RegisterWaitForSingleObject(...)

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

 System.Threading.Timer

पूल से एक थ्रेड को प्रतिनिधि भेजने का एक असामान्य रूप से असामान्य तरीका भी है - BeginInvoke विधि।

 DelegateInstance.BeginInvoke

मैं उस फ़ंक्शन पर एक नज़र डालना चाहूंगा, जिसके बारे में मैंने पहले उल्लेख किया था जिसमें से कई नीचे आते हैं - कर्नेल 32.dll Win32 API से CreateThread। तरीकों के बाहरी तंत्र की सहायता से इस फ़ंक्शन को कॉल करने का एक तरीका है। मैंने केवल एक बार विरासत कोड के एक विशेष रूप से खराब मामले में इसका इस्तेमाल किया है - और मैंने अभी भी यह नहीं समझा कि इसके लेखक के कारण क्या थे।

 Kernel32.dll CreateThread

थ्रेडिंग देखना और डिबग करना

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

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

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

async एक विधि का एक मापक है जो टास्क या शून्य लौटाता है
प्रतीक्षा गैर-अवरुद्ध प्रतीक्षा कार्य का एक ऑपरेटर है।

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

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

 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 शून्य के रूप में लेबल किए गए तरीकों को अक्सर देखा जा सकता है: वे आमतौर पर घटना हैंडलर या अन्य तरीके हैं जो आग के तहत काम करते हैं और सिद्धांत भूल जाते हैं। यदि निष्पादन समाप्त होने और परिणाम वापस करने के लिए इंतजार करना आवश्यक है, तो आपको टास्क का उपयोग करना चाहिए।

StartNew पद्धति को वापस करने वाले कार्यों के लिए, हम ConfigureAwait को झूठे पैरामीटर के साथ कॉल कर सकते हैं - फिर, प्रतीक्षा के बाद निष्पादन को कैप्चर किए गए के बजाय यादृच्छिक संदर्भ में जारी रखा जाएगा। यह हमेशा किया जाना चाहिए यदि प्रतीक्षा के बाद लिखे गए कोड को एक विशिष्ट निष्पादन संदर्भ की आवश्यकता नहीं है। यह भी एक पुस्तकालय के रूप में प्रदान की कोड लिखने के लिए आता है जब एमएस से एक सिफारिश है।

आइए देखें कि हम किसी कार्य के समाप्त होने की प्रतीक्षा कैसे कर सकते हैं। नीचे, आप उन टिप्पणियों के साथ कोड का उदाहरण देख सकते हैं, जो प्रतीक्षा करते हुए कि अपेक्षाकृत अच्छे या बुरे तरीके से कार्यान्वित की जाती हैं।

 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 }

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

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

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

दो अंतिम उदाहरणों को समान कारणों से अपेक्षाकृत खराब माना जाता है और दोनों में समान मुद्दे होते हैं।

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

थ्रेडिंग रोकना

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

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

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

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

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

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

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

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

TaskCompletionSource का उपयोग करके टास्क-आधारित एक में एक लिगेसी एपीआई को चालू करना

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

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

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

 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 टिप्स और ट्रिक्स

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

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

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

हालाँकि, इस समाधान की प्रभावशीलता मौलिक रूप से घटती हुई होनी चाहिए, जो कि घटना के बढ़ने की प्रतीक्षा कर रहे ग्राहकों की संख्या - प्रत्येक प्रतीक्षा करने वाले ग्राहक के पास एक पूर्ण सूत्र है। साथ ही, हमें इवेंट ट्रिगरिंग के लिए 1ms की अतिरिक्त देरी मिलती है। अक्सर, यह वास्तव में महत्वपूर्ण नहीं है, लेकिन हम अपने सॉफ़्टवेयर को इससे बदतर क्यों बना सकते हैं? दूसरी ओर, यदि हम थ्रेड को हटा दें। सोले (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); } }

कृपया ध्यान रखें कि कोड का यह टुकड़ा केवल एक उदाहरण है, और किसी भी तरह से उत्पादन के लिए तैयार नहीं है। वास्तविक मामलों में इसका उपयोग करने के लिए, हमें कम से कम उन स्थितियों को संभालने के लिए एक तरीका जोड़ना होगा जिसमें एक संदेश प्राप्त होता है जब इसके लिए कुछ भी इंतजार नहीं किया गया था: इस मामले में, AcceptMessageAsync विधि को पहले से ही समाप्त टास्क को वापस करना चाहिए। यदि यह मामला सबसे आम है, तो हम ValueTask का उपयोग करने पर विचार कर सकते हैं।

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

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

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

 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); }

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

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

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

TaskScheduler: कार्य निष्पादन रणनीतियों को नियंत्रित करना

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

CurrentThreadTaskScheduler - वर्तमान थ्रेड पर कार्य निष्पादित करता है
LimitedConcurrencyLevelTaskScheduler - कंस्ट्रक्टर में स्वीकार किए गए N पैरामीटर का उपयोग करके समवर्ती निष्पादित कार्य की संख्या को सीमित करता है
OrderedTaskScheduler - LimitedConcurrencyLevelTaskScheduler (1) के रूप में परिभाषित किया गया है, इसलिए कार्य क्रमिक रूप से निष्पादित किए जाएंगे।
WorkStealingTaskScheduler - कार्य निष्पादन के लिए कार्य -चोरी के दृष्टिकोण को लागू करता है। अनिवार्य रूप से, इसे एक अलग थ्रेडपूल के रूप में देखा जा सकता है। यह थ्रेडपूल के .NET में एक स्थिर वर्ग होने के मुद्दे के साथ मदद करता है - यदि यह आवेदन के एक हिस्से में अतिभारित या अनुचित तरीके से उपयोग किया जाता है, तो एक अलग स्थान पर अप्रिय दुष्प्रभाव हो सकते हैं। इस तरह के दोषों के वास्तविक कारणों का पता लगाना मुश्किल हो सकता है, इसलिए आपको आवेदन के उन हिस्सों में अलग-अलग वर्कस्टीलिंगटैस्कशॉटर्स का उपयोग करने की आवश्यकता हो सकती है जहां थ्रेडपूल का उपयोग आक्रामक और अप्रत्याशित हो सकता है।
QueuedTaskScheduler - प्राथमिकता वाले कतार के आधार पर कार्यों को निष्पादित करने की अनुमति देता है
ThreadPerTaskScheduler - उस पर निष्पादित प्रत्येक टास्क के लिए एक अलग थ्रेड बनाता है। यह उन कार्यों के लिए सहायक हो सकता है जिनके निष्पादन समय का अनुमान नहीं लगाया जा सकता है।

Microsoft के ब्लॉग पर TaskSchedulers के बारे में एक बहुत अच्छा लेख है , इसलिए इसे आज़ाद करें।

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

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

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

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

सारांश

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

निष्कर्ष:

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

जारी रखने के लिए ...

.NET: बहु सूत्रण और अतुल्यकालिक के साथ काम करने के लिए उपकरण - भाग 1