स्टैक-आधारित मेमोरी आवंटन: Difference between revisions

From Vigyanwiki
(Created page with "{{Short description|Form of computer memory allocation}} {{Other uses|Stack (disambiguation)}} {{Multiple issues| {{More citations needed|date=June 2022}} {{Original research...")
 
No edit summary
Line 1: Line 1:
{{Short description|Form of computer memory allocation}}
{{Short description|Form of computer memory allocation}}
{{Other uses|Stack (disambiguation)}}
{{Other uses|Stack (disambiguation)}}[[File:ProgramCallStack2 en.svg|thumb|350px|right|नेस्टेड प्रक्रिया कॉल के लिए स्थानीय [[आंकड़े]] और कॉल जानकारी संग्रहीत करने वाला विशिष्ट स्टैक (जरूरी नहीं कि [[नेस्टेड समारोह]])। यह ढेर अपने मूल स्थान से नीचे की ओर बढ़ता है। स्टैक पॉइंटर स्टैक पर वर्तमान शीर्षतम डेटा को इंगित करता है। पुश ऑपरेशन पॉइंटर को घटाता है और डेटा को स्टैक पर कॉपी करता है; पॉप ऑपरेशन स्टैक से डेटा कॉपी करता है और फिर पॉइंटर को बढ़ाता है। प्रोग्राम में बुलाई जाने वाली प्रत्येक प्रक्रिया स्टैक पर पुश करके प्रक्रिया वापसी जानकारी (पीले रंग में) और स्थानीय डेटा (अन्य रंगों में) को संग्रहीत करती है।]]स्टैक (अमूर्त डेटा प्रकार) #Hardware_stacks कंप्यूटिंग आर्किटेक्चर में [[मेमोरी (कंप्यूटर)]] के क्षेत्र हैं जहां डेटा को LIFO (कंप्यूटिंग) | लास्ट-इन-फर्स्ट-आउट (LIFO) तरीके से जोड़ा या हटाया जाता है।


{{Multiple issues|
अधिकांश आधुनिक कंप्यूटर प्रणालियों में, प्रत्येक थ्रेड (कंप्यूटर विज्ञान) में मेमोरी का आरक्षित क्षेत्र होता है जिसे स्टैक कहा जाता है। जब कोई फ़ंक्शन निष्पादित होता है, तो यह अपने कुछ स्थानीय राज्य डेटा को स्टैक के शीर्ष पर जोड़ सकता है; जब फ़ंक्शन बाहर निकलता है तो वह उस डेटा को स्टैक से हटाने के लिए ज़िम्मेदार होता है। कम से कम, थ्रेड के स्टैक का उपयोग कॉलर द्वारा प्रदान किए गए रिटर्न एड्रेस के स्थान को स्टोर करने के लिए किया जाता है ताकि रिटर्न स्टेटमेंट सही स्थान पर वापस आ सके।
{{More citations needed|date=June 2022}}
{{Original research|date=June 2022}}
}}
[[File:ProgramCallStack2 en.svg|thumb|350px|right|नेस्टेड प्रक्रिया कॉल के लिए स्थानीय [[आंकड़े]] और कॉल जानकारी संग्रहीत करने वाला एक विशिष्ट स्टैक (जरूरी नहीं कि [[नेस्टेड समारोह]])। यह ढेर अपने मूल स्थान से नीचे की ओर बढ़ता है। स्टैक पॉइंटर स्टैक पर वर्तमान शीर्षतम डेटा को इंगित करता है। एक पुश ऑपरेशन पॉइंटर को घटाता है और डेटा को स्टैक पर कॉपी करता है; एक पॉप ऑपरेशन स्टैक से डेटा कॉपी करता है और फिर पॉइंटर को बढ़ाता है। प्रोग्राम में बुलाई जाने वाली प्रत्येक प्रक्रिया स्टैक पर पुश करके प्रक्रिया वापसी जानकारी (पीले रंग में) और स्थानीय डेटा (अन्य रंगों में) को संग्रहीत करती है।]]स्टैक (अमूर्त डेटा प्रकार) #Hardware_stacks कंप्यूटिंग आर्किटेक्चर में [[मेमोरी (कंप्यूटर)]] के क्षेत्र हैं जहां डेटा को LIFO (कंप्यूटिंग) | लास्ट-इन-फर्स्ट-आउट (LIFO) तरीके से जोड़ा या हटाया जाता है।


