क्या मुझे दौड़ की स्थितियों का ध्यान रखना चाहिए जो निश्चित रूप से उत्पन्न होने का कोई मौका नहीं है?

Question

आइए एक GUI एप्लिकेशन की तरह कुछ पर विचार करें जहां मुख्य थ्रेड UI को लगभग तुरंत अपडेट कर रहा है, और कुछ अन्य थ्रेड नेटवर्क पर डेटा को प्रदूषित कर रहे हैं या ऐसा कुछ जो काम खत्म करने के लिए 5-10 सेकंड लेने की गारंटी है।

मुझे इसके लिए कई अलग-अलग उत्तर मिले हैं, लेकिन कुछ लोगों का कहना है कि अगर यह एक सांख्यिकीय अक्षमता की दौड़ की स्थिति है, तो इसके बारे में बिल्कुल भी चिंता न करें, लेकिन दूसरों ने कहा है कि अगर कोई 10 ^-53 % भी है (मैं बच्चा हूं आप संख्याओं पर नहीं, यह वही है जो मैंने सुना है) कुछ वूडू जादू की दौड़ की स्थिति के कारण, हमेशा उस थ्रेड पर ताले प्राप्त / जारी करते हैं जो इसकी आवश्यकता होती है।

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

Comments

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

— पीटर बी

भौतिक विज्ञानी के रूप में, पी <1E-140 का अर्थ है p = 0। इस ब्रह्मांड में होने वाला नहीं है। 0.000000000000000000000000000000000000000000001% एक बहुत बड़ा है।

— एमएसलेटर

सुनिश्चित करें कि यह दौड़ की स्थिति किसी को स्वेच्छा से आपके ऐप को क्रैश करने की ओर नहीं ले जा सकती है । यह सुरक्षा समस्या का कारण हो सकता है।

— टोस्ट_फ्लेक्स

दस में से एक नौ बार दस में से नौ बार होता है।

— काज ड्रैगन

"लगभग निश्चित रूप से कोई मौका नहीं है?" इसका मतलब है कि यह 3 बजे उत्पादन में होता है और सबसे अधिक संभावना है कि यह बहुत महंगा है।

Answer 1

यदि यह वास्तव में 10 ^ 55 ईवेंट में 1 है, तो इसके लिए कोड की आवश्यकता नहीं होगी। इसका अर्थ यह होगा कि यदि आपने ऑपरेशन 1 मिलियन बार सेकंड में किया है, तो आपको हर 3 * 10 ^ 41 साल में एक बग मिलेगा, जो लगभग, ब्रह्मांड की उम्र के 10 ^ 31 गुना है। यदि आपके आवेदन में ब्रह्मांड के हर खरबों खरबों अरब युगों में केवल एक बार त्रुटि हुई है, तो संभवतः यह पर्याप्त विश्वसनीय है।

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

Comments

मुझे एक टिप्पणी याद आ रही है जो मैंने सालों पहले पढ़ी थी, लेकिन अब नहीं मिल पा रहा है "एक लाख में एक मौका आमतौर पर अगले मंगलवार को होता है"। +1 यह कहने के लिए कि यह "उस संभावना के पास कहीं नहीं है"।

— बेवन

दांव के लिए +1। दौड़ की स्थिति से निपटने का सबसे अच्छा तरीका है कि उनसे छुटकारा पा लिया जाए।

— ब्लरफ्लू

@Bevan "A 1 मिलियन चांस में आम तौर पर अगले मंगलवार को होता है" ... जब तक आप लॉटरी नहीं खेल रहे हैं :)

— dasblinkenlight

@dasblinkenlight लेकिन अधिकांश लॉटरी में किसी के जीतने की संभावना 100% है। भविष्यवाणी करना कि अब कौन चुनौती है।

— बेवन

@Bevan: जब मैंने सवाल पढ़ा तो यह टिप्पणी मेरे दिमाग में क्या चल रही थी - यहाँ संदर्भ है: blogs.msdn.com/b/larryosterman/archive/2004/03/30/104165.aspx

— Doc Brown

Answer 2

लागत-लाभ के दृष्टिकोण से, आपको केवल अतिरिक्त कोड लिखना चाहिए जब यह आपको पर्याप्त लाभ देता है।

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

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

Comments

+1: "विफलता की तरह दिखने वाले विफलता" और "सफलता की तरह दिखने वाले विफलता" के बीच अंतर करने के लिए। डोमेन के आधार पर गलत जानकारी बहुत अधिक गंभीर है।

— डेवॉर्ड

+1 यह एक बड़ा अंतर बनाता है कि दौड़ की स्थिति के परिणाम क्या हो सकते हैं।

