कॉलिन वाल्स से RTOS के बारे में पूरी सच्चाई। अनुच्छेद # 4 कार्य, संदर्भ स्विचिंग, और व्यवधान

टास्क की पहचान करने वाले

आपको सिस्टम में प्रत्येक कार्य की पहचान करने में सक्षम होना चाहिए। यह आवश्यकता अन्य कर्नेल ऑब्जेक्ट के लिए महत्वपूर्ण है, लेकिन इस लेख के विषय के अनुरूप कार्यों में कुछ बारीकियां हैं।



आरटीओएस डेवलपर्स कार्यों की पहचान करने के लिए विभिन्न तरीकों का उपयोग करते हैं, लेकिन चार सामान्य रणनीतियों को प्रतिष्ठित किया जा सकता है:

• कार्य को "कंट्रोल ब्लॉक" के लिए पॉइंटर का उपयोग करके पहचाना जाता है। पॉइंटर्स हमेशा अद्वितीय होते हैं और उपयोग करने के लिए सुविधाजनक भी होते हैं, क्योंकि कई एपीआई कॉल के लिए कंट्रोल यूनिट तक पहुंच आवश्यक होती है। इसका तात्पर्य यह है कि सभी कार्य डेटा को रैंडम एक्सेस मेमोरी (रैम) में संग्रहीत किया जाता है, जो अक्षम हो सकता है। एक सूचक आमतौर पर लगभग 32 बिट मेमोरी लेता है।
• एक कार्य को एक मनमाना "इंडेक्स नंबर" का उपयोग करके परिभाषित किया जा सकता है। कुछ तालिका में रिकॉर्ड तक पहुंच प्रदान करते समय यह मान काम में आ सकता है। इस तरह के पहचानकर्ता आरटीओएस द्वारा समर्थित कार्यों की संख्या पर सीमाओं के आधार पर, मेमोरी के आठ या उससे कम बिट्स पर कब्जा कर सकते हैं।
• कुछ आरटीओएस प्राथमिकता के स्तर के अनुसार केवल एक कार्य की अनुमति देते हैं और इसलिए किसी कार्य को विशिष्ट रूप से पहचानने के लिए प्राथमिकता का उपयोग करते हैं। इसका मतलब है कि कार्य की प्राथमिकता को बदला नहीं जा सकता है। यह दृष्टिकोण पिछले दृष्टिकोण की भिन्नता है।
• कार्य में ऐसे नाम हो सकते हैं जो वर्ण के तार हों। यह डिबगिंग के लिए उपयोगी हो सकता है, लेकिन किसी कार्य को विशिष्ट रूप से पहचानने का एक प्रभावी साधन होने की संभावना नहीं है। RTOS जो कार्य के नामकरण का समर्थन करते हैं, उनके पास आम तौर पर एक अतिरिक्त पहचानकर्ता (जैसे एक सूचक) होता है, जिसका उपयोग एपीआई कॉल द्वारा किया जाता है, आदि। अधिकांश एम्बेडेड सिस्टम के लिए, टेक्स्ट नाम ओवरहेड होते हैं; एक अच्छा डिबगर आपको होस्ट पर स्थानीय रूप से उन्हें कॉल करने की अनुमति देता है।

श्रृंखला में पिछले लेख:
अनुच्छेद # ३ कार्य और योजना
अनुच्छेद # 2 आरटीओएस: संरचना और वास्तविक समय मोड
अनुच्छेद # 1। आरटीओएस: परिचय।

प्रसंग स्विच

प्रसंग स्विचिंग एक कार्य से दूसरे में नियंत्रण स्थानांतरित करने की प्रक्रिया है। यह विषय अधिक बारीकी से खोज करने के लायक है, क्योंकि संदर्भ स्विचिंग कैसे काम करता है RTOS का एक मूल सिद्धांत है।

एक कार्य क्या है?

