RAII मुहावरे और ताले के बारे में

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

.NET या जावा जैसे "प्रबंधित" प्लेटफार्मों पर स्विच करते समय, यह मुहावरे किसी तरह से इसकी प्रासंगिकता खो देते हैं, क्योंकि कचरा संग्रहकर्ता मेमोरी को मुक्त करने में लगा हुआ है, अर्थात्, मेमोरी सबसे लोकप्रिय संसाधन था जिसे C ++ में ध्यान रखना था। हालाँकि, चूंकि कचरा संग्रहकर्ता केवल मेमोरी के साथ काम करता है और संसाधनों के निर्धारक रिलीज (जैसे ऑपरेटिंग सिस्टम हैंडल) में योगदान नहीं करता है, RAII मुहावर अभी भी .NET और Java दोनों में उपयोग किया जाता है, हालांकि कुछ डेवलपर्स को इस जटिल नाम के बारे में पता है।

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



ManualLockManagerment विधि मैन्युअल लॉकिंग नियंत्रण का उपयोग करती है, जबकि UsingBasedMethod विधि एक छोटे शेल पर आधारित है। इस शेल का एक पूर्ण उदाहरण यहां पाया जा सकता है , लेकिन यह अनुमान लगाना मुश्किल नहीं है कि यह कैसे काम करता है : UseReadLock एक्सटेंशन विधि एक ऑब्जेक्ट बनाता है जिसका निर्माता रीड लॉक को कैप्चर करता है, और डिस्पोज विधि इसे जारी करता है। सवाल यह है कि दो टुकड़ों को बराबर दिया गया है और उन्हें क्या प्राथमिकता दी जानी चाहिए? बेशक, एक ब्लॉकिंग ब्लॉक वाली "साइकिल" अधिक पठनीय लगती है, लेकिन क्या यह केवल उनके बीच का अंतर है?

लगभग। पहले उदाहरण को थोड़ा जटिल करते हैं। क्या होगा यदि हमारे कोड में रीड लॉक को लॉक करने के बाद विधि के पुनरावर्ती कॉल की संभावना है, उस विधि को कॉल करता है जो रीड लॉक को फिर से लॉक करता है। मुझे नहीं लगता कि प्रत्येक पाठक रीड -कैप्चर (डिफ़ॉल्ट रूप से रीफ़्रेंटीसी मोड) के संदर्भ में ReaderWriterLockSlim ऑब्जेक्ट के व्यवहार को याद करता है, इसलिए मैं तुरंत कहता हूं कि, लॉक कंस्ट्रक्शन के विपरीत, ReaderWiteriterLockSlim ऑब्जेक्ट डिफ़ॉल्ट रूप से पुनरावर्ती कैप्चर का समर्थन नहीं करता है:



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

इस स्थिति में, निम्न होता है: चूंकि ReaderWriterLockSlim ऑब्जेक्ट पुनरावर्ती कैप्चर का समर्थन नहीं करता है , जब आप EnterReadLock विधि को दूसरी बार कॉल करने का प्रयास करते हैं (दूसरे मेथोडोड विधि की पंक्ति 3), एक LockRecusionException को फेंक दिया जाएगा, लेकिन चूंकि यह कॉल कोशिश ब्लॉक के अंदर स्थित है, इसलिए आखिर मेंमेथोड विधि कहा जाता है। ExitReadLock के लिए एक बाद में कॉल। नतीजतन, पहले से ही लाइन 4 में हमें एक मुफ्त लॉक मिलता है, जो अपने आप में स्वस्थ नहीं है, क्योंकि हमने इसे कब्जा नहीं किया था; उसके बाद, नियंत्रण को कुछ मेथमॉड विधि पर वापस लौटाया जाता है और अंत में ब्लॉक में जाता है, जहां एक्सिट्रिडलॉक विधि को फिर से बुलाया जाएगा।

गतिरोध और अन्य परेशानी

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

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

समस्या यह है कि .NET 4.0 (और नीचे) पर व्यवहार निम्नलिखित होगा: EnterReadLock विधि को कॉल करने से पहले ExitReadLock विधि को कॉल करने का प्रयास एक अपवाद फेंकता है, लेकिन EnterReadLock के एक कॉल के बाद ExitReadLock में दो कॉल सफल होते हैं!



