.NET: मल्टिथ्रेडिङ र एसिन्क्रोनीसँग काम गर्ने उपकरणहरू। भाग 1

म मूल लेख Habr मा प्रकाशित गर्दैछु, जसको अनुवाद कर्पोरेट मा पोस्ट गरिएको छ ब्लग पोष्ट.

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

टर्मिनलजी

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

रूपक

सबै परिभाषाहरू राम्रा छैनन् र केहीलाई थप व्याख्या चाहिन्छ, त्यसैले म औपचारिक रूपमा परिचय गरिएको शब्दावलीमा नाश्ता पकाउने बारे एउटा रूपक थप्नेछु। यस रूपकमा नाश्ता पकाउनु एक प्रक्रिया हो।

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

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

रूपकलाई निरन्तरता दिँदै:

• यदि ओमलेट तयार गर्ने क्रममा, म पनि लुगा परिवर्तन गर्ने प्रयास गर्छु, यो बहुकार्यको उदाहरण हुनेछ। एउटा महत्त्वपूर्ण सूक्ष्मता: कम्प्युटरहरू मानिसहरू भन्दा यसमा धेरै राम्रो छन्।
• धेरै शेफहरू भएको भान्सा, उदाहरणका लागि रेस्टुरेन्टमा - एक बहु-कोर कम्प्युटर।
• एक शपिंग सेन्टर मा एक खाना अदालत मा धेरै रेस्टुरेन्ट - डाटा केन्द्र

.NET उपकरणहरू

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

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

थ्रेड सुरु गर्दै

थ्रेड क्लास .NET मा थ्रेडहरूसँग काम गर्ने सबैभन्दा आधारभूत कक्षा हो। कन्स्ट्रक्टरले दुई प्रतिनिधि मध्ये एक स्वीकार गर्दछ:

• ThreadStart - कुनै प्यारामिटरहरू छैनन्
• ParametrizedThreadStart - प्रकारको वस्तुको एक प्यारामिटरसँग।

प्रतिनिधिलाई स्टार्ट विधिलाई कल गरेपछि नयाँ सिर्जना गरिएको थ्रेडमा कार्यान्वयन गरिनेछ। यदि ParametrizedThreadStart प्रकारको प्रतिनिधि कन्स्ट्रक्टरलाई पास गरिएको थियो भने, कुनै वस्तुलाई स्टार्ट विधिमा पास गर्नुपर्छ। यो संयन्त्र कुनै पनि स्थानीय जानकारी स्ट्रिममा स्थानान्तरण गर्न आवश्यक छ। यो ध्यान दिन लायक छ कि थ्रेड सिर्जना गर्नु एक महँगो अपरेशन हो, र थ्रेड आफैंमा भारी वस्तु हो, कम्तिमा किनभने यसले स्ट्याकमा 1MB मेमोरी आवंटित गर्दछ र OS API सँग अन्तरक्रिया चाहिन्छ।

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

ThreadPool वर्गले पूलको अवधारणालाई प्रतिनिधित्व गर्दछ। .NET मा, थ्रेड पूल ईन्जिनियरिङ्को एक टुक्रा हो, र Microsoft मा विकासकर्ताहरूले यो सुनिश्चित गर्न धेरै प्रयास गरेका छन् कि यसले विभिन्न परिदृश्यहरूमा राम्रोसँग काम गर्छ।

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

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

पूलबाट थ्रेड प्रयोग गर्नको लागि, त्यहाँ एक QueueUserWorkItem विधि हो जसले WaitCallback प्रकारको प्रतिनिधिलाई स्वीकार गर्दछ, जसमा ParametrizedThreadStart जस्तै हस्ताक्षर हुन्छ, र यसलाई पास गरिएको प्यारामिटरले समान कार्य गर्दछ।

ThreadPool.QueueUserWorkItem(...);

कम ज्ञात थ्रेड पूल विधि RegisterWaitForSingleObject गैर-ब्लकिङ IO सञ्चालनहरू व्यवस्थित गर्न प्रयोग गरिन्छ। यस विधिमा पास गरिएको प्रतिनिधिलाई भनिन्छ जब विधिमा पास गरिएको WaitHandle "रिलिज" हुन्छ।