हम जानते हैं कि एक कार्य एक अर्ध-स्वतंत्र कार्यक्रम है जो आरटीओएस के नियंत्रण में कई अन्य कार्यों के साथ प्रोसेसर समय साझा करता है। लेकिन आपको यह सोचने की जरूरत है कि वास्तव में कार्य की विशेषता क्या है।

रजिस्टर सेट करें

एक कार्य अंततः प्रोसेसर रजिस्टर मूल्यों का एक अनूठा सेट है। वे या तो प्रोसेसर रजिस्टरों में लोड होते हैं (जो कि, कार्य वर्तमान है), या निर्धारित निष्पादन समय तक कहीं संग्रहीत किया जाता है। एक आदर्श दुनिया में, एक केंद्रीय प्रोसेसर में रजिस्टरों के कई सेट होते हैं, और प्रत्येक को एक अलग कार्य सौंपा जा सकता है। यह विशेष अवसरों के लिए लागू किया गया है। कई साल पहले, टेक्सास इंस्ट्रूमेंट्स टीआई 9900 श्रृंखला में प्रत्येक काम के लिए रजिस्टरों के कई सेट थे, लेकिन उन्हें मुख्य मेमोरी में लागू किया गया था, जो कि सीमित प्रदर्शन था। SPARC आर्किटेक्चर (पहले यूनिक्स डेस्कटॉप सिस्टम पर इस्तेमाल किया गया था) "रिंग संरचना" में रजिस्टरों के कई सेटों का समर्थन करता है, लेकिन सेटों की संख्या अभी भी सीमित है।

आंतरिक डेटा

कार्य में संभवतः अपना स्वयं का स्टैक होगा, जिसका आकार प्रत्येक कार्य के लिए अलग से सेट किया जा सकता है या सिस्टम में सभी कार्यों के लिए एक वैश्विक पैरामीटर हो सकता है। यह, रजिस्टरों के साथ, विशिष्ट कार्यों के लिए डेटा भंडारण प्रदान करता है। किसी विशिष्ट कार्य के लिए डेटा संग्रहीत करने के लिए स्मृति के अन्य क्षेत्र हो सकते हैं।

साझा किए गए संसाधन

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

डेटा साझाकरण भी संभव है, लेकिन सावधानीपूर्वक पहुंच नियंत्रण आवश्यक है। आदर्श रूप में, केवल एक ही कार्य किसी भी समय डेटा का "स्वामी" है।

संदर्भ कैसे रखें

जब किसी कार्य को पुनर्निर्धारित किया जाता है (अर्थात, यह चालू होना बंद हो जाता है), इसके रजिस्टरों के सेट को कहीं और सहेजने की आवश्यकता है। कम से कम दो संभावनाएँ हैं:

• रजिस्टरों को कार्यों के लिए एक विशेष तालिका में संग्रहीत किया जा सकता है। एक टास्क कंट्रोल ब्लॉक (टीसीबी) का हिस्सा हो सकता है। आकार एक अनुमानित और निरंतर मूल्य है (एक विशिष्ट सीपीयू वास्तुकला के लिए)।
• रजिस्टरों को कार्य स्टैक पर धकेल दिया जा सकता है। इसके लिए पर्याप्त अतिरिक्त स्टैक स्थान के आवंटन और पॉइंटर के भंडारण (संभवतः टीसीबी में) की आवश्यकता होती है।

तंत्र की पसंद एक विशेष RTOS की सुविधाओं और लक्ष्य प्रोसेसर पर निर्भर करती है। कुछ (आमतौर पर 32-बिट) डिवाइस स्टैक को कुशलता से एक्सेस कर सकते हैं; बाकी (उदाहरण के लिए, 8-बिट) तालिकाओं के साथ काम करते समय अधिक इष्टतम हो सकता है।

गतिशील कार्य निर्माण

RTOS वास्तुकला का मुख्य पहलू यह है कि RTOS या तो "स्थिर" या "गतिशील" है।

