🧟 🤳 🆓 धागे के बीच मैसेज करना। क्लासिक अवरुद्ध एल्गोरिदम 🏿 🍷 🙍🏽

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

तो क्या हेरज़ेन जगाया?

मेरा परिचय एक्शन के साथ परिचित कराना

भाषा डी

सादृश्य को जारी रखने की आवश्यकता नहीं है, मेरा यह कहने का मतलब यह नहीं था कि वह लोगों से बहुत दूर है

- एक अत्यंत वैचारिक रूप से सुंदर भाषा जो विरासत में मिली और शक्तिशाली रूप से C ++ मुहावरों को आगे बढ़ाती है और एक ही समय में प्रभावी निम्न-स्तरीय उपकरण बनाए रखती है, जिसमें बिंदु और शामिल हैं। शायद इस वजह से, मेरी राय में, मानक पुस्तकालय डी में कुछ डाइकोटॉमी है - अधिकांश कार्यक्षमता को सरल और आसान तरीके से, या एक इंटरफ़ेस के माध्यम से कहा जा सकता है, जो मूल इंटरफ़ेस के करीब है, लेकिन सिस्टम के संसाधनों और क्षमताओं का पूरी तरह से उपयोग करता है। यदि C ++ निरंतर स्पेक्ट्रम के साथ पूरी रेंज को कवर करता है, तो D में यह विभाजन आमतौर पर स्पष्ट रूप से दिखाई देता है। अपने लिए देखें: आपको समय अंतराल को मापने की आवश्यकता है, एक अद्भुत मॉड्यूल std.datetime है , हालांकि, माप क्वांटम 100 एनएस है, जो मेरे लिए बिल्कुल पर्याप्त नहीं है, कृपया - कोई कम अद्भुत मॉड्यूल नहीं है - core.time । जावास्क्रिप्ट- जैसे std.concurrency.spawn, जो सीमा के लिए हल्का है, आपको सूट नहीं करता है - आप core.thread से पूरे गुलदस्ते का उपयोग कर सकते हैं। और इसलिए लगभग हर जगह, एक के अपवाद के साथ, लेकिन अत्यंत महत्वपूर्ण स्थान - धाराओं के बीच डेटा का पृथक्करण। हां, हां, किसी दिए गए धागे के लिए सभी स्थानीय चर थ्रेड स्थानीय भंडारण में रखे गए हैं और कोई भी बल दूसरे धागे को अपना पता देखने के लिए मजबूर नहीं कर सकता है। और डेटा के आदान-प्रदान के लिए, अंतर्निहित कतारें प्रदान की जाती हैं, इसे बहुत सुविधाजनक माना जाना चाहिए - बहुरूपी, महत्वपूर्ण संदेश भेजने की संभावना और एक बहुत अच्छा इंटरफ़ेस। स्वाभाविक रूप से या तो मूल्य, या अपरिवर्तनीय लिंक द्वारा उनके माध्यम से डेटा भेजना संभव है। जब मैंने पहली बार इसके बारे में पढ़ा, तो मैं केवल आक्रोश से बाहर कूद गया - "आपका गन्दा हाथ कैसे उठ गया ..." - और फिर मैंने इसके बारे में सोचा, हाल के वर्षों में अपनी परियोजनाओं को याद किया और स्वीकार किया - हाँ, इस योजना के अनुसार प्रवाह के बीच पूरा आदान-प्रदान होता है। , लेकिन जो पास नहीं होता है वह स्पष्ट डिजाइन त्रुटि है।
फिर भी, प्रश्न हवा में लटका हुआ है - डी में लाइनें कितनी प्रभावी हैं? यदि नहीं, तो यह भाषा की अन्य सभी प्रभावशीलता की उपेक्षा करता है, एक प्रकार की अंतर्निहित अड़चन। इसलिए मैं उठा और फिर से माप लिया।

हम वास्तव में क्या मापेंगे?

