🥇.NET: मल्टीथ्रेडिंग आणि एसिंक्रोनीसह कार्य करण्यासाठी साधने. भाग १

मी मूळ लेख Habr वर प्रकाशित करत आहे, ज्याचा अनुवाद कॉर्पोरेटमध्ये पोस्ट केला आहे ब्लॉग पोस्ट.

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

टर्मिनोलॉजी

प्रक्रिया - OS ऑब्जेक्ट, आयसोलेटेड अॅड्रेस स्पेसमध्ये थ्रेड्स आहेत.
धागा - एक OS ऑब्जेक्ट, अंमलबजावणीचे सर्वात लहान एकक, प्रक्रियेचा भाग, थ्रेड्स एका प्रक्रियेमध्ये मेमरी आणि इतर संसाधने आपापसात सामायिक करतात.
मल्टीटास्किंग - OS गुणधर्म, एकाच वेळी अनेक प्रक्रिया चालविण्याची क्षमता
मल्टी-कोर - प्रोसेसरची मालमत्ता, डेटा प्रक्रियेसाठी अनेक कोर वापरण्याची क्षमता
मल्टीप्रोसेसिंग - संगणकाची मालमत्ता, एकाच वेळी अनेक प्रोसेसरसह शारीरिकरित्या कार्य करण्याची क्षमता
मल्टीथ्रेडिंग — प्रक्रियेचा गुणधर्म, अनेक थ्रेड्समध्ये डेटा प्रोसेसिंग वितरित करण्याची क्षमता.
समांतरता - वेळेच्या प्रति युनिटमध्ये एकाच वेळी अनेक क्रिया शारीरिकरित्या करणे
असिंक्रोनी - ही प्रक्रिया पूर्ण होण्याची वाट न पाहता ऑपरेशनची अंमलबजावणी; अंमलबजावणीच्या निकालावर नंतर प्रक्रिया केली जाऊ शकते.

रूपक

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

