🛑 🤾🏾 💔 .NET - मल्टीथ्रेडिंग और एसिंक्रोनसी के साथ काम करने के लिए उपकरण

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

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

अंतर्वस्तु

साझा संसाधनों के संबंध में

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

उदाहरण # 1:

संभावित मुद्दों से बचने के लिए, आप थ्रेड्स को विभिन्न फ़ाइलों के साथ काम करते हैं, प्रत्येक थ्रेड के लिए एक फ़ाइल। यह आपको लगता है कि कार्यक्रम के पास कोई साझा संसाधन नहीं हैं।

कुछ स्तरों के नीचे जाने पर, आपको पता चलता है कि केवल एक हार्ड ड्राइव है, और हार्ड ड्राइव एक्सेस के साथ समस्याओं का समाधान खोजने के लिए यह ड्राइवर या ओएस पर निर्भर है।

उदाहरण # 2:

उदाहरण # 1 पढ़ने के बाद, आपने फ़ाइलों को भौतिक रूप से भिन्न हार्डवेयर और ऑपरेटिंग सिस्टम के साथ दो भिन्न दूरस्थ मशीनों पर रखने का निर्णय लिया। आप दो अलग-अलग एफ़टीपी या एनएफएस कनेक्शन भी बनाए रखते हैं।

कुछ स्तरों को फिर से नीचे जाने पर, आप समझते हैं कि वास्तव में कुछ भी नहीं बदला है, और प्रतिस्पर्धात्मक एक्सेस मुद्दा अब नेटवर्क कार्ड ड्राइवर या मशीन के ओएस को सौंपा गया है जिस पर प्रोग्राम चल रहा है।

उदाहरण # 3:

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

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

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

बहु-थ्रेडेड वातावरण में संभावित समस्याएँ

हम सॉफ्टवेयर त्रुटियों को निम्नलिखित श्रेणियों में वर्गीकृत कर सकते हैं:

कार्यक्रम एक परिणाम नहीं देता है - यह क्रैश या जमा देता है।
कार्यक्रम एक गलत परिणाम देता है।
कार्यक्रम एक सही परिणाम उत्पन्न करता है लेकिन कुछ गैर-फ़ंक्शन-संबंधित आवश्यकता को पूरा नहीं करता है - यह बहुत अधिक समय या संसाधन खर्च करता है।

बहु-थ्रेडेड परिवेशों में, # 1 और # 2 त्रुटियों के परिणामस्वरूप मुख्य मुद्दे गतिरोध और दौड़ की स्थिति हैं ।

गतिरोध

गतिरोध एक पारस्परिक अवरोध है। एक गतिरोध के कई रूप हैं। निम्नलिखित को सबसे आम माना जा सकता है:

जबकि थ्रेड # 1 कुछ कर रहा था, थ्रेड # 2 अवरुद्ध संसाधन बी। कुछ समय बाद, थ्रेड # 1 ने संसाधन ए को अवरुद्ध कर दिया और संसाधन बी को ब्लॉक करने की कोशिश कर रहा था। दुर्भाग्य से, ऐसा कभी नहीं होगा क्योंकि थ्रेड # 2 केवल संसाधन ए को अवरुद्ध करने के बाद संसाधन बी को जाने देगा ।

दौड़ की स्थिति

रेस-कंडीशन एक ऐसी स्थिति है जब दोनों, गणना का व्यवहार और परिणाम निष्पादन पर्यावरण के थ्रेड शेड्यूलर पर निर्भर करते हैं

मुसीबत यह है कि आपका कार्यक्रम सौ में एक बार, या एक मिलियन में भी अनुचित तरीके से काम कर सकता है।

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

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

व्यस्त-प्रतीक्षा

व्यस्त प्रतीक्षा एक मुद्दा है जो उस समय होता है जब प्रोग्राम प्रोसेसर संसाधनों को गणना के बजाय प्रतीक्षा पर खर्च करता है।

आमतौर पर, यह समस्या निम्न की तरह दिखती है:

while(!hasSomethingHappened) ;

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

शायद, कुछ पाठकों ने सुझाव दिया कि थ्रेड में से एक (स्लीप) (1) (या कुछ इसी तरह) को जोड़कर एक कोर के मुद्दे को पूरी तरह से कब्जा कर लिया जाए। जबकि यह इस मुद्दे को हल करेगा, एक नया बनाया जाएगा - परिवर्तनों पर प्रतिक्रिया करने में लगने वाला समय अब औसतन 0.5 एमएस होगा। एक तरफ, यह इतना अधिक नहीं है, लेकिन दूसरी तरफ, यह मूल्य उस स्थिति से बहुत अधिक है जो हम रीसेट परिवार के सिंक्रनाइज़ेशन प्राइमेटिव का उपयोग करके प्राप्त कर सकते हैं।

