वास्तविक समय की प्राथमिकता के साथ चलने वाली प्रक्रियाओं के नकारात्मक?

Question

क्या वास्तविक समय प्राथमिकता ( chrt -f 99) के साथ चलने वाली प्रक्रियाओं में कोई कमी है ?

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

(कर्नेल: २.६.१६ / ३.०)

Comments

यह आपके लिए उपयोगी है: जावा के लिए घबराना कैसे कम करें?

— ire_and_curses

@ire_and_curses, वर्तमान में यह प्रक्रिया अपने आप में अलग-थलग कोर (कम से कम मुख्य प्रोसेसिंग थ्रेड) पर चलती है, हालाँकि व्यवधान उसी कोर पर शेड्यूल नहीं किए जाते हैं (ऐसा नहीं कर सकते हैं क्योंकि एक ही नेटवर्क इंटरफ़ेस पर निर्भर करने वाली कई समान प्रक्रियाएं हैं ), यह एक अंतिम प्रयास का अधिक है। APIC आवृत्ति दिलचस्प है, मैंने इससे पहले इसका सामना नहीं किया है।

— निम

Answer 1

रीयलटाइम प्रक्रिया को चलाने का सबसे तात्कालिक पहलू यह है कि यह प्रक्रिया सिस्टम की हर दूसरी प्रक्रिया को आसानी से भुना सकती है। आपके दृष्टिकोण से परिणाम यह होगा कि कंप्यूटर कीबोर्ड, माउस और शायद नेटवर्क के लिए पूरी तरह से अनुत्तरदायी है, जब तक कि वास्तविक समय सीपीयू का उपयोग कर रहा है। ऐसा तब हो सकता है जब कुछ गलत हो जाता है और प्रक्रिया एक अनंत लूप में चली जाती है, या अस्थायी रूप से भी अगर प्रक्रिया समय-समय पर इनपुट की प्रतीक्षा किए बिना लंबे समय तक चलने वाली गणना शुरू करती है। (इसलिए, उदाहरण के लिए, वास्तविक समय प्राथमिकता के साथ SETI @ घर न चलाएं।)

मल्टी-कोर सीपीयू पर एक एकल-थ्रेडेड प्रक्रिया इस समस्या का कारण बनने की संभावना कम है क्योंकि अन्य कोर हैं जो निम्न-प्राथमिकता प्रक्रिया का उपयोग कर सकते हैं। लेकिन अगर यह प्रक्रिया किसी भी बच्चे की प्रक्रिया का निर्माण करती है, तो वे समान रीयलटाइम प्राथमिकता प्राप्त करेंगे, इसलिए यदि आप सावधान नहीं हैं तो चीजें नियंत्रण से बाहर हो सकती हैं।

sched_setscheduler(2)आदमी पेज अच्छी सलाह है:

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

यह कंसोल पर एक शेल होना चाहिए - एक Xterm के तहत नहीं, जब तक कि आप सभी एक्स रियलटाइम को प्राथमिकता नहीं देना चाहते।

Comments

हां - यह मुख्य समस्या है जिसका मुझे सामना करना पड़ता है। कर्नेल कोड के माध्यम से पढ़ने के लिए उन सभी प्रक्रियाओं को निर्धारित करने के लिए जिन्हें उच्च प्राथमिकता की आवश्यकता होती है, एकमात्र विकल्प यह है कि मेरी प्रक्रिया से सभी अन्य लोगों को अलग कर दें और फिर कुछ भी स्थानांतरित करें जिसमें किसी भी प्रकार के io को अन्य कोर ... hmmm की आवश्यकता होती है। ..

— निम