पिछले लेखों में, हमने मल्टीटास्किंग मॉडल की जांच की, और पाया कि प्रत्येक कार्य एक अर्ध-स्वतंत्र कार्यक्रम है। यद्यपि एम्बेडेड सिस्टम में कार्यों की एक निश्चित डिग्री स्वतंत्रता है, इसका मतलब यह नहीं है कि वे एक-दूसरे के बारे में "नहीं जानते" हैं। कुछ कार्य वास्तव में दूसरों से अलग-थलग हो जाएंगे, लेकिन उनके बीच बातचीत और सिंक्रनाइज़ेशन एक सामान्य आवश्यकता है। यह तंत्र आरटीओएस के प्रमुख कार्यों में से एक है। कार्यों की श्रेणी आरटीओएस के आधार पर भिन्न हो सकती है, इसलिए, इस लेख में हम सार्वजनिक रूप से उपलब्ध विकल्पों पर विचार करेंगे।
श्रृंखला में पिछले लेख:
अनुच्छेद # 4 कार्य, संदर्भ स्विचिंग, और व्यवधानअनुच्छेद # ३ कार्य और योजनाअनुच्छेद # 2 आरटीओएस: संरचना और वास्तविक समय मोड
अनुच्छेद # 1। आरटीओएस: परिचय।
समारोह की सीमा
इंटर-टास्क इंटरैक्शन और सिंक्रोनाइज़ेशन के तीन मॉडल हैं:
- सेवाओं को कार्यों से बांधा गया है: आरटीओएस उन विशेषताओं के साथ कार्य प्रदान करता है जो उनके बीच बातचीत प्रदान करते हैं। एक उदाहरण के रूप में संकेतों पर विचार करें।
- कर्नेल ऑब्जेक्ट संचार या सिंक्रनाइज़ेशन के स्वायत्त साधन हैं। उदाहरण: ईवेंट फ्लैग, मेलबॉक्स, कतार / चैनल, सेमीफ़ोर्स और म्यूटेक्स।
- मैसेजिंग एक सुव्यवस्थित योजना है जिसमें RTOS आपको संदेश ऑब्जेक्ट बनाने और उन्हें एक कार्य से दूसरे या कई में स्थानांतरित करने की अनुमति देता है। यह कर्नेल की वास्तुकला के लिए मौलिक है, और इसलिए ऐसी प्रणाली को "मैसेजिंग आरटीओएस" कहा जाता है।
विभिन्न प्रक्रियाओं के लिए आदर्श तंत्र अलग-अलग होंगे। उनकी क्षमताएं ओवरलैप हो सकती हैं, इसलिए यह इन मॉडलों की मापनीयता पर विचार करने योग्य है। उदाहरण के लिए, यदि किसी एप्लिकेशन को कई कतारों की आवश्यकता होती है, लेकिन केवल एक मेलबॉक्स के लिए, आप एक आइटम के लिए एक कतार के साथ एक मेलबॉक्स लागू कर सकते हैं। यह ऑब्जेक्ट पूरी तरह से इष्टतम नहीं होगा, लेकिन मेलबॉक्स के पूरे कोड को एप्लिकेशन में शामिल नहीं किया जाएगा, और इसलिए, स्केलेबिलिटी आरटीओएस द्वारा उपयोग की जाने वाली मेमोरी की मात्रा को कम कर देगी।
सामान्य चर या स्मृति क्षेत्र
कार्यों के बीच बातचीत के लिए एक सरलीकृत दृष्टिकोण चर या स्मृति क्षेत्रों की प्रणाली में उपस्थिति है जो सभी कार्यों के लिए उपलब्ध हैं। इस दृष्टिकोण को इसकी सादगी के बावजूद, कई प्रक्रियाओं पर लागू किया जा सकता है। पहुंच को नियंत्रित किया जाना चाहिए। यदि चर सिर्फ एक बाइट है, तो इससे लिखना या पढ़ना परमाणु ऑपरेशन (यानी, निरंतर) होने की संभावना है, लेकिन ध्यान रखना चाहिए कि क्या प्रोसेसर मेमोरी बाइट्स पर अन्य संचालन की अनुमति देता है, क्योंकि वे रुकावट हो सकते हैं और हो सकते हैं। तुल्यकालन समस्या। लॉकिंग / अनलॉकिंग को लागू करने का एक तरीका थोड़े समय के लिए व्यवधान को अक्षम करना है।
यदि आप मेमोरी क्षेत्र का उपयोग करते हैं, तो आपको अभी भी लॉक की आवश्यकता है। आप पहले बाइट को एक अवरुद्ध ध्वज के रूप में उपयोग कर सकते हैं, यह देखते हुए कि मेमोरी आर्किटेक्चर इस बाइट को परमाणु एक्सेस प्रदान करता है। एक कार्य मेमोरी क्षेत्र में डेटा लोड करता है, एक ध्वज सेट करता है, और फिर इसके रीसेट होने की प्रतीक्षा करता है। एक अन्य कार्य ध्वज के सेट होने, डेटा पढ़ने और ध्वज को रीसेट करने की प्रतीक्षा कर रहा है। लॉक के रूप में इंटरप्ट डिसेबल का उपयोग करना कम समझदार है क्योंकि पूरे डेटा बफर को हिलाने में कुछ समय लग सकता है।
साझा मेमोरी का यह उपयोग मल्टी-कोर सिस्टम में कई इंटरप्रोसेसर संचार के कार्यान्वयन के समान है। कुछ मामलों में, हार्डवेयर लॉकिंग और / या रुकावट साझा मेमोरी के इंटरप्रोसेसर इंटरफ़ेस में निर्मित होते हैं।
संकेत
पारंपरिक आरटीओएस द्वारा प्रस्तावित कार्यों के बीच बातचीत के लिए सिग्नल सबसे सरल तंत्र में से एक हैं। उनमें बिट फ्लैग का एक सेट (8, 16 या 32, विशिष्ट अनुप्रयोग के आधार पर) होता है, जो एक विशिष्ट कार्य से जुड़ा होता है।
सिग्नल फ्लैग (या कई झंडे) किसी भी कार्य द्वारा तार्किक ऑपरेशन "ओआर" का उपयोग करके सेट किया जा सकता है। फ्लैग (ओं) को केवल एक कार्य द्वारा पढ़ा जा सकता है जिसमें एक संकेत होता है। पढ़ने की प्रक्रिया आमतौर पर विनाशकारी होती है, अर्थात झंडे भी रीसेट हो जाते हैं।
कुछ प्रणालियों में, संकेतों को अधिक जटिल तरीके से कार्यान्वित किया जाता है, ताकि सिग्नल के कार्य-स्वामी द्वारा निर्दिष्ट एक विशेष फ़ंक्शन स्वचालित रूप से निष्पादित हो जाए जब कोई संकेत झंडे सेट किए जाते हैं। यह झंडे को नियंत्रित करने के लिए कार्य की आवश्यकता को समाप्त करता है। यह एक बाधा हैंडलर के समान है।
इवेंट फ्लैग ग्रुप्स
ईवेंट फ्लैग के समूह सिग्नल के समान हैं, जिसमें वे कार्यों के बीच बातचीत के लिए एक बिट-उन्मुख उपकरण हैं। इसी तरह, उनके पास 8, 16 या 32 बिट्स हो सकते हैं। संकेतों के विपरीत, वे स्वतंत्र कोर ऑब्जेक्ट हैं और किसी विशेष कार्य के लिए "संबंधित" नहीं हैं। कोई भी कार्य "फ्लैग" और "और" लॉजिकल ऑपरेशंस का उपयोग करके इवेंट फ्लैग को सेट और रीसेट कर सकता है। इसी तरह, कोई भी कार्य समान कार्यों का उपयोग करके घटना के झंडे की जांच कर सकता है। कई RTOS में, आप इवेंट फ्लैग के संयोजन के लिए एक अवरुद्ध एपीआई कॉल कर सकते हैं। यही है, कार्य को तब तक निलंबित किया जा सकता है जब तक कि ईवेंट झंडे का एक विशिष्ट संयोजन सेट नहीं किया जाता है। ईवेंट फ्लैग की जाँच करते समय "उपभोग" विकल्प भी उपलब्ध हो सकता है, जो सभी फ़्लैग को रीसेट करता है।
सेमाफोर
सेमीफोरर्स स्वतंत्र कर्नेल ऑब्जेक्ट हैं जिनका उपयोग संसाधन लेखांकन के लिए किया जाता है। दो प्रकार के सेमाफोर हैं: बाइनरी (केवल दो मान हो सकते हैं) और सामान्य (मूल्यों की असीमित संख्या)। कुछ प्रोसेसर समर्थन (परमाणु) निर्देश देते हैं जो बाइनरी सेमाफोर के त्वरित कार्यान्वयन की सुविधा प्रदान करते हैं। बाइनरी सेमाफोर्स को 1 के मान के साथ सामान्य सेमाफोर के रूप में लागू किया जा सकता है।
कोई भी कार्य संसाधन तक पहुँच प्राप्त करने के लिए एक सेमाफ़ोर निर्दिष्ट करने का प्रयास कर सकता है। यदि सेमाफोर का वर्तमान मूल्य 0 से अधिक है (सेमाफोर मुक्त है), काउंटर मूल्य 1 से कम हो जाता है, इसलिए, असाइनमेंट सफल होगा। कई ऑपरेटिंग सिस्टमों में, एक लॉकिंग मैकेनिज्म का उपयोग सेमाफोर को असाइन करने के लिए किया जा सकता है। इसका मतलब है कि यह कार्य प्रतीक्षा की स्थिति में हो सकता है जब तक कि अर्धचालक किसी अन्य कार्य द्वारा जारी नहीं किया जाता है। कोई भी कार्य अर्धकुम्भ को मुक्त कर सकता है, और फिर अर्धमात्रा का मान बढ़ जाएगा।
मेलबॉक्स
मेलबॉक्स स्वतंत्र कर्नेल ऑब्जेक्ट हैं जो संदेश भेजने के लिए साधन प्रदान करते हैं। संदेश का आकार कार्यान्वयन पर निर्भर है, लेकिन यह आमतौर पर तय होता है। विशिष्ट संदेश आकार एक से चार तत्वों के सूचक के आकार के होते हैं। आमतौर पर, मेलबॉक्स के माध्यम से अधिक जटिल डेटा के लिए एक संकेतक भेजा जाता है। कुछ कर्नेल मेलबॉक्सों को इस तरह से लागू करते हैं कि डेटा बस एक नियमित चर में संग्रहीत होता है और कर्नेल उस तक पहुंच को नियंत्रित करता है। मेलबॉक्स को "एक्सचेंज" भी कहा जा सकता है, हालांकि यह नाम अब शायद ही कभी देखा जाता है।
कोई भी कार्य मेलबॉक्स को संदेश भेज सकता है, जो तब आबादी है। यदि कोई कार्य पूर्ण मेलबॉक्स पर संदेश भेजने का प्रयास करता है, तो उसे एक त्रुटि प्रतिक्रिया मिलेगी। कई आरटीओएस में, आप मेलबॉक्स को भेजने के लिए एक अवरुद्ध तंत्र का उपयोग कर सकते हैं। इसका अर्थ है कि मेलबॉक्स में संदेश पढ़ने तक कार्य स्थगित रहेगा। कोई भी कार्य मेलबॉक्स से संदेश पढ़ सकता है, जिसके बाद वह खाली है। यदि कोई कार्य खाली मेलबॉक्स से पढ़ने का प्रयास करता है, तो उसे एक त्रुटि प्रतिक्रिया मिलेगी। कई RTOS में, आप एक मेलबॉक्स से पढ़ने के लिए एक अवरुद्ध कॉल का उपयोग कर सकते हैं। इसका अर्थ है कि मेलबॉक्स में एक नया संदेश दिखाई देने तक कार्य स्थगित रहेगा।
कुछ RTOS "प्रसारण" फ़ंक्शन का समर्थन करते हैं। यह आपको उन सभी कार्यों के लिए संदेश भेजने की अनुमति देता है जो वर्तमान में एक विशिष्ट मेलबॉक्स पढ़ते समय रुके हुए हैं।
कुछ RTOS मेलबॉक्सों का समर्थन नहीं करते हैं। इसके बजाय, यह अनुशंसा की जाती है कि आप एकल-तत्व कतार का उपयोग करें। यह कार्यात्मक रूप से समतुल्य है, लेकिन स्मृति और क्रम के लिए अतिरिक्त उपरि वहन करता है।
कतारों
कतार स्वतंत्र कर्नेल ऑब्जेक्ट हैं जो संदेश भेजने के लिए एक तंत्र प्रदान करते हैं। वे मेलबॉक्स से थोड़े अधिक लचीले और जटिल हैं। संदेश का आकार कार्यान्वयन पर निर्भर करता है, लेकिन यह आमतौर पर निश्चित होता है और शब्द / सूचक के लिए उन्मुख होता है।
कोई भी कार्य कतार में संदेश भेज सकता है, और जब तक कतार पूरी नहीं हो जाती, तब तक इसे दोहराया जा सकता है, जिसके बाद भेजने के किसी भी प्रयास में त्रुटि होगी। सिस्टम बनाते या कॉन्फ़िगर करते समय कतार की लंबाई आमतौर पर उपयोगकर्ता द्वारा निर्धारित की जाती है। कई RTOS में, आप एक अवरुद्ध तंत्र को कतार में लगा सकते हैं। अर्थात्, यदि कतार भरी हुई है, तो कार्य को तब तक निलंबित रखा जा सकता है जब तक कतार में संदेश किसी अन्य कार्य द्वारा पढ़ा नहीं जाता है। कोई भी कार्य कतार से संदेश पढ़ सकता है। संदेशों को उसी क्रम में पढ़ा जाता है, जिसमें उन्हें भेजा गया था (पहले में - पहले बाहर, फीफो)। यदि कोई कार्य खाली कतार से पढ़ने का प्रयास करता है, तो उसे त्रुटि प्रतिक्रिया प्राप्त होगी। कई आरटीओएस में, खाली कतार से पढ़ने के लिए एक अवरुद्ध तंत्र का उपयोग किया जा सकता है। अर्थात्, यदि कतार खाली है, तो कार्य को तब तक निलंबित रखा जा सकता है जब तक संदेश किसी अन्य कार्य द्वारा कतार में नहीं भेजा जाता है।
सबसे अधिक संभावना है, कतार के सामने एक संदेश भेजने के लिए RTOS में एक तंत्र होगा, इसे जैमिंग कहा जाता है। कुछ RTOS भी प्रसारण समारोह का समर्थन करते हैं। इससे आप कतार पढ़ते हुए रुके हुए सभी कार्यों को संदेश भेज सकते हैं।
इसके अलावा, RTOS चर लंबाई के संदेश भेजने और पढ़ने का समर्थन कर सकता है। यह अधिक लचीलापन देता है, लेकिन अतिरिक्त ओवरहेड को मजबूर करता है।
कई RTOS कर्नेल ऑब्जेक्ट के अन्य प्रकार, "पाइप" का समर्थन करते हैं। संक्षेप में, एक चैनल एक कतार के समान है, लेकिन बाइट-ओरिएंटेड डेटा को प्रोसेस करता है।
कतारों की कार्यक्षमता रुचि की नहीं है, लेकिन यह समझा जाना चाहिए कि उनके पास मेलबॉक्स की तुलना में स्मृति और रनटाइम के लिए अधिक ओवरहेड है, मुख्य रूप से क्योंकि यह दो बिंदुओं को बचाने के लिए आवश्यक है: कतार की शुरुआत और अंत।
mutexes
म्यूटेक्स (पारस्परिक रूप से अनन्य सेमाफोर) स्वतंत्र कर्नेल ऑब्जेक्ट हैं जो नियमित बाइनरी सेमाफोर की तरह बहुत व्यवहार करते हैं। वे semaphores की तुलना में थोड़ा अधिक जटिल हैं और इसमें अस्थायी स्वामित्व (एक संसाधन जिसके लिए पहुंच नियंत्रित है) की अवधारणा शामिल है। यदि कोई कार्य म्यूटेक्स को असाइन करता है, तो केवल वही कार्य इसे फिर से जारी कर सकता है: म्यूटेक्स (और इसलिए, संसाधन) अस्थायी रूप से कार्य के अंतर्गत आता है।
म्यूटेक्स सभी आरटीओएस द्वारा प्रदान नहीं किए जाते हैं, लेकिन नियमित बाइनरी सेमाफोर को अनुकूलित करना बहुत आसान है। आपको एक म्यूटेक्स प्राप्त फ़ंक्शन लिखना होगा जो एक सेमीफ़ायर प्रदान करता है और एक कार्य पहचानकर्ता प्रदान करता है। फिर अतिरिक्त फ़ंक्शन "म्यूटेक्स रिलीज़" कॉलिंग टास्क के पहचानकर्ता की जांच करता है और अर्ध-विमोचन करता है यदि यह संग्रहीत मूल्य से मेल खाता है, अन्यथा यह एक त्रुटि लौटाएगा।
जब हमने अपने स्वयं के वास्तविक समय के OSRV MAX ऑपरेटिंग सिस्टम (इसके बारे में पहले प्रकाशित लेख) पर काम किया, तो हमारी टीम “कॉलिन वाल्स का ब्लॉग”, माइक्रोइलेक्ट्रॉनिक के विशेषज्ञ और मेंटर ग्राफिक्स के विशेषज्ञ थे। लेख दिलचस्प लग रहे थे, उन्हें खुद के लिए अनुवादित किया, लेकिन "तालिका में लिखने" के लिए नहीं उन्होंने प्रकाशित करने का फैसला किया। मुझे उम्मीद है कि वे भी आपके लिए उपयोगी होंगे। यदि ऐसा है, तो हम श्रृंखला में सभी अनुवादित लेख प्रकाशित करने की योजना बनाते हैं।
लेखक के बारे में: कॉलिन वाल्स तीस वर्षों से इलेक्ट्रॉनिक्स उद्योग में काम कर रहे हैं, अपने अधिकांश समय को फर्मवेयर के लिए समर्पित करते हैं। वह अब मेंटर एंबेडेड (मेंटर ग्राफिक्स का एक प्रभाग) में एक फर्मवेयर इंजीनियर है। कॉलिन वॉल्स अक्सर सम्मेलनों और सेमिनारों में बोलते हैं, कई तकनीकी लेखों के लेखक और फर्मवेयर पर दो किताबें। ब्रिटेन में रहता है। कॉलिन का पेशेवर ब्लॉग: blogs.mentor.com/colinwalls , ई-मेल: colin_walls@mentor.comपहले प्रकाशित पहले
, दूसरे, तीसरे, चौथे लेख को पढ़ें।