ThreadPool.RegisterWaitForSingleObject(...)

.NET सँग थ्रेड टाइमर छ र यो WinForms/WPF टाइमरहरू भन्दा फरक छ कि यसको ह्यान्डलरलाई पूलबाट लिइएको थ्रेडमा बोलाइनेछ।

System.Threading.Timer

त्यहाँ पूलबाट थ्रेडमा कार्यान्वयनको लागि प्रतिनिधि पठाउने बरु विदेशी तरिका पनि छ - BeginInvoke विधि।

DelegateInstance.BeginInvoke

म माथिका धेरै विधिहरू - Kernel32.dll Win32 API बाट CreateThread कल गर्न सकिने प्रकार्यमा संक्षिप्त रूपमा ध्यान दिन चाहन्छु। त्यहाँ एक तरिका छ, बाह्य विधिहरूको संयन्त्रको लागि धन्यवाद, यस प्रकार्यलाई कल गर्न। मैले लिगेसी कोडको भयानक उदाहरणमा एक पटक मात्र यस्तो कल देखेको छु, र वास्तवमा यो गर्ने लेखकको प्रेरणा अझै पनि मेरो लागि रहस्य बनेको छ।

Kernel32.dll CreateThread

थ्रेडहरू हेर्ने र डिबग गर्ने

तपाईंले सिर्जना गर्नुभएको थ्रेडहरू, सबै तेस्रो-पक्ष कम्पोनेन्टहरू, र .NET पूल भिजुअल स्टुडियोको थ्रेड्स विन्डोमा हेर्न सकिन्छ। यो सञ्झ्यालले थ्रेड जानकारी मात्र प्रदर्शन गर्नेछ जब अनुप्रयोग डिबग अन्तर्गत छ र ब्रेक मोडमा छ। यहाँ तपाईँले प्रत्येक थ्रेडको स्ट्याक नाम र प्राथमिकताहरू सजिलैसँग हेर्न सक्नुहुन्छ, र डिबगिङलाई निर्दिष्ट थ्रेडमा स्विच गर्न सक्नुहुन्छ। थ्रेड वर्गको प्राथमिकता गुण प्रयोग गरेर, तपाइँ थ्रेडको प्राथमिकता सेट गर्न सक्नुहुन्छ, जुन OC र CLR ले थ्रेडहरू बीचको प्रोसेसर समय विभाजन गर्दा सिफारिसको रूपमा बुझ्नेछ।

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

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

• async कार्य वा शून्य फिर्ता गर्ने विधिको परिमार्जक हो
• र प्रतीक्षा एक गैर-ब्लक टास्क पर्खाइ अपरेटर हो।

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