अधिकांश आधुनिक कंप्यूटर प्रणालियों में, प्रत्येक थ्रेड (कंप्यूटर विज्ञान) में मेमोरी का एक आरक्षित क्षेत्र होता है जिसे स्टैक कहा जाता है। जब कोई फ़ंक्शन निष्पादित होता है, तो यह अपने कुछ स्थानीय राज्य डेटा को स्टैक के शीर्ष पर जोड़ सकता है; जब फ़ंक्शन बाहर निकलता है तो वह उस डेटा को स्टैक से हटाने के लिए ज़िम्मेदार होता है। कम से कम, थ्रेड के स्टैक का उपयोग कॉलर द्वारा प्रदान किए गए रिटर्न एड्रेस के स्थान को स्टोर करने के लिए किया जाता है ताकि रिटर्न स्टेटमेंट सही स्थान पर वापस आ सके।
स्टैक का उपयोग अक्सर वर्तमान में सक्रिय कार्यों के लिए स्थानीय निश्चित लंबाई के चर को संग्रहीत करने के लिए किया जाता है। प्रोग्रामर आगे चर लंबाई के स्थानीय डेटा को स्टोर करने के लिए स्टैक का स्पष्ट रूप से उपयोग करना चुन सकते हैं। यदि मेमोरी का क्षेत्र थ्रेड के स्टैक पर स्थित है, तो कहा जाता है कि मेमोरी को स्टैक पर आवंटित किया गया है, यानी स्टैक-आधारित मेमोरी एलोकेशन (एसबीएमए)। यह [[हीप-आधारित मेमोरी आवंटन]] (HBMA) के विपरीत है। एसबीएमए अक्सर कॉल स्टैक # कॉल स्टैक के कार्यों के साथ निकटता से जुड़ा होता है।
 
स्टैक का उपयोग अक्सर वर्तमान में सक्रिय कार्यों के लिए स्थानीय निश्चित लंबाई के चर को संग्रहीत करने के लिए किया जाता है। प्रोग्रामर आगे चर लंबाई के स्थानीय डेटा को स्टोर करने के लिए स्टैक का स्पष्ट रूप से उपयोग करना चुन सकते हैं। यदि मेमोरी का एक क्षेत्र थ्रेड के स्टैक पर स्थित है, तो कहा जाता है कि मेमोरी को स्टैक पर आवंटित किया गया है, यानी स्टैक-आधारित मेमोरी एलोकेशन (एसबीएमए)। यह [[हीप-आधारित मेमोरी आवंटन]] (HBMA) के विपरीत है। एसबीएमए अक्सर कॉल स्टैक # कॉल स्टैक के कार्यों के साथ निकटता से जुड़ा होता है।


== फायदे और नुकसान ==
== फायदे और नुकसान ==
क्योंकि डेटा को लास्ट-इन-फर्स्ट-आउट तरीके से जोड़ा और हटाया जाता है, स्टैक-आधारित मेमोरी एलोकेशन बहुत सरल है और आमतौर पर हीप-आधारित मेमोरी एलोकेशन ([[गतिशील स्मृति आवंटन]] के रूप में भी जाना जाता है) की तुलना में बहुत तेज़ है। [[ सी (प्रोग्रामिंग भाषा) ]]। {{code|malloc}}.
क्योंकि डेटा को लास्ट-इन-फर्स्ट-आउट तरीके से जोड़ा और हटाया जाता है, स्टैक-आधारित मेमोरी एलोकेशन बहुत सरल है और आमतौर पर हीप-आधारित मेमोरी एलोकेशन ([[गतिशील स्मृति आवंटन]] के रूप में भी जाना जाता है) की तुलना में बहुत तेज़ है। [[ सी (प्रोग्रामिंग भाषा) |सी (प्रोग्रामिंग भाषा)]] । {{code|malloc}}.


