कर्नेल को सिस्टम कॉल के बीच में थ्रेड को पूर्व-खाली किया जा सकता है?

Question

मैं 2 थ्रेड चला रहा हूं (मान लीजिए कि वे इस पल के लिए pthreads हैं)। Thread_1() उपयोगकर्ता द्वारा परिभाषित एपीआई कॉल बनाता है जो आखिरकार कर्नेल में कुछ काम करता है। थ्रेड_2() पूरी तरह से उपयोगकर्ता-स्थान में है।

मेरा प्रश्न है: क्या थ्रेड_2() एपीआई कॉल प्रगति पर है, जबकि पूर्व-खाली थ्रेड_1() द्वारा निष्पादित करना प्रारंभ कर सकता है, नियंत्रण कर्नेल के अंदर कहीं है? यदि नहीं, क्यों, और यदि मैं यह परिदृश्य होना चाहता हूं (किसी भी कारण से), मुझे क्या करना है?

Answer 1

यदि आप पूछ रहे हैं कि ब्लॉकिंग कर्नेल fread() की तरह कॉल करता है जिसके लिए डिस्क IO को पूर्व-खाली किया जा सकता है, तो हाँ।

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

संपादित करें: आप एक तरह से "काफी विश्वास है" होने के लिए कि Thread_1 एक अवरुद्ध कॉल प्रदर्शन कर रहा है चाहते हैं, Thread_2 कम प्राथमिकता Thread_1 (इतना है कि यह आम तौर पर नहीं रन करता है जब तक कि Thread_1 अवरुद्ध है) और की तुलना में कर जब यह चलता है, तो यह हार्डवेयर प्राथमिकता को तब तक थ्रेड_1 की तुलना में उच्च स्तर तक बढ़ा देता है, जिस बिंदु पर यह इसकी प्राथमिकता को कम करता है और sched_yield() पर कॉल करता है।

Answer 2

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

आम तौर पर, मल्टीथ्रेड कोड लिखते समय, आप ध्यान केंद्रित करते हैं कि ये धागे एक दूसरे के साथ कैसे बातचीत करते हैं, और कर्नेल के साथ कर्नेल के साथ अपनी बातचीत को प्रबंधित करने के लिए छोड़ देते हैं। यह एक बहुत अच्छी नौकरी करने के लिए डिज़ाइन किया गया है।

Answer 3

यह कर्नेल पर निर्भर करता है। शास्त्रीय कर्नल ने मोचन की अनुमति नहीं दी (विशिष्ट बिंदुओं को छोड़कर जब यह धागा सोएगा)। लेकिन नए कर्नल ने कर्नेल के भीतर ही प्रीमिशन को सक्षम करना शुरू कर दिया है।

लिनक्स एक preemptible कर्नेल का समर्थन करता है जब यह CONFIG_PREEMPT के साथ बनाया गया है। गिरी प्रलेखन से:

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

यदि आप डेस्कटॉप के लिए कर्नेल बना रहे हैं या मिलीसेकंड रेंज में विलंबता आवश्यकताओं के साथ एम्बेडेड सिस्टम का चयन कर रहे हैं तो इसे चुनें।