कार्य सुरु गर्न र प्रयोग गर्नका लागि विकल्पहरू हेरौं। तलको कोड उदाहरणमा, हामी एउटा नयाँ कार्य सिर्जना गर्छौं जसले केही पनि उपयोगी छैन (Thread.Sleep(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 कार्य चाँडै पूरा हुने छैन भन्ने संकेत हो, जसको मतलब यो पोखरीबाट थ्रेड नलिने, तर अरूलाई हानी नहोस् भनेर यस कार्यको लागि छुट्टै एउटा सिर्जना गर्ने विचार गर्न लायक हुन सक्छ।
• AttachedToParent - कार्यहरू पदानुक्रममा व्यवस्थित गर्न सकिन्छ। यदि यो विकल्प प्रयोग गरिएको थियो भने, कार्य यस्तो अवस्थामा हुन सक्छ जहाँ यो आफैले पूरा गरेको छ र आफ्ना बच्चाहरूको कार्यान्वयनको लागि पर्खिरहेको छ।
• PreferFairness - यसको अर्थ कार्यान्वयनको लागि पठाइएका कार्यहरू पछि पठाइएका भन्दा पहिले कार्यान्वयन गर्नु राम्रो हुन्छ। तर यो केवल एक सिफारिस हो र परिणाम ग्यारेन्टी छैन।

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

अन्तिम प्यारामिटर TaskScheduler प्रकारको अनुसूचक वस्तु हो। यो वर्ग र यसका सन्तानहरू थ्रेडहरूमा कार्यहरू वितरण गर्ने रणनीतिहरू व्यवस्थापन गर्न डिजाइन गरिएका छन्; पूर्वनिर्धारित रूपमा, कार्य पूलबाट अनियमित थ्रेडमा कार्यान्वयन गरिनेछ।

पर्खाइ अपरेटर सिर्जना गरिएको कार्यमा लागू हुन्छ, जसको अर्थ यसको पछि लेखिएको कोड, यदि त्यहाँ एक छ भने, पर्खनु अघि कोड जस्तै समान सन्दर्भमा कार्यान्वयन गरिनेछ (अक्सर यसको अर्थ उही थ्रेडमा)।

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

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

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

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/await प्रयोग गर्दा ह्यान्डल गर्न धेरै सजिलो हुन्छ - तिनीहरूले कोड सिंक्रोनस भए जस्तै व्यवहार गर्छन्। यदि हामीले कार्यमा सिंक्रोनस वेट एक्सोर्सिज्म लागू गर्छौं भने, मूल अपवाद AggregateException मा परिणत हुन्छ, अर्थात्। अपवाद ह्यान्डल गर्नको लागि, तपाईंले InnerException प्रकारको जाँच गर्नुपर्नेछ र C# संसारमा परिचित क्याच ब्लकहरूको श्रृंखलाको सट्टा, एउटा क्याच ब्लक भित्र आफैलाई यदि चेन लेख्नुहोस् वा निर्माण गर्दा क्याच प्रयोग गर्नुहोस्।

तेस्रो र अन्तिम उदाहरणहरू पनि उही कारणका लागि खराब चिन्ह लगाइएका छन् र सबै समान समस्याहरू समावेश छन्।

जब कुनै र जब सबै विधिहरू कार्यहरूको समूहको लागि पर्खनका लागि अत्यन्त सुविधाजनक छन्; तिनीहरूले कार्यहरूको समूहलाई एउटामा बेर्छन्, जुन समूहबाट कार्य पहिलो पटक ट्रिगर हुँदा वा ती सबैले आफ्नो कार्यान्वयन पूरा गरेपछि सक्रिय हुनेछ।

थ्रेडहरू रोक्दै

विभिन्न कारणहरूले गर्दा, यो सुरु भएपछि प्रवाह रोक्न आवश्यक हुन सक्छ। यो गर्नका लागि धेरै तरिकाहरू छन्। थ्रेड क्लासमा दुई उपयुक्त नाम दिइएको विधिहरू छन्: परित्याग गर्नुहोस् и अवरोध। पहिलो प्रयोगको लागि अत्यधिक सिफारिस गरिएको छैन, किनभने कुनै पनि अनियमित क्षणमा यसलाई कल गरेपछि, कुनै पनि निर्देशनको प्रशोधनको क्रममा, एक अपवाद फ्याँकिनेछ। ThreadAbortedException। तपाईंले कुनै पनि पूर्णांक चर वृद्धि गर्दा यस्तो अपवाद फ्याँकिएको आशा गर्नुहुन्न, हैन? र यो विधि प्रयोग गर्दा, यो एक धेरै वास्तविक स्थिति हो। यदि तपाइँले CLR लाई कोडको निश्चित खण्डमा यस्तो अपवाद उत्पन्न गर्नबाट रोक्न आवश्यक छ भने, तपाइँ यसलाई कलहरूमा लपेट्न सक्नुहुन्छ। Thread.BeginCriticalRegion, Thread.EndCriticalRegion। अन्तमा ब्लकमा लेखिएको कुनै पनि कोड त्यस्ता कलहरूमा बेरिएको हुन्छ। यस कारणका लागि, फ्रेमवर्क कोडको गहिराइमा तपाईंले खाली प्रयासको साथ ब्लकहरू फेला पार्न सक्नुहुन्छ, तर अन्तमा खाली छैन। माइक्रोसफ्टले यस विधिलाई यति हतोत्साहित गर्दछ कि उनीहरूले यसलाई .net कोरमा समावेश गरेनन्।

अवरोध विधिले अधिक अनुमानित रूपमा काम गर्दछ। यसले अपवादको साथ थ्रेडलाई अवरोध गर्न सक्छ ThreadInterruptedException केवल ती क्षणहरूमा जब थ्रेड पर्खिरहेको अवस्थामा हुन्छ। WaitHandle, लक, वा Thread.Sleep कल गरेपछि ह्याङ्गिङ गर्दा यो स्थितिमा प्रवेश गर्छ।

माथि वर्णन गरिएका दुवै विकल्पहरू तिनीहरूको अप्रत्याशितताको कारण खराब छन्। समाधान भनेको संरचना प्रयोग गर्नु हो रद्द गर्ने टोकन र कक्षा रद्दीकरण टोकन स्रोत। बिन्दु यो हो: रद्दीकरण टोकन स्रोत वर्गको एउटा उदाहरण सिर्जना गरिएको छ र यसको स्वामित्व लिनेले मात्र विधिलाई कल गरेर सञ्चालन रोक्न सक्छ। रद्द। रद्दीकरण टोकन मात्र सञ्चालनमा पास गरिएको छ। CancellationToken मालिकहरूले आफैंले सञ्चालन रद्द गर्न सक्दैनन्, तर अपरेशन रद्द गरिएको छ कि छैन भनेर मात्र जाँच गर्न सक्छन्। यसका लागि बुलियन सम्पत्ति छ रद्द गर्न अनुरोध गरियो र विधि ThrowIfCancel अनुरोध गरियो। पछिल्लोले अपवाद फ्याँक्नेछ TaskCancelledException यदि रद्द विधिलाई रद्दीकरण टोकन उदाहरणमा बोलाइयो भने। र यो मैले प्रयोग गर्न सिफारिस गर्ने विधि हो। यो कुन बिन्दुमा अपवाद अपरेशन रद्द गर्न सकिन्छ भन्नेमा पूर्ण नियन्त्रण प्राप्त गरेर अघिल्लो विकल्पहरूमा भएको सुधार हो।

थ्रेड रोक्नको लागि सबैभन्दा क्रूर विकल्प Win32 API TerminateThread प्रकार्यलाई कल गर्नु हो। यस प्रकार्यलाई कल गरेपछि CLR को व्यवहार अप्रत्याशित हुन सक्छ। MSDN मा यस प्रकार्यको बारेमा निम्न लेखिएको छ: "TerminateThread एक खतरनाक प्रकार्य हो जुन केवल सबैभन्दा चरम अवस्थामा प्रयोग गरिनु पर्छ। "

FromAsync विधि प्रयोग गरेर लिगेसी API लाई टास्कमा रूपान्तरण गर्दै

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

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

यो केवल एउटा उदाहरण हो र तपाईंले यो बिल्ट-इन प्रकारहरूसँग गर्नु पर्ने सम्भावना छैन, तर कुनै पनि पुरानो परियोजनाले यसलाई प्राप्त गर्ने IAsyncResult र EndDoSomething विधिहरू फर्काउने BeginDoSomething विधिहरूसँग मात्र मिल्छ।

TaskCompletionSource क्लास प्रयोग गरेर Legacy API लाई Task Based मा रूपान्तरण गर्नुहोस्

विचार गर्न अर्को महत्त्वपूर्ण उपकरण कक्षा हो TaskCompletion स्रोत। कार्यहरू, उद्देश्य र सञ्चालनको सिद्धान्तको सन्दर्भमा, यो केहि हदसम्म थ्रेडपुल कक्षाको RegisterWaitForSingleObject विधिको सम्झना दिलाउने हुन सक्छ, जुन मैले माथि लेखेको छु। यो वर्ग प्रयोग गरेर, तपाइँ टास्कहरूमा पुरानो एसिन्क्रोनस API हरू सजिलै र सहज रूपमा लपेट्न सक्नुहुन्छ।

तपाईंले भन्नुहुनेछ कि मैले पहिले नै यी उद्देश्यहरूको लागि लक्षित TaskFactory कक्षाको FromAsync विधिको बारेमा कुरा गरिसकेको छु। यहाँ हामीले .net मा एसिन्क्रोनस मोडेलहरूको विकासको सम्पूर्ण इतिहास सम्झनुपर्छ जुन माइक्रोसफ्टले विगत 15 वर्षहरूमा प्रस्ताव गरेको छ: टास्क-आधारित एसिन्क्रोनस ढाँचा (TAP) अघि, त्यहाँ एसिन्क्रोनस प्रोग्रामिङ ढाँचा (APP), जुन थियो। विधिहरूको बारेमा थियो सुरू गर्नुहोस्केहि फिर्ता गर्दै IAsyncResult र विधिहरू अन्तDoSomething जसले यसलाई स्वीकार गर्दछ र यी वर्षहरूको विरासतको लागि FromAsync विधि एकदम सही छ, तर समयको साथ, यो घटना आधारित एसिन्क्रोनस ढाँचा (र एपी), जसले एसिन्क्रोनस अपरेसन पूरा भएपछि एउटा घटना उठ्नेछ भनेर मानेको छ।

TaskCompletionSource घटना मोडेल वरिपरि निर्मित Tasks र लिगेसी API हरू र्‍याप गर्नको लागि उपयुक्त छ। यसको कामको सार निम्नानुसार छ: यस वर्गको वस्तुसँग टास्क प्रकारको सार्वजनिक सम्पत्ति छ, जसको अवस्था SetResult, SetException, आदि TaskCompletionSource वर्गको विधिहरू मार्फत नियन्त्रण गर्न सकिन्छ। यस कार्यमा प्रतिक्षा अपरेटर लागू गरिएको ठाउँहरूमा, TaskCompletionSource मा लागू गरिएको विधिको आधारमा अपवादको साथ यो कार्यान्वयन वा असफल हुनेछ। यदि यो अझै स्पष्ट छैन भने, यो कोड उदाहरण हेरौं, जहाँ केहि पुरानो EAP API टास्कमा एक TaskCompletionSource प्रयोग गरी बेरिएको छ: जब घटना फायर हुन्छ, कार्य पूर्ण स्थितिमा स्थानान्तरण हुनेछ, र प्रतीक्षा अपरेटर लागू गर्ने विधि। यस कार्यमा वस्तु प्राप्त भएपछि यसको कार्यान्वयन पुन: सुरु हुनेछ परिणाम.

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

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

    result completionSource.Task;
}

TaskCompletionस्रोत सुझाव र युक्तिहरू

TaskCompletionSource प्रयोग गरेर पुरानो API हरू र्‍यापिङ गर्न सकिँदैन। यस वर्गको प्रयोगले थ्रेडहरूले ओगटेका कार्यहरूमा विभिन्न API हरू डिजाइन गर्ने रोचक सम्भावना खोल्छ। र स्ट्रिम, जसरी हामी सम्झन्छौं, एक महँगो स्रोत हो र तिनीहरूको संख्या सीमित छ (मुख्यतया RAM को मात्रा द्वारा)। यो सीमा सजिलैसँग विकास गरेर हासिल गर्न सकिन्छ, उदाहरणका लागि, जटिल व्यापार तर्कको साथ लोड गरिएको वेब अनुप्रयोग। लङ-पोलिङ जस्ता ट्रिक लागू गर्दा मैले कुरा गरिरहेको सम्भावनाहरूलाई विचार गरौं।

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

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 प्रयोग गर्ने बारे सोच्न सक्नुहुन्छ।

जब हामीले सन्देशको लागि अनुरोध प्राप्त गर्छौं, हामी शब्दकोशमा TaskCompletionSource सिर्जना गर्छौं र राख्छौं, र त्यसपछि पहिले के हुन्छ भनेर पर्खनुहोस्: निर्दिष्ट समय अन्तराल समाप्त हुन्छ वा सन्देश प्राप्त हुन्छ।

ValueTask: किन र कसरी

async/await अपरेटरहरू, जस्तै उपज रिटर्न अपरेटर, विधिबाट राज्य मेसिन उत्पन्न गर्दछ, र यो एउटा नयाँ वस्तुको सिर्जना हो, जुन लगभग सधैं महत्त्वपूर्ण हुँदैन, तर दुर्लभ अवस्थामा यसले समस्या सिर्जना गर्न सक्छ। यो केस एक विधि हुन सक्छ जुन वास्तवमा प्राय: भनिन्छ, हामी दसौं र सयौं हजारौं कलहरू प्रति सेकेन्डको बारेमा कुरा गर्दैछौं। यदि यस्तो विधि यसरी लेखिएको छ कि प्राय जसो अवस्थामा यसले सबै प्रतीक्षा विधिहरूलाई बाइपास गरेर परिणाम फर्काउँछ, तब .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);
}

