ऐसे कौन से गलत विचार हैं जो लोगों को धागों का इस्तेमाल करने से रोकते हैं? [बन्द है]

Question

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

एक उदाहरण: प्रोग्राम को एक डेटाबेस से डेटासेट लोड करना है, जो करना है वह होगा कनेक्शन बनाने के लिए और एक वर्कर थ्रेड में डेटाबेस से डेटा प्राप्त करना और फिर इसे GUI में लोड करना, जिससे उपयोगकर्ता के लिए GUI थ्रेड उत्तरदायी बन जाए। ।

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

हार्डवेयर मल्टी-कोर में जाने के साथ, मुझे लगता है कि हमें थ्रेड्स को बेहतर ढंग से समझने की जरूरत है और उन्हें इस्तेमाल करने से डरना नहीं चाहिए। मुझे यह व्यक्तिगत रूप से एक आकर्षक विषय लगता है।

तो क्या चीजें हैं जो आपने थ्रेडिंग के बारे में सुनी हैं जो झूठी हैं?

Comments

Misfits और जांघिया धागे को संभाल नहीं सकते। असली सवाल यह है कि आप उसके बारे में क्या करने जा रहे हैं?

— नौकरी

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

— tp1

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

— user1172763

Answer 1

थ्रेडिंग कठिन है

ज़रूर। यह हो सकता है। हालाँकि, लोगों को यह विचार अपने सिर में है कि यह इतना कठिन है, जैसे कि वे इसे समझने की कोशिश नहीं करते हैं।

यह असंभव जैसा नहीं है।

Comments

मैं इस जवाब का समर्थन करता हूं। लोगों को लगता है कि यह कठिन है। हालांकि यह तब नहीं है जब आप समझने के लिए पर्याप्त समय बिताते हैं।

@Pierre, मैं मुश्किल से लोगों की परिभाषा की है कि बहुत से उम्मीद होती है "तुम समझने की कोशिश कर पर्याप्त समय खर्च करने के लिए है"।

— बेंजोल

थ्रेडिंग बहुत से आसान हो करने के लिए हो रही है TPL और await/ asyncकीवर्ड :)

— राहेल

@ पियरे 303: जब आप यह समझने के लिए पर्याप्त समय बिताते हैं कि यह अभी भी कठिन है , और वास्तव में जो लोग इसे सबसे अच्छा समझते हैं, वे यथासंभव इसे टालने की सबसे अधिक संभावना है।

— माइकल बोर्गवर्ड्ट

Answer 2

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

मैंने वास्तव में धागे के बारे में कोई झूठी बात नहीं सुनी है। मैंने अभी-अभी स्थितिजन्य केस स्टडीज के एक पूरे समूह को एक कुतिया होने के बारे में पढ़ा है जब आप जो भी एल्गोरिथ्म का उपयोग कर रहे हैं वह स्वाभाविक रूप से समानांतर नहीं है।

Comments

स्वयं पर ध्यान दें: समानांतर एल्गोरिदम लिखें ... धन्यवाद।

— Droogans 15

संदेश की कतारें (MFC के समान)। हालाँकि, प्रोग्रामर को संदेश कतार को तोड़-मरोड़ कर (सीधे मेमोरी में डेटा साझा करके) नहीं मिल रहा है, जबकि यह एक अक्षम्य अपराध है, लगता है कि विफल रहा है।

— rwong

Answer 3

थ्रेडिंग आपकी सभी समस्याओं को हल करता है

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

धागे हल्के होते हैं

धागे दसियों और बिसवां दशा में हल्के होते हैं। हजारों धागे पैदा करना नहीं है।

थ्रेडिंग आसान है [जावा]

धागे बनाना आसान है, इसका मतलब यह नहीं है कि आप इससे लाभान्वित होंगे।

Comments

सिर्फ रिकॉर्ड के लिए, मैक ओएस आपको (एक डिफ़ॉल्ट इंस्टॉल पर) 512 से अधिक धागे बनाने की अनुमति नहीं देगा।

— zneak

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

— जॉर्ग डब्ल्यू मित्तग

@ Jörg W Mittag: मैं आपकी टिप्पणी से भ्रमित हूं। एरलैंग कैसे बदलता है ओएस कैसे एक धागा या प्रक्रिया बनाता है?

— स्टीवन एवर्स

