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

हम Go लेते हैं, प्रतिस्पर्धी कोड लिखना शुरू करते हैं। बेशक, हम उम्मीद करते हैं कि हम अपने प्रोसेसर के प्रत्येक कोर की शक्ति को आसानी से रोक सकते हैं। क्या ऐसा है?

मेरा नाम Artemy है। यह पोस्ट गोफरकॉन रूस के साथ मेरी बात का एक मुक्त प्रतिलेख है। यह उन लोगों को प्रेरणा देने के प्रयास के रूप में दिखाई दिया जो यह जानना चाहते हैं कि अच्छा, प्रतिस्पर्धी कोड कैसे लिखना है।

गोफरकोन रूस सम्मेलन से वीडियो

सहभागिता मॉडल

यह समझने के लिए कि क्या गो वास्तव में हमारे लिए आसान बनाता है, आइए दो इंटरैक्शन मॉडल देखें: साझा की गई मेमोरी और संदेश पासिंग ।

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

  
  

• संदेश पासिंग कहता है कि हम स्पष्ट रूप से बातचीत करेंगे, और इसके लिए हम उन चैनलों का उपयोग करेंगे जिनमें हम संदेश भेजेंगे। CSP ( संचार प्रक्रियाएँ ) और अभिनेता मॉडल इसी दृष्टिकोण पर आधारित हैं।

  
  

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

प्रश्न: क्या यह सच है कि अगर हम गो ले, तो सब ठीक हो जाएगा?

मुझे एक अध्ययन में पता चला जिसमें यह गोली मिली थी। टेबलेट कारणों और तालों से संबंधित बगों की संख्या को दर्शाता है। पहला कॉलम उन उत्पादों को दिखाता है जिन्हें अध्ययन में लिया गया था। ये गो में लिखे सबसे लोकप्रिय उत्पाद हैं। साझा मेमोरी कॉलम साझा मेमोरी के अनुचित उपयोग के कारण उत्पन्न होने वाले बग्स की संख्या को दर्शाता है, और संदेश पासिंग कॉलम क्रमशः संदेश पासिंग के कारण बग की संख्या को दर्शाता है।

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

तो बस जाओ और त्रुटि मुक्त कोड लिखना शुरू कर देंगे।

सामंजस्य और समानता

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

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

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

आमदाल का नियम

हम प्रोसेसर कोर का उपयोग करना चाहते हैं, हम इसके लिए कुछ कोड लिखते हैं। लेकिन सवाल उठता है: उत्पादकता में किस तरह की वृद्धि हमें कोर की संख्या में वृद्धि के साथ मिलती है। तो, हम जो त्वरण प्राप्त कर सकते हैं, वह वास्तव में, अम्दल के कानून द्वारा सीमित है ।

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

भले ही हमारे पास क्रमिक रूप से निष्पादित होने वाले कार्यक्रम का केवल 5% है, जो अधिकतम त्वरण हमें प्राप्त होता है वह कोर की संख्या में वृद्धि के साथ बहुत कम हो जाएगा। आप अनुमान लगा सकते हैं कि एफ को बढ़ाने वाले कौन से हिस्से हैं ।

सीपीयू बाउंड बनाम आई / ओ बाउंड

यह हमेशा मल्टीथ्रेडिंग का उपयोग करने के लिए समझ में नहीं आता है। पहले आपको लोड के प्रकार को देखने की जरूरत है। दो प्रकार के लोड हैं: सीपीयू बाउंड और आई / ओ बाउंड । अंतर यह है कि सीपीयू बाउंड के साथ हम प्रोसेसर के प्रदर्शन से सीमित हैं, और आई / ओ बाउंड से हम अपने आई / एस सबसिस्टम की गति से सीमित हैं। गति भी नहीं है, लेकिन एक उत्तर के लिए प्रतीक्षा समय है। ऑनलाइन जाना - उत्तर की प्रतीक्षा करना, डिस्क पर जाना - फिर से उत्तर की प्रतीक्षा करना। क्या अंतर है, कितने कोर हैं, अगर ज्यादातर समय हम एक उत्तर की प्रतीक्षा कर रहे हैं?