वास्तवमा, यस अवस्थामा इष्टतम समाधान हट-पथ अप्टिमाइज गर्नु हो, अर्थात्, कुनै अनावश्यक आवंटन र GC मा लोड बिना शब्दकोशबाट मान प्राप्त गर्ने, जबकि ती दुर्लभ अवस्थामा जब हामीले डाटाको लागि 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# सिन्ट्याक्सको दृष्टिकोणबाट, यस अवस्थामा नियमित कार्य जस्तै व्यवहार गर्नेछ।

टास्क शेड्युलरहरू: कार्य प्रक्षेपण रणनीतिहरू प्रबन्ध गर्दै

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

• CurrentThreadTaskScheduler - हालको थ्रेडमा कार्यहरू कार्यान्वयन गर्दछ
• LimitedConcurrencyLevelTaskSeduler - परिमिति N द्वारा एकै साथ कार्यान्वयन गरिएका कार्यहरूको संख्यालाई सीमित गर्दछ, जुन कन्स्ट्रक्टरमा स्वीकार गरिन्छ।
• OrderedTaskScheduler — LimitedConcurrencyLevelTaskScheduler(1) को रूपमा परिभाषित गरिएको छ, त्यसैले कार्यहरू क्रमिक रूपमा कार्यान्वयन गरिनेछ।
• WorkStealingTaskScheduler - लागू गर्दछ काम चोरी कार्य वितरण को दृष्टिकोण। अनिवार्य रूपमा यो एक अलग थ्रेडपूल हो। .NET ThreadPool मा सबै अनुप्रयोगहरूको लागि एक स्थिर वर्ग हो, जसको मतलब यो हो कि कार्यक्रमको एक भागमा यसको ओभरलोडिङ वा गलत प्रयोगले अर्कोमा साइड इफेक्टहरू निम्त्याउन सक्छ भन्ने समस्याको समाधान गर्छ। यसबाहेक, यस्तो दोष को कारण बुझ्न धेरै गाह्रो छ। त्यो। ThreadPool को प्रयोग आक्रामक र अप्रत्याशित हुन सक्ने कार्यक्रमका भागहरूमा छुट्टै WorkStealingTaskSchedulers प्रयोग गर्न आवश्यक हुन सक्छ।
• कतारबद्ध कार्य तालिका - तपाईंलाई प्राथमिकता लाम नियम अनुसार कार्यहरू गर्न अनुमति दिन्छ
• ThreadPerTaskScheduler - यसमा कार्यान्वयन गरिएको प्रत्येक कार्यको लागि छुट्टै थ्रेड सिर्जना गर्दछ। पूरा हुन अप्रत्याशित रूपमा लामो समय लाग्ने कार्यहरूको लागि उपयोगी हुन सक्छ।