— ग्रांट

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

— प्रहार

+1: मैं कहूंगा कि परिणाम शायद वही हैं, जिनका आपको विश्लेषण करना चाहिए और न कि इसकी संभावना घटती है। यदि परिणाम मायने नहीं रखते हैं, तो आपको दौड़ की स्थिति EVEN को संभालना नहीं पड़ सकता है यदि यह बहुत सामान्य है।

— सिंह

लेकिन यह मत समझो कि एक दौड़ की स्थिति को स्वचालित रूप से ठीक करने का मतलब है कि आपको अधिक कोड लिखना होगा। यह बस के रूप में अच्छी तरह से छोटी गाड़ी कोड का एक बड़ा हिस्सा निकाल सकते हैं और सही कोड का एक छोटा हिस्सा के साथ बदल सकते हैं।

— जेस्पर

Answer 3

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

जहां तक ​​संभावनाओं का सवाल है, आप आश्चर्यचकित होंगे। मैं एक रेस स्थिति बग रिपोर्ट पिछले साल है कि मैं स्वचालित कोशिश करता के हजारों के साथ पुन: पेश नहीं कर सका, लेकिन था एक की प्रणाली एक ग्राहक हर समय इसे देखा। अब इसे ठीक करने के लिए 5 मिनट खर्च करने का व्यावसायिक मूल्य, बनाम संभवतः ग्राहक की स्थापना में "असंभव" बग का निवारण करना, यह विकल्प को बिना दिमाग वाला बनाता है।

Comments

यह भी! अपने कोड को पढ़ते समय संभावित समस्याओं के बारे में अन्य प्रोग्रामर विचार करने से बचें, जो आवश्यक है उसे करके (भले ही वह 'असफल' होने की संभावना न हो)।

— केसी कुबैल

आपकी बात को अच्छी तरह से लिया गया है (अब किए गए सुधार पहले से बने लोगों की तुलना में जल्दी और सस्ते हैं) सिवाय इसके कि यह "अब इसे ठीक करने के लिए सिर्फ 5 मिनट" होने वाला नहीं है।

— iconoclast

उनका कहना है कि रेस स्थिति की संभावना शायद कई कारकों पर निर्भर है, तो भले ही वह में संभावना नहीं लग रहा है के लिए +1 आपके विन्यास, यह एक ग्राहक सिस्टम पर अकसर हो सकता है / एक अलग ओएस पर / अगली फिल्म आदि में

— sleske

Answer 4

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

Comments

एल्गोरिदम परिवर्तन के लिए +1। अभी, जब आप दौड़ की स्थिति से अवगत हैं, तो संभावनाएँ कम हैं। एक साल के बाद, जब आप दौड़ की स्थिति के बारे में भूल गए हैं, तो आप अपने कोड में बदलाव कर सकते हैं जो बग की समय और संभावना को काफी बदल देता है।

— फिल

Answer 5

और कुछ अन्य थ्रेड नेटवर्क पर डेटा मतदान कर रहे हैं या कुछ और जो काम खत्म करने के लिए 5-10 सेकंड लेने की गारंटी है।

जब तक कोई प्रदर्शन में सुधार करने के लिए कैशिंग लेयर का परिचय नहीं देता। अचानक कि अन्य ट्रेडमिल तात्कालिक के पास समाप्त हो गया और दौड़ की स्थिति अधिक बार प्रकट होती है।

कुछ हफ्ते पहले हुआ था, बग को खोजने के लिए लगभग 2 पूर्ण डेवलपर दिनों का समय लगा।

यदि आप उन्हें पहचानते हैं तो हमेशा दौड़ की स्थिति ठीक करें।

Answer 6

सरल बनाम सही।

कई मामलों में, सादगी शुद्धता को ट्रम्प करती है। यह एक लागत मुद्दा है।

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

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

Comments

लॉगिंग के लिए +1 और यदि इसे ठीक करना बहुत जल्दी विफल हो जाता है तो यह बहुत जटिल है।

— मार्टिन बा

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

— रीहराब

@ श्रेयब मैं असहमत हूँ। यदि आप बार-बार होने वाली घटनाओं पर विचार करते हैं, तो लॉग की विफलता लागत प्रभावी है। एक उदाहरण: यदि आपके फ़ोन ऐप में 1/100 विफलता दर (दुर्घटना) है यदि उपयोगकर्ता एक सटीक महीने के संक्रमण पर नेटवर्क स्विच कर रहा है (1/31 23:59:00 -> 2/1 00:00:00), तो आप 'शायद इसके बारे में कभी नहीं सुना होगा। लेकिन फिर एक सर्वर पर कनेक्शन पर दुर्घटना का 1/10 ^ 9 मौका अस्वीकार्य है। निर्भर करता है।