धागा भुखमरी

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

आप विभिन्न प्रोफाइलरों का उपयोग करके इस तरह के मुद्दों को पा सकते हैं। निम्नलिखित टाइमलाइन मोड में काम कर रहे डॉटट्रेस प्रोफाइलर का स्क्रीनशॉट है

(विस्तार करने के लिए क्लिक करें)।

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

जब इस तरह के एक मुद्दे का निदान किया जाता है, तो आप इसका ध्यान रख सकते हैं बस: आपने एक बार में बहुत सारे थ्रेड शुरू कर दिए हैं, इसलिए बस कुछ थ्रेड शुरू करें।

तुल्यकालन के तरीके

Interlocked

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

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

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

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

 public static int CompareExchange (ref int location1, int value, int comparand);

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

 var original = location1; if (location1 == comparand) location1 = value; return original;

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

हम एक अच्छा उदाहरण पा सकते हैं कि इस पद्धति का उपयोग उस कोड में कैसे किया जा सकता है जो कंपाइलर किसी C # ईवेंट के लिए उत्पन्न करता है।

आइए MyEvent नामक एक घटना के साथ एक साधारण वर्ग लिखें:

 class MyClass { public event EventHandler MyEvent; }

अब, रिलीज कॉन्फ़िगरेशन में प्रोजेक्ट का निर्माण करें और “Show Compiler Generated Code” विकल्प के साथ dotPeek के माध्यम से बिल्ड को खोलें।

 [CompilerGenerated] private EventHandler MyEvent; public event EventHandler MyEvent { [CompilerGenerated] add { EventHandler eventHandler = this.MyEvent; EventHandler comparand; do { comparand = eventHandler; eventHandler = Interlocked.CompareExchange<EventHandler>(ref this.MyEvent, (EventHandler) Delegate.Combine((Delegate) comparand, (Delegate) value), comparand); } while (eventHandler != comparand); } [CompilerGenerated] remove { // The same algorithm but with Delegate.Remove } }

यहां, हम देख सकते हैं कि संकलक ने पर्दे के पीछे एक बल्कि जटिल एल्गोरिथ्म उत्पन्न किया है। यह एल्गोरिथ्म हमें उस घटना के लिए सदस्यता खोने से रोकता है जिसमें कुछ धागे एक साथ इस घटना के लिए सदस्यता लेते हैं। आइए इस बात पर ध्यान दें कि पर्दे के पीछे तुलनात्मक पद्धति क्या करती है:

 EventHandler eventHandler = this.MyEvent; EventHandler comparand; do { comparand = eventHandler; // Begin Atomic Operation if (MyEvent == comparand) { eventHandler = MyEvent; MyEvent = Delegate.Combine(MyEvent, value); } // End Atomic Operation } while (eventHandler != comparand);

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

यदि MyEvent अभी भी वैसी ही है जैसा कि इस समय हमने Delegate.Combine को निष्पादित करना शुरू किया था, तो इसे Delegate.Combine पर वापस लौटा दें। यदि ऐसा नहीं है, तो तब तक फिर से कोशिश करें जब तक यह काम न करे।

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

मॉनीटर.इंटर, मॉनीटर। एक्सिट, लॉक

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

 lock(a) { lock (a) { ... } }

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

C # में महत्वपूर्ण अनुभाग की कार्य प्रक्रिया की यह ख़ासियत लॉक ऑपरेटर पर एक दिलचस्प सीमा को लागू करती है: आप लॉक ऑपरेटर के अंदर प्रतीक्षित ऑपरेटर का उपयोग नहीं कर सकते। सबसे पहले, इसने मुझे आश्चर्यचकित कर दिया क्योंकि इसी तरह की एक कोशिश के बाद मॉनिटर.इंटर / एक्ज़िट निर्माण संकलित किया जा सकता है। सौदा क्या है? पिछले पैराग्राफ को फिर से पढ़ना और async / काम करने का कुछ ज्ञान लागू करना महत्वपूर्ण है: प्रतीक्षा के बाद का कोड इंतजार करने से पहले कोड के समान थ्रेड पर निष्पादित नहीं किया जाएगा। यह सिंक्रोनाइज़ेशन के संदर्भ पर निर्भर करता है और कॉन्फिगरवाइट विधि को कॉल किया जाता है या नहीं। इस से, यह निम्नानुसार है कि Monitor.Exit Monitor.Enter की तुलना में एक अलग थ्रेड पर निष्पादित किया जा सकता है, जो SynchronizationLockException को फेंक दिया जाएगा। यदि आप मुझ पर विश्वास नहीं करते हैं, तो कंसोल कोड में निम्नलिखित कोड चलाने का प्रयास करें - यह एक सिंक्रोनाइज़ेशन उत्पन्न करेगा। अपवाद :

 var syncObject = new Object(); Monitor.Enter(syncObject); Console.WriteLine(Thread.CurrentThread.ManagedThreadId); await Task.Delay(1000); Monitor.Exit(syncObject); Console.WriteLine(Thread.CurrentThread.ManagedThreadId);

यह ध्यान देने योग्य है कि, एक WinForms या WPF एप्लिकेशन में, यह कोड सही ढंग से काम करेगा यदि आप इसे मुख्य थ्रेड से कहते हैं क्योंकि एक सिंक्रनाइज़ेशन संदर्भ होगा जो प्रतीक्षा करने के बाद UI-थ्रेड पर लौटने वाले उपकरणों को लागू करता है। किसी भी मामले में, यह आवश्यक है कि किसी ऐसे कोड के संदर्भ में महत्वपूर्ण भूमिका न निभाई जाए, जिसमें वेइट ऑपरेटर हो। ऐसे उदाहरणों में, सिंक्रनाइज़ेशन प्राइमेटिव का उपयोग करना बेहतर है जिसे हम बाद में थोड़ा देखेंगे।

जब हम .NET में महत्वपूर्ण खंडों के विषय पर होते हैं, तो यह महत्वपूर्ण है कि वे लागू होने के तरीके की एक और विशिष्टता का उल्लेख करें। .NET में एक महत्वपूर्ण खंड दो मोड में काम करता है: स्पिन-प्रतीक्षा और कोर-प्रतीक्षा। हम निम्नलिखित pseudocode की तरह स्पिन-प्रतीक्षा एल्गोरिथ्म का प्रतिनिधित्व कर सकते हैं:

 while(!TryEnter(syncObject)) ;

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

स्पिनलॉक, स्पिनवाइट

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

मॉनीटर.वेट, मॉनीटर.पुलिस [सभी]

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

निर्माता-उपभोक्ता बहु-प्रक्रिया / बहु-थ्रेडेड डिज़ाइन का एक पैटर्न है जिसमें एक या एक से अधिक थ्रेड / प्रक्रियाएँ होती हैं जो डेटा का उत्पादन करती हैं और एक या अधिक प्रक्रियाएँ / थ्रेड जो इस डेटा को प्रोसेस करते हैं। आमतौर पर, एक साझा संग्रह का उपयोग किया जाता है।

इन दोनों विधियों को केवल एक थ्रेड द्वारा बुलाया जा सकता है जिसमें वर्तमान में एक ब्लॉक है। प्रतीक्षा विधि ब्लॉक को मुक्त कर देगी और तब तक फ्रीज करेगी जब तक कि एक और धागा पल्स को कॉल नहीं करेगा।

इसके प्रदर्शन के रूप में, मैंने एक छोटा सा उदाहरण लिखा:

 object syncObject = new object(); Thread t1 = new Thread(T1); t1.Start(); Thread.Sleep(100); Thread t2 = new Thread(T2); t2.Start();

(मैं अनुदेश निष्पादन आदेश को सटीक रूप से दिखाने के लिए पाठ के बजाय एक छवि का उपयोग करता हूं)
व्याख्या: मैंने विशेष रूप से गारंटी देने के लिए दूसरा धागा शुरू करते समय एक 100-एमएस विलंबता निर्धारित की है कि इसे बाद में निष्पादित किया जाएगा।
- T1: पंक्ति # 2 धागा शुरू किया गया है
- T1: लाइन # 3 धागा एक महत्वपूर्ण खंड में प्रवेश करता है
- T1: लाइन # 6 धागा सोने के लिए जाता है
- टी 2: पंक्ति # 3 धागा शुरू किया गया है
- टी 2: लाइन # 4 यह जमा देता है और महत्वपूर्ण खंड की प्रतीक्षा करता है
- T1: लाइन # 7 यह महत्वपूर्ण सेक्शन को जाने देता है और पल्स के बाहर आने के इंतजार में जम जाता है
- टी 2: लाइन # 8 यह महत्वपूर्ण अनुभाग में प्रवेश करती है
- T2: लाइन # 11 यह पल्स की मदद से T1 को इंगित करता है
- T2: लाइन # 14 यह महत्वपूर्ण खंड से बाहर आता है। ऐसा होने से पहले T1 अपने निष्पादन को जारी नहीं रख सकता है।
- T1: लाइन # 15 यह प्रतीक्षा से निकलती है
- T1: लाइन # 16 यह महत्वपूर्ण खंड से निकलती है

पल्स / प्रतीक्षा विधियों के उपयोग के संबंध में MSDN में एक महत्वपूर्ण टिप्पणी है: मॉनिटर राज्य की जानकारी संग्रहीत नहीं करता है, जिसका अर्थ है कि प्रतीक्षा विधि से पहले पल्स विधि को कॉल करने से गतिरोध हो सकता है। यदि ऐसा कोई मामला संभव है, तो ResetEvent परिवार से किसी एक वर्ग का उपयोग करना बेहतर है।

पिछला उदाहरण स्पष्ट रूप से दिखाता है कि मॉनिटर वर्ग के प्रतीक्षा / पल्स तरीके कैसे काम करते हैं, लेकिन फिर भी उन मामलों के बारे में कुछ प्रश्न छोड़ते हैं जिनमें हमें उनका उपयोग करना चाहिए। इसका एक अच्छा उदाहरण ब्लॉकिंगक्यू <टी> का कार्यान्वयन है। दूसरी ओर, System.Collections.Concurrent से ब्लॉकिंगकॉलिनेशन <T> का कार्यान्वयन सिंक्रनाइज़ेशन के लिए SemaphoreSlim का उपयोग करता है।

ReaderWriterLockSlim

मुझे इस सिंक्रोनाइज़ेशन आदिम से बहुत प्यार है, और यह System.Threading नामस्थान से उसी नाम के वर्ग द्वारा दर्शाया गया है। मुझे लगता है कि यदि उनके डेवलपर्स ने मानक लॉक के बजाय इस वर्ग का उपयोग किया तो बहुत सारे कार्यक्रम बहुत बेहतर काम करेंगे।

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

System.Threading नाम स्थान में, ReadWriteLock वर्ग भी है, लेकिन इसे नए विकास के लिए उपयोग नहीं करने की अत्यधिक अनुशंसा की जाती है। स्लिम संस्करण उन मामलों से बचने में मदद करेगा जो गतिरोध की ओर ले जाते हैं और कोर मोड पर जाने से पहले स्पिन-वेट मोड में सिंक्रोनाइज़ेशन का समर्थन करने वाले ब्लॉक को तुरंत कैप्चर करने की अनुमति देते हैं।

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

ReaderWriterLockSlim वर्ग का इंटरफ़ेस सरल और समझने में आसान है, लेकिन यह उपयोग करने के लिए आरामदायक नहीं है:

 var @lock = new ReaderWriterLockSlim(); @lock.EnterReadLock(); try { // ... } finally { @lock.ExitReadLock(); }

मैं आमतौर पर इसे एक कक्षा में लपेटना पसंद करता हूं - यह इसे बहुत आसान बनाता है।

Idea: Read / WriteLock मेथड बनाएं जो किसी ऑब्जेक्ट को Dispose मेथड के साथ लौटाता है। तब आप उन्हें उपयोग करने में उपयोग कर सकते हैं, और जब यह लाइनों की संख्या में आता है, तो यह मानक लॉक से बहुत अधिक भिन्न नहीं होगा।

 class RWLock : IDisposable { public struct WriteLockToken : IDisposable { private readonly ReaderWriterLockSlim @lock; public WriteLockToken(ReaderWriterLockSlim @lock) { this.@lock = @lock; @lock.EnterWriteLock(); } public void Dispose() => @lock.ExitWriteLock(); } public struct ReadLockToken : IDisposable { private readonly ReaderWriterLockSlim @lock; public ReadLockToken(ReaderWriterLockSlim @lock) { this.@lock = @lock; @lock.EnterReadLock(); } public void Dispose() => @lock.ExitReadLock(); } private readonly ReaderWriterLockSlim @lock = new ReaderWriterLockSlim(); public ReadLockToken ReadLock() => new ReadLockToken(@lock); public WriteLockToken WriteLock() => new WriteLockToken(@lock); public void Dispose() => @lock.Dispose(); }

यह हमें निम्नलिखित को कोड में बाद में लिखने की अनुमति देता है:

 var rwLock = new RWLock(); // ... using(rwLock.ReadLock()) { // ... }

ResetEvent परिवार

मैं इस परिवार में निम्न वर्ग शामिल करता हूं: ManualResetEvent, ManualResetEventSlim, और AutoResetEvent।

ManualResetEvent क्लास, इसका स्लिम वर्जन और AutoResetEvent क्लास दो राज्यों में मौजूद हो सकती है:

- गैर-संकेतित - इस स्थिति में, सभी थ्रेड्स, जिन्होंने WaitOne को फ्रीज कहा है, जब तक कि घटना सिग्नल वाले राज्य में स्विच नहीं हो जाती।
- संकेतित - इस अवस्था में, वेटऑन कॉल पर पहले से जमे हुए सभी थ्रेड जारी किए जाते हैं। एक संकेतित घटना पर सभी नए WaitOne कॉल अपेक्षाकृत त्वरित रूप से किए जाते हैं।

AutoResetEvent मैन्युअलResetEvent से भिन्न है कि यह वास्तव में एक थ्रेड को जारी करने के बाद गैर-संकेतित स्थिति पर स्विच करता है। यदि AutoResetEvent की प्रतीक्षा करते समय कुछ थ्रेड्स जमे हुए हैं, तो कॉलिंग सेट केवल एक यादृच्छिक थ्रेड जारी करेगा, जैसा कि ManualResetEvent के विपरीत है जो सभी थ्रेड्स को रिलीज़ करता है।

आइए एक उदाहरण देखें कि AutoResetEvent कैसे काम करता है:

 AutoResetEvent evt = new AutoResetEvent(false); Thread t1 = new Thread(T1); t1.Start(); Thread.Sleep(100); Thread t2 = new Thread(T2); t2.Start();

इन उदाहरणों में, हम देख सकते हैं कि ईवेंट एक सिग्नलऑन पर जमे हुए धागे को जारी करने के बाद ही गैर-सिग्नल वाले राज्य में स्वचालित रूप से स्विच हो जाता है।

ReaderWriterLock के विपरीत, ManualResetEvent को इसके स्लिम वर्जन के प्रकट होने के बाद भी अप्रचलित नहीं माना जाता है। स्पिन-वेट मोड में होने वाले शॉर्ट वेट के लिए क्लास का यह स्लिम वर्जन प्रभावी हो सकता है; मानक संस्करण लंबे इंतजार के लिए अच्छा है।

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

निष्कर्ष

थ्रेड्स के साथ काम करते समय, दो मुद्दे हैं जो गलत परिणाम या परिणाम की अनुपस्थिति का कारण हो सकते हैं - दौड़ की स्थिति और गतिरोध।
समस्याएँ जो प्रोग्राम को अधिक समय बिता सकती हैं या संसाधन थ्रेड भुखमरी और व्यस्त प्रतीक्षा हैं।
.NET थ्रेड को सिंक्रनाइज़ करने के लिए बहुत सारे तरीके प्रदान करता है।
ब्लॉक वेट के दो तरीके हैं - स्पिन प्रतीक्षा और कोर प्रतीक्षा। .NET में Som.e थ्रेड सिंक्रोनाइज़ेशन प्राइमेटिव दोनों का उपयोग करते हैं।
इंटरलॉक्ड परमाणु परिचालनों का एक समूह है जिसका उपयोग लॉक-फ्री एल्गोरिदम को लागू करने के लिए किया जा सकता है। यह सबसे तेज़ सिंक्रनाइज़ेशन आदिम है।
लॉक और मॉनिटर। एंटर / एक्जिट ऑपरेटर एक महत्वपूर्ण खंड की अवधारणा को लागू करते हैं - एक कोड टुकड़ा जिसे केवल एक समय में एक थ्रेड द्वारा निष्पादित किया जा सकता है।
निर्माता-उपभोक्ता परिदृश्यों को लागू करने के लिए Monitor.Pulse / Wait मेथड उपयोगी हैं।
जब समानांतर रीडिंग की उम्मीद की जाती है तो ReaderWriterLockSlim मानक लॉकिंग मामलों की तुलना में अधिक उपयोगी हो सकता है।
थ्रेड सिंक्रनाइज़ेशन के लिए ResetEvent वर्ग परिवार उपयोगी हो सकता है।

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