स्मृति बाधा

कम्प्यूटिंग में, एक मेमोरी बैरियर, जिसे मेम्बर, मेमोरी फेंस या फेंस इंस्ट्रक्शन के रूप में भी जाना जाता है, एक प्रकार का बैरियर (कंप्यूटर साइंस) इंस्ट्रक्शन (कंप्यूटर साइंस) है जो एक सेंट्रल प्रोसेसिंग यूनिट (सीपीयू) या संकलक को मेमोरी ऑर्डरिंग बाधा को लागू करने का कारण बनता है। बैरियर निर्देश से पहले और बाद में जारी किए गए रैंडम एक्सेस मेमोरी ऑपरेशंस पर। इसका आम तौर पर मतलब यह है कि बैरियर से पहले जारी किए गए ऑपरेशन को बैरियर के बाद जारी किए गए ऑपरेशन से पहले निष्पादित करने की गारंटी दी जाती है।

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

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

उदाहरण

जब कोई प्रोग्राम एकल-सीपीयू मशीन पर चलता है, तो हार्डवेयर यह सुनिश्चित करने के लिए आवश्यक बही-खाता निष्पादित करता है कि प्रोग्राम निष्पादित हो जैसे कि सभी मेमोरी ऑपरेशन प्रोग्रामर (प्रोग्राम ऑर्डर) द्वारा निर्दिष्ट क्रम में किए गए थे, इसलिए मेमोरी बाधाएं आवश्यक नहीं हैं। हालाँकि, जब मेमोरी को कई डिवाइसों के साथ साझा किया जाता है, जैसे कि मल्टीप्रोसेसर सिस्टम में अन्य सीपीयू, या मेमोरी-मैप्ड I/O|मेमोरी-मैप्ड पेरिफेरल्स, तो आउट-ऑफ-ऑर्डर एक्सेस प्रोग्राम व्यवहार को प्रभावित कर सकता है। उदाहरण के लिए, एक दूसरा सीपीयू पहले सीपीयू द्वारा किए गए मेमोरी परिवर्तनों को एक क्रम में देख सकता है जो प्रोग्राम ऑर्डर से भिन्न होता है।

एक प्रोग्राम एक प्रक्रिया के माध्यम से चलाया जाता है जो मल्टी-थ्रेडेड हो सकता है (यानी हार्डवेयर थ्रेड के विपरीत एक सॉफ्टवेयर थ्रेड जैसे कि pthreads)। विभिन्न प्रक्रियाएँ मेमोरी स्पेस साझा नहीं करती हैं इसलिए यह चर्चा दो प्रोग्रामों पर लागू नहीं होती है, प्रत्येक एक अलग प्रक्रिया में चल रहा है (इसलिए एक अलग मेमोरी स्पेस)। यह एक ही प्रक्रिया में चलने वाले दो या दो से अधिक (सॉफ्टवेयर) थ्रेड्स पर लागू होता है (यानी एक सिंगल मेमोरी स्पेस जहां कई सॉफ्टवेयर थ्रेड्स एक ही मेमोरी स्पेस साझा करते हैं)। एक ही प्रक्रिया के भीतर एकाधिक सॉफ़्टवेयर थ्रेड, मल्टी-कोर प्रोसेसर पर कॉनकरेंसी (कंप्यूटर विज्ञान) चला सकते हैं।

मल्टी-कोर प्रोसेसर पर चलने वाला निम्नलिखित मल्टी-थ्रेडेड प्रोग्राम इस बात का उदाहरण देता है कि इस तरह का आउट-ऑफ-ऑर्डर निष्पादन प्रोग्राम व्यवहार को कैसे प्रभावित कर सकता है:

प्रारंभ में, स्मृति स्थान x और f दोनों का महत्व है 0. प्रोसेसर #1 पर चलने वाला सॉफ़्टवेयर थ्रेड का मान लूप करता है f शून्य है, तो यह का मान प्रिंट करता है x. प्रोसेसर #2 पर चलने वाला सॉफ़्टवेयर थ्रेड मान संग्रहीत करता है 42 में x और फिर मूल्य संग्रहीत करता है 1 में f. दो प्रोग्राम अंशों के लिए छद्म कोड नीचे दिखाया गया है।

प्रोग्राम के चरण अलग-अलग प्रोसेसर निर्देशों के अनुरूप होते हैं।

पावरपीसी प्रोसेसर के मामले में, eioio निर्देश, मेमोरी बाड़ के रूप में, यह सुनिश्चित करता है कि प्रोसेसर द्वारा पहले शुरू किए गए किसी भी लोड या स्टोर ऑपरेशंस को मुख्य मेमोरी के संबंध में पूरी तरह से पूरा किया जाता है, इससे पहले कि प्रोसेसर द्वारा शुरू किए गए किसी भी बाद के लोड या स्टोर ऑपरेशंस मुख्य मेमोरी तक पहुंच सकें।^[1]^[2] थ्रेड #1 कोर #1:

 while (f == 0);
 // Memory fence required here
 print x;

