मल्टी-थ्रेडिंग क्यों मुश्किल है, यह कैसे समझा जाए


84

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

जिस समय आपको गतिरोध और दौड़ की स्थिति के बारे में चिंता होने लगती है, मुझे यह बहुत मुश्किल लगता है, लेकिन बॉस को इसकी सराहना नहीं लगती है - मुझे नहीं लगता कि वह कभी इस पार आए हैं। बस इस पर एक ताला थप्पड़ बहुत ज्यादा रवैया है।

तो मैं उसे कैसे पेश कर सकता हूं, या यह बता सकता हूं कि वह संगामिति, समानता और बहु-थ्रेडिंग की जटिलताओं को क्यों कम कर सकता है? या शायद मैं गलत हूँ?

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


17
मल्टी-थ्रेडिंग आसान है। सही सिंक्रनाइज़ेशन कठिन है।
विनीत रेनॉल्ड्स

33
तीन लोगों को कमरे में लाओ, अधिमानतः विभिन्न लहजे के साथ, और उन्हें अलग-अलग समझाएं, समवर्ती समस्या की कुछ हिस्सों को ओवरलैपिंग करते हुए .... धीरे-धीरे।
ग्रेफेड

मल्टीथ्रेडिंग बहुत कठिन या बहुत आसान हो सकती है, जो हाथ पर और भाषा के समर्थन में समस्या पर निर्भर करता है। क्लोजर
जॉब

4
@ जॉब समवर्ती प्रोग्रामिंग हमेशा (वास्तविक विश्व परियोजनाओं में) कठिन होती है, चाहे आप किसी भी भाषा का उपयोग कर रहे हों। स्केला, क्लॉजुर या एरलंग इसे थोड़ा सा समझदार बनाते हैं जब आप इसे उन भाषाओं के साथ तुलना करना चाहते हैं जो पारस्परिक अवस्थाओं का उपयोग और प्रोत्साहित करते हैं।
चिरोन

4
इसके लिए मेरा पसंदीदा रूपक है: "क्या आप एक ही समय में नींद की गोली और एक रेचक ले लेंगे?" यहां तक ​​कि जटिल संदेश कतारों का उपयोग करते हुए, आदेश सही किए गए संगामिति का फल है । जब तक कि आपके पास इसके साथ बहुत अच्छा अनुभव न हो, कई लोगों के लिए कठिन है
टिम पोस्ट

जवाबों:


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

  2. "एक ताला थप्पड़ पर यह" है तुच्छ समाधान ... यह अपने सभी समस्याओं को हल करती है , तो आप प्रदर्शन के बारे में चिंतित नहीं हैं। उदाहरण के लिए, यदि कोई प्रदर्शन हिट होता, तो यह बताने की कोशिश करें कि उदाहरण के लिए, जब भी अटलांटा में कोई व्यक्ति किसी अन्य पुस्तक का आदेश देता है, अमेज़ॅन को पूरे पूर्वी तट पर ताला लगाना पड़ता है!


1
गणितीय जटिलता की चर्चा के लिए +1 - यह है कि मैं साझा-राज्य संगामिति में कठिनाई को कैसे समझ सकता हूं, और तर्क है कि मैं आमतौर पर संदेश-पास आर्किटेक्चर की वकालत करता हूं। -1 के लिए "उस पर एक ताला लगाओ" ... वाक्यांश ताले के उपयोग के लिए एक अप्राप्य दृष्टिकोण को दर्शाता है, जो बहुत संभावना को गतिरोध या असंगत व्यवहार के रूप में ले जाएगा (आपके कोड के ग्राहक जो विभिन्न थ्रेड्स में रहते हैं, परस्पर विरोधी बनाते हैं अनुरोध, लेकिन खुद के बीच समन्वयित न करें, ग्राहकों के पास आपके पुस्तकालय के राज्य के असंगत मॉडल होंगे)।
एदन कूली

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

@ ब्लरफ्ल: प्रोग्राम वे कर सकते हैं यदि वे कतारों से गुजरने वाले संदेश का उपयोग करने के लिए लिखे गए हों। किसी विशेष थ्रेड के लिए सभी संदेशों को एक ही कतार से
गुजरने की आवश्यकता नहीं है