इसलिए, एक कोर या एक हजार, हमें I / O बाउंड लोड के तहत प्रदर्शन में वृद्धि नहीं मिली। लेकिन अगर हमारे पास सीपीयू बाउंड लोड है, तो हमारे कार्यक्रम को समानांतर करते समय त्वरण प्राप्त करने का एक मौका है।

हालांकि ऐसी परिस्थितियां हैं जब स्पष्ट सीपीयू बाउंड लोड होता है, यह वास्तव में I / O बाउंड में पतित हो जाता है। यदि, उदाहरण के लिए, हम एक बड़े सरणी के सभी तत्वों को लेना और जोड़ना चाहते हैं, तो हम क्या करेंगे? हम एक चक्र लिखेंगे, सब कुछ काम करेगा। फिर हम सोचते हैं: “तो हमारे पास लाशों का एक समूह है। चलो बस इसे लेते हैं, सरणी को विखंडू में विभाजित करते हैं और पूरी चीज़ को समानांतर करते हैं। ” इसका परिणाम क्या होगा?

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

गलत बंटवारा

इसके अलावा, झूठी बंटवारे जैसी कहानी है। झूठी साझाकरण एक ऐसी स्थिति है जब गुठली एक दूसरे के साथ हस्तक्षेप करना शुरू कर देती है। पहला कोर है, दूसरा कोर है, और उनमें से प्रत्येक का अपना एल 1 कैश है । L1 कैश 64 बाइट्स की लाइनों ( कैश लाइन ) में विभाजित है। जब हम मेमोरी से कुछ डेटा प्राप्त करते हैं, तो हमें हमेशा 64 बाइट्स से कम नहीं मिलता है। इस डेटा को बदलकर, हम सभी कोर के कैश को अक्षम कर देते हैं।

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

शेड्यूलर

हम योजनाकारों के लिए अमूर्त के अगले स्तर तक बढ़ेंगे।

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

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

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

ऑपरेटिंग सिस्टम प्रीमेप्टिव मल्टीटास्किंग के आधार पर एक शेड्यूलर का उपयोग करता है, क्योंकि प्रत्येक उपयोगकर्ता के लिए समान शर्तों की गारंटी देने के लिए ओएस की आवश्यकता होती है। जाने के बारे में क्या?

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

ऐसा कोड जम जाएगा।

क्यों? क्योंकि सबसे पहले, GOMAXPROCS का उपयोग करते GOMAXPROCS , हमने प्रोग्राम को केवल एक कोर का उपयोग करने के लिए मजबूर किया। उसके बाद, गोरोइन को कतार में रखा गया, जिसके अंदर एक अंतहीन चक्र काम करना चाहिए। फिर हम 500 एमएस और प्रिंट x इंतजार करते हैं। समय के बाद। time.Sleep गोरोइन वास्तव में शुरू हो जाएगा, लेकिन अनंत लूप से बाहर निकलने का कोई रास्ता नहीं होगा, क्योंकि संकलक संदर्भ स्विच बिंदु नहीं डालेगा। कार्यक्रम जमा देता है।

और अगर हम runtime.Gosched() जोड़ते हैं। लूप के अंदर रखा हुआ runtime.Gosched() , तो सब कुछ ठीक हो जाएगा, क्योंकि हम स्पष्ट रूप से संकेत देंगे कि हम संदर्भ को स्विच करना चाहते हैं।

ऐसी विशेषताओं को भी जानना और याद रखना आवश्यक है।

हमने संदर्भ स्विचिंग के बारे में बात की थी, लेकिन गो आमतौर पर स्विच पॉइंट कहां डालते हैं?

runtime.morestack() और runtime.newstack() आमतौर पर उस समय डाला जाता है जब फ़ंक्शन कहा जाता है। runtime.Goshed() हम खुद को आपूर्ति कर सकते हैं। और हां, लॉक्स, नेटवर्क हाइक और सिस्टम कॉल के दौरान संदर्भ स्विचिंग होता है। आप इस विषय पर Kirill Lashkevich की एक रिपोर्ट देख सकते हैं। बहुत अच्छा, मैं सलाह देता हूं।

कोड के आगे चलते हैं। हम त्रुटियों को देखेंगे।

दौड़ की स्थिति

