इस नेट का लाभ क्या है

Question

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

तो मैं 'Systems.Collections' नाम स्थान में हर जगह इस पैटर्न को खोजने:

public class WhatEv 
{ 
    private class SyncWhatEv : WhatEv 
    { 
     // overrides IsSyncronized = true 
     // overrides whatever else to make it thread safe 
    } 

    public virtual bool IsSynchronized 
    { 
     get { return false; } 
    } 

    public static WhatEv Synchronized(WhatEv whatEv) 
    { 
     return new SyncWhatEv(whatEv); 
    } 
} 

वर्गों है कि यह लागू की एक संख्या हैं: हैशटेबल, कतार, ऐरेलिस्ट, ढेर, आदि ... मैं विरासत को समझता हूं। लेकिन इसे एक निजी, नेस्टेड क्लास क्यों बनाते हैं और उपयोगकर्ता इसे प्राप्त करने के लिए एक उछाल से कूदते हैं? क्या इस तरह से ऐसा करने के लिए कोई फायदा है?

Answer 1

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

उनके इनपुट के लिए सभी को धन्यवाद। मैं इसकी सराहना करता हूं।

Answer 2

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

ऑब्जेक्ट का सिंक्रनाइज़ संस्करण, थ्रेड-सुरक्षा के अलावा कोई अतिरिक्त कार्यक्षमता नहीं जोड़ता है। वे किसी भी नए सदस्यों का पर्दाफाश नहीं करते हैं, न ही उनके अंतर्निहित प्रकार को जानने में वास्तव में मदद करते हैं। इसलिए उन्हें निजी/बस अपनी सार्वजनिक/बेस क्लास की तरह "देखो" बनाया जाता है।

Answer 3

सिद्धांत रूप में, यह एक अच्छा विचार है, और @CodeNaked की अच्छी व्याख्या है। अभ्यास में, अभी भी इसके साथ समस्याएं हैं। उदाहरण के लिए, यदि आपको अपने थ्रेड-सुरक्षित वर्ग में 2 कॉल करने की आवश्यकता है और दोनों कॉलों के लिए थ्रेड सुरक्षा की आवश्यकता है, तो आपको अभी भी लॉक करने की आवश्यकता है। इस SO आइटम में अच्छी व्याख्या: In C# would it be better to use Queue.Synchronized or lock() for thread safety?