मल्टीथ्रेडिंग बनाम मल्टी-इंस्टेंसिंग - कौन सा चयन करना है?

Question

यह बीच एक बड़ा अंतर हो जाएगा इस दो scenarious:

1. एक आवेदन के कहने 100 धागे कुछ नौकरियों
एक ही आवेदन की
2. 10 उदाहरणों पर कार्रवाई करने के बनाता है 10 धागे प्रत्येक नौकरियों पर कार्रवाई करने के बनाता है (कुल 100)

दोनों मामलों में धागे की संख्या समान होगी। क्या यह कुछ प्रदर्शन या किसी एक के दूसरे में सुधार है?

इंस्टेंस - उदाहरण के लिए कंसोल एप्लिकेशन है, इसलिए दूसरे मामले में यह 10 कंसोल एप्लिकेशन चल रहा होगा। प्रत्येक एप्लिकेशन में यह स्वयं का फ़ोल्डर है।

Answer 1

एक थ्रेड एक प्रक्रिया से कम संसाधनों का उपयोग करता है ताकि सैद्धांतिक रूप से विकल्प 1 "बेहतर" होगा। हालांकि, आप शायद दोनों के बीच बहुत अंतर नहीं देखेंगे, क्योंकि 100 अलग-अलग धागे या प्रक्रियाएं एक साथ चल रही हैं और एक ही ओ/एस संसाधनों के लिए लड़ रही हैं, यह आपके सिस्टम को रोकने के लिए बहुत अधिक गारंटी है।

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

ThreadPool वर्ग, या अधिमानतः, सब के ऊपर कई उच्च स्तर कपोल-कल्पना में से एक (जैसे task library, या यहाँ तक कि सादे पुराने asynchronous delegates) देखें।

Answer 2

इस तरह का एक अजीब सवाल, व्यावहारिक अनुप्रयोग खोजने में मुश्किल है .. लेकिन मुझे लगता है कि विकल्प 1 प्रदर्शन दृष्टिकोण से बेहतर होगा। एक ही ऐप के 10 उदाहरण चलने के साथ, ऐसा लगता है कि ऐसा और अधिक काम किया जाएगा। (सफाई, पंजीकरण, कंसोल ओपन, ect)

संपादित करें * क्योंकि विकल्प 1 के साथ, आप काम को कतार में डाल सकते हैं और थ्रेड को लोड को संभालने दें।

Answer 3

विकल्प 2 है (कम से कम) के बाद ओवरहेड्स:

• अधिक प्रक्रिया वस्तुओं प्रक्रिया स्थिर स्मृति प्रति
• अधिक
• CLR और jitted कोड के अधिक उदाहरणों
• प्रसंग स्विच करने की आवश्यकता है पता स्थान स्विच करें (बहुत महंगा)
• एप्लिकेशन डेटा संरचनाओं को साझा करने के कम अवसर
• आपको सीआर की आवश्यकता है ओएसएस-प्रक्रिया संचार। सरल विधि कॉल आईपीसी संचालन बन
• के लिए कीड़े के लिए आप
• अधिक अवसरों (आईपीसी संचार, कांटा बम, ...)
• इससे भी बदतर debuggability
• thread- के माध्यम से नहीं निर्मित लोड संतुलन अधिक काम पूल
• कठिन और अधिक त्रुटि-प्रवण सिंक्रनाइज़ेशन। कम अंतर्निहित सामान और धीमी

यदि आप चुन सकते हैं (2) यदि आप (1) चुन सकते हैं तो आप क्यों चुनेंगे? वैध कारण हैं, लेकिन वे विशेष हैं:

• आपको मनमाने ढंग से स्मृति भ्रष्टाचार को सहन करने में सक्षम होना चाहिए। यह मामला सामान्य नहीं है (बिल्कुल नहीं!)
• आपको धागे को मारने की क्षमता की आवश्यकता है। यह एकल धागे के लिए सीएलआर के अंदर भरोसेमंद नहीं किया जा सकता है। लेकिन आप इसे सहकारी रूप से कर सकते हैं जो आमतौर पर बेहतर विकल्प है
• आपके थ्रेड को विभिन्न उपयोगकर्ताओं और ऐसे में चलाने की आवश्यकता है। यह लगभग कभी नहीं होता है।

सामान्य रूप से, कम प्रक्रिया बेहतर होती है।

Answer 4

हां, यह एक बड़ा अंतर होगा। प्रत्येक दृष्टिकोण में पेशेवर और विपक्ष हैं:

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

मैं व्यक्तिगत रूप से एक प्रक्रिया/कई धागे पसंद करूंगा। हालांकि, यह वास्तव में कार्य पर निर्भर करता है।

Answer 5

यह आपके द्वारा किए जा रहे कार्यों पर निर्भर करता है, लेकिन ज्यादातर मामलों में विकल्प 1 का सर्वश्रेष्ठ प्रदर्शन होगा और साथ काम करना सबसे आसान होगा।

• 100 धागे सभी एक ही कार्य कर रहे हैं:
  आप एक अधिक पूरा जवाब मैं निम्नलिखित पता करने की आवश्यकता होगी देने के लिए?
• क्या 100 थ्रेड एक ही डेटा तक पहुंच रहे हैं?
• क्या थ्रेडों द्वारा प्राकृतिक डाउन टाइम होने के लिए किए गए कार्यों (किसी अन्य प्रक्रिया को समाप्त करने या संसाधन उपलब्ध होने का इंतजार कर रहे हैं)?
• क्या थ्रेड द्वारा प्रबंधित किए गए कार्यों को सीमित संसाधन (जैसे हार्ड डिस्क या नेटवर्क कार्ड) तक पहुंचने का प्रयास करने के लिए जा रहे हैं?
• आपके कंप्यूटर एक समय में कितने एक साथ संभाल सकता है (उदाहरण के लिए हाइपर-थ्रेडिंग के साथ 4 कोर प्रोसेसर 8 थ्रेड को संभाल सकता है, हाइपर-थ्रेडिंग के बिना 4 कोर प्रोसेसर 4 थ्रेड को संभाल सकता है)?
• धागे पर कुछ गलत होने पर क्या होता है? प्रक्रिया क्रैश है, धागा फिर से शुरू किया गया है?

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

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

चूंकि कई उत्तर आपकी परियोजना को कार्यान्वित करने के बारे में सलाह दे रहे हैं, यह जानकर कि प्रत्येक थ्रेड को सीपीयू का पूरी तरह से उपयोग करने के लिए डिज़ाइन किया गया है या नहीं, या यदि ये पृष्ठभूमि कार्य हैं जो पहले थोड़ी सी काम करते हैं सोने के लिए वापस जाने से हमें आपकी स्थिति के लिए सुझाव सही करने में मदद मिलेगी।

यह जानना कि प्रक्रिया किस हार्डवेयर पर चल रही है, हमें आपकी स्थिति के लिए सुझाव प्रदान करने में मदद मिलेगी।

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

---

क्रिश्चियन हैटर का विकल्प 3 समझ में आता है, लेकिन सी # के साथ हमेशा प्रासंगिक नहीं होता है।
आप documentation को देखें, तो यह कहा गया है:

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

असल में इसका मतलब है कि नेट फ्रेमवर्क आपके धागे को पूल करेगा यदि ऐसा लगता है कि यह एक अच्छा विचार होगा। यदि आपकी प्रक्रियाएं अधिक धागे का उपयोग कर रही हैं, तो यह अधिक होने की संभावना है, जबकि कुल धागे की संख्या बहु-थ्रेडेड प्रक्रियाओं के बीच शायद समान ही रहेगी। नतीजतन मैं 1 प्रक्रिया, 100 धागे समाधान कम कुल धागे का उपयोग करने के लिए 10 प्रक्रियाओं, 10 धागे प्रत्येक (10 से 40 की तरह कुछ, लेकिन आपको जांचना होगा) की उम्मीद होगी।

कहा जा रहा है कि ढांचा अनुमान लगाएगा, इसलिए कुछ मामलों में थ्रेड पूल बेहतर विकल्प होगा। पहले documentation को पढ़ना सुनिश्चित करें, क्योंकि कुछ ऐसे मामले हैं जहां थ्रेड पूल का उपयोग नहीं किया जाना चाहिए। पूल पर एक त्वरित ट्यूटोरियल MSDN पर पाया जा सकता है। thread भी है जो थ्रेड पूल का उपयोग करने पर रोक लगाता है।

---

यदि आप अधिक जानकारी प्रदान करते हैं तो मैं एक और सटीक उत्तर देने का प्रयास करूंगा। अन्यथा विकल्प 1 (और संभवतः विकल्प 3) अधिकांश स्थितियों में बेहतर विकल्प हैं।