थ्रेड #2 कोर #2:

 x = 42;
 // Memory fence required here
 f = 1;

कोई यह उम्मीद कर सकता है कि प्रिंट स्टेटमेंट हमेशा संख्या 42 प्रिंट करेगा; हालाँकि, यदि थ्रेड #2 के स्टोर संचालन को ऑर्डर से बाहर निष्पादित किया जाता है, तो यह संभव है f अद्यतन किया जाएगा before x, और प्रिंट स्टेटमेंट इसलिए 0 प्रिंट कर सकता है। इसी प्रकार, थ्रेड #1 के लोड संचालन को ऑर्डर से बाहर निष्पादित किया जा सकता है और यह संभव है x पढ़ने के लिए before f जाँच की गई है, और फिर से प्रिंट स्टेटमेंट एक अप्रत्याशित मान प्रिंट कर सकता है। अधिकांश कार्यक्रमों के लिए इनमें से कोई भी स्थिति स्वीकार्य नहीं है। थ्रेड #2 के असाइनमेंट से पहले एक मेमोरी बैरियर डाला जाना चाहिए f यह सुनिश्चित करने के लिए कि नया मान x के मूल्य में परिवर्तन से पहले या उससे पहले अन्य प्रोसेसरों को दिखाई देता है f. एक अन्य महत्वपूर्ण बिंदु यह है कि थ्रेड #1 की पहुंच से पहले एक मेमोरी बैरियर भी डाला जाना चाहिए x का मूल्य सुनिश्चित करने के लिए x के मूल्य में परिवर्तन देखने से पहले नहीं पढ़ा जाता है f.

एक अन्य उदाहरण तब होता है जब कोई ड्राइवर निम्नलिखित क्रम निष्पादित करता है:

 prepare data for a hardware module
 // Memory fence required here
 trigger the hardware module to process the data

यदि प्रोसेसर के स्टोर संचालन को ऑर्डर से बाहर निष्पादित किया जाता है, तो मेमोरी में डेटा तैयार होने से पहले हार्डवेयर मॉड्यूल चालू हो सकता है।

एक अन्य उदाहरणात्मक उदाहरण के लिए (एक गैर-तुच्छ उदाहरण जो वास्तविक व्यवहार में सामने आता है), लॉकिंग की दोबारा जांच की गई देखें।

मल्टीथ्रेडेड प्रोग्रामिंग और मेमोरी दृश्यता

मल्टीथ्रेडेड प्रोग्राम आमतौर पर उच्च-स्तरीय प्रोग्रामिंग वातावरण - जैसे जावा (प्रोग्रामिंग भाषा) या .NET - या एक अप्लिकेशन प्रोग्रामिंग अंतरफलक (एपीआई) जैसे POSIX थ्रेड्स या विंडोज़ एपीआई द्वारा प्रदान किए गए सिंक्रोनाइज़ेशन प्रिमिटिव का उपयोग करते हैं। निष्पादन के समानांतर थ्रेड से संसाधनों तक पहुंच को सिंक्रनाइज़ करने के लिए पारस्परिक बहिष्करण और सेमाफोर (प्रोग्रामिंग) जैसे सिंक्रनाइज़ेशन प्राइमेटिव प्रदान किए जाते हैं। ये प्रिमिटिव आमतौर पर अपेक्षित मेमोरी दृश्यता प्रदान करने के लिए आवश्यक मेमोरी बाधाओं के साथ कार्यान्वित किए जाते हैं। सिमेंटिक्स#कंप्यूटर विज्ञान। ऐसे वातावरण में मेमोरी बाधाओं का स्पष्ट उपयोग आम तौर पर आवश्यक नहीं होता है।

आउट-ऑफ-ऑर्डर निष्पादन बनाम कंपाइलर रीऑर्डरिंग ऑप्टिमाइज़ेशन

मेमोरी बैरियर निर्देश केवल हार्डवेयर स्तर पर पुन: व्यवस्थित करने के प्रभावों को संबोधित करते हैं। कंपाइलर प्रोग्राम अनुकूलन प्रक्रिया के भाग के रूप में निर्देशों को पुन: व्यवस्थित भी कर सकते हैं। यद्यपि समानांतर प्रोग्राम व्यवहार पर प्रभाव दोनों मामलों में समान हो सकते हैं, सामान्य तौर पर डेटा के लिए कंपाइलर रीऑर्डरिंग अनुकूलन को रोकने के लिए अलग-अलग उपाय करना आवश्यक है जिसे निष्पादन के कई थ्रेड्स द्वारा साझा किया जा सकता है।