सकाळी नाश्ता तयार करताना मी (सीपीयू) मी स्वयंपाकघरात येतो (संगणक). माझ्याकडे 2 हात आहेत (कोर). स्वयंपाकघरात अनेक उपकरणे आहेत (IO): ओव्हन, केटल, टोस्टर, रेफ्रिजरेटर. मी गॅस चालू करतो, त्यावर एक तळण्याचे पॅन ठेवतो आणि ते गरम होण्याची वाट न पाहता त्यात तेल ओततो (असिंक्रोनसली, नॉन-ब्लॉकिंग-IO-प्रतीक्षा), मी अंडी रेफ्रिजरेटरमधून बाहेर काढतो आणि एका प्लेटमध्ये तोडतो, नंतर एका हाताने मारतो (धागा #1), आणि दुसरा (धागा #2) प्लेट धरून (सामायिक संसाधन). आता मला किटली चालू करायची आहे, पण माझ्याकडे पुरेसे हात नाहीत (धागा उपासमार) या वेळी, तळण्याचे पॅन गरम होते (परिणामावर प्रक्रिया करत आहे) ज्यामध्ये मी जे फेटले आहे ते ओतते. मी किटलीकडे पोहोचतो आणि ती चालू करतो आणि मूर्खपणाने त्यात पाणी उकळताना पाहतो (अवरोधित करणे-IO-प्रतीक्षा), जरी या काळात तो ज्या ठिकाणी ऑम्लेट चाबूक मारत होता ती प्लेट त्याला धुता आली असती.

मी फक्त 2 हात वापरून ऑम्लेट शिजवले, आणि माझ्याकडे जास्त नाही, परंतु त्याच वेळी, ऑम्लेट चाबूक मारण्याच्या क्षणी, एकाच वेळी 3 ऑपरेशन्स झाल्या: ऑम्लेट चाबकाने मारणे, प्लेट पकडणे, तळण्याचे पॅन गरम करणे CPU हा संगणकाचा सर्वात वेगवान भाग आहे, IO म्हणजे बहुतेक वेळा सर्वकाही मंदावते, त्यामुळे बर्‍याचदा एक प्रभावी उपाय म्हणजे IO कडून डेटा प्राप्त करताना CPU ला काहीतरी व्यापून टाकणे.

रूपक चालू ठेवणे:

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

.NET साधने

.NET इतर अनेक गोष्टींप्रमाणेच थ्रेड्ससह काम करण्यात चांगले आहे. प्रत्येक नवीन आवृत्तीसह, ते त्यांच्यासोबत काम करण्यासाठी अधिकाधिक नवीन साधने सादर करते, OS थ्रेड्सवर अॅब्स्ट्रॅक्शनचे नवीन स्तर. अ‍ॅब्स्ट्रॅक्शनच्या बांधकामासोबत काम करताना, फ्रेमवर्क डेव्हलपर उच्च-स्तरीय अ‍ॅब्स्ट्रॅक्शन वापरताना, एक किंवा अधिक पातळी खाली जाण्यासाठी संधी सोडण्याचा दृष्टिकोन वापरतात. बर्‍याचदा हे आवश्यक नसते, खरं तर ते शॉटगनने स्वतःला पायात गोळी मारण्याचे दार उघडते, परंतु काहीवेळा, क्वचित प्रसंगी, अमूर्ततेच्या वर्तमान स्तरावर सोडवलेल्या समस्येचे निराकरण करण्याचा हा एकमेव मार्ग असू शकतो. .

साधनांद्वारे, मला असे म्हणायचे आहे की फ्रेमवर्क आणि तृतीय-पक्ष पॅकेजेसद्वारे प्रदान केलेले दोन्ही ऍप्लिकेशन प्रोग्रामिंग इंटरफेस (एपीआय), तसेच संपूर्ण सॉफ्टवेअर सोल्यूशन्स जे मल्टी-थ्रेडेड कोडशी संबंधित कोणत्याही समस्यांसाठी शोध सुलभ करतात.

धागा सुरू करत आहे

थ्रेड क्लास हा .NET मध्ये थ्रेड्ससह काम करण्यासाठी सर्वात मूलभूत वर्ग आहे. कन्स्ट्रक्टर दोनपैकी एक प्रतिनिधी स्वीकारतो:

थ्रेडस्टार्ट - कोणतेही पॅरामीटर नाहीत
ParametrizedThreadStart - प्रकार ऑब्जेक्टच्या एका पॅरामीटरसह.

स्टार्ट मेथडला कॉल केल्यानंतर नव्याने तयार केलेल्या थ्रेडमध्ये डेलिगेट कार्यान्वित केले जाईल. जर पॅरामेट्रीज्ड थ्रेडस्टार्ट प्रकाराचा प्रतिनिधी कन्स्ट्रक्टरला पास केला असेल, तर ऑब्जेक्ट स्टार्ट मेथडला पास करणे आवश्यक आहे. कोणतीही स्थानिक माहिती प्रवाहात हस्तांतरित करण्यासाठी ही यंत्रणा आवश्यक आहे. हे लक्षात घेण्यासारखे आहे की थ्रेड तयार करणे हे एक महाग ऑपरेशन आहे आणि थ्रेड स्वतःच एक जड वस्तू आहे, कमीतकमी कारण ते स्टॅकवर 1MB मेमरी वाटप करते आणि OS API सह परस्परसंवाद आवश्यक आहे.

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

थ्रेडपूल वर्ग पूलची संकल्पना दर्शवतो. .NET मध्ये, थ्रेड पूल हा अभियांत्रिकीचा एक भाग आहे, आणि Microsoft मधील विकासकांनी ते विविध प्रकारच्या परिस्थितींमध्ये चांगल्या प्रकारे कार्य करते याची खात्री करण्यासाठी खूप प्रयत्न केले आहेत.

सामान्य संकल्पना:

अनुप्रयोग सुरू झाल्यापासून, ते पार्श्वभूमीमध्ये राखीव मध्ये अनेक थ्रेड तयार करते आणि ते वापरण्यासाठी घेण्याची क्षमता प्रदान करते. थ्रेड्स वारंवार आणि मोठ्या संख्येने वापरल्यास, कॉलरच्या गरजा पूर्ण करण्यासाठी पूल विस्तृत होतो. जेव्हा योग्य वेळी पूलमध्ये कोणतेही विनामूल्य थ्रेड नसतात, तेव्हा ते एकतर थ्रेड परत येण्याची प्रतीक्षा करेल किंवा नवीन तयार करेल. हे खालीलप्रमाणे आहे की थ्रेड पूल काही अल्प-मुदतीच्या क्रियांसाठी उत्तम आहे आणि अनुप्रयोगाच्या संपूर्ण ऑपरेशनमध्ये सेवा म्हणून चालणार्‍या ऑपरेशन्ससाठी योग्य नाही.

पूलमधून थ्रेड वापरण्यासाठी, एक QueueUserWorkItem पद्धत आहे जी WaitCallback प्रकाराचे प्रतिनिधी स्वीकारते, ज्याची स्वाक्षरी ParametrizedThreadStart सारखीच असते आणि त्यास पास केलेले पॅरामीटर समान कार्य करते.

ThreadPool.QueueUserWorkItem(...);

RegisterWaitForSingleObject ही कमी-ज्ञात थ्रेड पूल पद्धत नॉन-ब्लॉकिंग IO ऑपरेशन्स आयोजित करण्यासाठी वापरली जाते. या पद्धतीला पास केलेल्या प्रतिनिधीला जेव्हा वेटहँडल पद्धतीने पास केले जाते तेव्हा "रिलीझ" केले जाते.

ThreadPool.RegisterWaitForSingleObject(...)

.NET मध्ये एक थ्रेड टाइमर आहे आणि तो WinForms/WPF टाइमरपेक्षा वेगळा आहे कारण त्याचा हँडलर पूलमधून घेतलेल्या थ्रेडवर कॉल केला जाईल.

System.Threading.Timer

पूलमधून थ्रेडवर अंमलबजावणीसाठी प्रतिनिधी पाठवण्याचा एक विचित्र मार्ग देखील आहे - BeginInvoke पद्धत.

DelegateInstance.BeginInvoke

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

Kernel32.dll CreateThread

थ्रेड्स पहाणे आणि डीबग करणे

तुम्ही तयार केलेले थ्रेड्स, सर्व तृतीय-पक्ष घटक आणि .NET पूल व्हिज्युअल स्टुडिओच्या थ्रेड्स विंडोमध्ये पाहिले जाऊ शकतात. जेव्हा अनुप्रयोग डीबग आणि ब्रेक मोडमध्ये असेल तेव्हाच ही विंडो थ्रेड माहिती प्रदर्शित करेल. येथे तुम्ही प्रत्येक थ्रेडची स्टॅक नावे आणि प्राधान्यक्रम सहजतेने पाहू शकता आणि डीबगिंगला विशिष्ट थ्रेडवर स्विच करू शकता. थ्रेड क्लासच्या प्रायोरिटी प्रॉपर्टीचा वापर करून, तुम्ही थ्रेडचा प्राधान्यक्रम सेट करू शकता, जे OC आणि CLR ला थ्रेड्स दरम्यान प्रोसेसर वेळ विभाजित करताना एक शिफारस म्हणून समजेल.

कार्य समांतर लायब्ररी

टास्क पॅरलल लायब्ररी (TPL) .NET 4.0 मध्ये सादर करण्यात आली. आता हे एसिंक्रोनीसह कार्य करण्यासाठी मानक आणि मुख्य साधन आहे. जुना दृष्टिकोन वापरणारा कोणताही कोड वारसा मानला जातो. TPL चे मूळ युनिट म्हणजे System.Threading.Tasks नेमस्पेस मधील टास्क क्लास. कार्य म्हणजे थ्रेडवरील अमूर्तता. C# भाषेच्या नवीन आवृत्तीसह, आम्हाला Tasks - async/await operators सह काम करण्याचा एक सुंदर मार्ग मिळाला. या संकल्पनांमुळे असिंक्रोनस कोड लिहिणे शक्य झाले जसे की ते सोपे आणि सिंक्रोनस होते, यामुळे थ्रेड्सच्या अंतर्गत कार्याबद्दल थोडेसे समज नसलेल्या लोकांना देखील ते वापरणारे अनुप्रयोग लिहिणे शक्य झाले, दीर्घ ऑपरेशन्स करताना गोठत नसलेले अनुप्रयोग. async/await वापरणे हा एक किंवा अनेक लेखांसाठी एक विषय आहे, परंतु मी काही वाक्यांमध्ये त्याचा सारांश घेण्याचा प्रयत्न करेन:

async हे टास्क किंवा व्हॉइड परत करणार्‍या पद्धतीचे सुधारक आहे
आणि प्रतीक्षा हे नॉन-ब्लॉकिंग टास्क वेटिंग ऑपरेटर आहे.

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

टास्क लाँच आणि वापरण्यासाठी पर्याय पाहू. खालील कोड उदाहरणामध्ये, आम्ही एक नवीन कार्य तयार करतो जे काहीही उपयुक्त नाही (थ्रेड.स्लीप(10000)), परंतु वास्तविक जीवनात हे काही जटिल CPU-केंद्रित कार्य असावे.

using TCO = System.Threading.Tasks.TaskCreationOptions;

public static async void VoidAsyncMethod() {
    var cancellationSource = new CancellationTokenSource();

    await Task.Factory.StartNew(
        // Code of action will be executed on other context
        () => Thread.Sleep(10000),
        cancellationSource.Token,
        TCO.LongRunning | TCO.AttachedToParent | TCO.PreferFairness,
        scheduler
    );

    //  Code after await will be executed on captured context
}

अनेक पर्यायांसह कार्य तयार केले आहे:

लाँगरनिंग हा एक इशारा आहे की कार्य त्वरीत पूर्ण होणार नाही, याचा अर्थ पूलमधून धागा न घेण्याचा विचार करणे योग्य आहे, परंतु इतरांना हानी पोहोचवू नये म्हणून या कार्यासाठी एक वेगळा तयार करणे योग्य आहे.
AttachedToParent - कार्ये पदानुक्रमात मांडली जाऊ शकतात. जर हा पर्याय वापरला गेला असेल, तर कार्य अशा स्थितीत असू शकते जिथे त्याने स्वतः पूर्ण केले आहे आणि आपल्या मुलांच्या अंमलबजावणीची वाट पाहत आहे.
PreferFairness - म्हणजे अंमलबजावणीसाठी पाठवलेली कार्ये नंतर पाठवण्याआधी कार्यान्वित करणे अधिक चांगले होईल. परंतु ही फक्त एक शिफारस आहे आणि परिणामांची हमी नाही.

या पद्धतीला पास केलेले दुसरे पॅरामीटर म्हणजे CancellationToken. ऑपरेशन सुरू झाल्यानंतर रद्द करणे योग्यरित्या हाताळण्यासाठी, कार्यान्वित केलेला कोड रद्दीकरण टोकन स्थितीसाठी चेकने भरलेला असणे आवश्यक आहे. कोणतेही चेक नसल्यास, CancellationTokenSource ऑब्जेक्टवर कॉल केलेली रद्द पद्धत कार्य सुरू होण्यापूर्वीच कार्यान्वित करणे थांबवू शकेल.

शेवटचा पॅरामीटर टास्कशेड्युलर प्रकाराचा शेड्यूलर ऑब्जेक्ट आहे. हा वर्ग आणि त्याचे वंशज थ्रेडवर कार्ये वितरित करण्याच्या धोरणांवर नियंत्रण ठेवण्यासाठी डिझाइन केलेले आहेत; डीफॉल्टनुसार, पूलमधून यादृच्छिक थ्रेडवर कार्य कार्यान्वित केले जाईल.

प्रतीक्षा ऑपरेटर तयार केलेल्या टास्कवर लागू केला जातो, याचा अर्थ त्याच्या नंतर लिहिलेला कोड, जर एखादा असेल तर, प्रतीक्षा करण्यापूर्वी कोडच्या संदर्भात (बहुतेकदा याचा अर्थ त्याच थ्रेडवर) कार्यान्वित केला जाईल.

पद्धत async शून्य म्हणून चिन्हांकित केली आहे, याचा अर्थ ती प्रतीक्षा ऑपरेटर वापरू शकते, परंतु कॉलिंग कोड अंमलबजावणीसाठी प्रतीक्षा करण्यास सक्षम असणार नाही. असे वैशिष्ट्य आवश्यक असल्यास, पद्धत कार्य परत करणे आवश्यक आहे. async void चिन्हांकित केलेल्या पद्धती अगदी सामान्य आहेत: एक नियम म्हणून, हे इव्हेंट हँडलर किंवा इतर पद्धती आहेत ज्या अग्निवर कार्य करतात आणि तत्त्व विसरतात. आपल्याला केवळ अंमलबजावणीच्या समाप्तीपर्यंत प्रतीक्षा करण्याची संधीच देण्याची आवश्यकता नसल्यास, परंतु परिणाम देखील परत करणे आवश्यक आहे, तर आपल्याला कार्य वापरण्याची आवश्यकता आहे.

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/await वापरताना असिंक्रोनस कोडमधील त्रुटी हाताळणे खूप सोपे आहे - ते कोड सिंक्रोनस असल्यासारखेच वागतात. आम्ही टास्कमध्ये सिंक्रोनस वेट एक्सॉर्सिझम लागू केल्यास, मूळ अपवाद एकूण अपवादात बदलतो, उदा. अपवाद हाताळण्यासाठी, तुम्हाला InnerException प्रकार तपासावा लागेल आणि C# जगामध्ये अधिक परिचित असलेल्या कॅच ब्लॉक्सच्या साखळीऐवजी एका कॅच ब्लॉकमध्ये स्वतःला इफ चेन लिहावे लागेल किंवा बांधताना कॅच वापरावा लागेल.

तिसरी आणि अंतिम उदाहरणे देखील त्याच कारणास्तव खराब म्हणून चिन्हांकित केली आहेत आणि सर्व समान समस्या आहेत.

टास्कच्या गटाची वाट पाहण्यासाठी व्हेनएन्नी आणि व्हेन ऑल पद्धती अत्यंत सोयीस्कर आहेत; ते टास्कचा एक गट एकामध्ये गुंडाळतात, जे एकतर गटातील टास्क पहिल्यांदा ट्रिगर झाल्यावर किंवा त्या सर्वांनी पूर्ण केल्यावर सक्रिय होतील.

धागे थांबवत आहेत

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

व्यत्यय पद्धत अधिक अंदाजानुसार कार्य करते. हे अपवादाने थ्रेडमध्ये व्यत्यय आणू शकते ThreadInterruptedException केवळ त्या क्षणांमध्ये जेव्हा धागा प्रतीक्षा स्थितीत असतो. वेटहँडल, लॉक किंवा थ्रेड.स्लीप कॉल केल्यानंतर प्रतीक्षा करत असताना लटकत असताना ते या स्थितीत प्रवेश करते.

वर वर्णन केलेले दोन्ही पर्याय त्यांच्या अप्रत्याशिततेमुळे खराब आहेत. उपाय म्हणजे रचना वापरणे रद्दीकरण टोकन आणि वर्ग रद्दीकरण टोकनस्रोत. मुद्दा असा आहे: कॅन्सलेशनटोकनसोर्स क्लासचे एक उदाहरण तयार केले आहे आणि ज्याच्याकडे आहे तोच या पद्धतीला कॉल करून ऑपरेशन थांबवू शकतो. रद्द करा. ऑपरेशनला फक्त रद्दीकरण टोकन दिले जाते. CancellationToken मालक स्वतः ऑपरेशन रद्द करू शकत नाहीत, परंतु ऑपरेशन रद्द केले गेले आहे की नाही ते फक्त तपासू शकतात. यासाठी बुलियन प्रॉपर्टी आहे रद्द करण्याची विनंती केली आहे आणि पद्धत ThrowIfCancel विनंती केली. नंतरचे अपवाद फेकतील TaskCancelledException कॅन्सलेशनटोकनच्या उदाहरणावर कॅन्सल पद्धत कॉल केली असल्यास पॅरोट केली जात आहे. आणि ही पद्धत मी वापरण्याची शिफारस करतो. कोणत्या टप्प्यावर अपवाद ऑपरेशन रद्द केले जाऊ शकते यावर पूर्ण नियंत्रण मिळवून मागील पर्यायांपेक्षा ही सुधारणा आहे.

थ्रेड थांबवण्याचा सर्वात क्रूर पर्याय म्हणजे Win32 API TerminateThread फंक्शनला कॉल करणे. हे फंक्शन कॉल केल्यानंतर CLR चे वर्तन अप्रत्याशित असू शकते. MSDN वर या कार्याबद्दल खालील लिहिले आहे: "TerminateThread हे एक धोकादायक फंक्शन आहे जे केवळ अत्यंत अत्यंत प्रकरणांमध्ये वापरले जावे. "

FromAsync पद्धत वापरून लेगसी API कार्य आधारित मध्ये रूपांतरित करणे

टास्क सादर केल्यानंतर सुरू झालेल्या प्रकल्पावर काम करण्यासाठी तुम्ही भाग्यवान असाल आणि बहुतेक विकासकांसाठी शांत भय निर्माण करणे थांबवले असेल, तर तुम्हाला तृतीय-पक्ष आणि तुमची टीम अशा दोन्ही जुन्या API चा सामना करावा लागणार नाही. भूतकाळात छळ केला आहे. सुदैवाने, .NET फ्रेमवर्क टीमने आमची काळजी घेतली, जरी कदाचित आमचे ध्येय स्वतःची काळजी घेणे होते. ते जसे असेल तसे असो, .NET कडे जुन्या असिंक्रोनस प्रोग्रामिंग पध्दतीमध्ये लिहिलेल्या कोडला वेदनारहित रूपांतरित करण्यासाठी अनेक साधने आहेत. त्यापैकी एक टास्कफॅक्टरीची FromAsync पद्धत आहे. खालील कोड उदाहरणामध्ये, मी WebRequest क्लासच्या जुन्या async पद्धती या पद्धतीचा वापर करून टास्कमध्ये गुंडाळतो.

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

हे फक्त एक उदाहरण आहे आणि तुम्हाला हे अंगभूत प्रकारांसह करावे लागण्याची शक्यता नाही, परंतु कोणताही जुना प्रकल्प फक्त BeginDoSomething पद्धतींचा वापर करतो ज्या IAsyncResult आणि EndDoSomething पद्धती प्राप्त करतात.

TaskCompletionSource क्लास वापरून Legacy API ला Task Based मध्ये रूपांतरित करा

विचारात घेण्यासारखे दुसरे महत्त्वाचे साधन म्हणजे वर्ग TaskCompletionSource. फंक्शन्स, उद्देश आणि ऑपरेशनच्या तत्त्वाच्या बाबतीत, ते थ्रेडपूल क्लासच्या RegisterWaitForSingleObject पद्धतीची आठवण करून देणारे असू शकते, ज्याबद्दल मी वर लिहिले आहे. हा वर्ग वापरून, तुम्ही टास्कमध्ये जुने असिंक्रोनस API सहज आणि सोयीस्करपणे गुंडाळू शकता.

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

TaskCompletionSource इव्हेंट मॉडेलच्या आसपास तयार केलेली टास्क आणि लीगेसी API गुंडाळण्यासाठी योग्य आहे. त्याच्या कार्याचे सार खालीलप्रमाणे आहे: या वर्गाच्या ऑब्जेक्टमध्ये टास्क प्रकारची सार्वजनिक मालमत्ता आहे, ज्याची स्थिती SetResult, SetException इत्यादी TaskCompletionSource वर्गाच्या पद्धतींद्वारे नियंत्रित केली जाऊ शकते. ज्या ठिकाणी प्रतीक्षा ऑपरेटरला या टास्कसाठी लागू केले गेले होते, ते कार्य पूर्णत्व स्त्रोतावर लागू केलेल्या पद्धतीवर अवलंबून अपवादाने कार्यान्वित केले जाईल किंवा अयशस्वी होईल. हे अद्याप स्पष्ट नसल्यास, या कोडचे उदाहरण पाहू या, जेथे काही जुने EAP API टास्कमध्ये टास्क कॉम्प्लेशनस्रोत वापरून गुंडाळले आहे: जेव्हा इव्हेंट सुरू होईल, तेव्हा कार्य पूर्ण स्थितीत ठेवले जाईल आणि प्रतीक्षा ऑपरेटरला लागू केलेली पद्धत या कार्यासाठी ऑब्जेक्ट प्राप्त झाल्यानंतर त्याची अंमलबजावणी पुन्हा सुरू होईल परिणाम.

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, काही कारणास्तव, इव्हेंटची तक्रार करू शकत नाही, परंतु केवळ स्थिती परत करू शकते. वेबसॉकेटच्या काळापूर्वी किंवा हे तंत्रज्ञान वापरणे काही कारणास्तव अशक्य असताना HTTP च्या शीर्षस्थानी तयार केलेले सर्व API हे याचे उदाहरण आहे. क्लायंट HTTP सर्व्हरला विचारू शकतो. HTTP सर्व्हर स्वतः क्लायंटशी संप्रेषण सुरू करू शकत नाही. टायमर वापरून सर्व्हरचे मतदान करणे हा एक सोपा उपाय आहे, परंतु यामुळे सर्व्हरवर अतिरिक्त भार निर्माण होतो आणि सरासरी TimerInterval / 2 वर अतिरिक्त विलंब होतो. हे जाणून घेण्यासाठी, लाँग पोलिंग नावाची युक्ती शोधण्यात आली, ज्यामध्ये प्रतिसादास उशीर करणे समाविष्ट आहे. टाइमआउट कालबाह्य होईपर्यंत किंवा एखादी घटना घडेपर्यंत सर्व्हर. जर घटना घडली असेल, तर त्यावर प्रक्रिया केली जाते, नसल्यास, पुन्हा विनंती पाठविली जाते.

while(!eventOccures && !timeoutExceeded)  {

  CheckTimout();
  CheckEvent();
  Thread.Sleep(1);
}

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

class LongPollingApi {

    private Dictionary<int, TaskCompletionSource<Msg>> tasks;

    public async Task<Msg> AcceptMessageAsync(int userId, int duration) {

        var cs = new TaskCompletionSource<Msg>();
        tasks[userId] = cs;
        await Task.WhenAny(Task.Delay(duration), cs.Task);
        return cs.Task.IsCompleted ? cs.Task.Result : null;
    }

    public void SendMessage(int userId, Msg m) {

        if (tasks.TryGetValue(userId, out var completionSource))
            completionSource.SetResult(m);
    }
}

हा कोड उत्पादनासाठी तयार नाही, परंतु केवळ एक डेमो आहे. वास्तविक प्रकरणांमध्ये ते वापरण्यासाठी, जेव्हा कोणीही त्याची अपेक्षा करत नसेल अशा वेळी संदेश येतो तेव्हा परिस्थिती हाताळण्यासाठी तुम्हाला कमीतकमी आवश्यक आहे: या प्रकरणात, AsseptMessageAsync पद्धतीने आधीच पूर्ण केलेले कार्य परत केले पाहिजे. हे सर्वात सामान्य प्रकरण असल्यास, आपण ValueTask वापरण्याचा विचार करू शकता.

जेव्हा आम्हाला संदेशासाठी विनंती प्राप्त होते, तेव्हा आम्ही डिक्शनरीमध्ये TaskCompletionSource तयार करतो आणि ठेवतो आणि नंतर काय होते याची प्रतीक्षा करा: निर्दिष्ट वेळ मध्यांतर कालबाह्य होते किंवा संदेश प्राप्त होतो.

ValueTask: का आणि कसे

async/await ऑपरेटर, yield return operator प्रमाणे, पद्धतीतून एक स्टेट मशीन तयार करतात, आणि हे नवीन ऑब्जेक्टची निर्मिती आहे, जे जवळजवळ नेहमीच महत्त्वाचे नसते, परंतु क्वचित प्रसंगी ते समस्या निर्माण करू शकते. हे केस एक पद्धत असू शकते ज्याला खरोखर अनेकदा कॉल केले जाते, आम्ही प्रति सेकंद दहापट आणि शेकडो हजारो कॉलबद्दल बोलत आहोत. जर अशी पद्धत अशा प्रकारे लिहिली गेली असेल की बहुतेक प्रकरणांमध्ये ती सर्व प्रतीक्षा पद्धतींना मागे टाकून निकाल देते, तर .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));
}

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