4
@ डॉनल फेलो: यदि किसी गोदाम में स्टॉक में 1M विजेट्स हैं और 1M ऑर्डर एक ही इंस्टैंट पर आते हैं, तो उन सभी अनुरोधों को कुछ स्तर पर क्रमबद्ध किया जाता है, जबकि आइटमों को ऑर्डर करने के लिए कोई फर्क नहीं पड़ता कि वे कैसे संभाले जाते हैं। व्यावहारिक वास्तविकता यह है कि अमेज़ॅन के पास शायद स्टॉक में इतने सारे विजेट नहीं हैं कि आदेशों के क्रश को संसाधित करने में विलंबता सूची से बाहर होने से पहले अस्वीकार्य रूप से उच्च हो जाती है और पंक्ति में सभी को बताया जा सकता है (समानांतर में), "हम बाहर हैं। " गतिरोध को रोकने के लिए संदेश कतारें एक शानदार तरीका है, लेकिन वे सीमित संसाधन के लिए उच्च विवाद की समस्या को हल नहीं करते हैं।
ब्लर

79

बहु सूत्रण है सरल। मल्टी-थ्रेडिंग के लिए एप्लिकेशन को कोड करना बहुत आसान है।

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

कठिन हिस्सा कई धागे को जादुई तरीके से किसी साझा वस्तु को अपडेट करने की कोशिश कर रहा है। ऐसा तब होता है जब इसमें त्रुटि हो जाती है क्योंकि लोग दौड़ की स्थितियों पर ध्यान नहीं देते हैं जो मौजूद हैं।

कई लोग संदेश कतारों का उपयोग नहीं करते हैं और साझा किए गए ऑब्जेक्ट को अपडेट करने और खुद के लिए समस्याएं पैदा करने की कोशिश करते हैं।

क्या मुश्किल हो जाता है एक एल्गोरिथ्म डिजाइन करना जो कई कतारों के बीच डेटा पारित करते समय अच्छी तरह से काम करता है। यह मुश्किल है। लेकिन सह-मौजूदा थ्रेड्स (साझा कतार के माध्यम से) के यांत्रिकी आसान है।

इसके अलावा, ध्यान दें कि थ्रेड्स I / O संसाधनों को साझा करते हैं। I / O बाध्य प्रोग्राम (यानी, नेटवर्क कनेक्शन, फ़ाइल संचालन या डेटाबेस संचालन) बहुत सारे थ्रेड्स के साथ किसी भी तेज़ी से जाने की संभावना नहीं है।

यदि आप साझा किए गए ऑब्जेक्ट अपडेट की समस्या को चित्रित करना चाहते हैं, तो यह आसान है। पेपर कार्ड के एक समूह के साथ मेज पर बैठें। गणना का एक सरल सेट - 4 या 6 सरल सूत्र लिखें - पृष्ठ के नीचे बहुत सारे कमरे के साथ।

यहाँ खेल है। आप प्रत्येक एक सूत्र पढ़ते हैं, एक उत्तर लिखते हैं और उत्तर के साथ एक कार्ड लगाते हैं।

आप में से प्रत्येक आधा काम करेगा, है ना? आप आधे समय में कर रहे हैं, है ना?

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

बुरी तरह से या अन-लॉक संसाधनों के साथ दौड़ की स्थिति बनाने के कई, कई तरीके हैं।

यदि आप सभी संघर्षों से बचना चाहते हैं, तो आप कागज को सूत्रों के ढेर में काट दें। आप कतार से एक को निकालते हैं, उत्तर लिखते हैं, और उत्तर पोस्ट करते हैं। कोई विरोध नहीं है क्योंकि आप दोनों एक-पाठक-केवल संदेश कतार से पढ़ते हैं।


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

@Airsource.in वास्तव में आप "अपने पोर-पोर को स्मैक द्वारा" क्या कह रहे हैं? जब तक आपके पास एक संदेश कतार है जो दो अलग-अलग थ्रेड को एक ही संदेश लेने से रोकता है, यह एक समस्या नहीं होगी। जब तक मैं गलत समझ रहा हूं कि आपका क्या मतलब है।
जैक

25

मल्टी-थ्रेडेड प्रोग्रामिंग संभवतः संगामिति का सबसे कठिन समाधान है। यह मूल रूप से मशीन क्या वास्तव में करता है की एक निम्न स्तर अमूर्त है।

अभिनेता मॉडल या (सॉफ्टवेयर) लेनदेन स्मृति जैसे कई दृष्टिकोण हैं, जो बहुत आसान हैं। या अपरिवर्तनीय डेटा संरचनाओं (जैसे सूचियों और पेड़ों) के साथ काम करना।

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

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

लेकिन व्यवहार में, इन समस्याओं को हल करना किसी भी अन्य प्रोग्रामिंग समस्याओं की तरह ही कठिन है और उपयुक्त सार के साथ सबसे अच्छा किया जाता है। जो वास्तव में इसे काफी आसान बनाता है।


14

मुझे लगता है कि इस सवाल का एक गैर तकनीकी कोण है - IMO यह विश्वास का मुद्दा है। हम आम तौर पर जटिल ऐप्स जैसे - ओह, मुझे नहीं पता - उदाहरण के लिए फेसबुक को पुन: पेश करने के लिए कहते हैं। मैं इस नतीजे पर पहुंचा हूं कि यदि आप किसी कार्य की जटिलता को एकतरफा / प्रबंधन को बता रहे हैं - तो डेनमार्क में कुछ सड़ा हुआ है।

भले ही अन्य निंजा प्रोग्रामर 5 मिनट में कार्य कर सकते हैं, आपके अनुमान आपकी व्यक्तिगत क्षमता पर आधारित हैं। आपके वार्ताकार को या तो मामले पर अपनी राय पर भरोसा करना सीखना चाहिए या किसी ऐसे व्यक्ति को नियुक्त करना चाहिए, जिसके शब्द को वे स्वीकार करने के लिए तैयार हों।

चुनौती तकनीकी निहितार्थों को दूर करने में नहीं है, जिसे लोग या तो अनदेखा करते हैं या बातचीत के माध्यम से समझ नहीं पाते हैं, लेकिन आपसी सम्मान का रिश्ता कायम करने में।


1
दिलचस्प जवाब, हालांकि यह एक तकनीकी सवाल है। हालाँकि मैं इस बात से सहमत हूँ कि आप क्या कहते हैं ... हालाँकि इस मामले में, मेरा प्रबंधक एक बहुत अच्छा प्रोग्रामर है, हालाँकि मैं सिर्फ इसलिए सोचता हूँ क्योंकि वह मल्टी-थ्रेडेड ऐप्स की जटिलताओं में नहीं आया है, वह उन्हें कम आंकता है।
15:34 बजे मिस्टर शुब्स

6

गतिरोध को समझने के लिए एक सरल विचार प्रयोग " डाइनिंग दार्शनिक " समस्या है। उदाहरणों में से एक मैं यह बताने के लिए उपयोग करता हूं कि दौड़ की स्थिति कितनी खराब हो सकती है, यह थेरैक 25 की स्थिति है।

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


1
यानी सैंडविच की समस्या: आप सैंडविच का ढेर बनाते हैं, लेकिन इसमें केवल 1 बटर डिश और 1 चाकू होता है। आम तौर पर सभी ठीक है लेकिन अंततः किसी ने मक्खन को पकड़ लिया होगा, जबकि कोई और चाकू को पकड़ लेता है .. और फिर वे दोनों वहां खड़े होकर दूसरे के इंतजार में अपने संसाधन को जाने देते हैं।
gbjbaanb

एक सेट क्रम में हमेशा संसाधनों को प्राप्त करके इस तरह के गतिरोध के मुद्दों को हल किया जा सकता है?
कॉम्पैन जू

@ माइक्रोमैक्स, नहीं। क्योंकि 2 थ्रेड्स के लिए एक ही समय में एक ही संसाधन के लिए हथियाने की कोशिश करना संभव है, और उन थ्रेडों को जरूरी नहीं कि संसाधनों के एक ही सेट की आवश्यकता हो - समस्याओं का कारण बनने के लिए बस एक ओवरलैप। एक योजना संसाधन को "वापस" रखना है और फिर इसे फिर से हथियाने से पहले एक यादृच्छिक अवधि की प्रतीक्षा करें। यह बैकऑफ़ अवधि कई प्रोटोकॉलों में होती है, जिनमें से सबसे पहले अलोहा था। en.wikipedia.org/wiki/ALOHAnet
Tangurena