सबसे लोकप्रिय गलतियों में से एक हम Race Condition । लब्बोलुआब यह है कि जब हम करते हैं, उदाहरण के लिए, एक वेतन वृद्धि, वास्तव में हम एक ऑपरेशन नहीं करते हैं, लेकिन कई: प्रोसेसर मेमोरी से डेटा को पढ़ता है, रजिस्टर को अपडेट करता है और मेमोरी को डेटा लिखता है।

इन तीनों ऑपरेशनों को परमाणु रूप से नहीं किया जाता है। इसलिए, किसी भी समय अनुसूचक, इनमें से किसी भी ऑपरेशन पर, हमारे प्रवाह को ले जा सकता है और भीड़ सकता है। यह पता चला है कि कार्रवाई समाप्त नहीं हुई है, और इस वजह से हम कीड़े पकड़ते हैं।

इस तरह के एक कोड का एक उदाहरण है ( वेतन वृद्धि तुरंत कई कार्यों में विघटित हो जाती है )।

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

हम sync का उपयोग करके लॉक कर सकते हैं। मानक sync पैकेज से sync.Mutex । प्रवेश अवरुद्ध करने से हमें स्पष्ट रूप से संकेत मिलता है कि कोड को एक समय में एक थ्रेड द्वारा निष्पादित किया जाना चाहिए। इस कोड के साथ, हमें वह मिलता है जो हमें चाहिए।

ताले काफी महंगे ऑपरेशन हैं। इसलिए, प्रोसेसर स्तर पर परमाणु संचालन होते हैं। इस मामले में, वृद्धि को परमाणु के साथ प्रतिस्थापित करके परमाणु बनाया जा सकता है। atomic पैकेज से atomic.AddInt64 ऑपरेशन।

यदि हम परमाणु निर्देशों के साथ काम करना शुरू करते हैं, तो हमें न केवल परमाणु लिखने की जरूरत है, बल्कि परमाणु भी पढ़ें। यदि हम नहीं करते हैं, तो समस्याएं पैदा हो सकती हैं।

अनुकूलन - क्या गलत हो सकता है गलत?

ताले अच्छे हैं, लेकिन महंगे हो सकते हैं। एटमिक्स प्रदर्शन के बारे में चिंता न करने के लिए पर्याप्त सस्ते हैं।

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

सब कुछ ठीक है, सिवाय इसके कि कंपाइलर हमारे कोड को ऑप्टिमाइज़ करने की कोशिश कर रहा है। वह क्या कर रहा है? वह असाइनमेंट निर्देशों को स्वैप करता है, और हमें गैर-वैध व्यवहार प्राप्त होता है, क्योंकि हमारा done गया वेरिएबल " " असाइन किए जाने से पहले true हो जाता true ।

ऐसी अनुकूलन करने की कोशिश न करें - उनकी वजह से आपको बहुत सारी समस्याएं मिलेंगी। मैं आपको द गो मेमोरी मॉडल के विनिर्देश और दिमित्री व्युकोवा ( @dvyukov ) सौम्य डेटा दौड़ के एक लेख को पढ़ने की सलाह देता हूं : क्या गलत हो सकता है? बेहतर मुद्दों को समझने के लिए।

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

गतिरोध

अगली समस्या जिसका हम सामना करेंगे वह है डेडलॉक। ऐसा लग सकता है कि यहां सब कुछ काफी तुच्छ है। दो संसाधन हैं, उदाहरण के लिए, दो Mutex । पहले धागे में, हम पहले Mutex पर कब्जा करते हैं, और दूसरे धागे में हम पहले Mutex पर कब्जा करते हैं। आगे हम दूसरे Mutex को पहले धागे में लेना चाहेंगे, लेकिन हम ऐसा नहीं कर पाएंगे, क्योंकि यह पहले से ही ब्लॉक है। दूसरे धागे में, हम क्रमशः पहला Mutex और ब्लॉक करने की कोशिश करेंगे। वहाँ वह है, डेडलॉक।

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

ऐसा प्रतीत हो सकता है कि अनुभवी डेवलपर्स ऐसी त्रुटियों का सामना नहीं करते हैं, लेकिन यहां प्रोजेक्ट कोड etcd से गतिरोध का एक उदाहरण है।

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

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

