अवरुद्ध धागे को कौन से संसाधन लेते हैं

Question

एसिंक्रोनस प्रोग्रामिंग मॉडल में कोड लिखने के मुख्य उद्देश्यों में से एक (अधिक विशेष रूप से - धागे को अवरुद्ध करने के बजाय कॉलबैक का उपयोग करके) सिस्टम में अवरुद्ध थ्रेड की संख्या को कम करना है।

धागे चलाने के लिए, यह लक्ष्य स्पष्ट है, संदर्भ स्विच और सिंक्रनाइज़ेशन लागतों के कारण।

लेकिन अवरुद्ध धागे के बारे में क्या? उनकी संख्या को कम करना इतना महत्वपूर्ण क्यों है?

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

तो मेरा सवाल है: रैम के अलावा (लगभग 1 एमबी प्रति धागा?) अन्य संसाधन अवरुद्ध धागे क्या करते हैं?

और एक और अधिक व्यक्तिपरक सवाल: क्या मामलों इस कीमत वास्तव में अतुल्यकालिक कोड लिखने की परेशानी का औचित्य साबित होगा (कीमत हो सकता है, उदाहरण के लिए, beginXXX और EndXXX तरीकों की बहुत सारी करने के लिए अपने अच्छे सुसंगत विधि बंटवारे, और चलती मानकों और वर्ग चर होने के लिए स्थानीय चर)।

अद्यतन - अतिरिक्त कारण मैं उल्लेख नहीं किया था या करने के लिए पर्याप्त वजन नहीं दिया:

1. अधिक धागे

2. अधिक धागे का मतलब सांप्रदायिक संसाधनों के बारे में अधिक ताला अधिक निर्माण और के निपटान का मतलब थ्रेड जो महंगा है

3. सिस्टम निश्चित रूप से थ्रेड/रैम से बाहर चला सकता है और फिर सर्विसिंग क्लाइंट को रोक सकता है (वेब ​​सर्वर परिदृश्य में यह वास्तव में सेवा को नीचे ला सकता है)

Answer 1

तो मेरा सवाल है: राम के अलावा (लगभग 1 एमबी प्रति धागा?) अन्य संसाधन अवरुद्ध धागे क्या करते हैं?

यह सबसे बड़ा है। ऐसा कहा जा रहा है कि, एक कारण है कि .NET में थ्रेडपूल प्रति कोर के इतने सारे धागे की अनुमति देता है - 3.5 the default was 250 worker threads per core in the system में। (.NET 4 में, यह वर्चुअल एड्रेस साइज, प्लेटफ़ॉर्म इत्यादि जैसी सिस्टम जानकारी पर निर्भर करता है - अब एक निश्चित डिफ़ॉल्ट नहीं है।) थ्रेड, विशेष रूप से अवरुद्ध धागे, वास्तव में महंगी नहीं हैं ...

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

और एक और अधिक व्यक्तिपरक सवाल: क्या मामलों इस कीमत वास्तव में अतुल्यकालिक कोड लिखने की परेशानी का औचित्य साबित होगा (कीमत हो सकता है, उदाहरण के लिए, beginXXX और EndXXX तरीकों की बहुत सारी करने के लिए अपने अच्छे सुसंगत विधि बंटवारे, और चलती वर्ग फ़ील्ड होने के लिए पैरामीटर और स्थानीय चर)।

अभी, यह अक्सर दर्द होता है। यह परिदृश्य पर बहुत निर्भर करता है। .NET 4 में Task<T> कक्षा कई परिदृश्यों के लिए इसे क्रमशः बेहतर बनाती है। टीपीएल का उपयोग करके, यह एपीएम (BeginXXX/EndXXX) या यहां तक ​​कि ईएपी का उपयोग करने से पहले बहुत कम दर्दनाक है।

यही कारण है कि भाषा डिजाइनर improving this situation in the future में इतना प्रयास कर रहे हैं। उनके लक्ष्यों को एसिंक कोड लिखने के लिए बहुत आसान बनाना है, ताकि इसे अधिक बार उपयोग किया जा सके।

Answer 2

किसी भी संसाधन के अलावा अवरुद्ध धागा को लॉक हो सकता है, थ्रेड पूल आकार भी विचार किया जा सकता है। यदि आप अधिकतम थ्रेड पूल आकार तक पहुंच गए हैं (यदि मैं .NET 4 के लिए सही ढंग से याद करता हूं तो अधिकतम थ्रेड गिनती 100 प्रति सीपीयू है) तो आप थ्रेड पूल पर चलाने के लिए और कुछ भी नहीं प्राप्त कर पाएंगे जब तक कि कम से कम एक थ्रेड न हो जाए मुक्त।

Answer 3

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

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