@SnOrfus: Erlang OS थ्रेड का उपयोग नहीं करता है। अभी तीन मुख्य Erlang कार्यान्वयन हैं: BEAM, HiPE और Erjang। BEAM और HiPE मूल कार्यान्वयन हैं (जो बिना किसी OS के भी चल सकते हैं) और अपनी स्वयं की प्रक्रियाओं को लागू कर सकते हैं। Erjang JVM पर चलता है और काल्पनिक रूप से शानदार किलिम लाइब्रेरी का उपयोग करके प्रक्रियाओं को लागू करता है।

— जोर्ग डब्ल्यू मित्तग

@ Jörg W Mittag: मेरे प्रश्न को ध्यान में रखते हुए प्रोग्रामर.स्टैकएक्सचेंज. com/questions/28453/… , मुझे यह बहुत दिलचस्प लगता है। धन्यवाद।

— स्टीवन एवर्स

Answer 4

आप अंततः थ्रेडिंग से किसी भी लाभ को ढीला कर देंगे क्योंकि कुछ बग्स / फ़ंक्शंस के उपयोग से उत्पन्न होने वाले पागल कीड़े को ठीक करना जो कि थ्रेड सुरक्षित नहीं हैं (जो आपको जानकारी नहीं थी) को अत्यधिक सिंक्रनाइज़ेशन की आवश्यकता होगी।

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

Comments

अविच्छिन्न कीड़े? मैंने उन लोगों में से एक को पहले नहीं देखा है ..

— adamk

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

— कामिल स्ज़ोट

यदि आपने कभी भी एक बग का सामना नहीं किया है तो आप उद्योग में लंबे समय से नहीं हैं। मेरे 12+ वर्षों के काम में, मैंने जो भी प्रोजेक्ट देखा है, उसमें कम से कम एक बग है, जिसे किसी ने भी ठीक नहीं किया है और किसी को भी पता नहीं है कि कैसे ठीक किया जाए या फिर कैसे पुन: पेश किया जाए। इसमें वह कोड शामिल है जिस पर मुझे काम करने के लिए नियोजित किया गया है और मेरे पास पढ़ने के लिए एक्सेस है (ओपन सोर्स कोड)। सॉफ्टवेयर के केवल टुकड़े जो बग मुक्त हैं वे 2 या 3 पृष्ठों से कम लंबे हैं। लेकिन आपके सभी कोड 1 या 2 पृष्ठों को लंबे समय तक बनाने से पूरी तरह से कुछ भी हल नहीं होता है क्योंकि आपके पास एकीकरण कीड़े हैं।

— स्लीपबेटमैन

Answer 5

बिंदु वार को सारांशित करने के लिए कि थ्रेड्स का उपयोग करना मुश्किल क्यों है: -
ट्रू थिंग्स 1) सिंक्रनाइज़ेशन की आवश्यकता है, और
2 को लॉक करने के लिए क्या और कब लॉक करना है, इस बारे में सावधानीपूर्वक डिजाइन के निर्णय ) रन टाइम फ्लो पर कोई नियंत्रण
3) कठिन डिबगिंग
4) (बहुत कम समय) प्लेटफ़ॉर्म संगतता: - लाइब्रेरीज़ इसका ध्यान रखने के लिए मौजूद हैं

गलत बातें: -
1) थ्रेड-सेफ और री-एंट्रेंट फ़ंक्शंस की अवधारणाओं को भ्रमित करना
2) कागज पर धागे अच्छे लगते हैं, लेकिन इन्हें लागू करना बहुत कठिन है

Comments

क्या ये सच या असत्य माना जाता है? ओपी ने पूछा कि कौन सी चीजें सच नहीं हैं, और लोगों को मल्टी-थ्रेडेड प्रोग्रामिंग करने से दूर करते हैं।

— स्टीवन एवर्स

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

— केविन

Answer 6

यदि आप अपने कोड के लिए परीक्षण नहीं लिखना चाहते हैं, तो थ्रेड का उपयोग न करें।