टास्क शेड्युलर: टास्क लॉन्च धोरणे व्यवस्थापित करणे

मी विचार करू इच्छित पुढील API वर्ग आहे टास्क शेड्युलर आणि त्याचे डेरिव्हेटिव्ह्ज. मी आधीच वर नमूद केले आहे की TPL कडे थ्रेड्सवर कार्ये वितरित करण्यासाठी धोरणे व्यवस्थापित करण्याची क्षमता आहे. टास्कशेड्युलर वर्गाच्या वंशजांमध्ये अशा धोरणांची व्याख्या केली जाते. तुम्हाला आवश्यक असलेली जवळपास कोणतीही रणनीती लायब्ररीमध्ये आढळू शकते. समांतर विस्तार एक्स्ट्रा, मायक्रोसॉफ्टने विकसित केले आहे, परंतु .NET चा भाग नाही, परंतु Nuget पॅकेज म्हणून पुरवले आहे. त्यापैकी काही थोडक्यात पाहू:

CurrentThreadTaskScheduler - वर्तमान थ्रेडवर कार्ये कार्यान्वित करते
LimitedConcurrencyLevelTaskScheduler — पॅरामीटर N द्वारे एकाच वेळी कार्यान्वित केलेल्या कार्यांची संख्या मर्यादित करते, जे कन्स्ट्रक्टरमध्ये स्वीकारले जाते
ऑर्डर केलेले टास्क शेड्यूलर — LimitedConcurrencyLevelTaskScheduler(1) म्हणून परिभाषित केले आहे, त्यामुळे कार्ये क्रमाने चालविली जातील.
WorkStealingTaskScheduler - अवजारे कामाची चोरी कार्य वितरणाचा दृष्टीकोन. मूलत: तो एक वेगळा थ्रेडपूल आहे. समस्येचे निराकरण करते की .NET ThreadPool मध्ये एक स्थिर वर्ग आहे, सर्व अनुप्रयोगांसाठी एक आहे, याचा अर्थ प्रोग्रामच्या एका भागामध्ये त्याचा ओव्हरलोडिंग किंवा चुकीचा वापर केल्यास दुस-या भागात दुष्परिणाम होऊ शकतात. शिवाय, अशा दोषांचे कारण समजणे अत्यंत कठीण आहे. ते. प्रोग्रामच्या काही भागांमध्ये वेगळे WorkStealingTaskSchedulers वापरण्याची आवश्यकता असू शकते जेथे ThreadPool चा वापर आक्रमक आणि अप्रत्याशित असू शकतो.
रांगेत टास्क शेड्यूलर — तुम्हाला प्राधान्य रांगेच्या नियमांनुसार कार्ये करण्यास अनुमती देते
ThreadPerTaskScheduler — त्यावर कार्यान्वित केलेल्या प्रत्येक टास्कसाठी स्वतंत्र थ्रेड तयार करतो. ज्या कार्यांना पूर्ण होण्यास अप्रत्याशितपणे बराच वेळ लागतो त्यांच्यासाठी उपयुक्त ठरू शकते.

