.NET: मल्टीथ्रेडिंग और अतुल्यकालिक के साथ काम करने के लिए उपकरण। भाग २

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

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

सामग्री

• साझा संसाधनों के बारे में
• बहु-थ्रेडेड वातावरण में काम करते समय संभावित समस्याएं
  • गतिरोध
  • दौड़ की स्थिति
  • व्यस्त-प्रतीक्षा
  • धागा भुखमरी
• सिंक उपकरण
  • Interlocked
  • मॉनीटर.इंटर, मॉनीटर। एक्सिट, लॉक
  • स्पिनलॉक, स्पिनवाइट
  • मॉनीटर.वेट, मॉनीटर.पुलिस [सभी]
  • ReaderWriterLockSlim
  • रीसेट करें परिवार
• निष्कर्ष

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

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

उदाहरण # 1:

संभावित समस्याओं के डर से, आपने थ्रेड को विभिन्न फ़ाइलों के साथ काम किया। फाइल स्ट्रीम करने के लिए। यह आपको लगता है कि कार्यक्रम में एक भी सामान्य संसाधन नहीं है।

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

उदाहरण # 2:

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

नीचे कई स्तरों के नीचे जाने के बाद, हम समझते हैं कि कुछ भी नहीं बदला है, और नेटवर्क कार्ड या मशीन के ऑपरेटिंग सिस्टम जिस पर प्रोग्राम चल रहा है, उसे प्रतिस्पर्धी पहुंच की समस्या को हल करना होगा।

उदाहरण # 3:

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

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

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

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

सॉफ्टवेयर में त्रुटियों को कई समूहों में विभाजित किया जा सकता है:

1. कार्यक्रम एक परिणाम नहीं देता है। क्रैश या फ्रीज।
2. प्रोग्राम गलत परिणाम देता है।
3. कार्यक्रम सही परिणाम पैदा करता है, लेकिन एक या दूसरे गैर-कार्यात्मक आवश्यकता को पूरा नहीं करता है। बहुत लंबे समय तक चलता है या बहुत सारे संसाधनों का उपभोग करता है।

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

गतिरोध

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



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

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

दौड़-हालत - race condition। वह स्थिति जिसमें कार्यक्रम द्वारा निष्पादित गणनाओं का व्यवहार और परिणाम रन-टाइम थ्रेड शेड्यूलर के काम पर निर्भर करता है।
इस स्थिति की अप्रियता इस तथ्य में ठीक है कि आपका कार्यक्रम केवल एक बार सौ में से एक बार भी काम नहीं कर सकता है।

स्थिति इस तथ्य से बढ़ जाती है कि समस्याएं एक साथ जा सकती हैं, उदाहरण के लिए: थ्रेड शेड्यूलर के एक निश्चित व्यवहार के साथ, एक गतिरोध होता है।

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

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

व्यस्त-प्रतीक्षा एक समस्या है जिसमें कार्यक्रम प्रोसेसर संसाधनों की गणना के लिए नहीं, बल्कि प्रतीक्षा के लिए खपत करता है।

अक्सर कोड में ऐसी समस्या कुछ इस तरह दिखती है:

while(!hasSomethingHappened) ; 

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

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

धागा भुखमरी

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


(छवि क्लिक करने योग्य है)

उस कार्यक्रम में, जो स्ट्रीमिंग भूख से ग्रस्त नहीं है, रेखांकन पर गुलाबी रंग नहीं होगा, जो धाराओं को दर्शाते हैं। इसके अलावा, सबसिस्टम श्रेणी में, यह स्पष्ट है कि 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; } 

चलो रिलीज़ कॉन्फ़िगरेशन में प्रोजेक्ट का निर्माण करते हैं और शो कंपाइलर जनरेट किए गए कोड विकल्प के साथ डॉटपेक का उपयोग करके विधानसभा को खोलते हैं:

 [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 रिटर्न देता है, और यदि नहीं, तो इससे कोई फर्क नहीं पड़ता, चलो फिर से कोशिश करें और इसे फिर से दोहराएं।


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

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

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

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

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

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

 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 में महत्वपूर्ण खंड दो मोड में काम करता है: स्पिन-प्रतीक्षा मोड और कर्नेल मोड। स्पिन-वेट एल्गोरिथ्म को निम्नलिखित छद्म कोड के रूप में आसानी से दर्शाया गया है:

 while(!TryEnter(syncObject)) ; 

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

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

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

मॉनीटर.वेट, मॉनीटर.पल्स

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

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

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

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

 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 स्ट्रीम सो जाती है
- T2: लाइन # 3 स्ट्रीम शुरू होती है
- T2: लाइन # 4 एक महत्वपूर्ण खंड की प्रतीक्षा करते हुए जमा देता है
- T1: लाइन # 7 क्रिटिकल सेक्शन जारी करता है और पल्स के बाहर निकलने का इंतजार करता है
- T2: लाइन # 8 महत्वपूर्ण अनुभाग में प्रवेश करती है
- टी 2: पल्स विधि का उपयोग करके लाइन # 11 टी 1 को सूचित करता है
- T2: लाइन # 14 महत्वपूर्ण खंड से बाहर निकलता है। तब तक, T1 निष्पादन जारी नहीं रख सकता है।
- T1: लाइन # 15 जागता है
- T1: लाइन # 16 महत्वपूर्ण खंड छोड़ देता है

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

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

ReaderWriterLockSlim

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

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

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

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

ReaderWriterLockSlim वर्ग का इंटरफ़ेस सरल और सीधा है, लेकिन इसके उपयोग को शायद ही सुविधाजनक कहा जा सकता है:

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

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

 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()) { // ... } 

रीसेट करें परिवार

मैं इस परिवार को ManualResetEvent, ManualResetEventSlim, AutoResetEvent की कक्षाएं शामिल करता हूं।
ManualResetEvent क्लासेस, इसका स्लिम वर्जन और AutoResetEvent क्लास दो राज्यों में हो सकती है:
- गैर-संकेतित, इस स्थिति में, सभी थ्रेड्स जिन्हें WaitOne कहा जाता है, तब तक सिग्नल स्टेट की घटना के संक्रमण तक लटका रहता है।
- निम्न स्थिति (संकेतित), इस अवस्था में सभी वाट्सएप कॉल पर लटके हुए प्रवाह जारी होते हैं। रन-डाउन इवेंट में सभी नए WaitOne कॉल सशर्त रूप से तुरंत पास हो जाते हैं।

AutoResetEvent वर्ग ManualResetEvent वर्ग से भिन्न होता है, क्योंकि यह ठीक थ्रेड जारी करने के बाद स्वचालित रूप से एक कॉकड अवस्था में प्रवेश करता है। यदि कई थ्रेड्स AutoResetEvent की प्रतीक्षा कर रहे हैं, तो सेट कॉल मैन्युअलResetEvent के विपरीत केवल एक मनमाना जारी करेगा। 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 वर्ग को इसके स्लिम संस्करण की उपस्थिति के बाद उपयोग के लिए पदावनत नहीं किया जाता है और न ही अनुशंसित किया जाता है। इस वर्ग का पतला संस्करण कुशलतापूर्वक छोटी उम्मीदों के लिए उपयोग किया जाता है, जैसा कि यह स्पिन-वेट मोड में होता है, नियमित संस्करण लंबे लोगों के लिए उपयुक्त है।

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

निष्कर्ष

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