C (प्रोग्रामिंग भाषा) और C++ में, volatile कीवर्ड का उद्देश्य C और C++ प्रोग्रामों को सीधे मेमोरी-मैप्ड I/O तक पहुंचने की अनुमति देना था। मेमोरी-मैप्ड I/O के लिए आम तौर पर यह आवश्यक है कि स्रोत कोड में निर्दिष्ट पठन और लेखन बिना किसी चूक के निर्दिष्ट सटीक क्रम में हो। कंपाइलर द्वारा पढ़ने और लिखने की चूक या पुनर्क्रमण प्रोग्राम और मेमोरी-मैप्ड I/O द्वारा एक्सेस किए गए डिवाइस के बीच संचार को तोड़ देगा। एक C या C++ कंपाइलर अस्थिर मेमोरी स्थानों से पढ़ने और लिखने को नहीं छोड़ सकता है, न ही यह उसी अस्थिर स्थान (चर) के लिए ऐसे अन्य कार्यों के सापेक्ष पढ़ने/लिखने को पुन: व्यवस्थित कर सकता है। कीवर्ड volatile does not guarantee a memory barrier कैश-स्थिरता लागू करने के लिए। इसलिए, का उपयोग volatile सभी सिस्टम और प्रोसेसर पर अंतर-थ्रेड संचार के लिए एक वेरिएबल का उपयोग करने के लिए अकेले पर्याप्त नहीं है।^[3] C11 और C++11 से पहले के C और C++ मानक एकाधिक थ्रेड (या एकाधिक प्रोसेसर) को संबोधित नहीं करते हैं,^[4] और इस प्रकार, की उपयोगिता volatile कंपाइलर और हार्डवेयर पर निर्भर करता है। हालांकि volatile गारंटी देता है कि अस्थिर पढ़ना और अस्थिर लिखना स्रोत कोड में निर्दिष्ट सटीक क्रम में होगा, कंपाइलर कोड उत्पन्न कर सकता है (या सीपीयू निष्पादन को फिर से ऑर्डर कर सकता है) जैसे कि एक अस्थिर पढ़ने या लिखने को गैर के संबंध में फिर से व्यवस्थित किया जाता है। अस्थिर पढ़ता या लिखता है, इस प्रकार इंटर-थ्रेड फ़्लैग या म्यूटेक्स के रूप में इसकी उपयोगिता सीमित हो जाती है।

यह भी देखें

संदर्भ

↑ May, Cathy; Silha, Ed; Simpson, Eick; Warren, Hank (1993). The PowerPC Architecture: A Specification for a New Family of RISC Processors. Morgan Kaufmann Publishers. p. 350. ISBN 1-55860-316-6.
↑ Kacmarcik, Cary (1995). पावरपीसी कोड का अनुकूलन. Addison-Wesley Publishing Company. p. 188. ISBN 0-201-40839-2.
↑ Corbet, Jonathan. "'अस्थिर' प्रकार के वर्ग का उपयोग क्यों नहीं किया जाना चाहिए?". Kernel.org. Retrieved April 13, 2023.
↑ Boehm, Hans (June 2005). थ्रेड्स को लाइब्रेरी के रूप में कार्यान्वित नहीं किया जा सकता. Proceedings of the 2005 ACM SIGPLAN conference on Programming language design and implementation. Association for Computing Machinery. p. 261. CiteSeerX 10.1.1.308.5939. doi:10.1145/1065010.1065042. ISBN 1595930566.

बाहरी संबंध

[1] May, Cathy; Silha, Ed; Simpson, Eick; Warren, Hank (1993). The PowerPC Architecture: A Specification for a New Family of RISC Processors. Morgan Kaufmann Publishers. p. 350. ISBN 1-55860-316-6.

[2] Kacmarcik, Cary (1995). पावरपीसी कोड का अनुकूलन. Addison-Wesley Publishing Company. p. 188. ISBN 0-201-40839-2.

[3] Corbet, Jonathan. "'अस्थिर' प्रकार के वर्ग का उपयोग क्यों नहीं किया जाना चाहिए?". Kernel.org. Retrieved April 13, 2023.

[4] Boehm, Hans (June 2005). थ्रेड्स को लाइब्रेरी के रूप में कार्यान्वित नहीं किया जा सकता. Proceedings of the 2005 ACM SIGPLAN conference on Programming language design and implementation. Association for Computing Machinery. p. 261. CiteSeerX 10.1.1.308.5939. doi:10.1145/1065010.1065042. ISBN 1595930566.

[1]

[2]

[3]

[4]