छान तपशीलवार आहे लेख मायक्रोसॉफ्ट ब्लॉगवरील TaskSchedulers बद्दल.

टास्कशी संबंधित प्रत्येक गोष्टीच्या सोयीस्कर डीबगिंगसाठी, व्हिज्युअल स्टुडिओमध्ये टास्क विंडो आहे. या विंडोमध्ये तुम्ही कार्याची सद्यस्थिती पाहू शकता आणि कोडच्या सध्या कार्यान्वित होत असलेल्या ओळीवर जाऊ शकता.

PLinq आणि समांतर वर्ग

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

पॅरलल स्टॅटिक क्लास फॉरेच कलेक्शनद्वारे समांतर मध्ये पुनरावृत्ती करण्यासाठी, फॉर लूप कार्यान्वित करण्यासाठी आणि समांतर इनव्होकमध्ये एकाधिक प्रतिनिधी कार्यान्वित करण्यासाठी पद्धती प्रदान करतो. गणना पूर्ण होईपर्यंत वर्तमान थ्रेडची अंमलबजावणी थांबविली जाईल. शेवटचा युक्तिवाद म्हणून ParallelOptions पास करून थ्रेडची संख्या कॉन्फिगर केली जाऊ शकते. तुम्ही पर्याय वापरून TaskScheduler आणि CancellationToken देखील निर्दिष्ट करू शकता.