सवाल वास्तव में सरल नहीं है, मैंने पिछली बार इसके बारे में लिखा था और शायद मैं इसे दोहराऊंगा। सामान्य "भोले" दृष्टिकोण, जब वे एन संदेश भेजते हैं, तो कुल समय को मापते हैं और एन द्वारा विभाजित करते हैं काम नहीं करता है । देखते हैं, हम कतार प्रदर्शन को मापते हैं, है ना? इसलिए, हम मान सकते हैं कि माप प्रक्रिया के दौरान संदेश जनरेटर और संदेश रिसीवर की गति अनंत तक जाती है , एक उचित धारणा के साथ कि डेटा को कतार के अंदर कॉपी नहीं किया जाता है, यह कतार में जितना संभव हो उतना डेटा रखने के लिए फायदेमंद होता है , फिर कुछ आंतरिक पॉइंटर का एक ही ट्रांसमिशन निष्पादित करें और यह डेटा पहले से ही है। । इस स्थिति में, संदेश के लिए औसत समय 1 / N (वास्तव में इन्सर्ट / डिलीट टाइम, जो कुछ नैनोसेकंड हो सकता है, नीचे से सीमित है) के रूप में गिर जाएगा, जबकि सिद्धांत में प्रत्येक संदेश का वितरण समय स्थिर रहता है, और यहां तक कि व्यवहार में O (N) के रूप में बढ़ता है। ।
इसके बजाय, मैं विपरीत दृष्टिकोण का उपयोग करता हूं - प्रत्येक संदेश भेजा जाता है, समय मापा जाता है, और उसके बाद ही अगला ( विलंबता ) भेजा जाता है। नतीजतन, परिणाम एक्स अक्ष - समय, वाई अक्ष के साथ - इस समय के दौरान वितरित पैकेट की संख्या के साथ, हिस्टोग्राम के रूप में प्रस्तुत किए जाते हैं। दो पैरामीटर सबसे दिलचस्प हैं - औसत औसत वितरण समय और संदेशों का प्रतिशत जो कुछ (मनमाना) ऊपरी सीमा में फिट नहीं हुआ।
कड़ाई से बोलते हुए, यह दृष्टिकोण भी पर्याप्त रूप से पर्याप्त नहीं है, हालांकि, यह प्रदर्शन की आवश्यकताओं का अधिक सटीक वर्णन करता है। मैं निष्कर्ष में थोड़ी आत्म-आलोचना करूंगा, जब तक कि मैं सिर्फ यह नहीं कहूंगा कि पूर्ण विवरण में सभी प्रकार के ट्रैफ़िक उत्पन्न करना और सांख्यिकीय विधियों के साथ इसका विश्लेषण करना शामिल है, मुझे क्यूए सिद्धांत के क्षेत्र से पूर्ण वैज्ञानिक काम मिलेगा, या मैं जल्द ही शिथिलता के एक और हमले को झेलूंगा।
एक और बिंदु, मैं इसका उल्लेख करता हूं क्योंकि पिछली बार एक लंबी बहस हुई थी, संदेश जनरेटर उन्हें कतार में मनमाने ढंग से जल्दी से सम्मिलित कर सकता है, लेकिन बशर्ते कि रिसीवर के पास औसतन उन्हें निकालने और संसाधित करने का समय है, अन्यथा पूरा माप केवल व्यर्थ है। यदि आपकी प्राप्त स्ट्रीम डेटा स्ट्रीम को संसाधित करने का प्रबंधन नहीं करती है, तो आपको कोड को तेज़ बनाने, प्रसंस्करण को समानांतर करने, संदेश प्रोटोकॉल को बदलने की आवश्यकता है, लेकिन किसी भी मामले में, कतार का खुद से कोई लेना-देना नहीं है। यह एक आसान विचार है, लेकिन पिछली बार टिप्पणियों में कई बार दोहराया जाना था। गति में उतार-चढ़ाव, जब अचानक कतार में बहुत सारे संदेश होते हैं, तो बहुत संभव है और यहां तक कि अपरिहार्य भी है, यह सिर्फ उन कारकों में से एक है जो एक अच्छी तरह से डिज़ाइन किए गए एल्गोरिथ्म को सुचारू करना चाहिए, लेकिन यह केवल तभी संभव है जब अधिकतम प्राप्त गति औसत भेजने की गति से अधिक हो।

से शुरू करें

यह क्या है? और यह वास्तव में परिणाम है, मेरे सभी काम एक तस्वीर में फिट होते हैं, लेकिन अब मैं लंबे समय तक समझाऊंगा कि यहां क्या और क्यों चित्रित किया गया है।

गुलाबी। मानक गियर डी

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

चित्रण के लिए कोड