त्यहाँ एक राम्रो विस्तृत छ लेख माइक्रोसफ्ट ब्लगमा TaskSchedulers को बारेमा।

कार्यहरूसँग सम्बन्धित सबै कुराको सुविधाजनक डिबगिङको लागि, भिजुअल स्टुडियोमा कार्य विन्डो छ। यस सञ्झ्यालमा तपाईले कार्यको हालको अवस्था देख्न सक्नुहुन्छ र हालको कोडको कार्यान्वयन लाइनमा जानुहोस्।

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

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

समानान्तर स्थिर वर्गले समानान्तरमा फोरच सङ्कलन मार्फत दोहोरिने, लूपको लागि कार्यान्वयन गर्ने, र समानान्तर आह्वानमा बहु प्रतिनिधिहरू कार्यान्वयन गर्ने विधिहरू प्रदान गर्दछ। गणना पूरा नभएसम्म हालको थ्रेडको कार्यान्वयन रोकिनेछ। थ्रेडहरूको संख्यालाई अन्तिम तर्कको रूपमा ParallelOptions पास गरेर कन्फिगर गर्न सकिन्छ। तपाईंले विकल्पहरू प्रयोग गरेर TaskScheduler र CancellationToken पनि निर्दिष्ट गर्न सक्नुहुन्छ।