1
क्या होगा यदि कार्यक्रम के प्रत्येक संसाधन में एक संख्या थी, और जब एक थ्रेड / प्रक्रिया को संसाधनों के एक सेट की आवश्यकता होती है, तो यह हमेशा संख्यात्मक क्रम को बढ़ाने में संसाधनों को लॉक करता है? मुझे नहीं लगता कि गतिरोध हो सकता है।
22

1
@ माइक्रोमैक्स: यह वास्तव में गतिरोध से बचने का एक तरीका है। उपकरणों को डिजाइन करना संभव है जो आपको इसके लिए स्वचालित रूप से जांचने देते हैं; इसलिए यदि आपका एप्लिकेशन संख्यात्मक क्रम को बढ़ाने के अलावा संसाधनों को लॉक करने के लिए नहीं पाया जाता है, तो आपके पास संभावित गतिरोध कभी नहीं था । (ध्यान दें कि संभावित गतिरोध कभी वास्तविक गतिरोध में बदल जाते हैं जब आपका कोड किसी ग्राहक के कंप्यूटर पर चलता है)।
gnasher729

3

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

इसलिए केवल सही समवर्ती अनुप्रयोग वह है जो काफी हद तक सही है, सॉफ्टवेयर विकास में अक्सर कुछ अभ्यास नहीं किया जाता है। नतीजतन, एस.लॉट का जवाब सबसे अच्छी सामान्य सलाह है, क्योंकि संदेश गुजरना सही साबित करने के लिए अपेक्षाकृत आसान है।


3

दो शब्दों में संक्षिप्त उत्तर: OBSERVABLE NONDETERMINISM

दीर्घ उत्तर: यह इस बात पर निर्भर करता है कि समवर्ती प्रोग्रामिंग के लिए आप किस दृष्टिकोण का उपयोग करते हैं। पुस्तक कॉन्सेप्ट, टेक्निक्स, और मॉडल्स ऑफ़ कंप्यूटर प्रोग्रामिंग में , लेखक समवर्ती कार्यक्रमों को लिखने के लिए चार मुख्य व्यावहारिक दृष्टिकोणों को स्पष्ट रूप से समझाते हैं:

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

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

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

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

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


0

मुझे पहली बार सिखाया गया था कि 2 थ्रेड शुरू करने वाले एक साधारण प्रोग्राम को देखकर मुद्दों को लाया जा सकता है और उन दोनों को 1-100 से एक ही समय में कंसोल पर प्रिंट किया गया है। के बजाय:

1
1
2
2
3
3
...

आपको कुछ इस तरह से मिलता है:

1
2
1
3
2
3
...

इसे फिर से चलाएँ और आप पूरी तरह से अलग परिणाम प्राप्त कर सकते हैं।

हम में से अधिकांश को यह मानने के लिए प्रशिक्षित किया गया है कि हमारा कोड क्रमिक रूप से निष्पादित होगा। अधिकांश मल्टी-थ्रेडिंग के साथ हम इसे "आउट ऑफ द बॉक्स" नहीं ले सकते।


-3

हथौड़ों को पकड़ने वालों के बीच कुछ संचार के बिना एक ही बार में बारीकी से जगह वाले नाखूनों के एक गुच्छा में मैश करने के लिए कई हथौड़ों का उपयोग करने की कोशिश करें ... (मान लें कि वे आंखों पर पट्टी बांध चुके हैं)।

एक घर बनाने के लिए इसे बढ़ाएँ।

अब रात को सोने की कल्पना करो। :)


-3

आसान हिस्सा: फ्रेमवर्क, ऑपरेटिंग सिस्टम और हार्डवेयर की समकालीन विशेषताओं जैसे मल्टीफ्रेडिंग का उपयोग करें, जैसे कि सेमीफोर, क्यू, इंटरलॉक किए गए काउंटर, परमाणु बॉक्सिंग प्रकार आदि।

कठिन हिस्सा: पहली जगह में बिना किसी फीचर का उपयोग किए सुविधाओं को कार्यान्वित करना, हार्डवेयर की कुछ बहुत ही सीमित क्षमताओं को छोड़कर हो सकता है, केवल कई कोर के दौरान सुसंगतता की गारंटी देने पर भरोसा करना।


3
कठिन हिस्सा वास्तव में कठिन है, लेकिन यह भी इतना आसान हिस्सा इतना आसान नहीं है।
पीटरअलेनवेब
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.