2012-03-07 7 views
11

मैं मल्टीथ्रेडिंग के बारे में सीख रहा हूं, लेकिन कुछ ट्यूटोरियल्स पढ़ने के बाद मैं उलझन में हूं। मुझे समझ में नहीं आता कि मल्टीथ्रेडिंग एक एप्लिकेशन को कैसे बढ़ा सकती है।multithreading एक एप्लिकेशन को गति कैसे बढ़ा सकता है (जब थ्रेड एक साथ चल नहीं सकते हैं)?

अंतर्ज्ञान से, मैं कहूंगा कि मल्टीथ्रेडिंग एक एप्लिकेशन को धीमा कर देती है, क्योंकि आपको लगातार उन सेफफोर्स के लिए इंतजार करना पड़ता है।

मल्टीथ्रेडिंग एक अनुप्रयोग को गति कैसे और कब कर सकता है, जब थ्रेड एक साथ नहीं चल सकते हैं?

+0

मल्टीथ्रेडिंग एक से अधिक प्रोसेसर, या हाइपरथ्रेडिंग क्षमता वाले प्रोसेसर के दौरान एक एप्लिकेशन को गति देता है। अन्यथा यह नहीं कर सकता है। –

+1

क्या आप पूछ रहे हैं कि क्या यह एकाधिक धागे होने के लायक है भले ही वे एक साथ नहीं चल सकते हैं? –

+8

करीबी वोट से असहमत है, यह एक आसान सवाल है कि आकर्षक जवाब हो सकते हैं। –

उत्तर

11

दो तरीकों से मैं सोच सकता हूं, जिनमें से पहला शायद "समांतर थ्रेडिंग" से आपका मतलब है।

  • यदि आपके पास एकाधिक CPUs या कोर हैं, तो यदि आप एकाधिक थ्रेड चला रहे हैं तो वे एक साथ काम कर सकते हैं।
  • एकल कोर मामले में, यदि आपका धागा समाप्त होता है (सिंक्रोनस) I/O की प्रतीक्षा करता है, तो मान लें कि आप टेप से 100 एमबी पढ़ने के लिए पढ़ते हैं() एक और थ्रेड निर्धारित हो सकता है और प्रतीक्षा करते समय काम पूरा कर सकता है।
+1

टेप से पढ़ें? कितना अजीब। एक बेहतर उदाहरण एक धीमी नेटवर्क कनेक्शन होगा। –

+1

एक थ्रेड के साथ कुछ पढ़ते समय, और 'साथ-साथ' (नोट: मैं एक सिंगल-कोर सिस्टम के बारे में बात कर रहा हूं) एक और धागे के साथ काम कर रहा हूं: क्या यह वास्तव में मेरे आवेदन को तेज करेगा, या यह सिर्फ एक सुविधा है? यदि आप सभी एक धागे में करते हैं तो क्या यह वही गति नहीं होगी? यदि नहीं, तो क्यों नहीं? – xcrypt

+1

+1 टेप के लिए, के रूप में मैं सिर्फ ZX स्पेक्ट्रम संदर्भ :) एक प्रोसेसर कोर के मामले में –

3

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

अनिवार्य लिंक: http://en.wikipedia.org/wiki/Amdahl's_law

इसके अलावा, के रूप में मार्क Ransom कहा, यदि आपका हार्डवेयर वास्तव में एक ही बार में 1 से अधिक बात नहीं कर सकते, तो सूत्र वास्तव में सिर्फ तार्किक एक ही समय में (स्वैप करके) से चल रहे हैं वास्तव में एक ही समय में चल रहा है। हालांकि आईओ अवरोधन के साथ हालात में यह अभी भी उपयोगी हो सकता है।

0

मल्टीथ्रेडिंग की अवधारणा से 'समानांतर थ्रेडिंग' को हटाने से यह व्यर्थ हो जाता है - यदि आप थ्रेड को एक ही समय में निष्पादित करने की अनुमति नहीं देते हैं तो आपके पास जो भी मिला है वह प्रसंस्करण की एक धारा है जो बहुत समय बिताती है ओएस के शेड्यूलर में hopping।

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

3

क्योंकि आपको लगातार उन सेफफोर्स का इंतजार करना पड़ता है।

केवल एक खराब डिज़ाइन किया गया कार्यक्रम में या एक एकल प्रोसेसर मशीन पर समानांतर काम के लिए बनाया गया एक में

। एक अच्छी तरह से डिज़ाइन किए गए प्रोग्राम में, थ्रेड सिंक्रनाइज़ेशन पॉइंट्स के बीच समानांतर में उपयोगी काम करते हैं, और सिंक्रनाइज़ेशन के ओवरहेड से अधिक होने के लिए पर्याप्त है।

समानांतर (मल्टीकोर/मल्टीप्रोसेसर) प्रसंस्करण के बिना भी, थ्रेड्स I/O अवरुद्ध करते समय मल्टीथ्रेडिंग लाभकारी हो सकती है। उदाहरण के लिए, पुराने पुराने CVSup कार्यक्रमों ने नेटवर्क कनेक्शन 'डुप्लेक्स क्षमताओं का पूरा उपयोग करने के लिए सिंगल-कोर युग में मल्टीथ्रेडिंग का उपयोग किया। जबकि एक थ्रेड लिंक पर पहुंचने के लिए डेटा की प्रतीक्षा कर रहा था, दूसरा डेटा को दूसरी तरफ धक्का दे रहा था।नेटवर्क विलंबता के कारण, दोनों थ्रेडों को जरूरी समय इंतजार करना पड़ता था, जिसके दौरान अन्य धागे उपयोगी काम कर सकते थे।

0

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

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

1

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

एकल कोर मशीनों में, एकाधिक धागे के साथ एक एकल कार्य चलाना निश्चित रूप से ऊपर वर्णित तथ्य के कारण धीमा हो जाएगा।

धागे का एक और उपयोग ui उत्तरदायी रखना है, एक परिदृश्य की कल्पना करें जब आपको एक भारी आई/ओ संचालन करने की आवश्यकता होती है, जैसे किसी डिवाइस से पढ़ने, नेटवर्क से डेटा लाने आदि। यदि आप उन कार्यों को मुख्य धागे में करते हैं , I/O ऑपरेशन चल रहा है, जबकि आपका UI अवरुद्ध हो जाएगा। आप अलग थ्रेड में I/O संचालन चलाकर ui अवरुद्ध से बच सकते हैं। शायद, इसका मतलब "एप्लिकेशन को तेज करना" था।

1

सीपीयू पर सबकुछ नहीं होता है। एक कंप्यूटर की कल्पना करो जिसमें धागे नहीं हैं। माउस कुछ से पहुंचने के लिए नेटवर्क पैकेट के लिए इंतज़ार कर अनुरोध को पूरा करने

  • हार्ड ड्राइव के लिए इंतज़ार कर
  • प्रतिक्रिया करने के लिए के लिए इंतज़ार कर
  • प्रतिक्रिया करने के लिए कीबोर्ड के लिए इंतज़ार कर

    • : यह कंप्यूटर समय की बहुत बड़ी मात्रा में बर्बाद करेंगे गंतव्य

    और इसी तरह। असल में, ऐसा कंप्यूटर सीपीयू के साथ कुछ भी करने में सक्षम नहीं होगा, अगर एक प्रणाली को कम से कम इंटरैक्टिव होने के लिए डिज़ाइन किया गया है।

    वही बात, कुछ हद तक, एक प्रक्रिया पर लागू होती है यानी आपका आवेदन।

    संपादित करें:

    इससे पहले कि 'अच्छा' कर्नेल ऐसे 286 के रूप में है और वहाँ से, ओएस-एस (या आदिम-ओएस-ते) बीच में आता है से निपटने के द्वारा बहु सूत्रण का अनुकरण कर रहे थे '' अच्छा प्रोसेसर पर चलने वाले। यहां तक ​​कि ज़ेडएक्स स्पेक्ट्रम ने कीबोर्ड को संभालने में बाधा डाली थी, उदाहरण के लिए (अगर मुझे सही याद है)।

  • +0

    ज्यादा नहीं बदला है। आधुनिक प्रीपेप्टिव ओएस पर मल्टीथ्रेडिंग हार्डवेयर संकेतों के लिए तेजी से राहत के लिए इंटरप्ट पर बिल्कुल 100% निर्भर है। –

    2

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

    एकाधिक धागे का उपयोग करके, पृष्ठभूमि में डाउनलोड होने पर आप अपने ब्राउज़र का उपयोग जारी रख सकते हैं।

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

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

    +0

    मुझे यकीन नहीं है कि नियंत्रण जीयूआई में वापस आने के साथ क्या मतलब है? क्या यह कुछ ओएस-विशिष्ट है? मैं केवल किसी भी प्रकार के ग्राफिक्स के लिए डायरेक्टएक्स से परिचित हूं, इसलिए मैं आमतौर पर अपने स्वयं के जीयूआई सिस्टम को कोड करता हूं – xcrypt

    +0

    @xcrypt एक थ्रेड को उपयोगकर्ता को GUI में एक बटन पर क्लिक करने के लिए सुनना होता है। यदि आपका एप्लिकेशन सिंगल थ्रेडेड है, तो उस थ्रेड को बटन से जुड़े क्रिया को भी संसाधित करना होगा। हालांकि यह क्रिया को संसाधित कर रहा है, यह उपयोगकर्ता को GUI पर क्लिक करने के लिए नहीं सुन रहा है, इसलिए जब तक कार्रवाई को संभाला नहीं जाता है तब तक एप्लिकेशन लटकता प्रतीत होता है और थ्रेड उपयोगकर्ता क्रियाओं को फिर से सुनने के लिए उपलब्ध होता है। "नियंत्रण जीयूआई में लौटा" शायद गलत वाक्यांश है। – Endophage

    +0

    ओह, मैं देखता हूं। चूंकि मैं अपने स्वयं के जीयूआई सिस्टम को कोड करता हूं, इसलिए मैं आमतौर पर उसी समस्या से निपटता नहीं हूं। फिर फिर मैं जो कर रहा हूं वह शायद इतना अनुकूल अनुकूल नहीं है x) लेकिन जीयूआई का प्रदर्शन वास्तव में कभी भी कोई समस्या नहीं है, मैं आमतौर पर वास्तविक समय सिमुलेशन में प्रदर्शन की परवाह करता हूं, जब इसकी वास्तव में आवश्यकता होती है :) – xcrypt

    0

    धागे के बारे में सोचें "एक ही समय में होने वाली चीजें"।

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

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

    अंत में, जब आप एक कोर कोर से कई कोर के साथ एक में जाते हैं, यदि आपने अपने आवेदन को सही तरीके से थ्रेड किया है, तो उन संदर्भों में वास्तव में एक साथ चलने का एक बेहतर मौका है।

    संबंधित मुद्दे