साझा लाइब्रेरी मेमोरी स्पेस

Question

क्या सी ++ साझा लाइब्रेरी की अपनी मेमोरी स्पेस है? या यह कॉलर प्रक्रिया 'एक साझा करता है?

मेरे पास एक साझा लाइब्रेरी है जिसमें कुछ कक्षाएं और रैपर फ़ंक्शन शामिल हैं। इस रैपर फ़ंक्शन में से एक है kinda:

libXXX_construct() जो किसी ऑब्जेक्ट को प्रारंभ करता है और पॉइंटर को उस ऑब्जेक्ट पर लौटाता है।

एक बार जब मैं कॉलर प्रोग्राम में libXXX_construct() का उपयोग करता हूं तो ऑब्जेक्ट कहां रखा जाता है? क्या यह "कॉलर" मेमोरी स्पेस में है या क्या यह लाइब्रेरी की मेमोरी स्पेस में है?

Answer 1

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

Answer 2

सभी साझा पुस्तकालय अपनी प्रक्रिया की वर्चुअल मेमोरी स्पेस साझा करते हैं। (मुख्य निष्पादन खुद सहित)

Answer 3

आपका वस्तु फोन करने वाले का स्मृति स्थान में मौजूद है (वास्तव में एक स्मृति स्थान पुस्तकालय और मुख्य निष्पादन के बीच साझा)

Answer 4

शेयर पता स्थान ताकि आप संकेत दिए गए साझा कर सकते हैं, फिर भी वे आवंटक साझा नहीं करते हैं (कम से कम खिड़कियों पर नहीं)।

इसका अर्थ यह है कि यदि आप किसी साझा लाइब्रेरी के अंदर किसी ऑब्जेक्ट को आवंटित करने के लिए नया कहते हैं तो आपको उसी लाइब्रेरी के अंदर हटाना होगा या अजीब चीजें हो सकती हैं।

Answer 5

साझा लाइब्रेरी की मेजबान प्रक्रिया के समान पता स्थान है। यह वही होना चाहिए, अन्यथा आप एक मॉड्यूल से दूसरे मॉड्यूल में पॉइंटर्स पास नहीं कर पाएंगे क्योंकि वे उन्हें खराब नहीं कर पाएंगे।

लेकिन हालांकि वे एक ही पता स्थान में हैं, इसका मतलब यह नहीं है कि वे सभी एक ही मेमोरी मैनेजर का उपयोग करते हैं। नतीजा यह है कि यदि आप एक ऐसा फ़ंक्शन प्रदान करते हैं जो कॉलर की तरफ से स्मृति आवंटित करता है, तो आपको उस स्मृति को मुक्त करने के लिए एक संबंधित फ़ंक्शन प्रदान करना चाहिए, libXXX_destroy()।

Answer 6

अन्यथा निर्दिष्ट किए जाने तक, साझा लाइब्रेरी इसे होस्ट करने की प्रक्रिया के साथ स्मृति साझा करेगा। प्रत्येक प्रक्रिया के उदाहरण के बाद अपनी प्रतिलिपि होगी।

हालांकि, विंडोज़ पर साझा चर बनाने के लिए संभव है जो इंटर-प्रोसेस संचार की अनुमति देता है। आप उन्हें सही प्रकार के सेगमेंट में डालकर ऐसा करते हैं। डिफ़ॉल्ट रूप से विंडोज दो प्रकार के सेगमेंट का उपयोग करता है: डेटा सेगमेंट को पढ़ा/लिखना नहीं है, जबकि कोड सेगमेंट केवल-पढ़ने योग्य और साझा किए जाते हैं। हालांकि, पढ़ने-लिखने और साझा गुण ऑर्थोगोनल हैं। लाइब्रेरी में एक साझा रीड-राइट सेगमेंट का उपयोग साझा चर को संग्रहीत करने के लिए किया जा सकता है, और यह तब तक जीवित रहेगा जब तक कि अंतिम प्रक्रिया समाप्त न हो जाए।

सी ++ से सावधान रहें, क्योंकि प्रक्रियाओं पर रचनाकारों और विनाशकों को खुशी से चलाया जाएगा & बाहर निकलें, भले ही आप साझा सेगमेंट में चर डाल दें।

विवरण के लिए, मैट Pietrek द्वारा Peering Inside the PE: A Tour of the Win32 Portable Executable File Format part 2 देखें।

Answer 7

यह सच है कि लाइब्रेरी प्रत्येक प्रक्रिया में मेमोरी का उपयोग करेगी जो इसे लोड करती है।हालांकि, कम से कम विंडोज के तहत, जब कई प्रक्रियाएं एक ही डीएलएल लोड करती हैं, तो असम्बद्ध पृष्ठों (सभी कोड पृष्ठों सहित) को कवर के तहत चुपचाप साझा किया जाता है। साथ ही, वे स्वैप फ़ाइल में कोई स्थान नहीं लेते हैं, क्योंकि उन्हें मूल फ़ाइल द्वारा समर्थित किया जाता है।

मेरा मानना ​​है कि यह जेआईटी संकलन के कारण .NET के लिए अधिक जटिल है, लेकिन अभी भी एनजीएनएड असेंबली के लिए सच होगा।

संपादित

यह वीएम का एक विस्तार है। हालांकि, आप प्रक्रियाओं में साझा करने के लिए एक डीएलएल में flag एक सेगमेंट भी कर सकते हैं।