"विंडोज एक वास्तविक समय ऑपरेटिंग सिस्टम नहीं है" क्या मतलब है?

Question

मुझे लेटेंसीमॉन नामक एक आवेदन मिला , जो स्पष्ट रूप से विलंबता निगरानी करता है।

मैंने हमेशा समझा है कि आप प्रोसेसर पर जितना लोड डालते हैं, उतना कम उत्तरदायी, या अधिक अव्यक्त, सिस्टम बन जाता है। हालांकि, लेटेंसीमॉन पेज के दूसरे खंड में, पहला वाक्य कहता है, "विंडोज एक वास्तविक समय ऑपरेटिंग सिस्टम नहीं है" (आरटीओएस)। यही सोचकर मुझे मिला। मेरा मतलब है, क्या यह किसी भी अन्य ऑपरेटिंग सिस्टम जैसे लिनक्स, यूनिक्स या मैक ओएस एक्स से अलग है?

क्या कोई "वास्तविक समय" ऑपरेटिंग सिस्टम हैं? या क्या यह केवल एक मार्केटिंग स्कीम है जिससे आप उनका उत्पाद खरीद सकते हैं।

संपादित करें:

इसके अलावा, आरटीओएस के बाहर होने के कोई उदाहरण हैं?

Comments

उदाहरण के लिए, QNX वास्तविक समय है।

— new123456

Answer 1

विकिपीडिया वास्तव में जानकारी का एक आश्चर्यजनक धन है।

एक रीयल-टाइम ऑपरेटिंग सिस्टम (RTOS) एक ऑपरेटिंग सिस्टम (OS) है जिसका उद्देश्य वास्तविक समय के एप्लिकेशन अनुरोधों की सेवा करना है।

आरटीओएस की एक प्रमुख विशेषता इसकी निरंतरता का स्तर है जो किसी एप्लिकेशन के कार्य को स्वीकार करने और पूरा करने में जितना समय लगता है; परिवर्तनशीलता घबराना है। एक हार्ड-टाइम ऑपरेटिंग सिस्टम में सॉफ्ट रियल-टाइम ऑपरेटिंग सिस्टम की तुलना में कम घबराहट होती है। मुख्य डिजाइन लक्ष्य उच्च थ्रूपुट नहीं है, बल्कि एक नरम या कठोर प्रदर्शन श्रेणी की गारंटी है। एक RTOS जो आम तौर पर या आम तौर पर एक समय सीमा को पूरा कर सकता है, एक नरम वास्तविक समय ओएस है, लेकिन अगर यह निर्धारित समय सीमा को पूरा कर सकता है तो यह एक कठिन वास्तविक समय ओएस है।

एक RTOS शेड्यूलिंग के लिए एक उन्नत एल्गोरिथ्म है। शेड्यूलर लचीलापन प्रक्रिया प्राथमिकताओं के व्यापक, कंप्यूटर-सिस्टम ऑर्केस्ट्रेशन को सक्षम बनाता है, लेकिन एक वास्तविक समय ओएस अधिक बार अनुप्रयोगों के संकीर्ण सेट के लिए समर्पित होता है। वास्तविक समय के ओएस में मुख्य कारक न्यूनतम व्यवधान विलंबता और न्यूनतम धागा स्विचिंग विलंबता हैं; एक रीयल-टाइम OS का मूल्य इस बात के लिए अधिक होता है कि यह कितनी जल्दी या कितनी अनुमानित प्रतिक्रिया दे सकता है जितना कि किसी निश्चित अवधि में काम कर सकता है।

यह कुछ ऐसा है जो बहुत कम ऑपरेटिंग सिस्टम वास्तव में करते हैं, क्योंकि बहुत सारे वर्कलोड के लिए यह बस कम कुशल है। कोई भी प्रमुख उपभोक्ता ऑपरेटिंग सिस्टम अब (या मेरे ज्ञान के लिए कभी नहीं) वास्तविक समय है। दुर्भाग्य से, इसका मतलब यह है कि कभी-कभी गैर-वास्तविक समय के वातावरण में चीजों को अन्य चीजों पर इंतजार करने के लिए बैठना पड़ता है। यह केवल एक समस्या बन जाता है जब किसी चीज की समय पर उचित मात्रा में पैदावार नहीं होती है।

वर्तमान में सबसे प्रसिद्ध, सबसे व्यापक रूप से तैनात, वास्तविक समय ऑपरेटिंग सिस्टम हैं:

LynxOS
OSE
QNX
RTLinux
VxWorks
Windows CE

देखें वास्तविक समय ऑपरेटिंग सिस्टम की सूची व्यापक सूची के लिए।

Comments