निष्कर्ष

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

निष्कर्ष:

• आधुनिक पीसीहरूको स्रोतहरू प्रयोग गर्नको लागि तपाईंले थ्रेड, एसिन्क्रोनी र समानान्तरसँग काम गर्ने उपकरणहरू जान्न आवश्यक छ।
• .NET सँग यी उद्देश्यका लागि धेरै फरक उपकरणहरू छन्
• ती सबै एकैचोटि देखा पर्दैनन्, त्यसैले तपाईले प्रायः विरासतहरू फेला पार्न सक्नुहुन्छ, तथापि, त्यहाँ धेरै प्रयास बिना पुरानो API लाई रूपान्तरण गर्ने तरिकाहरू छन्।
• .NET मा थ्रेडहरूसँग काम गर्दा थ्रेड र थ्रेडपुल वर्गहरूद्वारा प्रतिनिधित्व गरिन्छ
• Thread.Abort, Thread.Interrupt, र Win32 API TerminateThread विधिहरू खतरनाक छन् र प्रयोगको लागि सिफारिस गरिँदैन। बरु, रद्दीकरण टोकन मेकानिजम प्रयोग गर्नु राम्रो हुन्छ
• प्रवाह एक बहुमूल्य स्रोत हो र यसको आपूर्ति सीमित छ। घटनाहरूको प्रतीक्षामा थ्रेडहरू व्यस्त हुने अवस्थाहरू बेवास्ता गर्नुपर्छ। यसका लागि TaskCompletionSource वर्ग प्रयोग गर्न सजिलो छ
• समानान्तर र एसिन्क्रोनीसँग काम गर्नका लागि सबैभन्दा शक्तिशाली र उन्नत .NET उपकरणहरू कार्यहरू हुन्।
• c# async/await अपरेटरहरूले गैर-ब्लकिङ पर्खाइको अवधारणा लागू गर्दछ
• तपाईंले TaskScheduler-व्युत्पन्न वर्गहरू प्रयोग गरेर थ्रेडहरूमा कार्यहरूको वितरण नियन्त्रण गर्न सक्नुहुन्छ।
• ValueTask संरचना हट-पाथ र मेमोरी-ट्राफिक अनुकूलन गर्न उपयोगी हुन सक्छ
• भिजुअल स्टुडियोका कार्यहरू र थ्रेडहरू विन्डोहरूले बहु-थ्रेडेड वा एसिन्क्रोनस कोड डिबग गर्नका लागि उपयोगी जानकारी प्रदान गर्दछ।
• PLinq एउटा राम्रो उपकरण हो, तर यसमा तपाईको डेटा स्रोतको बारेमा पर्याप्त जानकारी नहुन सक्छ, तर यसलाई विभाजन गर्ने संयन्त्र प्रयोग गरेर समाधान गर्न सकिन्छ।
• फेरि जारी राखौंला…

स्रोत: www.habr.com