मल्टीप्रेडिंग के कैस्पियन राक्षस

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

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

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

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

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

हम अपने प्रत्येक प्रवाह को एक वाहक के रूप में प्रस्तुत करते हैं। इसका मतलब है कि धागा कुछ "अनंत" चक्र में घूमता है, जो एक नए संदेश के आने की प्रतीक्षा कर रहा है। जैसे ही संदेश संसाधित होता है, पाइपलाइन की गई स्ट्रीम या तो अगली प्रक्रिया करती है या एक नए की प्रत्याशा में सो जाती है।

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

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

enum {MESSAGE_....., MESSAGE_....., MESSAGE_.....} 

क्रूर लगेगा, और उनका प्रसंस्करण

 switch (messageType) { case MESSAGE_.....: ....... break; case MESSAGE_.....: ....... break; case MESSAGE_.....: ....... break; case MESSAGE_.....: ....... break; } 

कृतज्ञ वंशजों से घृणा और डायरिया की वैध किरणें निकालेंगे।

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

 //,       class SomeJobThread : public CallbackThread { public: //thread SomeJobThread void DoSomeJob(String arg1, double arg2) { //      //    } private: //  }; SomeJobThread someJob; someJob.Request(&SomeJobThread::DoSomeJob, "OMG!", -1); 

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

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

यहाँ, मेरे मित्र के। ओ।, स्नेहपूर्वक स्क्वीटिंग करते हैं, टिप्पणी करते हैं कि मैं धागा सुरक्षा के लिए भुगतान करता हूं:

• एक संदेश प्रसंस्करण चक्र की उपस्थिति
• एक पंक्ति के साथ थ्रेड सिंक्रनाइज़ेशन
• तर्कों को कॉपी करने की आवश्यकता
• वह स्मृति जो धागा कतार खाती है

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

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

दलीलों को कॉपी करने के बारे में। फली प्रकार की नकल एक काफी त्वरित ऑपरेशन है, जो आमतौर पर अधिकांश अनुप्रयोगों में अदृश्य होता है। जब अधिक जटिल तर्कों की बात आती है, तो यह विनाशकारी नकल का उपयोग करने के लिए समझ में आता है। उदाहरण के लिए, एक स्ट्रिंग को आंतरिक डेटा को सूचक के विनाशकारी संचरण के माध्यम से पारित किया जा सकता है (यह तंत्र यू ++ में सक्रिय रूप से उपयोग किया जाता है)। इसलिए, एक सूची या एक साहचर्य सरणी के तर्क के रूप में गुजरना एक बहुत सस्ता ऑपरेशन है। वास्तव में, वास्तविक कार्यक्रमों में मनमाने ढंग से जटिल मापदंडों का स्थानांतरण, अधिकतम, कई पीओडी चर की नकल करने के लिए नीचे आता है।

और अंत में, स्मृति का उपयोग। कतार का प्रत्येक तत्व एक छोटी संरचना है, जिसमें तर्कों के अलावा, एक सूचक और दो बिंदुओं की एक आभासी तालिका (कुल == (1 + 1 + 2) * आकार (शून्य *) है, जो कि थोड़ा सा है।

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

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

मैं और क्या कह सकता हूं ... कतारें शांत हैं, कतारों से डरो मत!


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