2011-02-15 17 views

उत्तर

5

यह डॉन बॉक्स की पुस्तक Essential COM में विस्तार से समझाया गया है।

AddRef/Release कक्षा वस्तुओं के आईसीएलएएस फैक्ट्री इंटरफेस पर अक्सर प्रक्रियाओं के बाहर सर्वरों में खाली विधियां होती हैं। ऐसा इसलिए है क्योंकि क्लास ऑब्जेक्ट का आंतरिक संदर्भ सर्वर द्वारा बनाए रखा जाता है जब यह CoRegisterClassObject पर कॉल करता है, और इस प्रकार AddRef/Release के "सामान्य" इन-प्रोसेस सर्वर कार्यान्वयन के परिणामस्वरूप वर्ग ऑब्जेक्ट पर संदर्भ गणना हमेशा एक से अधिक हो जाती है, और सर्वर CoRevokeClassObject पर कॉल करने के बारे में नहीं पता होगा।

COM रनटाइम IClassFactory::LockServer पर कॉल करता है जब यह CoGetClassObject पर कॉल के बाद क्लास ऑब्जेक्ट के बाहरी संदर्भ को मार्शल करता है। इस तरह सर्वर प्रक्रिया जीवनकाल को बाहरी संदर्भों के अस्तित्व या अन्यथा के आधार पर ठीक से नियंत्रित किया जा सकता है।

+0

उस पुस्तक में इसे देखने का अच्छा विचार ... मैंने ऐसा क्यों नहीं सोचा! –

3

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

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

मुझे संदेह है कि उन्होंने आईसीएलएएसफ़ैक्टरी को पेश किया है: : लॉकसेवर यह था कि सर्वर को लॉक करना अर्थपूर्ण रूप से addRef'ing जैसा ही नहीं है। AddRef/रिलीज सामान्य ऑब्जेक्ट लाइफसाइक्ल प्रबंधन के लिए है और स्पष्ट रूप से परिभाषित अर्थशास्त्र परिभाषित किया गया है। सर्वर लॉक करना एक प्रदर्शन ट्विक है।

संबंधित मुद्दे