इस मामले में सबसे अप्रिय बात यह है कि फ्रेमवर्क के वर्तमान पुराने संस्करणों में यह कोड न केवल सफल होगा, यह लॉक ऑब्जेक्ट की स्थिति का एक बेमेल होगा, जिसके परिणामस्वरूप हम कंसोल पर निम्नलिखित देखेंगे: " रीडआउट = 4294967295, ReadLockHeld = गलत " । वास्तव में, लाइन 3 में हमने लॉक काउंटर के मूल्य को 0 तक घटा दिया, और लाइन 4 में हमने इसे फिर से घटा दिया; परिणामस्वरूप, काउंटर -1 हो जाता है, और 4294967295 एक अहस्ताक्षरित प्रारूप में "-1" मूल्य का प्रतिनिधित्व करता है। लेकिन सबसे महत्वपूर्ण बात यह है कि राइट लॉक को कैप्चर करने का कोई भी बाद का प्रयास हमेशा के लिए चिपक जाएगा, क्योंकि डोप यह मान लेगा कि रीड लॉक अभी भी कैप्चर किया गया है।

जैसा कि यह निकला, यह .NET फ्रेमवर्क में एक ज्ञात बग है, जो अंततः .NET 4.5 में तय किया गया था। VS2012 को स्थापित करने के बाद, हम अपेक्षित व्यवहार प्राप्त करते हैं, यद्यपि बहुत सुखद नहीं: मूल अपवाद जो तब होता है जब रीडिंग के लिए लॉक को फिर से कब्जा कर लिया जाता है, तब नया अपवाद होता है जो तब होता है जब आप अन-कैप्चर किए गए लॉक को रिलीज़ करने की कोशिश करते हैं!

संसाधनों का सही तरीके से उपयोग या कैप्चर करें !

अब याद करते हैं कि ब्लॉकिंग का उपयोग कैसे काम करता है :



उपयोग निर्माण इस तरह से फैलता है कि संसाधन का कब्जा कोशिश ब्लॉक से पहले होता है, ताकि जब पकड़े जाने पर अपवाद को फेंक दिया जाए, तो रिलीज नहीं किया जाएगा। यह व्यवहार अप्रिय परिणामों को जन्म दे सकता है यदि उपयोग करने वाले निर्माण को ऑब्जेक्ट इनिलाइज़र (विवरण के लिए, उपयोग ब्लॉक में ऑब्जेक्ट इनिशलाइज़र देखें ) के साथ जोड़ा जाता है, लेकिन यह पूरी तरह से C ++ में कंस्ट्रक्टर्स / डिस्ट्रक्टर्स के व्यवहार से मेल खाता है, जिसमें ऑब्जेक्ट को सफलतापूर्वक बनाया गया था, तो केवल विध्वंसक कहा जाता था ।

नोट
यहाँ हम C ++ में डिस्ट्रक्टर्स के बीच एक और अंतर के साथ सामना कर रहे हैं और C # में फाइनल कर रहे हैं। विध्वंसक के विपरीत, फाइनली को तब भी कहा जाता है, भले ही निर्मित वस्तु का निर्माता अपवाद के साथ गिर गया हो। यह व्यवहार काफी तार्किक है, क्योंकि यह सी # में अपवादों के दृष्टिकोण से सुरक्षित संसाधन प्रबंधन कोड के निर्माण को सरल बनाता है, जब अंतिम रूप में यह सफल संसाधन कैप्चर के बहुत तथ्य ( null , IntPtr । Zero , आदि की जांच करके) की जांच करने के लिए पर्याप्त है।

चूंकि निर्माण का उपयोग करते समय, डिस्पोज़ विधि को संसाधन के सफल कैप्चर पर ही बुलाया जाता है, निम्न कोड यथासंभव संभव व्यवहार करता है: कोड जो someMethod विधि को कॉल करता है, उसे एक अपवाद प्राप्त होगा जो किसी अन्य Memeth विधि की पंक्ति 2 में तब होता है जब वह पुन: लॉक को पकड़ने का प्रयास करता है, और लॉक ऑब्जेक्ट पूरी तरह से है। .NET फ्रेमवर्क के किसी भी संस्करण में सामान्य स्थिति: