मुझे थ्रेडपूल का उपयोग नेट में कब नहीं करना चाहिए?

मुझे .NET में ThreadPool का उपयोग कब नहीं करना चाहिए?

ऐसा लगता है कि थ्रेडपूल का उपयोग करने का सबसे अच्छा विकल्प है, इस मामले में, यह एकमात्र विकल्प क्यों नहीं है?

इस के आसपास आपके अनुभव क्या हैं?

 0
जोड़ा संपादित
विचारों: 27
स्रोत

9 उत्तर

The only reason why I wouldn't use the ThreadPool for cheap multithreading is if I need to…

  1. चल रहे विधि के साथ इंटरैक्ट करें (उदा।, इसे मारने के लिए)
  2. एक कोड STA थ्रेड के लिए यह एमएसडीएन संदर्भ पृष्ठ (यह मेरे साथ हुआ)
  3. मेरे आवेदन की मृत्यु हो जाने के बाद धागा को जीवित रखें ( थ्रेडपूल धागे पृष्ठभूमि धागे हैं)
  4. यदि मुझे थ्रेड की प्राथमिकता बदलने की आवश्यकता है। हम ThreadPool में थ्रेड की प्राथमिकता को नहीं बदल सकते हैं जो डिफ़ॉल्ट रूप से सामान्य है।

PS: एमएसडीएन लेख " प्रबंधित थ्रेड पूल " शीर्षक वाला एक अनुभाग है, " जब थ्रेड पूल थ्रेड का उपयोग न करें ", के साथ थ्रेड पूल का उपयोग न करने के संभावित कारणों की बहुत समान लेकिन थोड़ी अधिक पूरी सूची।

ThreadPool को छोड़ने के कई कारण हैं, लेकिन यदि आप उन्हें नहीं जानते हैं तो ThreadPool आपके लिए पर्याप्त होना चाहिए।

वैकल्पिक रूप से, नए समांतर एक्सटेंशन फ्रेमवर्क , जिसमें वहां कुछ साफ चीजें हैं जो ThreadPool का उपयोग किए बिना आपकी आवश्यकताओं के अनुरूप हो सकती हैं।

0
जोड़ा Will
स्रोत
@Mou: मैं कहता हूं कि मुझे नहीं पता कि आप क्या कहने की कोशिश कर रहे हैं, दुर्भाग्य से।
जोड़ा लेखक Will, स्रोत
यदि आप इसे पढ़ रहे हैं, तो आपको अब थ्रेडपूल के बजाय कार्य का उपयोग करना चाहिए।
जोड़ा लेखक Will, स्रोत
@Mou यह msdn.microsoft.com/en पढ़ें -US/पुस्तकालय/h339syd0 (v = vs.110) .aspx
जोड़ा लेखक Will, स्रोत
आपने कहा: - मेरे आवेदन की मृत्यु हो जाने के बाद धागा को जीवित रखें (थ्रेडपूल धागे पृष्ठभूमि धागे हैं) लेकिन मुझे पता है कि पृष्ठभूमि थ्रेड हमेशा मुख्य धागे के साथ समाप्त होता है। तो आप क्या कहते हैं ??
जोड़ा लेखक Mou, स्रोत
आपने कहा <कोड> मेरे आवेदन की मृत्यु हो जाने के बाद धागा को जीवित रखें (थ्रेडपूल धागे पृष्ठभूमि धागे हैं) ... क्या मैं सही हूँ। क्या यह सच है ? यदि थ्रेड पूल थ्रेड पृष्ठभूमि थ्रेड है तो थ्रेड चला सकता है जब मुख्य धागा मर जाता है? plzz समझाओ
जोड़ा लेखक Mou, स्रोत
मैंने मुद्दों # 1 में चलाया है (एक तृतीय-पक्ष लाइब्रेरी में लंबे समय से चलने वाले (5+ मिनट) "शुद्ध" (पर्याप्त) फ़ंक्शन कॉल को रद्द करना टोकन समर्थन) और # 2 (समवर्ती wpf ImageSource प्रतिपादन ... प्रत्येक समवर्ती एक ही एसटीए थ्रेड पर शुरू करने और समाप्त करने की आवश्यकता है, लेकिन उसी एप्लिकेशन में फिर से अन्य धागे से प्रदर्शित किया जा सकता है), इसलिए यह मेरे लिए सही जवाब है। अधिकांश समय, प्रबंधित थ्रेड पूल (या टीपीएल जैसी अन्य अरब चीजों में से एक जो अंत में इसका उपयोग करता है) सही है, लेकिन कभी-कभी सही जवाब वास्तव में एक नया थ्रेड स्पिन करना और आपके जीवन के साथ आगे बढ़ना है।
जोड़ा लेखक Joe Amenta, स्रोत

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

0
जोड़ा
स्रोत

जब भी आपके पास कार्यकर्ता धागे की अवधारणा होती है तो थ्रेड पूल समझ में आता है। जब भी आप आसानी से छोटी नौकरियों में प्रसंस्करण का विभाजन कर सकते हैं, जिनमें से प्रत्येक को स्वतंत्र रूप से संसाधित किया जा सकता है, कार्यकर्ता धागे (और इसलिए एक धागा पूल) समझ में आता है।

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

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

0
जोड़ा
स्रोत
क्या आप टिप्पणी को समझा सकते हैं "प्रसंस्करण करते समय थ्रेड पूल समझ में नहीं आता है"? मान लीजिए मेरे पास काम करने वाले आइटम हैं जिन्हें संपीड़ित करने की आवश्यकता है, फिर एन्क्रिप्टेड, और संपीड़न 10x गणना को एन्क्रिप्शन के रूप में उपयोग करता है। कंप्रेसर के 10: 1 अनुपात के साथ एन्क्रिप्टर थ्रेड के साथ थ्रेडपूल का उपयोग क्यों न करें?
जोड़ा लेखक Cheeso, स्रोत
थ्रेड पूल आमतौर पर तब होते हैं जब एक कार्यक्रम स्वतंत्र होता है, काम करने के अलग-अलग टुकड़े होते हैं। यदि कार्यकर्ता धागे (जैसे पाइपलाइन में) के बीच संचार है, तो आपके पास वास्तव में थ्रेड पूल परिदृश्य नहीं है।
जोड़ा लेखक Derek Park, स्रोत

@ एरिक, मुझे डीन से सहमत होना होगा। धागे महंगी हैं। आप यह नहीं मान सकते कि आपका प्रोग्राम केवल एक ही चल रहा है। जब हर कोई संसाधनों से लालची होता है, तो समस्या बढ़ जाती है।

मैं अपने धागे मैन्युअल रूप से बनाना और उन्हें स्वयं नियंत्रित करना पसंद करता हूं। यह कोड को समझने में बहुत आसान रखता है।

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

  थ्रेड टी = नया थ्रेड (नया थ्रेडस्टार्ट (कुछ करना));
t.Start ();
t.Join ();

मुझे आशा है कि आपके पास आमतौर पर प्रारंभ() और Join() के बीच कुछ अतिरिक्त कोड होगा। अन्यथा, अतिरिक्त धागा बेकार है, और आप किसी भी कारण से संसाधन बर्बाद कर रहे हैं।

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

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

गंभीरता से, ज़िंदगी को ज़्यादा जटिल बनाने की ज़रूरत नहीं है। थ्रेड पूल का उपयोग न करें जब तक कि आपको कुछ विशिष्ट विशिष्टता की आवश्यकता न हो।

वास्तव में। जीवन को और अधिक जटिल मत बनाओ। यदि आपके कार्यक्रम को कई कार्यकर्ता धागे की आवश्यकता है, तो पहिया को फिर से न करें। थ्रेड पूल का प्रयोग करें। यही कारण है कि यह वहाँ है। क्या आप अपनी खुद की स्ट्रिंग क्लास रोल करेंगे?

0
जोड़ा
स्रोत
टीआईएस काफी जवाब है। लेकिन इस समय 22 अपवॉट्स? यह वह अच्छा नहीं है। रेडमंड से बाहर एक बड़ा मतदाता नहीं चल रहा है, है ना?
जोड़ा लेखक Will, स्रोत
@ डेरेक पार्क: और आपको नहीं करना चाहिए। मैंने एनएए ध्वज के कारण यहां दिखाया। फिर, जलती हुई ईर्ष्या से, टिप्पणी छोड़ दी। बस चुटकुले
जोड़ा लेखक Will, स्रोत
@Will, यह एक 4 साल पुरानी टिप्पणी है। यह औसत प्रति माह आधे से ऊपर की औसत औसत है। शायद ही अविश्वसनीय स्तर के वोट।
जोड़ा लेखक Derek Park, स्रोत
@ ह्वाइचर्स, इसका आधा जवाब, आधा जवाब है। जब यह पोस्ट किया गया था तो इस पर टिप्पणियां नहीं थीं, और मैं अपने सभी पुराने उत्तरों से गुज़रने और उन्हें टिप्पणियों में बदलने के लिए समय बर्बाद करने के लिए तैयार नहीं हूं।
जोड़ा लेखक Derek Park, स्रोत
@ विल, कोई चिंता नहीं। मुझे पता था कि आप मतदाता के बारे में मजाक कर रहे थे (हम 4 वर्षों में 22 से अधिक वोट प्रबंधित कर सकते थे), लेकिन यह सुनिश्चित नहीं था कि आप "यह नहीं है वह अच्छी" टिप्पणी के बारे में आप कितने गंभीर थे। :)
जोड़ा लेखक Derek Park, स्रोत
विचार यह है कि किसी को किसी के कोड को नहीं मानना ​​चाहिए, केवल एक ही चीज चल रही है आईएमएचओ 10/00 से अधिक समय लेने की अपेक्षा की जाने वाली किसी भी महत्वपूर्ण संख्या के संचालन के लिए थ्रेडपूल धागे का उपयोग करके विरुद्ध तर्क है। यदि किसी एप्लिकेशन के एक हिस्से का प्रदर्शन I/O पूर्णता कॉलबैक के समय पर निष्पादन पर निर्भर है, तो एप्लिकेशन का एक और हिस्सा लंबे समय से चलने वाले तरीकों के साथ थ्रेडपूल कतार भरने से पहले भाग के प्रदर्शन को पहले भाग के प्रदर्शन से अधिक खराब कर सकता है दूसरा भाग असतत धागे का उपयोग करता है, विशेष रूप से यदि वे विधियां अवरुद्ध करने में काफी समय व्यतीत करती हैं।
जोड़ा लेखक supercat, स्रोत
कुछ लोग अपने स्वयं के रैपर को चारों के सरणी पर घुमाते हैं और इसे स्ट्रिंग की तरह इस्तेमाल करते हैं .. इसलिए यह संभव है ... और यह भी उदास है।
जोड़ा लेखक Andrei Rînea, स्रोत
मैंने इसे वोट दिया। यह एक जवाब नहीं है; यह किसी और के लिए एक जवाब है।
जोड़ा लेखक hwiechers, स्रोत

