सरल उत्तर यह है कि सभी धागे एक साथ निष्पादित नहीं होते हैं। फुलर स्पष्टीकरण के लिए, पर पढ़ें।
ऑपरेटिंग सिस्टम के टास्क शेड्यूलर को आमतौर पर एप्लिकेशन को शेड्यूल करने के बारे में सोचा जाता है, और ऐसा करने से आप एक काम कर सकते हैं जबकि कंप्यूटर दूसरे पर काम कर रहा है। पुराने दिनों में, मल्टीटास्किंग का लिटमस टेस्ट कुछ और करने के दौरान फ्लॉपी डिस्क को स्वरूपित कर रहा था। यदि आप वास्तव में OS को परीक्षण में लाना चाहते हैं, तो आप सीरियल पोर्ट से जुड़े मॉडेम पर फ़ाइल डाउनलोड करते समय एक फ्लॉपी डिस्क को प्रारूपित करेंगे। जैसा कि हार्डवेयर वास्तव में काफी शक्तिशाली हो गया था, इसे सार्थक तरीके से करने के लिए, वीडियो प्लेबैक कभी-कभी ऐसे परीक्षणों में भी चित्रित किया गया था। यदि OS का कार्य अनुसूचक उन कार्यों को सुचारू रूप से चलाने में सक्षम हो सकता है, तो यह कुछ भी संभाल सकता है।
हालाँकि, कार्य अनुसूचक वास्तव में अनुप्रयोगों (प्रक्रियाओं) को शेड्यूल नहीं करता है, यह थ्रेड्स को शेड्यूल करता है । प्रत्येक एप्लिकेशन में कम से कम एक धागा होता है, लेकिन संभावित रूप से संबंधित या स्वतंत्र भागों में विभाजित करने के लिए बड़ी संख्या में थ्रेड्स का उपयोग कर सकता है। उदाहरण के लिए, एप्लिकेशन के लिए एक थ्रेड होना आम बात है जो उपयोगकर्ता इंटरफ़ेस को हैंडल करता है, और जब उपयोगकर्ता संभावित रूप से लंबे समय तक चलने वाला ऑपरेशन शुरू करता है, तो एक और थ्रेड बनाने के लिए (जो मुद्रण जैसी चीजें हो सकती हैं, स्प्रेडशीट को पुन: परिकलित करना, एक विकास का वातावरण बनाना) एक प्रतीक देखने, आदि आदि)। कुछ प्रोग्रामिंग वातावरण थ्रेड की कुछ मात्रा को अदृश्य-से-प्रोग्रामर से परिचित कराते हैं; उदाहरण के लिए, Java और .NET कचरा संग्रहण कर सकते हैंएक अलग थ्रेड में, जो प्रोग्रामर के तत्काल नियंत्रण से बाहर है। कुछ प्रोग्राम जल्दी से कई थ्रेड बनाते हैं और उन्हें पूल करते हैं, क्योंकि नए थ्रेड्स बनाना एक तुलनात्मक रूप से महंगा ऑपरेशन है (इसलिए आप जरूरी नहीं कि हर बार एक धागा बनाना चाहते हों)। कुछ भी जो पूर्वावलोकन करता है, आमतौर पर एक अलग थ्रेड में किया जाता है, इसलिए पूर्वावलोकन किए जाने के दौरान UI का शेष उत्तरदायी रहता है। और इसी तरह। एक साथ लिया गया, इसका मतलब यह है कि किसी भी समय सिस्टम पर थ्रेड्स की संख्या आसानी से कई बार हो सकती है।
प्रत्येक धागा कुछ संभावित राज्यों में से एक में हो सकता है, लेकिन सबसे महत्वपूर्ण अंतर रनिंग , रननेबल और वेटिंग स्टेट्स के बीच है; शब्दावली थोड़ा भिन्न हो सकती है, लेकिन यह सामान्य विचार है। किसी भी समय, केवल एक थ्रेड प्रति वर्चुअल (हाइपरथ्रेडिंग और समान तकनीकों के कारण) सीपीयू कोर चल सकता है (यानी, मशीन कोड निर्देशों को निष्पादित कर रहा है), लेकिन किसी भी संख्या में थ्रेड को चलाने योग्य हो सकता है (जिसका अर्थ है कि यह एक उम्मीदवार है अगली बार CPU को शेड्यूलर को यह निर्णय लेने की आवश्यकता होती है कि किस थ्रेड को चलाने की अनुमति दी जानी चाहिए)। इंतज़ार कर रही (अवरुद्ध के रूप में भी जाना जाता है) थ्रेड्स बस कुछ के लिए इंतजार कर रहे हैं - सबसे आम मामलों में शायद यह है कि यह उपयोगकर्ता, डिस्क या नेटवर्क I / O की प्रतीक्षा कर रहा है (विशेष रूप से उपयोगकर्ता इनपुट असाधारण धीमा है)।
कार्य प्रबंधक में आप जो थ्रेड काउंट देखते हैं, वह इनमें से किसी भी राज्य में थ्रेड्स की कुल संख्या है। उदाहरण के लिए, मैं जिस विंडोज 7 सिस्टम को टाइप कर रहा हूं, उसमें इस समय लगभग 70 प्रक्रियाएं शुरू हुई हैं, लेकिन लगभग 900 धागे हैं। विभिन्न कार्यों को संभालने के लिए सभी पृष्ठभूमि प्रक्रियाओं के साथ और कैसे वे संभवतः प्रत्येक धागे की एक भीड़ में उप-विभाजित होते हैं, यह एक अपमानजनक संख्या नहीं है।
तकनीकी कार्यान्वयन की गहराई में थोड़ा और अधिक जाना, पूर्व-खाली मल्टीटास्किंग ऑपरेटिंग सिस्टम के कार्य अनुसूचक के मूल में आमतौर पर किसी प्रकार का हार्डवेयर अवरोध हुक होता है। इसका मतलब है कि गिरी सीपीयू जब यह प्रदर्शन करने के लिए कोई उपयोगी काम है रोक सकते हैं (यह लगभग निश्चित रूप से किसी एक कारण से है अगर नहीं हो, क्यों लिनक्स चेकों अनुदेश पर बूट पर IA-32HLTअसंगत सीपीयू, और संभवत: अन्य आर्किटेक्चर पर भी इसी तरह की जांच होती है), इस ज्ञान में सुरक्षित है कि भविष्य में कुछ उचित समय निर्धारित करें, एक बाधा आग लग जाएगी और कार्य अनुसूचक को आमंत्रित किया जाएगा। चूंकि सीपीयू क्या काम कर रहा है, इस बात की परवाह किए बिना कि आग लग रही है (यह बीच में विचार है), अनुसूचक को नियमित रूप से निष्पादित किया जाता है और यह निर्धारित करने का मौका मिलता है कि निम्नलिखित समय के दौरान कौन सा धागा निष्पादित किया जाना चाहिए। चूंकि संदर्भ स्विच अपेक्षाकृत महंगे हैं (आमतौर पर स्रोत कोड के माध्यम से) कम से कम यह ट्यून करने के लिए कि शेड्यूलर स्विच आक्रामक रूप से कैसे संभव है; स्विचिंग थ्रेड्स अधिक बार सिस्टम को अधिक संवेदनशील बनाने का कारण बनता है, लेकिन स्विचिंग ओवरहेड का अर्थ है कि दिए गए कार्यों को पूरा करने के लिए समग्र समय लंबा है। सबसे तेजसिस्टम वह होगा जो केवल थ्रेड्स के बीच स्विच करता है जब रनिंग थ्रेड को चलाना संभव नहीं होता है (इसका अर्थ है कि यह किसी चीज़ पर प्रतीक्षा करने से अवरुद्ध हो जाता है, या इसने अपना काम पूरा कर लिया है) क्योंकि यह ओवरहेड को कम करता है, जबकि सबसे उत्तरदायी सिस्टम थ्रेड्स के बीच स्विच करेगा हर बार शेड्यूल करने वाले को आमंत्रित किया जाता है क्योंकि किसी विशेष थ्रेड के सीपीयू समय से पहले प्रतीक्षा करने के लिए औसत समय को कम करता है। आदर्श सेटिंग आमतौर पर इन दोनों के बीच में होती है, और उन विकल्पों के बीच के व्यापार की संभावना एक बड़ा कारण है कि लिनक्स कर्नेल कॉन्फ़िगरेशन के माध्यम से कई शेड्यूलरों के साथ-साथ कुछ ट्यूनिंग मापदंडों को चुनने का प्रस्ताव देता है।
दूसरी ओर सहकारी रूप से मल्टीटास्किंग ओएस और वातावरण, ( विंडोज़ 3.x एक उदाहरण है), नियमित रूप से शेड्यूलर पर नियंत्रण को कम करने के लिए प्रत्येक एप्लिकेशन पर भरोसा करते हैं। आमतौर पर एक एपीआई फ़ंक्शन विशेष रूप से ऐसा करने के लिए होता है, और अक्सर कई एपीआई फ़ंक्शन इसे अपने आंतरिक निष्पादन प्रवाह के हिस्से के रूप में करेंगे, क्योंकि यह उपयोगकर्ता के अनुभव को चिकना बनाने में मदद करता है। वह डिज़ाइन दृष्टिकोण तब तक अच्छी तरह से काम करता है जब तक कि सभी अनुप्रयोग अच्छी तरह से व्यवहार किए जाते हैं और किसी भी लंबे समय तक चलने वाले संचालन (एक दूसरे के छोटे अंश से अधिक लंबे समय तक चलने वाले अर्थ) के दौरान छोटे अंतराल के साथ नियंत्रण को नियंत्रित करते हैं, लेकिन एक ऐसा अनुप्रयोग जो ऊपर नहीं चढ़ सकता है पूरी प्रणाली। यह एक बड़ा कारण है कि विंडोज 3.x ने मेरे द्वारा उल्लिखित मल्टीटास्किंग टेस्ट पर इतना खराब प्रदर्शन किया, जबकि ओएस / 2समान हार्डवेयर पर समान कार्य करते हुए पूरी तरह से टहलते हुए: एक एप्लिकेशन फ़्लॉपी डिस्क ड्राइव को एक निश्चित क्षेत्र लिखने के लिए कह सकता है, और कॉल लौटने से पहले ऐसा करने में लगने वाला समय वास्तव में औसत दर्जे का हो सकता है (दसियों से सैकड़ों मिलीसेकंड या अधिक); प्रीमेचटली मल्टीटास्किंग सिस्टम के अपने शेड्यूलर ब्रेक पर उसके शेड्यूलर ब्रेकडाउन पर होगा, ध्यान दें कि जो थ्रेड वर्तमान में "रनिंग" है, वह वास्तव में राइट कॉल द्वारा ब्लॉक किया गया है और बस दूसरे थ्रेड पर स्विच किया जा सकता है जो कि रनने योग्य है। (व्यवहार में यह थोड़ा अधिक शामिल है, लेकिन यह सामान्य विचार है।)
दोनों पूर्ववर्ती मल्टीटास्किंग और सहकारी वातावरण में, अलग-अलग थ्रेड्स के अलग-अलग प्राथमिकताएं होने की संभावना है। उदाहरण के लिए, समय पर फैशन को अंजाम देना अधिक महत्वपूर्ण है कि जिस थ्रेड को सिस्टम टाइम डिस्प्ले अपडेट करता है, उसकी तुलना में संचार लिंक पर डेटा प्राप्त हो रहा है, इसलिए प्राप्त थ्रेड में उच्च प्राथमिकता होती है और टाइम डिस्प्ले अपडेशन थ्रेड की प्राथमिकता कम होती है। । थ्रेड प्राथमिकताएं शेड्यूलर के निर्णय में एक भूमिका निभाती हैं कि कौन सा धागा निष्पादित करने की अनुमति देता है (उदाहरण के लिए, बहुत सरल, उच्च प्राथमिकता वाले थ्रेड्स को हमेशा कम प्राथमिकता वाले थ्रेड्स से पहले निष्पादित करना चाहिए, इसलिए भले ही कम प्राथमिकता वाले धागे के पास काम करने के लिए छोड़ दिया गया हो, यदि उच्च प्राथमिकता वाला धागा रनवेबल हो जाता है, तो यह पूर्ववर्ती है), लेकिन इस तरह के विशिष्ट शेड्यूलिंग निर्णय अंतर्निहित तंत्र डिजाइन को प्रभावित नहीं करते हैं।