import std.stdio, std.concurrency, std.datetime, core.thread; void main() { immutable int N=1000000; auto tid=spawn(&f, N); foreach(i; 0..N) { tid.send(thisTid, MonoTime.currTime.ticks); // wait for receiver to handle message receiveOnly!int(); } } void f(int n) { foreach(i; 0..n) { auto m=receiveOnly!(Tid,long)(); writeln(MonoTime.currTime.ticks-m[1]); // ask for the next message m[0].send(0); } }

ब्लू। भयंकर और निर्विवाद C ++।

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

बढ़ावा :: तालाबंदी

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

तो कारण के भीतर रहकर क्या किया जा सकता है?

लाल। उचित और संतुलित C ++।

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

यह सब निश्चित रूप से बिल्लियों की वजह से है

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

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

ग्रीन। स्केलेबिलिटी, स्केलेबिलिटी।

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

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

अलग तर्क, मामले में और बहुत नहीं।

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

यहीं पर मैंने धोखा दिया

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

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

स्टॉक में रेक की एक अपूर्ण सूची।

लिखने और पढ़ने का संतुलन बनाए रखें : यदि रीडिंग स्ट्रीम विफल हो जाती है, तो कोई एल्गोरिथ्म आपको नहीं बचाएगा। आप जो भी करना चाहते हैं उसे गति दें, लेकिन लाइन को दोष न दें।
संचयी मंदी : ऐसा होता है कि कुछ कार्यान्वयन के लिए कतार की गति इसमें संदेशों की संख्या पर निर्भर करती है, फिर गतिविधि का एक यादृच्छिक फट कतार को इतना धीमा कर सकता है कि यह अगले फटने तक मुक्त नहीं होता है, लगभग ट्रैफ़िक जाम की तरह। इस तरह की अस्थिरता परीक्षण के दौरान मॉडल करना मुश्किल है।
नाइट वॉचमैन सिंड्रोम : कभी-कभी संदेश बहुत कम ही आते हैं, एक घंटे या एक बार भी, ओएस के दृष्टिकोण से यह हमेशा एक अनंत काल होता है। अगर एक चौकीदार एक चौकीदार बैठता है और अलार्म की प्रतीक्षा करता है, लेकिन उसके पूरे जीवन में कभी कोई संकेत नहीं आया है, तो वह एक महत्वपूर्ण क्षण में क्या करेगा? सोते हुए इस तरह के सहज लड़ना मुश्किल है।
वितरण की पूंछ पर विचार करें : उपरोक्त परीक्षणों में, प्रति 1000 पर 2-3 संदेशों को लंबे समय तक अनौपचारिक रूप से संसाधित किया गया था, यह सभी सामान्य-उद्देश्य ऑपरेटिंग सिस्टम के लिए एक सामान्य विशेषता है। यदि आपको अचानक इस संख्या को कम करने की आवश्यकता है, तो आपको कड़ी मेहनत करनी होगी।
समर्पित सीपीयू पर भरोसा न करें : यह एक शक्तिशाली त्वरित कारक है, लेकिन पूरी तरह से स्केलेबल नहीं है। मेमोरी के विपरीत, एक सीपीयू एक महंगा संसाधन है। यहां तक कि अगर आपके सिस्टम में 100500 कोर हैं, तो निश्चित रूप से 100500 + 1 डेवलपर्स हैं जो अपने लिए एक चीज चाहते हैं
व्यक्तिगत उपयोग के लिए।
वही पीएम, जिसने एक साल पहले खुद को कतार में तेजी लाने के लिए कोर आरक्षित करने का प्रस्ताव दिया था, अब ईमानदारी से नीली आँखों से आत्मा को देखेंगे और कहेंगे, "सामने वाले लोग मेरे पास आए, कंपनी का लोगो उनके मुख्य पृष्ठ पर मुख्य पृष्ठ पर फिर से बनाया गया है। वे आपको उनमें से एक को आवंटित करने के लिए कहते हैं, आप समझते हैं - यह गंभीर है और हर कोई देख सकता है, यहां तक कि ग्राहक ने हाल ही में ध्यान दिया है। और आपका सर्वर पहले से ही काम कर रहा है, और कोई भी इसे वैसे भी नहीं देखता है। " यदि ऐसा होता है, तो मैं गहरी सांस लेने और धीरे-धीरे दस तक गिनने की सलाह देता हूं, अन्यथा विनाश और बलिदान अपरिहार्य हैं।
वहाँ बहुत कुछ है : लेकिन मैं भूल गया कि वास्तव में क्या है

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

धागे के बीच मैसेज करना। क्लासिक अवरुद्ध एल्गोरिदम