रीडरवाइटर लॉकस्लिम कैसे 'डिस्पोजेबल' है?

Question

मैं मुख्य रूप से IDisposable पैटर्न का पालन करता हूं, और अधिकांश वर्गों के लिए उचित है। लेकिन ReaderWriterLockSlim ने मुझे इस तरह के पैटर्न को लागू करने की व्यवहार्यता पर सवाल उठाया। सभी ReaderWriterLockSlim.Dispose कुछ घटना हैंडल बंद है। तो Dispose इतनी कम संसाधनों के साथ इस वर्ग के लिए कितना महत्वपूर्ण है? इस मामले में, मुझे वास्तव में कोई फर्क नहीं पड़ता कि जीसी को अप्रबंधित संसाधनों के फाइनलरों को खत्म करने के लिए एक और दौर का इंतजार करना पड़ा।

IDisposable पैटर्न लागू करने का नतीजा काफी हद तक है, लेकिन डिस्पोजेबल क्लास का उपयोग करने वाले प्रत्येक वर्ग को अब IDisposable लागू करना होगा। मेरे विशेष मामले में, मैं HashSet के लिए एक रैपर लागू कर रहा हूं। मैं विशेष रूप से इस तरह के ऑब्जेक्ट को निपटाने की आवश्यकता की अपेक्षा नहीं करता क्योंकि, गलती से, यह सिंक्रनाइज़र का उपयोग करता है जो करता है।

क्या इस मामले में डिस्पोजेबल पैटर्न का उल्लंघन न करने के कोई कारण हैं? जबकि मैं उत्सुक हूं, मैं अभ्यास में ऐसा नहीं करता, क्योंकि स्थिरता का उल्लंघन करना बहुत खराब है।

Answer 1

अप्रबंधित ओएस हैंडल के साथ समस्या यह है कि handles come from a limited supply. जीसी इस बारे में अवगत नहीं है।

एक हैंडल की शुद्ध स्मृति खपत इतना बड़ी नहीं है। कर्नेल मेमोरी में किसी ऑब्जेक्ट से कहीं ज्यादा नहीं है और शायद कहीं हैश टेबल एंट्री कहीं भी नहीं है।

आप सही कह रहे हैं कि यह कहना पर्याप्त नहीं है: "आपको हमेशा सभी डिस्पोजेबल ऑब्जेक्ट्स का निपटान करना चाहिए"। वह नियम बहुत आसान है। For example the Task class does not need to be disposed. यदि आप जानते हैं कि आप क्या कर रहे हैं तो आप निपटान के संबंध में एक कमजोर रुख ले सकते हैं। ध्यान रखें कि सभी टीम के सदस्य इस बिंदु को समझ नहीं सकते हैं (अब आप स्रोत कोड में इस उत्तर का एक लिंक छोड़ सकते हैं ...)।

यदि आप सुनिश्चित हैं कि आप बहुत से हैंडल रिसाव नहीं करेंगे तो आप सुरक्षित रूप से ऐसा कर सकते हैं। ध्यान रखें कि किनारे की स्थिति (लोड, बग, ...) के तहत आप उत्पादन के मुद्दों के कारण अनुमान लगा सकते हैं।

Answer 2

यदि यह फ़ील्ड staticyou don't need to dispose of it है, तो यह आपके आवेदन के समान जीवनकाल (दाएं) होगा। मुझे लगता है कि यह नहीं है, चलते हैं।

आईडीस्पोज़ेबल को संभालने का सही तरीका इसका निपटान करना है। मुझे लगता है कि हमें ऐसा करने का एक अच्छा कारण नहीं है।

उपयोग एक और ताला:

मुझे लगता है कि ऐसा करने के लिए सबसे अच्छी बात Monitor या किसी अन्य ताला, जिनसे आपको अपने कोड को सरल बनाने का बोनस होगा उपयोग करने के लिए है। ConcurrentDictionary और अन्य ढांचे वर्ग इस दृष्टिकोण को लेते हैं।

आप लॉक के बारे में चिंतित हैं, लेकिन मुझे यकीन नहीं है कि यह ReaderWriterLockSlim तक भी हल किया गया है, केवल वास्तविक समाधान कम ताले रखने और उन्हें कम समय तक पकड़ना है।

निपटान नहीं है:

यह एक औचित्य की जरूरत है। क्या आप यहां आवश्यक प्रदर्शन लाभ प्रदर्शित कर सकते हैं?

यदि आपके पास इनमें से कुछ ऑब्जेक्ट्स लंबे समय तक रहते हैं, ठीक है, तो सभी डिस्पोजेबल समान रूप से वज़न नहीं होते हैं (यह एक शब्द दस्तावेज़ को छोड़ने जैसा नहीं है), तो आप शायद इससे दूर हो जाएंगे। जैसा कि यह बताया गया है कि आवेदन बंद होने से पहले इस सभी मिलीसेकंडों का निपटान करने का क्या मतलब है।मेरा मानना ​​है कि एक आईडीस्पोजेबल का विनाशक उन स्थितियों को संभालने के लिए है जहां ऑब्जेक्ट का निपटारा नहीं किया गया है, हालांकि आप यह सुनिश्चित नहीं कर सकते कि यह कहां या कब कहा जाता है।

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