रियल-टाइम OS का उपयोग आम तौर पर बेहद सटीक नियंत्रण प्रणालियों जैसे बहुत ही समर्पित भूमिकाओं में किया जाता है जहां एक निर्णय / गणना / आदि को बहुत सटीक समय सीमा में पूरा किया जाना चाहिए।

— लैमर बी

क्या आरटीओएस के कोई उदाहरण हैं? इस संबंध में प्रश्न को अद्यतन करना।

— चाड हैरिसन

en.wikipedia.org/wiki/Real-time_operating_system#Examples

— ta.speot.is

क्या @ ta.speot.is ने कहा - लेख में कुछ पहले से ही जुड़ा हुआ है। मैं हालांकि में कुछ संपादित करेंगे।

— शिन्राइ

मैं विकी पेज के निचले हिस्से में नहीं गया था ... सॉरी बाउट कि: /

— चाड हैरिसन

Answer 2

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

Answer 3

मूल रूप से, एक आरटीओएस गारंटी दे सकता है कि वह एक विशिष्ट (आमतौर पर कम) समय-सीमा में एक आईआरक्यू (रुकावट अनुरोध) की सेवा कर सकता है। मानक ऑपरेटिंग सिस्टम में ऐसी कोई गारंटी नहीं है।

आधुनिक प्रणालियों में, अधिकांश डिवाइस एक IRQ उत्पन्न कर सकते हैं। इसके कारण CPU बंद हो जाता है (यानी बाधित हो जाता है) कि वह क्या कर रहा है और एक बाधा सेवा कार्यक्रम चलाता है। विचार यह है कि यह सेवा कार्यक्रम डिवाइस को जो कुछ भी चाहिए, वह करता है, अर्थात डिवाइस का डेटा बंद हो जाता है और रैम में, डिवाइस को बताता है कि आगे क्या करना है, आदि।

X86 पर, चूंकि इसमें CPU पर केवल 1 IRQ लाइन है, जब यह एक रुकावट प्राप्त करता है, तो आगे व्यवधान स्वचालित रूप से अक्षम हो जाते हैं (NMI, RESET, और SMI को छोड़कर) जब तक CPU व्यवधान स्रोत को स्वीकार नहीं करता है और उन्हें reenables करता है। मानक i386 / amd64 विंडोज के तहत इतने अच्छे डिवाइस ड्राइवर इस राज्य में न्यूनतम प्रसंस्करण करेंगे, बस इतना पर्याप्त है कि यह रीनेम करने योग्य अवरोधों के लिए ठीक है, और फिर बाद में तब तक रुकावट के पूर्ण प्रसंस्करण को स्थगित कर दें (क्योंकि सिस्टम तकनीकी रूप से केवल सीपीयू प्रति सेवा को बाधित कर सकता है) एक समय में कोर)। मुझे यकीन नहीं है लेकिन मेरा मानना ​​है कि लिनक्स भी यही करता है। फिर भी, इस समय की कोई सख्त गारंटी नहीं है कि बीच में बाधा उत्पन्न हो जाएगी।

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

Comments

क्या आप बता सकते हैं कि "x86 की केवल 1 IRQ लाइन" से आपका क्या मतलब है? पिछली बार मैंने एक 80186 कंप्यूटर को तार-तार कर दिया था (दशकों पहले) एनएमआई?

— ग्लेन स्लेडेन

आपको सटीक रूप से PIC की आवश्यकता है क्योंकि x86 में केवल एक IRQ लाइन है लेकिन अगर x86 इंटरप्ट अक्षम है तो PIC केवल तब तक प्रतीक्षा कर सकता है जब तक CPU उन्हें पुनः सक्षम नहीं करता है, और IIRC यह बस करता है। IIRC अन्य सीपीयू जैसे 68000 में 3 इंटरप्ट पिन थे और सीपीयू पर ही कोडेड प्रायरिटी लेवल 0-4 की उम्मीद थी। हालाँकि अब मैं वास्तव में इस पर विचार कर रहा हूँ, हो सकता है कि 68000 किसी भी IRQ को प्राप्त करने में सभी व्यवधानों को बाधित कर दे - मैंने कभी भी 68000 को प्रोग्राम नहीं किया।

— लॉरेंस

आह हाँ, अब याद आया। और IIRC 8259 चिप डिजाइन के 'प्राथमिकता' पहलू - नेस्टेड IRQ हैंडलिंग की अनुमति देकर - यह संभव नहीं था या कम से कम संभव के रूप में बाधित करने के लिए ओएस को प्रोत्साहित करने के लिए माना जाता था, लेकिन पीसी बाधा लाइनों को बेतरतीब ढंग से सौंपा गया था, जिसे हराकर दृष्टिकोण? किसी भी तरह, निश्चित रूप से सीएलआई के तहत किसी भी पर्याप्त मात्रा में कोड को कॉल करना ... एसटीआई का इरादा कभी नहीं था।

— ग्लेन स्लेडेन