@Eric

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

क्या आप अपने द्वारा लिखे गए कार्यक्रमों के लिए एकमात्र लक्षित ग्राहक हैं? यदि नहीं, तो आप इसके बारे में निश्चित नहीं हो सकते हैं। जब आप एक प्रोग्राम लिखते हैं तो आपको आम तौर पर कोई जानकारी नहीं है कि क्या यह प्रभावी ढंग से एकल निष्पादित करेगा, या यदि यह एक डीडीओएस हमले से हथियाने वाले वेबसर्वर पर चलाएगा। आप नहीं जानते कि आप कितने CPU समय के लिए जा रहे हैं।

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

आम तौर पर, यह जानने का दावा करना कि आपका प्रोग्राम कैसा व्यवहार करेगा, दूर तक पहुंचाया जा रहा है, और मशीन के बारे में सबकुछ जानने का दावा लुभावना है।

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

मैं पूरी तरह से असहमत नहीं हूं, लेकिन मैं वास्तव में नहीं देखता कि यह कैसे प्रासंगिक है। यह साइट यहां विशेष रूप से है क्योंकि प्रोग्रामर के पास हमेशा सभी जवाब नहीं होते हैं।

यदि आपका आवेदन आपके द्वारा उपयोग किए जाने वाले धागे की संख्या को थ्रॉटल करने की आवश्यकता के लिए पर्याप्त जटिल है, तो क्या आप हमेशा फ्रेमवर्क की तुलना में अधिक नियंत्रण नहीं चाहते हैं?

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

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

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

0
जोड़ा
स्रोत

मैं केवल किसी के साथ बात नहीं कर रहा हूं   सैद्धांतिक ज्ञान यहाँ। मैं लिखता हूँ   और उच्च मात्रा अनुप्रयोगों को बनाए रखने   जो multithreading का भारी उपयोग करते हैं,   और मुझे आम तौर पर धागा नहीं मिलता है   सही जवाब होने के लिए पूल।

आह, अधिकार से तर्क - लेकिन हमेशा उन लोगों के लिए देखो जो विंडोज कर्नेल टीम पर हो सकते हैं।

हम में से कोई भी इस तथ्य से बहस नहीं कर रहा था कि यदि आपके पास कुछ विशिष्ट आवश्यकताएं हैं तो .NET ThreadPool सही चीज़ नहीं हो सकती है। हम जो थ्रेड कर रहे हैं वह थ्रेड बनाने की मशीन पर लागत का trivialisation है।

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

एक आधुनिक मशीन में मेमोरी पदानुक्रम का आकार का मतलब है कि एक सीपीयू 'विचलित करना' सबसे बुरी चीज है जो आप संभवतः कर सकते हैं, और जो लोग अपने शिल्प की परवाह करते हैं, उन्हें इससे बचने के लिए कड़ी मेहनत करनी चाहिए।

0
जोड़ा
स्रोत

थ्रेडपूल थ्रेड उन कार्यों के लिए उपयुक्त हैं जो निम्न मानदंडों को पूरा करते हैं:

  1. The task will not have to spend any significant time waiting for something to happen
  2. Anything that's waiting for the task to finish will likely be waiting for many tasks to finish, so its scheduling priority isn't apt to affect things much.

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

0
जोड़ा
स्रोत

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

बेशक दो चेतावनी:

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

एमएसडीएन की यहां कुछ कारण हैं:

http://msdn.microsoft.com/en-us/library/0ka9477y.aspx

There are several scenarios in which it is appropriate to create and manage your own threads instead of using thread pool threads:

  • You require a foreground thread.
  • You require a thread to have a particular priority.
  • You have tasks that cause the thread to block for long periods of time. The thread pool has a maximum number of threads, so a large number of blocked thread pool threads might prevent tasks from starting.
  • You need to place threads into a single-threaded apartment. All ThreadPool threads are in the multithreaded apartment.
  • You need to have a stable identity associated with the thread, or to dedicate a thread to a task.
0
जोड़ा
स्रोत