निष्कर्ष

जेव्हा मी माझ्या अहवालातील सामग्री आणि त्यानंतरच्या माझ्या कामाच्या दरम्यान गोळा केलेल्या माहितीच्या आधारे हा लेख लिहायला सुरुवात केली तेव्हा मला असे वाटले नव्हते की ते इतके असेल. आता, जेव्हा मी हा लेख टाईप करत असलेला मजकूर संपादक मला निंदनीयपणे सांगतो की पृष्ठ 15 गेले आहे, तेव्हा मी अंतरिम निकालांचा सारांश देईन. इतर युक्त्या, API, व्हिज्युअल टूल्स आणि तोटे पुढील लेखात समाविष्ट केले जातील.

निष्कर्ष:

आधुनिक पीसीची संसाधने वापरण्यासाठी तुम्हाला थ्रेड्स, एसिंक्रोनी आणि समांतरतेसह कार्य करण्यासाठी साधने माहित असणे आवश्यक आहे.
.NET कडे या उद्देशांसाठी अनेक भिन्न साधने आहेत
ते सर्व एकाच वेळी दिसले नाहीत, म्हणून आपण बर्‍याचदा वारसा शोधू शकता, तथापि, जास्त प्रयत्न न करता जुने API रूपांतरित करण्याचे मार्ग आहेत.
.NET मध्ये थ्रेड्ससह कार्य करणे हे थ्रेड आणि थ्रेडपूल वर्गांद्वारे प्रस्तुत केले जाते
Thread.Abort, Thread.Interrupt आणि Win32 API TerminateThread पद्धती धोकादायक आहेत आणि वापरण्यासाठी शिफारस केलेली नाही. त्याऐवजी, CancellationToken यंत्रणा वापरणे चांगले
प्रवाह हा एक मौल्यवान स्त्रोत आहे आणि त्याचा पुरवठा मर्यादित आहे. थ्रेड इव्हेंटची वाट पाहण्यात व्यस्त आहेत अशा परिस्थिती टाळल्या पाहिजेत. यासाठी TaskCompletionSource वर्ग वापरणे सोयीचे आहे
समांतरता आणि असिंक्रोनीसह कार्य करण्यासाठी सर्वात शक्तिशाली आणि प्रगत .NET साधने कार्ये आहेत.
c# async/await ऑपरेटर नॉन-ब्लॉकिंग प्रतीक्षा संकल्पना लागू करतात
तुम्ही TaskScheduler-व्युत्पन्न वर्ग वापरून थ्रेडवर टास्कचे वितरण नियंत्रित करू शकता
व्हॅल्यूटास्क रचना हॉट-पाथ आणि मेमरी-ट्रॅफिक ऑप्टिमाइझ करण्यासाठी उपयुक्त ठरू शकते
व्हिज्युअल स्टुडिओची कार्ये आणि थ्रेड्स विंडो बहु-थ्रेडेड किंवा एसिंक्रोनस कोड डीबग करण्यासाठी उपयुक्त माहिती प्रदान करतात.
PLinq हे एक छान साधन आहे, परंतु त्यात तुमच्या डेटा स्रोताविषयी पुरेशी माहिती नसू शकते, परंतु विभाजन यंत्रणा वापरून हे निश्चित केले जाऊ शकते.
पुढे चालू…

स्त्रोत: www.habr.com

.NET: मल्टीथ्रेडिंग आणि एसिंक्रोनीसह कार्य करण्यासाठी साधने. भाग 1