एक स्थिर आरटीओएस का उपयोग करते समय, एप्लिकेशन के निर्माण के दौरान सब कुछ निर्धारित किया जाता है, विशेष रूप से, सिस्टम में कार्यों की संख्या। यह एम्बेडेड अनुप्रयोगों के लिए एक तार्किक समाधान है, जिसमें आमतौर पर सीमित कार्यक्षमता होती है।

डायनामिक RTOS एक कार्य (जो कि एक विशेष "मुख्य" कार्य हो सकता है) लॉन्च करता है, और आवश्यकतानुसार अन्य कार्यों को भी बनाता और हटाता है। यह सिस्टम को बदलती आवश्यकताओं के अनुकूल बनाने की अनुमति देता है और यह डेस्कटॉप सिस्टम का एक नजदीकी एनालॉग है, जो इस तरह से व्यवहार करता है। स्थिर / गतिशील दृश्य अन्य कर्नेल ऑब्जेक्ट पर भी लागू होता है।

डायनेमिक टास्क क्रिएशन रिक्वायरमेंट

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

यह उल्लेखनीय है कि OSEK / VDX मानक को एक स्थिर वास्तुकला की आवश्यकता होती है, भले ही यह काफी जटिल अनुप्रयोगों पर लागू हो। इन आवश्यकताओं का परिणाम एक रैपर, एक नियमित (गतिशील) आरटीओएस के शीर्ष पर एक मध्यवर्ती परत के साथ OSEK / VDX को लागू करने में असमर्थता है।

गतिशील कार्य निर्माण के नुकसान

ऑपरेशन के गतिशील मोड के साथ कई समस्याएं हैं जो परेशान कर सकती हैं।

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

संभवतः सबसे चिंताजनक संसाधनों की अप्रत्याशित कमी की संभावना है, जिससे नई वस्तुओं को बनाने में असमर्थता हो सकती है। चूंकि एक वास्तविक समय प्रणाली का सार इसकी भविष्यवाणी है, यह अस्वीकार्य है। इसलिए, गतिशील कार्यों (और अन्य वस्तुओं) के निर्माण का उपयोग करते समय देखभाल की जानी चाहिए।

बीच में आता है

यह संभव है कि एक अंतःस्थापित वास्तविक समय प्रणाली को बिना किसी व्यवधान के उपयोग के लागू किया जा सकता है, लेकिन यह विशिष्ट नहीं है।

इंटरप्ट और कर्नेल

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

बचत का प्रसंग

ISR को हमेशा एक "संदर्भ" बनाए रखने की आवश्यकता होती है, ताकि ISR गणनाओं में अवरोधी कोड प्रभावित न हो। RTOS के बिना लागू की गई प्रणाली में, ISR द्वारा उपयोग किए जाने वाले किसी भी रजिस्टर को बचाने (आमतौर पर स्टैक पर) और वापस लौटने से पहले उन्हें बहाल करने की बात है। कुछ प्रोसेसर में एक समर्पित ISR स्टैक होता है, जबकि अन्य बस उसी स्टैक का उपयोग एप्लिकेशन कोड के रूप में करते हैं।

आरटीओएस का उपयोग करते समय, दृष्टिकोण बिल्कुल समान हो सकता है। उसी तरह, ISR द्वारा उपयोग किए गए स्टैक को वर्तमान कार्य से "उधार" लिया जा सकता है, या यह व्यवधान के लिए आवंटित किया गया एक और स्टैक हो सकता है। कुछ कोर इस सुविधा को लागू करते हैं, भले ही प्रोसेसर स्वयं इंटरप्ट स्टैक का समर्थन नहीं करता हो। यदि ISR एक API कॉल करता है जो कार्य शेड्यूलर को प्रभावित करता है, तो स्थिति जटिल है। यह रुकावट होने पर शुरू किए गए किसी अन्य कार्य पर लौटने के लिए रुकावट का कारण बन सकता है।

व्यवधान और समयबद्धक

ऐसी कई परिस्थितियाँ हैं जिनमें ISR निष्पादन संहिता दूसरे कार्य पर लौट सकती है:

• यदि वर्तमान प्राथमिकता शेड्यूलर का उपयोग किया जाता है, तो ISR पहले से ही पूर्ण कार्य के लिए एक उच्च प्राथमिकता प्रदान कर सकता है।
• ISR वर्तमान कार्य को रोक सकता है।
• टाइम-स्लाइस शेड्यूलर (टीएस) का उपयोग करते हुए, सिस्टम टाइमर इंटरप्ट हैंडलर समय अंतराल को नियंत्रित करेगा और यदि आवश्यक हो, तो शेड्यूलर को कॉल कर सकता है।

घड़ी घड़ी (टिक घड़ी)

एम्बेडेड सिस्टम में, एक आवधिक "घड़ी टाइमर" (समय टुकड़ा) का उपयोग अक्सर पाया जाता है। कुछ RTOS में, यह एक आवश्यक घटक है। आमतौर पर, एक घड़ी टाइमर की उपस्थिति वैकल्पिक है, और इसकी अनुपस्थिति बस कुछ सेवाओं की उपलब्धता को रोकती है। टाइमर में बाधा हैंडलर आमतौर पर चार कार्यक्षमता प्रदान करता है:

• यदि टाइम स्लॉट अनुसूचक का उपयोग किया जाता है, तो टाइमर इंटरप्ट हैंडलर समय काउंटर को नियंत्रित करेगा और हर बार समय समाप्त होने पर एक नया कार्य शेड्यूल करेगा।
• सिस्टम समय समर्थन प्रदान करता है। यह मुख्य रूप से एक 32-बिट चर है जो एक टाइमर द्वारा बढ़ाया जाता है और कार्यों द्वारा पूर्वनिर्धारित या अनुरोध किया जा सकता है।
• यदि RTOS टाइमर के साथ आवेदन प्रदान करता है, तो यह एक टाइमर इंटरप्ट हैंडलर द्वारा समर्थित होगा जो समाप्ति और पुनर्निर्धारण के लिए जिम्मेदार होगा।
• यदि RTOS API कॉल्स को ब्लॉक करने में टाइमआउट का समर्थन करता है या कार्य नींद की स्थिति में हो सकता है, तो ये समय अंतराल टाइमर इंटरप्ट हैंडलर द्वारा समर्थित होंगे।

जब हमने अपने स्वयं के वास्तविक समय के OSRV MAX ऑपरेटिंग सिस्टम (इसके बारे में पहले प्रकाशित लेख) पर काम किया, तो हमारी टीम “कॉलिन वाल्स का ब्लॉग”, माइक्रोइलेक्ट्रॉनिक के विशेषज्ञ और मेंटर ग्राफिक्स के विशेषज्ञ थे। लेख दिलचस्प लग रहे थे, उन्हें खुद के लिए अनुवादित किया, लेकिन "तालिका में लिखने" के लिए नहीं उन्होंने प्रकाशित करने का फैसला किया। मुझे उम्मीद है कि वे भी आपके लिए उपयोगी होंगे। यदि ऐसा है, तो हम श्रृंखला में सभी अनुवादित लेख प्रकाशित करने की योजना बनाते हैं।

लेखक के बारे में: कॉलिन वाल्स तीस वर्षों से इलेक्ट्रॉनिक्स उद्योग में काम कर रहे हैं, अपने अधिकांश समय को फर्मवेयर के लिए समर्पित करते हैं। वह अब मेंटर एंबेडेड (मेंटर ग्राफिक्स का एक प्रभाग) में एक फर्मवेयर इंजीनियर है। कॉलिन वॉल्स अक्सर सम्मेलनों और सेमिनारों में बोलते हैं, कई तकनीकी लेखों के लेखक और फर्मवेयर पर दो किताबें। ब्रिटेन में रहता है। कॉलिन का पेशेवर ब्लॉग: blogs.mentor.com/colinwalls, ई-मेल: colin_walls@mentor.com

पहले प्रकाशित श्रृंखला में पहला, दूसरा और तीसरा लेख पढ़ें।