समस्याओं का हल

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

दौड़ का पता लगाने

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

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

प्रोफ़ाइल अवरुद्ध करें

ब्लॉक प्रोफ़ाइल एक और उपकरण है जो हमें अवरुद्ध समस्याओं को खोजने और ठीक करने की अनुमति देता है।

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

कार्यक्रम का उदाहरण

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

यदि हम Go में लिखते हैं, तो हमें भाषा की पूरी शक्ति का उपयोग करना चाहिए। हम कोशिश करते हैं। हमें तीन गुना ज्यादा कोड मिलता है।

प्रश्न: क्या कोड में कोई त्रुटि हैं?

बेशक! आइए नजर डालते हैं कौन-कौन से हैं।

लूप में हम गोरोनाइट चलाते हैं। गोरोचन ऑर्केस्ट्रेशन के लिए, हम sync.WaitGroup उपयोग sync.WaitGroup । लेकिन हम गलत क्या कर रहे हैं? पहले से ही चल रहे गोरआउट के अंदर, हम wg.Add(1) कॉल wg.Add(1) , यानी हम प्रतीक्षा करने के लिए एक और गोरआउट जोड़ते हैं। और wg.Wait() का उपयोग करके, हम सभी गोरआउट के पूरा होने की प्रतीक्षा कर रहे हैं। लेकिन ऐसा हो सकता है कि जब तक wg.Wait() कहा जाता है, तब तक एक भी गोरोचन शुरू नहीं होगा। इस मामले में, wg.Wait() विचार wg.Wait() कि सब कुछ किया जाता है, हम चैनल को बंद कर देंगे और त्रुटियों के बिना फ़ंक्शन से बाहर निकल जाएंगे, यह मानते हुए कि सब कुछ ठीक है।

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

शायद अभी भी कुछ समस्याएं हैं?

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

व्यवहार में, इस कोड में, req मान सबसे अधिक बार सरणी के अंतिम तत्व के बराबर होगा। इसलिए, आप बस एक ही अनुरोध एन बार भेजते हैं। फिक्स: फ़ंक्शन के तर्क के रूप में हमारे अनुरोध को स्पष्ट रूप से पास करें।

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

लेकिन क्या होगा अगर सभी अनुरोध एक त्रुटि के साथ लौटते हैं?

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

हम इसे बहुत सरल रूप से ठीक करते हैं: हम स्लॉट चैनल में अनुरोधों की संख्या का चयन करते हैं। यह हमारी समस्या को बहुत प्रभावी नहीं बनाता है, क्योंकि यदि हमारे पास एक अरब अनुरोध हैं, तो हमें एक बिलियन स्लॉट आवंटित करने की आवश्यकता है।

हमने समस्याओं को हल किया। कोड अब प्रतिस्पर्धी है। लेकिन परेशानी पठनीयता के साथ है - कोड के तुल्यकालिक संस्करण की तुलना में, बहुत सारे हैं। और यह शांत नहीं है, क्योंकि प्रतिस्पर्धी कार्यक्रमों का विकास पहले से ही मुश्किल है, हम इसे बहुत सारे कोड के साथ जटिल क्यों करते हैं?

Errgroup

मैं कोड की पठनीयता बढ़ाने का सुझाव देता हूं।

मुझे सिंक के बजाय इरगग्रुप पैकेज का उपयोग करना पसंद है। sync.WaitGroup । इस पैकेज में यह निर्दिष्ट करने की आवश्यकता नहीं है कि कितने गोरोइन्ट्स की उम्मीद है, और आपको त्रुटियों के संग्रह को अनदेखा करने की अनुमति देता है। यह है कि errgroup का उपयोग करते समय हमारा कार्य कैसा दिखेगा:

इसके अलावा, errgroup आसानी से संदर्भ का उपयोग करके हमारे कार्यक्रम के घटकों को ऑर्केस्ट्रेट करने की अनुमति देता errgroup । मेरा क्या मतलब है?

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

इसका उपयोग जटिल बहुउद्देशीय कार्यक्रमों का निर्माण करने के लिए किया जा सकता है जो भविष्यवाणी करते हैं।

निष्कर्ष

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

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

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