थ्रेड्स विशिष्ट 'कॉपी और पेस्ट' प्रोग्रामर के लिए नहीं हैं जो ओएस और कंप्यूटर आर्किटेक्चर के अंतर्निहित मूल सिद्धांतों को नहीं समझते हैं। चूंकि 90% प्रोग्रामर केवल जावा से परिचित हैं, ये वास्तव में वे लोग नहीं हैं जिन्हें धागे का उपयोग करना चाहिए। जावा थ्रेड्स को "आसान" बनाता है, लेकिन मैंने बहुत सारे प्रोग्रामर्स को देखा है जो सिर्फ यह सोचते हैं कि अगर वे सिंक्रोनाइज़्ड स्ट्रक्चर का इस्तेमाल करते हैं तो उनका कोड थ्रेड्स में काम करेगा .... उह नहीं।

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

Comments

क्या आप थ्रेड्स को सही तरीके से करने के लिए कुछ संसाधनों की सिफारिश कर सकते हैं?

— जोनाथन

मुझे यकीन है कि इस पर ध्यान दिया गया है। यहां शुरू करने की कोशिश करें stackoverflow.com/questions/660621/threading-best-practices

— cmcginty

इसके साथ समस्या यह है कि यदि आपके पास 100% परीक्षण कवरेज है, तो आपके पास यह जानने का कोई तरीका नहीं होगा कि क्या आपके परीक्षण सभी संभावित मुद्दों को साझा करेंगे कि साझा संसाधनों के साथ निर्देशन कैसे करें। एक साझा कुछ भी नहीं वास्तुकला के साथ दूसरी ओर यह बहुत आसान हो जाता है।

— ज़ाचरी के

Answer 7

एक उदाहरण: प्रोग्राम को एक डेटाबेस से डेटासेट लोड करना है, जो करना है वह होगा कनेक्शन बनाने के लिए और एक वर्कर थ्रेड में डेटाबेस से डेटा प्राप्त करना और फिर इसे GUI में लोड करना, जिससे उपयोगकर्ता के लिए GUI थ्रेड उत्तरदायी बन जाए। ।

मैं नहीं देखता कि यह स्थिति कम से कम 4 कारणों से थ्रेडिंग का उपयोग करने की आवश्यकता का प्रतिनिधित्व करती है:

1. डेटा पुनर्प्राप्ति बहुत तेज़ होनी चाहिए।

2. कई व्यावसायिक अनुप्रयोगों में, उपयोगकर्ता को 1 सेकंड या दो में आवेदन से कोई लेना-देना नहीं है, वह परिणाम का इंतजार कर रहा है। इसके अलावा, उपयोगकर्ता को तब तक इंतजार करना होगा जब तक डेटा वांछित कार्य को पूरा करने के लिए किसी भी तरह से वापस नहीं आता है। दूसरी ओर क्वेरी को बुद्धिमानी से कोडित किया जा सकता है ताकि यह एक समय में केवल पृष्ठ-पूर्ण जानकारी प्राप्त कर सके और अन्य अनुकूलन तकनीक प्रतिक्रिया समय में मदद कर सके।

3. वेब आधारित इंटरफेस में, थ्रेडिंग मॉडल के संबंध में लिंक सक्रिय किए जा सकते हैं।

4. थ्रेडिंग जटिलता को जोड़ती है जैसा कि आप स्वीकार करते हैं, लाइन के नीचे कुछ डेवलपर्स सुविधाओं या डिबग जटिल कोड को जोड़ने में सक्षम नहीं हो सकते हैं।

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

Comments

आपका पहला बिंदु मुझे वितरित कंप्यूटिंग की गड़बड़ियों ( en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing ) की याद दिलाता है । बहुत सारे उपयोगकर्ता बेतहाशा क्लिक करना शुरू कर सकते हैं, जब उन्हें गैर-जिम्मेदार इंटरफ़ेस के लिए अपने बिंदु 2 से 1 या 2 सेकंड से अधिक इंतजार करना पड़ता है, जिससे चीजें बदतर हो जाती हैं।

— सुरक्षित

@ सुरक्षित, लिंक दिलचस्प है, इसे साझा करने के लिए धन्यवाद। मुझे यकीन नहीं है कि हम कभी भी इस दिन और उम्र में इंटरफ़ेस पर या यहां तक ​​कि पूरी नौकरी पर उपयोगकर्ता का ध्यान केंद्रित कर सकते हैं। मैं आपसे सहमत हूं कि ई-बिजनेस साइटों में, आप नहीं चाहते कि उपयोगकर्ता बिल्कुल भी चले जाएं।

— NoChance

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

— सुरक्षित

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

— सुरक्षित

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

— NoChance