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

मैं हैबर पर मूल लेख प्रकाशित कर रहा हूं, जिसका अनुवाद कॉर्पोरेट में पोस्ट किया गया है ब्लॉग.

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

शब्दावली

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

रूपक

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

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

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

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

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

.NET उपकरण

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

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

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

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

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

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

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

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

सामान्य सिद्धांत:

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

पूल से थ्रेड का उपयोग करने के लिए, एक QueueUserWorkItem विधि है जो वेटकॉलबैक प्रकार के एक प्रतिनिधि को स्वीकार करती है, जिसमें पैरामेट्रिज्डथ्रेडस्टार्ट के समान हस्ताक्षर होते हैं, और इसे पारित पैरामीटर समान कार्य करता है।

ThreadPool.QueueUserWorkItem(...);

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

ThreadPool.RegisterWaitForSingleObject(...)

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

System.Threading.Timer

पूल से थ्रेड में निष्पादन के लिए एक प्रतिनिधि को भेजने का एक अनोखा तरीका भी है - बेगिनइनवोक विधि।

DelegateInstance.BeginInvoke

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

Kernel32.dll CreateThread

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

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

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

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

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

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

आइए किसी कार्य को लॉन्च करने और उपयोग करने के विकल्पों पर नज़र डालें। नीचे दिए गए कोड उदाहरण में, हम एक नया कार्य बनाते हैं जो कुछ भी उपयोगी नहीं करता (धागा.नींद(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
}

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

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

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

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

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

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

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

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

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
}

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

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

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

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

कार्यों के समूह की प्रतीक्षा करने के लिएWhenAny औरWhenAll विधियां बेहद सुविधाजनक हैं; वे कार्यों के एक समूह को एक समूह में लपेटते हैं, जो या तो तब सक्रिय हो जाएगा जब समूह से कोई कार्य पहली बार ट्रिगर होगा, या जब उन सभी ने अपना निष्पादन पूरा कर लिया हो।

धागों को रोकना

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

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

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

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

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

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

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

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

TaskCompletionSource वर्ग का उपयोग करके लीगेसी API को कार्य आधारित में बदलें

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

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

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

public static Task<Result> DoAsync(this SomeApiInstance someApiObj) {

    var completionSource = new TaskCompletionSource<Result>();
    someApiObj.Done += 
        result => completionSource.SetResult(result);
    someApiObj.Do();

    result completionSource.Task;
}

कार्यपूर्तिस्रोत युक्तियाँ एवं युक्तियाँ

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

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

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

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

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

वैल्यूटास्क: क्यों और कैसे

एसिंक/वेट ऑपरेटर, यील्ड रिटर्न ऑपरेटर की तरह, विधि से एक राज्य मशीन उत्पन्न करते हैं, और यह एक नई वस्तु का निर्माण होता है, जो लगभग हमेशा महत्वपूर्ण नहीं होता है, लेकिन दुर्लभ मामलों में यह एक समस्या पैदा कर सकता है। यह मामला एक ऐसी विधि हो सकती है जिसे वास्तव में अक्सर कॉल किया जाता है, हम प्रति सेकंड दसियों और सैकड़ों हजारों कॉलों के बारे में बात कर रहे हैं। यदि ऐसी कोई विधि इस तरह से लिखी जाती है कि ज्यादातर मामलों में यह सभी प्रतीक्षा विधियों को छोड़कर परिणाम देता है, तो .NET इसे अनुकूलित करने के लिए एक टूल प्रदान करता है - वैल्यूटास्क संरचना। इसे स्पष्ट करने के लिए, आइए इसके उपयोग का एक उदाहरण देखें: एक कैश है जिस पर हम अक्सर जाते हैं। इसमें कुछ मान होते हैं और फिर हम उन्हें बस वापस कर देते हैं; यदि नहीं, तो हम उन्हें प्राप्त करने के लिए किसी धीमे 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);
}

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

public ValueTask<string> GetById(int id) {

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

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

कार्य अनुसूचक: कार्य लॉन्च रणनीतियों का प्रबंधन

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

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

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

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

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

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

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

निष्कर्ष

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

निष्कर्ष:

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

स्रोत: www.habr.com

.NET: मल्टीथ्रेडिंग और एसिंक्रोनी के साथ काम करने के लिए उपकरण। भाग ---- पहला