— ptyx

Answer 7

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

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

यहां तक ​​कि अगर किसी दौड़ की स्थिति में 10 ^ (- 80) होने की संभावना यादृच्छिक रूप से होती है , तो यह अच्छी तरह से हो सकता है कि एक निर्धारित हमलावर के पास जानबूझकर और कृत्रिम रूप से ऐसी स्थिति पैदा करने का एक अच्छा मौका है।

Answer 8

Therac -25!

थेरैक -25 परियोजना के डेवलपर्स यूआई और एक चिकित्सीय XRAY मशीन में इंटरफ़ेस से संबंधित समस्या के बीच के समय के बारे में बहुत आश्वस्त थे।

उन्हें नहीं होना चाहिए था।

आप इस प्रसिद्ध जीवन और मृत्यु सॉफ़्टवेयर आपदा के बारे में अधिक जान सकते हैं:

http://www.youtube.com/watch?v=izGSOsAGIVQ

या

http://en.wikipedia.org/wiki/Therac-25

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

यदि आपने अपना कोड अंतिम (और ऐसा लगता है कि आपके पास है) का निर्माण करने के लिए चुना है, तो आपको मूर के कानून पर विचार करना चाहिए जो हर कुछ वर्षों में कई शून्य को आसानी से बंद कर सकता है क्योंकि आपके सिस्टम के अंदर या बाहर के कंप्यूटर तेज हो जाते हैं। यदि आप हजारों प्रतियां शिप करते हैं, तो अधिक शून्य बंद करें। यदि उपयोगकर्ता इस ऑपरेशन को दैनिक (या मासिक) वर्षों तक करते हैं, तो कुछ और दूर करें। यदि यह उपयोग किया जाता है जहां Google फाइबर उपलब्ध है, तो क्या है? यदि UI कचरा मध्य GUI ऑपरेशन एकत्र करता है, तो क्या यह दौड़ को प्रभावित करता है? क्या आप अपने GUI के पीछे एक Open Source या Windows लाइब्रेरी का उपयोग कर रहे हैं? क्या अपडेट वहाँ समय को प्रभावित कर सकते हैं?

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

मेरा सुझाव है कि आप स्पष्ट रूप से सिंक्रनाइज़ करें क्योंकि जब आप कभी भी इसे एक समस्या बनाते हुए नहीं देख सकते हैं, तो ग्राहक हो सकता है। इसके अलावा, यहां तक ​​कि अगर आपकी दौड़ की स्थिति कभी नहीं होती है, तो क्या होगा यदि आपको या आपके संगठन को आपके कोड की रक्षा के लिए अदालत में बुलाया जाए (जैसा कि टोयोटा कुछ साल पहले प्रियस से संबंधित था)। जितना अधिक आपकी कार्यप्रणाली पूरी होगी, उतना ही बेहतर होगा। यह कहना अच्छा हो सकता है कि "हम इस असंभावित मामले के खिलाफ इस तरह की रक्षा करते हैं ..." कहने की तुलना में, "हमें पता है कि हमारा कोड विफल हो जाएगा, लेकिन हमने इस समीकरण को यह दिखाने के लिए लिखा था कि यह हमारे जीवनकाल में नहीं होगा। संभवतः। "

ऐसा लगता है कि संभावना गणना किसी और से आती है। क्या वे आपका कोड जानते हैं और क्या आप उन्हें यह जानना चाहते हैं कि कोई त्रुटि नहीं थी? अगर मैंने किसी चीज़ के लिए 99.99997% विश्वसनीयता की गणना की है, तो मैं अपने कॉलेज के आँकड़ों की कक्षाओं के बारे में भी सोच सकता हूँ और याद रखूँगा कि मुझे हमेशा 100% नहीं मिला, और अपने व्यक्तिगत विश्वसनीयता के अनुमानों पर कुछ प्रतिशत वापस मिला।

Comments

थेरैक -25 के उल्लेख के लिए +1। कई महत्वपूर्ण सबक यहाँ।

— स्टुअर्ट मार्क्स

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

— marktani

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

— DeveloperDon

Answer 9

यह पठनीयता में बाधा के लिए कोड की अधिक लाइनों को जोड़ने के लिए पूरी तरह से अनावश्यक या यहां तक ​​कि अनुत्पादक होगा?

सादगी तभी अच्छी होती है जब वह सही भी हो। चूंकि यह कोड सही नहीं है, भविष्य प्रोग्रामर होगा अनिवार्य रूप से इस पर गौर जब एक संबंधित बग की तलाश में।