एक अन्य विशेषता यह है कि स्टैक पर मेमोरी स्वचालित रूप से और बहुत कुशलता से, फ़ंक्शन से बाहर निकलने पर पुनः प्राप्त होती है, जो प्रोग्रामर के लिए सुविधाजनक हो सकती है यदि डेटा की आवश्यकता नहीं है।<ref>{{cite web |title=एलोका के फायदे|url=https://www.gnu.org/software/libc/manual/html_node/Advantages-of-Alloca.html |website=The GNU C Library}}</ref> (यही बात setjmp.h पर भी लागू होती है अगर यह कॉल करने से पहले एक बिंदु पर चली जाती है {{code|alloca}} हुआ।) हालांकि, यदि डेटा को किसी रूप में रखने की आवश्यकता है, तो फ़ंक्शन से बाहर निकलने से पहले इसे स्टैक से हीप में कॉपी किया जाना चाहिए। इसलिए, स्टैक आधारित आवंटन अस्थायी डेटा या डेटा के लिए उपयुक्त है जो वर्तमान फ़ंक्शन के बाहर निकलने के बाद आवश्यक नहीं है।
एक अन्य विशेषता यह है कि स्टैक पर मेमोरी स्वचालित रूप से और बहुत कुशलता से, फ़ंक्शन से बाहर निकलने पर पुनः प्राप्त होती है, जो प्रोग्रामर के लिए सुविधाजनक हो सकती है यदि डेटा की आवश्यकता नहीं है।<ref>{{cite web |title=एलोका के फायदे|url=https://www.gnu.org/software/libc/manual/html_node/Advantages-of-Alloca.html |website=The GNU C Library}}</ref> (यही बात setjmp.h पर भी लागू होती है अगर यह कॉल करने से पहले बिंदु पर चली जाती है {{code|alloca}} हुआ।) हालांकि, यदि डेटा को किसी रूप में रखने की आवश्यकता है, तो फ़ंक्शन से बाहर निकलने से पहले इसे स्टैक से हीप में कॉपी किया जाना चाहिए। इसलिए, स्टैक आधारित आवंटन अस्थायी डेटा या डेटा के लिए उपयुक्त है जो वर्तमान फ़ंक्शन के बाहर निकलने के बाद आवश्यक नहीं है।


एक थ्रेड का निर्धारित स्टैक आकार कुछ छोटे सीपीयू पर केवल कुछ बाइट्स जितना छोटा हो सकता है। स्टैक पर उपलब्ध मेमोरी से अधिक मेमोरी आवंटित करने से [[ स्टैक ओवरफ़्लो ]] के कारण [[क्रैश (कंप्यूटिंग)]] हो सकता है। यही कारण है कि उपयोग करने वाले कार्य {{code|alloca}} को आमतौर पर इनलाइन होने से रोका जाता है:<ref>{{cite web |title=इन - लाइन|url=http://gcc.gnu.org/onlinedocs/gcc/Inline.html |website=Using the GNU Compiler Collection (GCC)}}</ref> क्या इस तरह के फ़ंक्शन को एक लूप में रेखांकित किया जाना चाहिए, कॉल करने वाले को ढेर के उपयोग में अप्रत्याशित वृद्धि से पीड़ित होना चाहिए, जिससे अतिप्रवाह अधिक होने की संभावना है।
एक थ्रेड का निर्धारित स्टैक आकार कुछ छोटे सीपीयू पर केवल कुछ बाइट्स जितना छोटा हो सकता है। स्टैक पर उपलब्ध मेमोरी से अधिक मेमोरी आवंटित करने से [[ स्टैक ओवरफ़्लो |स्टैक ओवरफ़्लो]] के कारण [[क्रैश (कंप्यूटिंग)]] हो सकता है। यही कारण है कि उपयोग करने वाले कार्य {{code|alloca}} को आमतौर पर इनलाइन होने से रोका जाता है:<ref>{{cite web |title=इन - लाइन|url=http://gcc.gnu.org/onlinedocs/gcc/Inline.html |website=Using the GNU Compiler Collection (GCC)}}</ref> क्या इस तरह के फ़ंक्शन को लूप में रेखांकित किया जाना चाहिए, कॉल करने वाले को ढेर के उपयोग में अप्रत्याशित वृद्धि से पीड़ित होना चाहिए, जिससे अतिप्रवाह अधिक होने की संभावना है।


स्टैक-आधारित आवंटन मामूली प्रदर्शन समस्याएं भी पैदा कर सकता है: यह चर-आकार के स्टैक फ़्रेमों की ओर जाता है, ताकि दोनों कॉल स्टैक#STACK-POINTER को प्रबंधित करने की आवश्यकता हो (निश्चित आकार के स्टैक फ़्रेमों के साथ, स्टैक पॉइंटर बेमानी है क्योंकि ढेर फ्रेम सूचक प्रत्येक फ्रेम के आकार से)। यह आमतौर पर कॉल करने की तुलना में बहुत कम खर्चीला होता है {{code|malloc}} और {{code|free}} फिर भी। विशेष रूप से, यदि वर्तमान फ़ंक्शन में एलोका और चर-लंबाई वाले स्थानीय डेटा वाले ब्लॉक दोनों कॉल शामिल हैं, तो वर्तमान स्टैक फ्रेम को बढ़ाने के लिए एलोका के प्रयासों के बीच एक संघर्ष होता है, जब तक कि वर्तमान फ़ंक्शन बाहर नहीं निकलता है बनाम संकलक की चर लंबाई के स्थानीय चर को रखने की आवश्यकता होती है। ढेर फ्रेम में एक ही स्थान। एलोका को प्रत्येक कॉल के लिए ढेर भंडारण की एक अलग श्रृंखला बनाकर इस विरोध को आम तौर पर हल किया जाता है।<ref>{{cite web | url=https://code.woboq.org/gcc/libiberty/alloca.c.html | title=Alloca.c source code &#91;libiberty/Alloca.c&#93; - Codebrowser }}</ref> श्रृंखला स्टैक की गहराई को रिकॉर्ड करती है जिस पर प्रत्येक आवंटन होता है, बाद में किसी भी फ़ंक्शन में एलोका को कॉल करता है, इस श्रृंखला को वर्तमान स्टैक गहराई तक ट्रिम कर देता है ताकि अंततः (लेकिन तुरंत नहीं) इस श्रृंखला पर कोई भंडारण मुक्त हो सके। शून्य के तर्क के साथ एलोका को कॉल करने के लिए भी ऐसी मेमोरी आवंटित किए बिना स्मृति को मुक्त करने के लिए उपयोग किया जा सकता है। एलोका और स्थानीय चर भंडारण के बीच इस संघर्ष के परिणामस्वरूप, एलोका का उपयोग करना मॉलोक का उपयोग करने से अधिक कुशल नहीं हो सकता है।
स्टैक-आधारित आवंटन मामूली प्रदर्शन समस्याएं भी पैदा कर सकता है: यह चर-आकार के स्टैक फ़्रेमों की ओर जाता है, ताकि दोनों कॉल स्टैक#STACK-POINTER को प्रबंधित करने की आवश्यकता हो (निश्चित आकार के स्टैक फ़्रेमों के साथ, स्टैक पॉइंटर बेमानी है क्योंकि ढेर फ्रेम सूचक प्रत्येक फ्रेम के आकार से)। यह आमतौर पर कॉल करने की तुलना में बहुत कम खर्चीला होता है {{code|malloc}} और {{code|free}} फिर भी। विशेष रूप से, यदि वर्तमान फ़ंक्शन में एलोका और चर-लंबाई वाले स्थानीय डेटा वाले ब्लॉक दोनों कॉल शामिल हैं, तो वर्तमान स्टैक फ्रेम को बढ़ाने के लिए एलोका के प्रयासों के बीच संघर्ष होता है, जब तक कि वर्तमान फ़ंक्शन बाहर नहीं निकलता है बनाम संकलक की चर लंबाई के स्थानीय चर को रखने की आवश्यकता होती है। ढेर फ्रेम में ही स्थान। एलोका को प्रत्येक कॉल के लिए ढेर भंडारण की अलग श्रृंखला बनाकर इस विरोध को आम तौर पर हल किया जाता है।<ref>{{cite web | url=https://code.woboq.org/gcc/libiberty/alloca.c.html | title=Alloca.c source code &#91;libiberty/Alloca.c&#93; - Codebrowser }}</ref> श्रृंखला स्टैक की गहराई को रिकॉर्ड करती है जिस पर प्रत्येक आवंटन होता है, बाद में किसी भी फ़ंक्शन में एलोका को कॉल करता है, इस श्रृंखला को वर्तमान स्टैक गहराई तक ट्रिम कर देता है ताकि अंततः (लेकिन तुरंत नहीं) इस श्रृंखला पर कोई भंडारण मुक्त हो सके। शून्य के तर्क के साथ एलोका को कॉल करने के लिए भी ऐसी मेमोरी आवंटित किए बिना स्मृति को मुक्त करने के लिए उपयोग किया जा सकता है। एलोका और स्थानीय चर भंडारण के बीच इस संघर्ष के परिणामस्वरूप, एलोका का उपयोग करना मॉलोक का उपयोग करने से अधिक कुशल नहीं हो सकता है।


== सिस्टम इंटरफ़ेस ==
== सिस्टम इंटरफ़ेस ==
कई यूनिक्स-जैसी प्रणालियाँ और साथ ही [[ माइक्रोसॉफ़्ट विंडोज़ ]]़ नामक एक कार्य को लागू करते हैं {{code|alloca}} हीप-आधारित के समान स्टैक मेमोरी को गतिशील रूप से आवंटित करने के लिए <code>[[malloc]]</code>. एक कंपाइलर आमतौर पर इसे स्टैक पॉइंटर में हेरफेर करने वाले इनलाइन निर्देशों में अनुवाद करता है, जैसा कि [[चर-लंबाई सरणी]] को हैंडल किया जाता है।<ref>{{man|3|alloca|Linux}}</ref> हालाँकि मेमोरी को स्पष्ट रूप से मुक्त करने की कोई आवश्यकता नहीं है, स्टैक ओवरफ़्लो के कारण अपरिभाषित व्यवहार का जोखिम है।<ref>{{Cite web|title = Why is the use of alloca() not considered good practice?|url = https://stackoverflow.com/questions/1018853/why-is-the-use-of-alloca-not-considered-good-practice|website = stackoverflow.com|accessdate = 2016-01-05}}</ref> यह कार्य UNIX/32V|32/V (1978) से ही यूनिक्स सिस्टम पर मौजूद था, लेकिन यह मानक C या किसी [[POSIX]] मानक का हिस्सा नहीं है।
कई यूनिक्स-जैसी प्रणालियाँ और साथ ही [[ माइक्रोसॉफ़्ट विंडोज़ |माइक्रोसॉफ़्ट विंडोज़]] ़ नामक कार्य को लागू करते हैं {{code|alloca}} हीप-आधारित के समान स्टैक मेमोरी को गतिशील रूप से आवंटित करने के लिए <code>[[malloc]]</code>. कंपाइलर आमतौर पर इसे स्टैक पॉइंटर में हेरफेर करने वाले इनलाइन निर्देशों में अनुवाद करता है, जैसा कि [[चर-लंबाई सरणी]] को हैंडल किया जाता है।<ref>{{man|3|alloca|Linux}}</ref> हालाँकि मेमोरी को स्पष्ट रूप से मुक्त करने की कोई आवश्यकता नहीं है, स्टैक ओवरफ़्लो के कारण अपरिभाषित व्यवहार का जोखिम है।<ref>{{Cite web|title = Why is the use of alloca() not considered good practice?|url = https://stackoverflow.com/questions/1018853/why-is-the-use-of-alloca-not-considered-good-practice|website = stackoverflow.com|accessdate = 2016-01-05}}</ref> यह कार्य UNIX/32V|32/V (1978) से ही यूनिक्स सिस्टम पर मौजूद था, लेकिन यह मानक C या किसी [[POSIX]] मानक का हिस्सा नहीं है।


का एक सुरक्षित संस्करण {{code|alloca}} बुलाया {{code|_malloca}}, जो त्रुटियों की रिपोर्ट करता है, Microsoft Windows पर मौजूद है। इसके उपयोग की आवश्यकता है {{code|_freea}}.<ref>{{cite web |title=_malloca |url=https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/malloca?view=vs-2019 |website=Microsoft CRT Documentation |language=en-us}}</ref> [[gnulib]] समतुल्य इंटरफ़ेस प्रदान करता है, हालांकि अतिप्रवाह पर एसईएच अपवाद फेंकने के बजाय, यह प्रतिनिधि करता है {{code|malloc}} जब बड़े आकार का पता चलता है।<ref>{{cite web |title=gnulib/malloca.h |url=https://github.com/coreutils/gnulib/blob/master/lib/malloca.h |website=GitHub |accessdate=24 November 2019}}</ref> इसी तरह की सुविधा को मैन्युअल लेखा और आकार-जांच का उपयोग करके अनुकरण किया जा सकता है, जैसे कि उपयोग में {{code|alloca_account}} ग्लिब में।<ref>{{cite web |title=glibc/include/alloca.h |url=https://github.com/bminor/glibc/blob/780684eb04298977bc411ebca1eadeeba4877833/include/alloca.h |publisher=Beren Minor's Mirrors |date=23 November 2019}}</ref>
का सुरक्षित संस्करण {{code|alloca}} बुलाया {{code|_malloca}}, जो त्रुटियों की रिपोर्ट करता है, Microsoft Windows पर मौजूद है। इसके उपयोग की आवश्यकता है {{code|_freea}}.<ref>{{cite web |title=_malloca |url=https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/malloca?view=vs-2019 |website=Microsoft CRT Documentation |language=en-us}}</ref> [[gnulib]] समतुल्य इंटरफ़ेस प्रदान करता है, हालांकि अतिप्रवाह पर एसईएच अपवाद फेंकने के बजाय, यह प्रतिनिधि करता है {{code|malloc}} जब बड़े आकार का पता चलता है।<ref>{{cite web |title=gnulib/malloca.h |url=https://github.com/coreutils/gnulib/blob/master/lib/malloca.h |website=GitHub |accessdate=24 November 2019}}</ref> इसी तरह की सुविधा को मैन्युअल लेखा और आकार-जांच का उपयोग करके अनुकरण किया जा सकता है, जैसे कि उपयोग में {{code|alloca_account}} ग्लिब में।<ref>{{cite web |title=glibc/include/alloca.h |url=https://github.com/bminor/glibc/blob/780684eb04298977bc411ebca1eadeeba4877833/include/alloca.h |publisher=Beren Minor's Mirrors |date=23 November 2019}}</ref>
कुछ प्रोसेसर परिवारों, जैसे कि x[[86]], के पास वर्तमान में निष्पादित थ्रेड के ढेर में हेरफेर करने के लिए विशेष निर्देश हैं। [[PowerPC]] और MIPS आर्किटेक्चर सहित अन्य प्रोसेसर परिवारों के पास स्पष्ट स्टैक समर्थन नहीं है, बल्कि इसके बजाय सम्मेलन पर भरोसा करते हैं और ऑपरेटिंग सिस्टम के [[अनुप्रयोग बाइनरी इंटरफ़ेस]] (ABI) को स्टैक प्रबंधन सौंपते हैं।
कुछ प्रोसेसर परिवारों, जैसे कि x[[86]], के पास वर्तमान में निष्पादित थ्रेड के ढेर में हेरफेर करने के लिए विशेष निर्देश हैं। [[PowerPC]] और MIPS आर्किटेक्चर सहित अन्य प्रोसेसर परिवारों के पास स्पष्ट स्टैक समर्थन नहीं है, बल्कि इसके बजाय सम्मेलन पर भरोसा करते हैं और ऑपरेटिंग सिस्टम के [[अनुप्रयोग बाइनरी इंटरफ़ेस]] (ABI) को स्टैक प्रबंधन सौंपते हैं।


=== ऑटो वीएलए ===
=== ऑटो वीएलए ===
इसके अलावा, C संस्करण C99 (C11 के बाद से वैकल्पिक) के बाद से, एक फ़ंक्शन के भीतर स्टैक पर एक सरणी बनाना संभव है, स्वचालित रूप से, एक ऑटो VLA (चर-लंबाई सरणी) के रूप में जाना जाता है।<ref name="C99">{{cite web |title=ISO C 99 Definition |url=http://www.dii.uchile.cl/~daespino/files/Iso_C_1999_definition.pdf |access-date=2022-04-10 |ref=6.5.7.2}}</ref>
इसके अलावा, C संस्करण C99 (C11 के बाद से वैकल्पिक) के बाद से, फ़ंक्शन के भीतर स्टैक पर सरणी बनाना संभव है, स्वचालित रूप से, ऑटो VLA (चर-लंबाई सरणी) के रूप में जाना जाता है।<ref name="C99">{{cite web |title=ISO C 99 Definition |url=http://www.dii.uchile.cl/~daespino/files/Iso_C_1999_definition.pdf |access-date=2022-04-10 |ref=6.5.7.2}}</ref>


<syntaxhighlight lang="c">
<syntaxhighlight lang="c">
Line 41: Line 35:
}
}
</syntaxhighlight>
</syntaxhighlight>


== यह भी देखें ==
== यह भी देखें ==

Revision as of 14:03, 27 June 2023

नेस्टेड प्रक्रिया कॉल के लिए स्थानीय आंकड़े और कॉल जानकारी संग्रहीत करने वाला विशिष्ट स्टैक (जरूरी नहीं कि नेस्टेड समारोह)। यह ढेर अपने मूल स्थान से नीचे की ओर बढ़ता है। स्टैक पॉइंटर स्टैक पर वर्तमान शीर्षतम डेटा को इंगित करता है। पुश ऑपरेशन पॉइंटर को घटाता है और डेटा को स्टैक पर कॉपी करता है; पॉप ऑपरेशन स्टैक से डेटा कॉपी करता है और फिर पॉइंटर को बढ़ाता है। प्रोग्राम में बुलाई जाने वाली प्रत्येक प्रक्रिया स्टैक पर पुश करके प्रक्रिया वापसी जानकारी (पीले रंग में) और स्थानीय डेटा (अन्य रंगों में) को संग्रहीत करती है।

स्टैक (अमूर्त डेटा प्रकार) #Hardware_stacks कंप्यूटिंग आर्किटेक्चर में मेमोरी (कंप्यूटर) के क्षेत्र हैं जहां डेटा को LIFO (कंप्यूटिंग) | लास्ट-इन-फर्स्ट-आउट (LIFO) तरीके से जोड़ा या हटाया जाता है।

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

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

फायदे और नुकसान

क्योंकि डेटा को लास्ट-इन-फर्स्ट-आउट तरीके से जोड़ा और हटाया जाता है, स्टैक-आधारित मेमोरी एलोकेशन बहुत सरल है और आमतौर पर हीप-आधारित मेमोरी एलोकेशन (गतिशील स्मृति आवंटन के रूप में भी जाना जाता है) की तुलना में बहुत तेज़ है। सी (प्रोग्रामिंग भाषा)malloc.

एक अन्य विशेषता यह है कि स्टैक पर मेमोरी स्वचालित रूप से और बहुत कुशलता से, फ़ंक्शन से बाहर निकलने पर पुनः प्राप्त होती है, जो प्रोग्रामर के लिए सुविधाजनक हो सकती है यदि डेटा की आवश्यकता नहीं है।[1] (यही बात setjmp.h पर भी लागू होती है अगर यह कॉल करने से पहले बिंदु पर चली जाती है alloca हुआ।) हालांकि, यदि डेटा को किसी रूप में रखने की आवश्यकता है, तो फ़ंक्शन से बाहर निकलने से पहले इसे स्टैक से हीप में कॉपी किया जाना चाहिए। इसलिए, स्टैक आधारित आवंटन अस्थायी डेटा या डेटा के लिए उपयुक्त है जो वर्तमान फ़ंक्शन के बाहर निकलने के बाद आवश्यक नहीं है।

एक थ्रेड का निर्धारित स्टैक आकार कुछ छोटे सीपीयू पर केवल कुछ बाइट्स जितना छोटा हो सकता है। स्टैक पर उपलब्ध मेमोरी से अधिक मेमोरी आवंटित करने से स्टैक ओवरफ़्लो के कारण क्रैश (कंप्यूटिंग) हो सकता है। यही कारण है कि उपयोग करने वाले कार्य alloca को आमतौर पर इनलाइन होने से रोका जाता है:[2] क्या इस तरह के फ़ंक्शन को लूप में रेखांकित किया जाना चाहिए, कॉल करने वाले को ढेर के उपयोग में अप्रत्याशित वृद्धि से पीड़ित होना चाहिए, जिससे अतिप्रवाह अधिक होने की संभावना है।

स्टैक-आधारित आवंटन मामूली प्रदर्शन समस्याएं भी पैदा कर सकता है: यह चर-आकार के स्टैक फ़्रेमों की ओर जाता है, ताकि दोनों कॉल स्टैक#STACK-POINTER को प्रबंधित करने की आवश्यकता हो (निश्चित आकार के स्टैक फ़्रेमों के साथ, स्टैक पॉइंटर बेमानी है क्योंकि ढेर फ्रेम सूचक प्रत्येक फ्रेम के आकार से)। यह आमतौर पर कॉल करने की तुलना में बहुत कम खर्चीला होता है malloc और free फिर भी। विशेष रूप से, यदि वर्तमान फ़ंक्शन में एलोका और चर-लंबाई वाले स्थानीय डेटा वाले ब्लॉक दोनों कॉल शामिल हैं, तो वर्तमान स्टैक फ्रेम को बढ़ाने के लिए एलोका के प्रयासों के बीच संघर्ष होता है, जब तक कि वर्तमान फ़ंक्शन बाहर नहीं निकलता है बनाम संकलक की चर लंबाई के स्थानीय चर को रखने की आवश्यकता होती है। ढेर फ्रेम में ही स्थान। एलोका को प्रत्येक कॉल के लिए ढेर भंडारण की अलग श्रृंखला बनाकर इस विरोध को आम तौर पर हल किया जाता है।[3] श्रृंखला स्टैक की गहराई को रिकॉर्ड करती है जिस पर प्रत्येक आवंटन होता है, बाद में किसी भी फ़ंक्शन में एलोका को कॉल करता है, इस श्रृंखला को वर्तमान स्टैक गहराई तक ट्रिम कर देता है ताकि अंततः (लेकिन तुरंत नहीं) इस श्रृंखला पर कोई भंडारण मुक्त हो सके। शून्य के तर्क के साथ एलोका को कॉल करने के लिए भी ऐसी मेमोरी आवंटित किए बिना स्मृति को मुक्त करने के लिए उपयोग किया जा सकता है। एलोका और स्थानीय चर भंडारण के बीच इस संघर्ष के परिणामस्वरूप, एलोका का उपयोग करना मॉलोक का उपयोग करने से अधिक कुशल नहीं हो सकता है।

सिस्टम इंटरफ़ेस

कई यूनिक्स-जैसी प्रणालियाँ और साथ ही माइक्रोसॉफ़्ट विंडोज़ ़ नामक कार्य को लागू करते हैं alloca हीप-आधारित के समान स्टैक मेमोरी को गतिशील रूप से आवंटित करने के लिए malloc. कंपाइलर आमतौर पर इसे स्टैक पॉइंटर में हेरफेर करने वाले इनलाइन निर्देशों में अनुवाद करता है, जैसा कि चर-लंबाई सरणी को हैंडल किया जाता है।[4] हालाँकि मेमोरी को स्पष्ट रूप से मुक्त करने की कोई आवश्यकता नहीं है, स्टैक ओवरफ़्लो के कारण अपरिभाषित व्यवहार का जोखिम है।[5] यह कार्य UNIX/32V|32/V (1978) से ही यूनिक्स सिस्टम पर मौजूद था, लेकिन यह मानक C या किसी POSIX मानक का हिस्सा नहीं है।

का सुरक्षित संस्करण alloca बुलाया _malloca, जो त्रुटियों की रिपोर्ट करता है, Microsoft Windows पर मौजूद है। इसके उपयोग की आवश्यकता है _freea.[6] gnulib समतुल्य इंटरफ़ेस प्रदान करता है, हालांकि अतिप्रवाह पर एसईएच अपवाद फेंकने के बजाय, यह प्रतिनिधि करता है malloc जब बड़े आकार का पता चलता है।[7] इसी तरह की सुविधा को मैन्युअल लेखा और आकार-जांच का उपयोग करके अनुकरण किया जा सकता है, जैसे कि उपयोग में alloca_account ग्लिब में।[8] कुछ प्रोसेसर परिवारों, जैसे कि x86, के पास वर्तमान में निष्पादित थ्रेड के ढेर में हेरफेर करने के लिए विशेष निर्देश हैं। PowerPC और MIPS आर्किटेक्चर सहित अन्य प्रोसेसर परिवारों के पास स्पष्ट स्टैक समर्थन नहीं है, बल्कि इसके बजाय सम्मेलन पर भरोसा करते हैं और ऑपरेटिंग सिस्टम के अनुप्रयोग बाइनरी इंटरफ़ेस (ABI) को स्टैक प्रबंधन सौंपते हैं।

ऑटो वीएलए

इसके अलावा, C संस्करण C99 (C11 के बाद से वैकल्पिक) के बाद से, फ़ंक्शन के भीतर स्टैक पर सरणी बनाना संभव है, स्वचालित रूप से, ऑटो VLA (चर-लंबाई सरणी) के रूप में जाना जाता है।[9]

void f(int alen)
{
  int b[alen]; // auto VLA - this array's length is set at 
               // the time of the function invocation / stack generation.
  for (int i = 0; i < alen; i++)
    b[i] = 1;
  // at the end of this function, b[] is within the stack frame, and will 
  // disappear when the function exits, so no explicit call to free() is required.
}

यह भी देखें

संदर्भ

  1. "एलोका के फायदे". The GNU C Library.
  2. "इन - लाइन". Using the GNU Compiler Collection (GCC).
  3. "Alloca.c source code [libiberty/Alloca.c] - Codebrowser".
  4. alloca(3) – Linux Programmer's Manual – Library Functions
  5. "Why is the use of alloca() not considered good practice?". stackoverflow.com. Retrieved 2016-01-05.
  6. "_malloca". Microsoft CRT Documentation (in English).
  7. "gnulib/malloca.h". GitHub. Retrieved 24 November 2019.
  8. "glibc/include/alloca.h". Beren Minor's Mirrors. 23 November 2019.
  9. "ISO C 99 Definition" (PDF). Retrieved 2022-04-10.