जिस भी तरह से आप इसे संभालते हैं (या तो इसे लॉग इन करके, इसका दस्तावेजीकरण, या ताले जोड़कर - यह लागत पर निर्भर करता है), आप कोड को देखते समय अन्य प्रोग्रामर समय बचाएंगे।

Answer 10

यह संदर्भ पर निर्भर करेगा। यदि इसकी एक आकस्मिक iPhone खेल, शायद नहीं। अगले मानवयुक्त अंतरिक्ष यान के लिए उड़ान नियंत्रण प्रणाली, शायद। यह सब इस बात पर निर्भर करता है कि परिणाम क्या हैं अगर 'खराब' परिणाम इसे ठीक करने की अनुमानित लागत के खिलाफ मापा जाता है।

इस प्रकार के प्रश्नों के लिए शायद ही कभी एक 'एक आकार सभी फिट बैठता है' क्योंकि वे प्रोग्रामिंग प्रश्न नहीं हैं , बल्कि अर्थशास्त्र के प्रश्न हैं।

Comments

"अगले मानवयुक्त अंतरिक्ष यान के लिए उड़ान नियंत्रण प्रणाली" DEFINITELY ।

— डेवॉर्ड

शायद ... निश्चित रूप से ... यह निर्भर करेगा कि रॉकेट में कौन था :-)

— ग्रैंडमास्टरबी

Answer 11

हां, अप्रत्याशित की उम्मीद करें। मैंने घंटे (अन्य लोगों के कोड ^ ^ में) बिताए हैं जो कभी भी नहीं होनी चाहिए।

चीजें जैसे हमेशा एक और होती हैं, हमेशा केस पर डिफॉल्ट होती हैं, वैरिएबल इनिशियलाइज करें (हां, वास्तव में .. इस से बग्स होते हैं), प्रत्येक पुनरावृत्ति के लिए पुन: उपयोग किए गए वेरिएबल के लिए अपने लूप की जांच करें, आदि।

यदि आप विशेष रूप से मुद्दों को फैलाने के बारे में चिंतित हैं, तो इस विषय पर ब्लॉग, लेख और किताबें पढ़ें। वर्तमान विषय अपरिवर्तनीय डेटा प्रतीत होता है।

Answer 12

बस इसे ठीक करो।

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

कुछ ग्राहक कहीं न कहीं एक दिन कुछ ऐसा चलाने का फैसला करेंगे जो धीमी गति से चलने वाले थ्रेड को छोड़ते हुए "तेज" धागे के लिए सभी सीपीयू समय को हॉग करता है, और आपको खेद होगा :)

Answer 13

यदि आपने एक अप्रत्याशित दौड़ की स्थिति को पहचान लिया है, तो कम से कम इसे कोड में दस्तावेजित करें!

संपादित करें: मुझे यह जोड़ना चाहिए कि यदि संभव हो तो मैं इसे ठीक कर दूं, लेकिन ऊपर लिखे गए समय पर कोई अन्य उत्तर स्पष्ट रूप से नहीं कहा गया है कि कम से कम कोड में समस्या का दस्तावेजीकरण किया जाए।

Comments

हां, और कम से कम कोशिश करें और इसका पता लगाएं और ऐसा होने पर लॉग इन करें। IMHO यह पूरी तरह से ठीक है हर त्रुटि से बचने के लिए नहीं। लेकिन कम से कम किसी को पता है कि यह हुआ, और यह आपकी धारणा है कि यह गलत नहीं था।

— स्टीव बेनेट

Answer 14

मुझे लगता है कि अगर यो पहले से ही जानते हैं कि यह कैसे और क्यों हो सकता है, तो इससे निपट सकते हैं। अगर यह संसाधनों की एक प्रचुर मात्रा में नहीं लेता है।

Answer 15

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

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

Answer 16

मजेदार रूप से पर्याप्त, मुझे हाल ही में इस समस्या का सामना करना पड़ा। मुझे यह भी महसूस नहीं हुआ कि मेरी परिस्थिति में एक दौड़ की स्थिति संभव थी। मल्टी-कोर प्रोसेसर आदर्श बनने पर ही दौड़ की स्थिति ने खुद को प्रस्तुत किया।

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

Receive event from device:
{
    Record event details.
    Enqueue event in the queuing thread.
    Acknowledge the event.
}

Queueing thread receives an event:
{
    Retrieve event details.
    Process event.
    Send next command to device.
}

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

यह देखते हुए कि यह केवल एक विन्यास में एक ग्राहक को प्रभावित करता है, मैंने शर्म Thread.Sleep(1000)की बात यह है कि समस्या कहां थी। तब से कोई समस्या नहीं है।